Author: jaehaerys.eth
Compiled by: 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 a 50–800x performance slowdown.
Precompiled modules make the protocol complex and increase risk;
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 (compared to the vague yellow paper) → enables strict verification;
Hardware proof paths (ASICs/FPGAs) are already being tested (SP1, 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 (such as Polygon, zkSync, and Scroll) will gain significant advantages → cheaper, faster, and simpler.
Developers can use language libraries such as Rust, Go, and Python directly at the L1 layer;
Users will enjoy ~100x lower proof costs → leading to Gigagas L1 (~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-Snarked."
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 refactoring 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 "Lean Ethereum" vision.
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 for enhancing every layer of the protocol. However, this goal has long been more of a distant blueprint, as achieving it 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 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 exploring the “why,” we first need to clarify “what” is changing.
The EVM (Ethereum Virtual Machine), the runtime environment for Ethereum smart contracts, 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 extremely simple, consisting of only about 40 to 47 instructions. As Jeremy puts it, this makes it "almost perfect for the use case of a super minimalist general-purpose machine that we need."
- 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 imposing unnecessary complexity on the base protocol.
- Open Ecosystem: RISC-V has a large and mature toolchain, including the LLVM compiler, which enables developers to use mainstream programming languages such as Rust, C++, and Go. As Justin Drake mentioned, "The tooling around compilers is very rich, and compilers are extremely difficult to build... So having these compiler toolchains is extremely valuable." RISC-V allows Ethereum to inherit these ready-made 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 protocols.
Interpreter overhead problem
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 state 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 EVM execution to what ends up being RISC-V code, then why not just expose the underlying RISC-V to smart contract developers? That 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" 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 performance improvement.
The Technical Debt Trap
To address the EVM’s performance limitations for 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 using 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 explained, 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 high-level programming languages 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, making it easy for millions of developers familiar with languages such as Rust, C++, and Go to 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.
What’s more important is that the zkVM ecosystem has already made its choice. As Justin Drake points out, a clear trend can be seen from 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 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 exists primarily in textual form, 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 often overlooked but crucial to security. It defines distinct levels of operation, primarily user mode (for untrusted applications such as smart contracts) and supervisor mode (for trusted "execution kernels"). Cartesi's Diego explains 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 suggested, "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 will allow 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 be to "make the new VM directly accessible to users." Smart contracts will be able to indicate via a tag whether their bytecode is EVM or RISC-V. A key feature will be seamless interoperability: "the two types of contracts will be able to call each other." This functionality will be achieved through system calls (ECALLs), allowing the two 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 a simplified execution engine, significantly reducing complexity and maintenance costs.
Ripple effects in the ecosystem
The transition from EVM to RISC-V is more than just a core protocol change; it will have a profound impact on 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's 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 through 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 huge 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 actually becomes a specialized instance of L1's own execution environment, leveraging L1's built-in VM for seamless settlement. This alignment will bring the following changes:
Simplified technology stack: The L2 team will no longer need to build a complex bridge mechanism 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’s gas fees will more accurately reflect the actual cost of RISC-V-based ZK verification, thus forming 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 have 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." This shift to using mainstream programming languages and their vast library resources through the LLVM toolchain will be revolutionary. Vitalik likens it to a "NodeJS-like experience," where developers can 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," targeting approximately 10,000 TPS performance, paving the way for more complex and higher-value on-chain applications in the future.
Succinct Labs and SP1: Building for the Future 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 this proposal.
Succinct Labs' SP1, a high-performance, open-source zkVM based on RISC-V, demonstrates the feasibility of a new architectural approach. Adopting a "precompile-centric" philosophy, SP1 seamlessly addresses the cryptographic bottlenecks of the EVM. Unlike traditional precompile methods that rely on slow, hard-coded code, SP1 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 SP1 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 mathematical proof—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 “zkVM RISC-V circuits 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 horizons for blockchain security.
The main risks of transformation
Although the L1 of the RISC-V architecture has many advantages, it also brings new and complex challenges.
Gas metering problem
Creating a deterministic and fair gas model for common instruction set architectures (ISAs) is an unsolved problem. Simple instruction counting methods are susceptible 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 completely consistent with publicly available source code—the "reproducible build" problem—is extremely difficult. Minor differences in the build environment can result in different binaries, undermining 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 combination of RV64GC and a Linux-compatible ABI, as this combination boasts 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 improvement 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 common 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 its SP1 zkVM implementation, 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
