Goodbye EVM, Hello RISC-V

Original author: jaehaerys.eth, crypto researcher

Original translation: TechFlow

summary

Ethereum is preparing for its most important architectural transformation since its inception: replacing EVM with RISC-V.

The reason is simple — in a future centered around zero-knowledge (ZK), the EVM has become a performance bottleneck:

The current zkEVM relies on an interpreter, resulting in 50–800x performance slowdowns.

Precompiled modules make the protocol complex and risky;

The 256-bit stack design is extremely inefficient at generating proofs.

RISC-V’s solution:

Minimalist design (about 47 basic instructions) + mature LLVM ecosystem (supports Rust, C++, Go, etc.);

Has become the de facto zkVM standard (adopted by 90% of projects);

Has a formal SAIL specification (vs. the vague yellow paper) → enables rigorous verification;

Hardware proof paths (ASICs/FPGAs) are already being tested (SP 1, Nervos, Cartesi, etc.).

The migration process is divided into three phases:

Replace RISC-V as a precompiled module (low-risk testing);

Dual virtual machine era: EVM and RISC-V coexist and are fully interoperable;

Reimplementing the EVM in RISC-V (Rosetta strategy).

Ecosystem impacts:

Optimistic Rollups (such as Arbitrum and Optimism) need to rebuild their fraud proof mechanisms;

Zero-knowledge Rollups (e.g., Polygon, zkSync, Scroll) will gain significant advantages → cheaper, faster, and simpler.

Developers can use language libraries such as Rust, Go, and Python directly at L1.

Users will enjoy ~100x lower proof costs → leading to Gigagas L 1 (~10,000 TPS).

Ultimately, Ethereum will evolve from a "smart contract virtual machine" to a minimalist, verifiable trust layer for the Internet, with the ultimate goal of "making everything ZK-Snarkized."

Ethereum at a Crossroads

Vitalik Buterin once said, “The end point involves… making everything ZK-Snarked.”

The endgame of zero-knowledge (ZK) proofs is inevitable, and the core argument is simple: Ethereum is rebuilding itself from scratch, built on top of zero-knowledge proofs. This marks the technical end point of the protocol—reaching its final form through a reconstruction of Layer 1, powered by a high-performance zkVM backed by core developers like Succinct.

With this vision in mind, Ethereum is at the cusp of its most significant architectural transformation since its inception. The discussion is no longer about incremental upgrades, but rather a complete rebuild of its computing core—replacing the Ethereum Virtual Machine (EVM). This initiative is the cornerstone of the broader vision of "Lean Ethereum."

The Lean Ethereum vision aims to systematically simplify the entire protocol, breaking it down into three core modules: Lean Consensus, Lean Data, and Lean Execution. A key question at the heart of Lean Execution is whether the EVM, the engine driving the smart contract revolution, has become a major bottleneck for Ethereum's future development.

As Justin Drake of the Ethereum Foundation has stated, Ethereum's long-term goal has always been to "Snarkify everything," a powerful tool that could enhance every layer of the protocol. However, this goal has long been more of a distant blueprint, as its realization requires the concept of real-time proving. Now, with real-time proving becoming a reality, the theoretical inefficiencies of the EVM have become a practical problem that needs to be addressed.

This article will delve into the technical and strategic arguments for migrating Ethereum’s Layer 1 protocol to the RISC-V instruction set architecture (ISA). This move promises not only to unlock unprecedented scalability but also to simplify the protocol structure and align Ethereum with the future of verifiable computation.

What exactly has changed?

Before discussing the “why”, we first need to clarify “what” is changing.

The EVM (Ethereum Virtual Machine) is the runtime environment for Ethereum smart contracts and has been called the "world computer" that processes transactions and updates the blockchain's state. Over the years, its design has been revolutionary, laying the foundation for the emergence of decentralized finance (DeFi) and the NFT ecosystem. However, this nearly decade-old custom architecture has accumulated a significant amount of technical debt.

In contrast, RISC-V is not a product but an open standard—a free, universal “alphabet” for processor designs. As Jeremy Bruestle emphasized at the Ethproofs conference, its key principles make it an excellent choice for this role:

Minimalism: RISC-V’s base instruction set is incredibly simple, consisting of only about 40 to 47 instructions. As Jeremy puts it, this makes it “almost perfect for the use case we need of a super minimalist general-purpose machine.”

Modular design: More complex functionality is added through optional extensions. This feature is crucial because it allows the core to remain simple while expanding functionality as needed without forcing unnecessary complexity into the base protocol.

Open Ecosystem: RISC-V has a large and mature toolchain, including the LLVM compiler, enabling developers to use mainstream programming languages like Rust, C++, and Go. As Justin Drake noted, "The tooling around compilers is very rich, and compilers are incredibly difficult to build... so having these compiler toolchains is incredibly valuable." RISC-V allows Ethereum to inherit these existing tools for free.

Interpreter overhead problem

The impetus for replacing the EVM isn’t a single flaw, but rather a confluence of fundamental limitations that are impossible to ignore in the context of a future centered around zero-knowledge proofs. These limitations include performance bottlenecks within zero-knowledge proof systems and the risks posed by the increasing complexity accumulating within the protocol.

The most pressing driver of this transition is the inherent inefficiency of the EVM in zero-knowledge proof systems. As Ethereum gradually shifts to a model that verifies L1 states through ZK proofs, prover performance becomes the biggest bottleneck.

The problem lies in the way zkEVM currently works. They don’t perform zero-knowledge proofs directly on the EVM, but rather on the EVM interpreter, which itself is compiled to RISC-V. Vitalik Buterin bluntly identified this core issue:

“…if the zkVM implementation is to compile the EVM execution to what ends up being RISC-V code, then why not just expose the underlying RISC-V to smart contract developers? This would completely eliminate the overhead of the entire external VM.”

This additional layer of interpretation comes with a significant performance penalty. Estimates suggest this layer could result in a 50x to 800x performance degradation compared to proving native programs. Even after optimizing other bottlenecks (such as by switching to the Poseidon hashing algorithm), this "block execution" portion still accounts for 80-90% of all proving time, making the EVM the final and most intractable obstacle to scaling L1. By removing this layer, Vitalik anticipates a potential 100x improvement in execution efficiency.

The Technical Debt Trap

To compensate for the EVM’s performance limitations in certain cryptographic operations, Ethereum introduced precompiled contracts—dedicated functions hard-coded directly into the protocol. While this solution seemed pragmatic at the time, it now leads to what Vitalik Buterin calls a “bad” situation:

“Precompiles have been disastrous for us… They’ve massively bloated the trusted codebase of Ethereum… and they’ve caused us several serious issues where we almost had consensus failures.”

This complexity is staggering. Vitalik, for example, illustrates that the wrapper code for a single precompiled contract (such as modexp) is more complex than the entire RISC-V interpreter, and the precompiled logic is even more cumbersome. Adding new precompiled contracts requires a slow and politically contentious hard fork process, which severely hinders innovation in applications requiring new cryptographic primitives. Vitalik draws a clear conclusion:

“I think we should stop adding any new precompiled contracts starting today.”

Ethereum's architectural technical debt

The EVM's core design reflects the priorities of a bygone era, but it's no longer suitable for modern computing needs. The EVM chose a 256-bit architecture to handle cryptographic values, but this architecture is extremely inefficient for the 32-bit or 64-bit integers commonly used in smart contracts. This inefficiency is particularly costly in ZK systems. As Vitalik explained:

“When you use smaller numbers, you don’t actually save any resources per digit, and the complexity increases by a factor of two to four.”

In addition, the EVM's stack architecture is less efficient than the register architecture of RISC-V and modern CPUs. It requires more instructions to complete the same operation and also makes compiler optimization more complicated.

These issues—including performance bottlenecks in ZK proofs, the complexity of precompiles, and outdated architectural choices—taken together form a compelling and urgent reason: Ethereum must move beyond the EVM and embrace a more future-proof technology architecture.

RISC-V Blueprint: Reshaping the Future of Ethereum with a Stronger Foundation

RISC-V's strength lies not only in addressing the shortcomings of the EVM, but also in the inherent strength of its design philosophy. Its architecture provides a robust, simple, and verifiable foundation, making it well-suited for high-stakes environments like Ethereum.

Why are open standards better than custom designs?

Unlike custom instruction set architectures (ISAs) that require building an entire software ecosystem from scratch, RISC-V is a mature open standard with three key advantages:

Mature ecosystem

By adopting RISC-V, Ethereum is able to leverage decades of collective progress in computer science. As Justin Drake explains, this provides Ethereum with direct access to world-class tools:

“There’s an infrastructure component called LLVM, which is a compiler toolchain that allows you to compile a high-level programming language to one of a variety of back-end targets. One of the supported back-ends is RISC-V. So if you support RISC-V, you automatically support all the high-level languages that LLVM supports.”

This greatly lowers the development threshold, allowing millions of developers familiar with languages such as Rust, C++, and Go to easily get started.

RISC-V's minimalism is a deliberate feature, not a limitation. Its base instruction set consists of only approximately 47 instructions, keeping the core of the virtual machine extremely simple. This simplicity offers significant security advantages, as a smaller trusted code base makes auditing and formal verification easier.

More importantly , the zkVM ecosystem has already made its choice. As Justin Drake points out, a clear trend can be seen in the Ethproofs data:

“RISC-V is the leading instruction set architecture (ISA) for the zkVM backend.”

Of the ten zkVMs capable of proving Ethereum blocks, nine have chosen RISC-V as their target architecture. This market convergence sends a strong signal that Ethereum is not engaging in speculative experimentation by adopting RISC-V, but rather aligning with a proven standard recognized by the projects building their zero-knowledge future.

Born for trust, not just execution

In addition to its extensive ecosystem, RISC-V's internal architecture is also uniquely suited for building secure and verifiable systems. First, RISC-V boasts a formalized, machine-readable specification—SAIL. This represents a significant improvement over the EVM specification, which primarily exists in textual form in the Yellow Paper. While the Yellow Paper is somewhat ambiguous, the SAIL specification provides a "gold standard" capable of supporting critical mathematical correctness proofs, essential for securing high-value protocols. As Alex Hicks of the Ethereum Foundation (EF) noted at the Ethproofs conference, this allows zkVM circuits to be directly "verified against the official RISC-V specification." Second, RISC-V includes a privileged architecture, a feature that is often overlooked but crucial to security. It defines different levels of operation, primarily user mode (for untrusted applications such as smart contracts) and supervisor mode (for trusted "execution kernels"). Cartesi's Diego explained this in depth:

“The operating system itself has to protect itself from other code. It needs to isolate different program executions from each other, and all of these mechanisms are part of the RISC-V standard.”

In the RISC-V architecture, smart contracts running in user mode cannot directly access the blockchain state. Instead, they must issue requests to the trusted kernel running in supervisor mode through a special ECALL (environment call) instruction. This mechanism establishes a hardware-enforced security boundary that is more robust and easier to verify than the EVM's pure reliance on software sandboxing.

Vitalik’s Vision

This transition is envisioned as a gradual, multi-stage process to ensure system stability and backward compatibility. As Ethereum founder Vitalik Buterin has explained, this approach aims for an “evolutionary” development rather than a radical “revolutionary” change.

Step 1: Precompile Alternatives

The initial phase will take a conservative approach, introducing limited functionality for the new virtual machine (VM). As Vitalik Buterin suggests, "We can start with limited use cases for the new VM, such as replacing precompiled functionality." Specifically, this will pause the introduction of new EVM precompiled functionality and instead implement required functionality through whitelisted, approved RISC-V programs. This approach allows the new VM to be field-tested in a low-risk environment on mainnet, while the Ethereum client acts as an intermediary between the two execution environments.

Step 2: Dual virtual machines coexist

The next phase will involve making the new VM directly accessible to users. Smart contracts will be able to use a tag to indicate whether their bytecode is EVM or RISC-V. A key feature will be seamless interoperability: contracts of both types will be able to call each other. This functionality will be achieved through system calls (ECALLs), enabling both virtual machines to collaborate within the same ecosystem.

Step 3: EVM as a simulated contract (Rosetta strategy)

The ultimate goal is to achieve a radically simplified protocol. At this stage, "we will implement the EVM as an implementation within the new VM." The standardized EVM will be a formally verified smart contract running on native RISC-V L1. This not only ensures permanent support for legacy applications but also allows client developers to maintain only a simplified execution engine, significantly reducing complexity and maintenance costs.

Ripple effects in the ecosystem

The transition from the EVM to RISC-V is more than just a core protocol change; it will have profound implications for the entire Ethereum ecosystem. This transformation will not only reshape the developer experience, but will also fundamentally alter the competitive landscape for Layer-2 solutions and unlock new economic proof-of-stake models.

Rollup Repositioning: Optimistic vs. ZK

Adopting the RISC-V execution layer at L1 will have distinct impacts on the two main types of Rollups.

Optimistic Rollups (such as Arbitrum and Optimism) face architectural challenges. Their security model relies on resolving fraud proofs by re-executing disputed transactions using the L1 EVM. This model would completely break down if the L1 EVM were replaced. These projects would face a difficult choice: either undertake a major engineering overhaul to design a fraud proof system specific to the new L1 VM, or completely decouple from Ethereum's security model.

In contrast, ZK Rollup will gain a significant strategic advantage. The vast majority of ZK Rollups already use RISC-V as their internal instruction set architecture (ISA). An L1 that "speaks the same language" will enable tighter and more efficient integration. Justin Drake proposed a future vision of "native Rollup": L2 effectively becomes a specialized instance of L1's own execution environment, leveraging L1's built-in VM for seamless settlement. This alignment will bring about the following changes:

Technology stack simplification: L2 teams will no longer need to build complex bridge mechanisms between the internal RISC-V execution environment and the EVM.

Tool and code reuse: Compilers, debuggers, and formal verification tools developed for the L1 RISC-V environment can be directly used by L2, significantly reducing development costs.

Economic incentive alignment: L1 gas fees will more accurately reflect the actual cost of RISC-V-based ZK verification, leading to a more reasonable economic model.

A new era for developers and users

For Ethereum developers, this transition will be gradual rather than disruptive.

Developers will gain access to a broader and more mature software development ecosystem. As Vitalik Buterin noted, developers will be able to "write contracts in Rust, and these options can coexist." At the same time, he predicts that "Solidity and Vyper will continue to be popular due to their elegant design for smart contract logic." The shift to mainstream programming languages and their vast library resources through the LLVM toolchain will be revolutionary. Vitalik likened it to a "NodeJS-like experience," allowing developers to write both on-chain and off-chain code in the same language, achieving unified development.

For users, this transformation will ultimately result in a lower-cost, higher-performance network experience. Proofing costs are expected to decrease by approximately 100x, from a few dollars per transaction to pennies or less. This translates directly into lower L1 fees and L2 settlement fees. This economic feasibility will unlock the vision of "Gigagas L1," aiming for approximately 10,000 TPS performance, paving the way for more complex and higher-value on-chain applications in the future.

Succinct Labs and SP 1: Building Future-Proof Today

Ethereum is poised for growth. "Scaling L1, scaling blocks" is a strategic imperative within the EF Protocol Cluster. Significant performance improvements are expected over the next 6 to 12 months.

https://blog.ethereum.org/2025/07/31/lean-ethereum

Teams like Succinct Labs have demonstrated RISC-V's theoretical advantages in practice, and their work makes a strong case for validating the proposal.

Developed by Succinct Labs, SP 1 is a high-performance, open-source zkVM based on RISC-V that demonstrates the feasibility of a new architectural approach. SP 1 employs a "precompile-centric" philosophy, effectively addressing the cryptographic bottlenecks of the EVM. Unlike traditional approaches that rely on slow, hard-coded precompilation, SP 1 offloads intensive operations such as Keccak hashing to specially designed, hand-optimized ZK circuits, invoked via standard ECALL instructions. This approach combines the performance of custom hardware with the flexibility of software, providing developers with a more efficient and scalable solution.

Succinct Labs is already seeing real-world impact. Their OP Succinct product leverages SP 1 to ZK-ify Optimistic Rollups. As Succinct co-founder Uma Roy explained:

“With OP Stack’s Rollup, you no longer have to wait seven days for final confirmation and withdrawals… Now it takes only one hour to complete confirmation. This speed improvement is amazing.”

This breakthrough addresses a key pain point for the entire OP Stack ecosystem. Furthermore, Succinct's infrastructure—the Succinct Prover Network—is designed as a decentralized proof generation market, demonstrating a viable economic model for the future of verifiable computation. Their work is not just a proof of concept, but a practical blueprint for the future, as described in this article.

How Ethereum reduces risk

One of RISC-V's strengths is that it makes the holy grail of formal verification—proving a system's correctness through mathematics—an achievable goal. The EVM specification, written in natural language in Yellow Paper, is difficult to formalize. RISC-V, on the other hand, has an official, machine-readable SAIL specification, providing a clear "golden reference" for its behavior.

This paves the way for even stronger security. As Alex Hicks of the Ethereum Foundation noted, work is already underway to extract the zkVM RISC-V circuitry and the official RISC-V specification into Lean for formal verification. This is a milestone development, shifting trust from fallible human implementations to verifiable mathematical proofs, opening up new heights of blockchain security.

The main risks of transformation

Although L1 of the RISC-V architecture has many advantages, it also brings new and complex challenges.

Gas metering issues

Creating a deterministic and fair gas model for common instruction set architectures (ISAs) is an unsolved problem. Simple instruction counting methods are vulnerable to denial-of-service attacks. For example, an attacker could design a program to repeatedly trigger cache misses, resulting in high resource consumption with extremely low gas fees. This poses a serious challenge to network stability and economic models.

Toolchain security and the issue of "reproducible builds"

This is the most significant and often underestimated risk in this transition. The security model shifts from relying on on-chain virtual machines to relying on off-chain compilers (such as LLVM), which are extremely complex and known to contain vulnerabilities. Attackers could exploit compiler vulnerabilities to convert seemingly harmless source code into malicious bytecode. Furthermore, ensuring that compiled binaries on-chain are fully consistent with publicly available source code—the "reproducible build" problem—is extremely difficult. Minor differences in the build environment can result in different binaries, compromising transparency and trust. These issues pose a severe challenge to the security of developers and users.

Mitigation strategies

The path forward requires a multi-layered defense strategy.

Phased rollout

A gradual, multi-phased transition plan is a core strategy for mitigating risk. By first introducing RISC-V as a precompiled alternative and then running it in a dual-VM environment, the community can gain operational experience and build confidence in a low-risk environment, avoiding any irreversible changes. This incremental approach provides a stable foundation for technological transformation.

Comprehensive Audit: Fuzz Testing and Formal Verification

While formal verification is the ultimate goal, it must be combined with ongoing, rigorous testing. As Diligence Security's Valentine demonstrated during the Ethproofs call, their Argus fuzz testing tool has discovered 11 critical soundness and integrity vulnerabilities in leading zkVMs. This demonstrates that even the most well-designed systems can harbor vulnerabilities that can only be discovered through rigorous adversarial testing. Combining fuzz testing with formal verification provides a stronger guarantee for system security.

standardization

To avoid ecosystem fragmentation, the community needs to unify around a single, standardized RISC-V configuration. This will likely be the RV64 GC with a Linux-compatible ABI, as this combination has the broadest support among mainstream programming languages and tools, maximizing the benefits of the new ecosystem. Standardization not only improves developer efficiency but also lays a solid foundation for the long-term growth of the ecosystem.

Ethereum’s Verifiable Future

The proposal to replace the Ethereum Virtual Machine (EVM) with RISC-V is more than just an incremental upgrade; it represents a fundamental restructuring of Ethereum's execution layer. This ambitious vision aims to address deep scalability bottlenecks, simplify protocol complexity, and align the platform with the broader ecosystem of general-purpose computing. While this transition presents significant technical and societal challenges, the long-term strategic benefits justify this bold endeavor.

This transformation focuses on a series of core trade-offs:

The balance between the huge performance improvements brought by ZK-native architecture and the urgent need for backward compatibility;

The trade-off between the security benefits of protocol simplification and the inertia of the EVM’s massive network effects;

The choice between the power of a general-purpose ecosystem and the risks of relying on complex third-party toolchains.

Ultimately, this architectural transformation will be key to delivering on the promise of Lean Execution and a crucial component of the Lean Ethereum vision. It transforms Ethereum’s Layer 1 from a simple smart contract platform into an efficient and secure settlement and data availability layer designed to support the vast universe of verifiable computation.

As Vitalik Buterin put it, “The end point is… to provide ZK-snarks for everything.”

Projects like Ethproofs provide objective data and a collaborative platform for this transformation, while the Succinct Labs team, through the practical application of its SP 1 zkVM, offers an actionable blueprint for this future. By embracing RISC-V, Ethereum not only resolves its own scalability bottlenecks but also positions itself as the foundational trust layer for the next-generation internet—powered by SNARKs, the third most important cryptographic primitive after hashing and signatures.

World-proof software, ushering in a new era of encryption.

learn more:

Vitalik’s interpretation: Click to watch

ETHProofs 4th discussion: Click to watch

Original link