Goodbye EVM, hello RISC-V

Introduction

Ethereum is preparing for the most significant architectural shift since its launch: replacing the EVM with RISC-V. The reason is simple— in a ZK-first future, the EVM is a bottleneck:

Today's zkEVM relies on interpreters → slows down by 50-800 times,
Precompiles bloat the protocol due to complexity and risk,
The 256-bit stack design is extremely inefficient in proofs.

RISC-V addresses this issue:

Minimalism (about 47 basic instructions) + a mature LLVM ecosystem (Rust, C++, Go),
Already the de facto zkVM standard (9 out of 10 projects),
Formal SAIL specification (compared to the ambiguous yellow paper) → enables rigorous verification,
Hardware proof paths (ASIC/FPGA) are already in testing (SP1, Nervos, Cartesi).

The migration is divided into three phases:

RISC-V as a precompile alternative (low-risk testing).
Dual VM era: EVM + RISC-V, with full interoperability.
Reimplementing EVM internally in RISC-V (Rosetta strategy).

Ecosystem impact:

Optimistic Rollup collapse (Arbitrum/OP must rebuild fraud proofs).
ZK Rollup wins big (Polygon, zkSync, Scroll → cheaper, faster, simpler).
Developers gain access to Rust/Go/Python libraries directly on L1.
Users receive about 100 times cheaper proofs → paving the way to Gigagas L1 (around 10,000 TPS).

Ultimately, Ethereum evolves from a "smart contract VM" to a minimal, verifiable trust layer for the internet, where "the endpoint = ZK-snark everything."

Ethereum at a Crossroads

"The endpoint includes… ZK-snark everything." --- @VitalikButerin The ZK endgame is inevitable, and the argument is simple: Ethereum is rebuilding from the ground up on the foundation of zero-knowledge proofs. This represents the technical finish line of the protocol ------ a rearchitecture.

With this vision as the finish line, Ethereum is now on the threshold of the most significant architectural evolution since its launch. The discussion is no longer about incremental upgrades but a fundamental rearchitecture of its computational core: replacing the Ethereum Virtual Machine (EVM). This initiative is the cornerstone of the broader "(Lean Ethereum)" vision, which aims to systematically simplify the entire protocol, breaking it down into three core components: lean consensus, lean data, and lean execution. At the heart of lean execution is a critical question: Is the EVM (the engine powering the smart contract revolution) now the main bottleneck for Ethereum's future?

As Justin Drake from the Ethereum Foundation stated, the long-term goal has always been to "Snarkify everything," a powerful tool to enhance every layer of the protocol. For a long time, this felt somewhat like a "castle in the air because what we particularly needed was the concept of real-time proofs." Now that real-time proofs are becoming a reality, the theoretical inefficiency of the EVM has become a practical and urgent issue that needs to be addressed.

This analysis explores the compelling technical and strategic arguments for migrating Ethereum L1 to the RISC-V instruction set architecture (ISA), a move expected to unleash unprecedented scalability, simplify the protocol, and align Ethereum with the future of verifiable computation.

What Exactly is Changing?

Before delving into the "why," it is crucial to understand the "what."

The EVM is the runtime environment for smart contracts on Ethereum. It is the "world computer" that processes transactions and updates the blockchain state. Over the years, its design has been revolutionary, creating a permissionless platform that has spawned the entire DeFi and NFT ecosystems. However, its custom, nearly decade-old architecture now imposes a significant technical burden. On the other hand, RISC-V is not a product but an open standard— a free and universal "alphabet" for designing processors. As Jeremy Bruestle emphasized in the Ethproofs call, its key principles make it very suitable for this role:

Minimalism: The basic instruction set is very simple, containing only about 40-47 instructions. In Jeremy's words, this makes it "almost perfectly suited for the use cases of the super minimalist general-purpose machine we have."
Modularity: Adding more complex features through optional extensions. This is crucial as it allows a simple core to be expanded as needed without imposing unnecessary complexity on the base protocol.
Open ecosystem: It is supported by a wealth of mature toolchains, including the LLVM compiler, allowing developers to use mainstream languages like Rust, C++, and Go. As Justin Drake mentioned, "There are a lot of tools around the compiler, and the compiler is very hard to build… so having this compiler toolchain is very valuable." RISC-V allows Ethereum to inherit this work for free.

Interpreter Overhead Issues

The necessity of replacing the EVM is not driven by a single flaw but is the result of a series of fundamental limitations that have become impossible to ignore in the context of a ZK-native future. These issues include severe performance bottlenecks in ZK proof systems and the cumulative dangerous complexity within the protocol itself.

Interpreter Overhead Issues

The most pressing driver for this shift is the inherent inefficiency of the EVM in zero-knowledge proof systems. As Ethereum transitions to a model where ZK proofs validate L1 state, prover performance becomes the ultimate bottleneck.

"The virtual machine doesn't have to be complex." --- @VitalikButerin
For most people, the discussions around Vitalik's "long-term L1 execution layer proposal: replace EVM with RISC-V" sound like black magic. But what if it is actually simpler and affects everyone?

The problem lies in how current zkEVMs operate. They do not directly prove the EVM. Instead, they prove that the EVM's interpreter itself is compiled to RISC-V. Vitalik Buterin directly explained this fundamental issue:

"……If the implementation of zkVM is to execute EVM and compile it into something that ultimately becomes RISC-V code, then why not expose the underlying RISC-V directly to smart contract developers? This way, you can completely eliminate the overhead of the external layer of the entire virtual machine."

This additional layer of interpretation incurs a massive performance penalty. Estimates suggest that this leads to a slowdown of 50-800 times compared to proving native programs. After optimizing other bottlenecks like hashing (for example, by switching to Poseidon), this "block execution" portion will consume 80-90% of all proof time, making the EVM the ultimate and most powerful barrier to scaling L1. By eliminating this layer, Vitalik estimates that execution efficiency could improve by 100 times.

About the new @VitalikButerin blog post on replacing EVM with RISC-V in the long run. I really like this direction for Ethereum's execution layer. Nowadays, RISC-V zkVMs like SP1 are clearly the ultimate solution for "ZK-ifying" Ethereum and are rapidly becoming the de facto solution.

Precompile Debt Trap

To address the poor performance of the EVM in specific cryptographic operations, Ethereum introduced precompiled contracts—dedicated functions hardcoded into the protocol. While this was a pragmatic solution at the time, it has led to what Vitalik Buterin describes as a "terrible" situation:

"Precompiles are bad for us… they greatly bloat Ethereum's trusted codebase… they are responsible for our most serious near-misses in consensus failures."

The complexity is staggering. Vitalik illustrated this by comparing the wrapper code for a single precompiled modexp with the entire RISC-V interpreter—observing that the logic of precompiles is actually much more complex. Adding new precompiles requires a slow and politically contentious hard fork process, stifling innovation for applications that need new cryptographic primitives. This led Vitalik to a firm conclusion:

"I actually think we should pause any new precompiles starting today."

Ethereum's Architectural Technical Debt

The core design of the EVM reflects the priorities of a bygone era and is ill-suited for modern computation.

The 256-bit architecture was chosen for handling cryptographic values, which is extremely inefficient for most smart contract operations that typically use 32-bit or 64-bit integers. This inefficiency is particularly costly in ZK systems. As Vitalik explained:

"When you use smaller numbers, you actually don't gain any savings from each individual number, and the complexity increases by about two to four times."

Moreover, its stack-based architecture is less efficient than the register-based models of RISC-V and modern CPUs. It requires more instructions to perform the same operations and complicates compiler optimization.

These combined factors—ZK proof bottlenecks, the complexity of precompiles, and outdated architectural choices—create a compelling and urgent reason for Ethereum to move beyond the EVM.

RISC-V Blueprint—Building on a Stronger Foundation

Vitalik Buterin simplifies L1

The rationale for adopting RISC-V is not just about the shortcomings of the EVM; it is about the inherent advantages of RISC-V's design philosophy. Its architecture provides a robust, simple, and verifiable foundation, making it well-suited for high-risk environments like Ethereum.

Why Open Standards are Better than Custom Designs

Unlike custom ISAs that require building an entire software ecosystem from scratch, RISC-V is a mature open standard. This provides three key advantages:

Mature ecosystem. By adopting RISC-V, Ethereum can leverage decades of collective progress in the field of computer science. As Justin Drake explained, this provides immediate access to world-class tools:

"There is an infrastructure component called LLVM, which is a compiler toolchain that allows you to take high-level programming languages and compile them into various backends. RISC-V is one of the supported backends. So if you support RISC-V, you will automatically support all high-level languages enabled by LLVM."

This significantly lowers the entry barrier for millions of developers proficient in languages like Rust, C++, and Go.

Design simplicity. The minimalism of RISC-V is a deliberate feature, not a limitation. The basic instruction set contains only about 47 instructions, and the core of the virtual machine remains very simple. This simplicity is a huge advantage for security, as a smaller trusted codebase is easier to audit and formally verify.
Practical standardization in the ZK domain. Crucially, the zkVM ecosystem has already made choices. As Justin Drake emphasized, a clear pattern has emerged in the data from Ethproofs:

"RISC-V is the leading ISA for zkVM backends."

Of the ten zkVMs capable of proving Ethereum blocks, nine have already targeted RISC-V. This market convergence is a strong signal; by adopting RISC-V, Ethereum is not making a speculative bet but aligning with standards that have already been battle-tested and validated by projects building their ZK future.

Designed for Trust, Not Just Execution

Beyond its ecosystem, RISC-V's internal architecture is highly suitable for building secure and verifiable systems.

First, it has a formal, machine-readable specification called SAIL. This is a significant improvement over the EVM specification, which primarily exists in prose documentation (the yellow paper) that can be ambiguous. The SAIL specification serves as a "gold standard," enabling the correctness proofs essential for protocols protecting immense value. As Alex Hicks from the EF pointed out in the Ethproofs call, this allows for direct verification of zkVM circuits "according to the official RISC-V specification."

Second, RISC-V includes a privileged architecture, a frequently overlooked but crucial feature for security. It defines different levels of operation, primarily user mode (for untrusted applications like smart contracts) and supervisor mode (for trusted "execution kernels"). Diego from Cartesi explained its importance:

"The operating system itself must protect itself from other code. It needs to keep different programs running separately from each other, and all these mechanisms are part of the RISC-V standard."

In this model, smart contracts running in user mode cannot directly access the state of the blockchain. Instead, they must make requests to a trusted kernel running in supervisor mode via special ECALL (environment call) instructions. This creates a hardware-enforced security boundary—a more robust and verifiable model than the pure software sandbox model of the EVM.

Vitalik's Vision

The transition is envisioned as a gradual, multi-phase process to ensure stability and backward compatibility. This approach outlined by Vitalik Buterin aims for evolution rather than revolution.

Step 1: Precompile replacement. The first, most conservative step is to introduce the new VM in a limited capacity. As Vitalik suggested, "We first use the new VM in a limited way. For example, replacing precompiles." This would involve pausing new EVM precompiles and instead implementing any required functionality as whitelisted RISC-V programs. This allows the new VM to be tested in a low-risk environment on the mainnet.) interface, where the Ethereum client acts as a mediator between the two execution environments.
Step 2: Dual VM coexistence. The next phase will "make this new VM directly available to users." A flag can be used to deploy contracts, indicating whether their bytecode is EVM or RISC-V. The key feature is ensuring seamless interoperability: "Both types of contracts will be able to call each other." This will be achieved through system calls (ECALL).
Step 3: EVM as a simulated contract ("Rosetta" strategy). The ultimate goal is to achieve final protocol simplification. At this stage, "we make the EVM an implementation inside the new VM." The normative EVM will become a formally verified smart contract running on native RISC-V L1. This ensures permanent support for old applications while allowing client developers to maintain only a minimal execution engine.

Ripple Effects Across the Ecosystem

The proposed transition from EVM to RISC-V goes far beyond the core protocol, having profound ripple effects on the entire Ethereum ecosystem. It promises to reshape the developer experience, fundamentally alter the competitive landscape of Layer-2 solutions, and unlock new economic models for proofs.

Rollup Realignment: Optimistic vs. ZK

The shift of the execution layer on L1 to RISC-V will have profound and different impacts on the two main categories of Rollups.

Optimistic Rollups (Arbitrum, Optimism) face fundamental architectural challenges. Their security model is based on the ability to resolve fraud proofs by re-executing disputed transactions on L1 EVM. If the L1 EVM is replaced, the entire model collapses. These projects will face a stark choice: undertake significant engineering work to design a new fraud proof system for the new L1 VM or completely detach from Ethereum's security model.

In contrast, ZK Rollups gain a significant strategic advantage. The vast majority are already converging on RISC-V as their internal ISA. An L1 speaking the same language will enable tighter and more efficient integration. Justin Drake described a future of "native rollups," where L2 is essentially a specialized instance of L1's own execution environment, using the specified L1 VM for seamless settlement. This alignment will:

Simplify the tech stack: L2 teams will no longer need to bridge the complex gap between their internal RISC-V execution and the EVM.
Enable tool and code reuse: Compilers, debuggers, and formal verification tools developed for the L1 RISC-V environment can be directly reused by L2.
Adjust economic incentives: L1 gas costs will more accurately reflect the actual costs of ZK proof RISC-V execution, creating a more rational economic model.

A New Era for Developers and Users

For those building on Ethereum, the transition is expected to be evolutionary rather than disruptive.

For developers, the key benefit is access to a broader and more mature software development world. As Vitalik Buterin pointed out, developers will "be able to write contracts in Rust, and these two options will begin to coexist." Meanwhile, he predicts that "due to the elegance of Solidity and Vyper for smart contract logic, they will continue to be popular for a long time." The ability to use mainstream languages and their vast libraries through the LLVM toolchain is a transformative shift. It opens the door to what he describes as a "NodeJS-like experience, where you essentially use the same language to write on-chain code as you do to write off-chain code."
For users, the ultimate payoff is a cheaper, more powerful network. Proof costs are expected to drop by about 100 times—from several dollars per transaction to a few cents—directly translating to lower fees for L1 and L2 settlements. This economic viability unlocks the "Gigagas L1" vision, aiming for around 10,000 TPS on L1, paving the way for more complex and higher-value on-chain applications.

ETH zkEVM-L1 100x scaling: Ethereum reveals its roadmap to 10M TPS, how real-time ZK proofs unlock Ethereum's Teragas vision execution.

Succinct Labs and SP1: Proving the Future, Here Today

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

The theoretical advantages of RISC-V have been validated in practice by teams like Succinct Labs. Their work serves as a powerful case study for the entire proposal.

Succinct's SP1 is a high-performance open-source zkVM built on RISC-V that validates the new architectural approach. Its "precompile-centric" philosophy perfectly illustrates how to address the cryptographic bottlenecks of the EVM. SP1 does not rely on slow, hardcoded precompiles but instead offloads intensive operations like Keccak hashing to specially optimized ZK circuits called via standard ECALL instructions. This provides the performance of custom hardware with the flexibility of software.

@SuccinctLabs SP1 Hypercube real-time Ethereum proofs are here.

The practical impact is already visible. OP Succinct products use SP1 to "ZK-ify" Optimistic Rollup. As Succinct co-founder Uma Roy explained:

"Your OP Stack rollup no longer needs to wait seven days for finality and withdrawals… now achieving one-hour finality. Its finality is faster, which is fantastic."

This addresses a major pain point for the entire OP Stack ecosystem. Additionally, Succinct's infrastructure—the Succinct Prover Network—is designed as a decentralized marketplace for proof generation, showcasing a viable economic model for verifiable computation. Their work is not just a proof of concept; it is a feasible blueprint for the future described in this article.

How Ethereum Mitigates Risk

A key advantage of RISC-V is that it makes formal verification (the mathematical proof of a system's correctness) a realizable goal. The EVM is specified in natural language in the yellow paper, making it difficult to formalize. In contrast, RISC-V has an official, machine-readable SAIL specification that provides a clear "golden reference" for its behavior.

This offers a clear path to achieving stronger security. As Alex Hicks from the Ethereum Foundation pointed out, formal work is already underway to "verify zkVM RISC-V circuits based on the official RISC-V specification extracted into Lean." This is a significant advancement, shifting trust from error-prone human implementations to verifiable mathematical proofs.

Major Risks of the Transition

Despite the advantages of RISC-V, a RISC-V-based L1 introduces new and daunting challenges.

Gas metering. Creating a deterministic and fair gas model for a general-purpose ISA is one of the hardest problems to solve. A simple instruction count is easily susceptible to denial-of-service attacks (for example, an attacker could create a program that repeatedly misses the cache, leading to high resource usage at very low gas costs).
Toolchain security and reproducible build issues. This may be the most important and underappreciated risk. The security model shifts from trusting the on-chain VM to trusting the off-chain compilers (like LLVM) used by every developer. These compilers are highly complex and known to contain bugs. An attacker could exploit compiler bugs to generate malicious bytecode from seemingly benign source code. Additionally, ensuring that on-chain compiled binaries correspond exactly to specific public source code (the "reproducible build" problem) is very challenging, as minor differences in the build environment can produce different binaries.

Mitigation Strategies

The path forward requires a multi-layered defense strategy.

Phased rollout. A gradual, multi-phase transition plan is the primary risk mitigation strategy. By first introducing RISC-V as a precompile replacement and then introducing it in a dual VM environment, the community can gain operational experience and build confidence in a low-risk environment before making any irreversible changes.
Comprehensive audits: fuzz testing and formal methods. While formal verification provides the ultimate goal, it must be supplemented with ongoing, proactive testing. As Valentine from Diligence Security demonstrated in the Ethproofs call, their Argus fuzzer has already discovered 11 critical reliability and integrity bugs in leading zkVMs. This proves that even the most well-designed systems have vulnerabilities that can only be uncovered through rigorous adversarial testing.
Standardization. To avoid ecosystem fragmentation, it is crucial for the community to converge on a single standard RISC-V profile. This is likely to be RV64GC with a Linux-compatible ABI, as this combination provides the broadest support for mainstream languages and tools, maximizing the benefits of the new ecosystem.

Dawn of a Verifiable Future

The proposal to replace the Ethereum Virtual Machine with RISC-V represents a key and bold vision for the network's future. It is not just an incremental upgrade but a fundamental rearchitecture of Ethereum's execution layer, aimed at addressing deep-rooted scalability bottlenecks, simplifying protocol complexity, and aligning the platform with the broader world of general-purpose computing. While this path is fraught with significant technical and social challenges, the long-term strategic benefits are sufficient to justify this ambitious endeavor.

The transition hinges on a set of core trade-offs: the massive performance gains of a ZK-native architecture versus the critical need for backward compatibility; the security advantages of a simpler protocol versus the inertia of the EVM's vast network effects; and the power of a general ecosystem versus the risks of relying on complex third-party toolchains.

Ultimately, this architectural shift is key to fulfilling the "Lean Ethereum" vision's commitment to "lean execution." It will transform L1 from a simple smart contract platform into an efficient and secure settlement and data availability layer, specifically designed to support the realm of verifiable computation. The journey is long, but the direction is clear. As Vitalik Buterin stated, the ultimate goal is:

"The endpoint includes… ZK-snark everything."

Initiatives like Ethproofs provide the objective data and collaborative forums necessary to navigate this path, while the practical implementation of teams like Succinct Labs and their SP1 zkVM offers a viable blueprint for what this future looks like. By embracing RISC-V, Ethereum not only addresses its scalability bottlenecks; it positions itself as the foundational trust layer of the next generation of the internet, supported by the third great cryptographic primitive after hashes and signatures: SNARK.

Proving the software of the world.

Click to learn about job openings at ChainCatcher