Goodbye EVM, hello RISC-V

Author: 0xjaehaerys, Chain Community

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 (as opposed to the ambiguous yellow paper) → enables rigorous verification,
Hardware proof paths (ASIC/FPGA) are already being tested (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 within 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 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 endgame is inevitable, and the argument is simple: Ethereum is rebuilding from the ground up based on zero-knowledge proofs. This represents the technical finish line of the protocol—restructuring.

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 restructuring 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 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 addressing.

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

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 ecosystem. 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 conference 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: More complex features can be added 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 many tools around the compiler, and compilers are very hard to build… so having this compiler toolchain is very valuable." RISC-V allows Ethereum to inherit this work for free.

Interpreter Overhead Issue

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 Issue

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 the current zkEVMs operate. They do not directly prove the EVM. Instead, they prove that the EVM's interpreter itself is compiled into 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 loss. 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.

Regarding 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 failure."

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 the precompile 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 priorities from a bygone era and is ill-suited for modern computing.

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 optimizations.

These combined factors—the ZK proof bottleneck, 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

The rationale for adopting RISC-V is not just about the shortcomings of the EVM; it is about the inherent advantages of the RISC-V design philosophy. Its architecture provides a robust, simple, and verifiable foundation that is 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 offers 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 explains, this provides instant 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 to various backends. RISC-V is one of the supported backends. So if you support RISC-V, you 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 rather than 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 Realm. Crucially, the zkVM ecosystem has already made its choice. As Justin Drake emphasizes, a clear pattern emerges from the data in Ethproofs:

“RISC-V is the leading ISA for zkVM backends.”

Out of 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 tested and validated through projects building their ZK future.

Designed for Trust, Not Just Execution

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

First, it has a formal, machine-readable specification known as SAIL. This is a significant improvement over the EVM specification, which primarily exists in prose documents (the yellow paper) that can be ambiguous. The SAIL specification serves as a "gold standard" that enables the mathematical proofs of correctness essential for protocols protecting significant value. As EF's Alex Hicks pointed out in the Ethproofs conference 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"). Cartesi's Diego 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 issue requests to a trusted kernel running in supervisor mode through special ECALL (environment call) instructions. This creates a hardware-enforced security boundary—a more robust and verifiable model than the purely 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 suggests, "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 undergo real-world testing on the mainnet in a low-risk environment, where the Ethereum client acts as an intermediary 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. A 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 legacy applications while allowing client developers to maintain only a minimal execution engine.

Chain Reactions Across the Ecosystem

The proposed transition from EVM to RISC-V goes far beyond the core protocol, having profound chain reactions throughout the entire Ethereum ecosystem. It is expected to reshape the developer experience, fundamentally change 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 differing 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 the 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 describes a future of "native rollups," where L2 is essentially a specialized instance of L1's 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 points 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-type experience, where you basically 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 decrease 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 10M TPS Roadmap, 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 already been demonstrated 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, hard-coded 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 explains:

“Your OP Stack rollup no longer needs to wait seven days for finality and withdrawals… now achieving one hour of 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 Reduces 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 points out, work is already underway to formally "verify zkVM RISC-V circuits according to 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, introducing RISC-V-based L1 brings 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 significant and underappreciated risk. The security model shifts from trusting the on-chain VM to trusting the off-chain compilers (e.g., LLVM) used by each developer. These compilers are highly complex and known to contain bugs. Attackers could exploit compiler bugs to generate malicious bytecode from seemingly benign source code. Furthermore, ensuring that the on-chain compiled binaries correspond exactly to specific public source code (the "reproducible build" issue) is very difficult, 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 bringing it into 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 conference 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 future of the network. It is not just an incremental upgrade but a fundamental re-architecture 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 significant 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 realizing the broader "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 domain 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 teams like Succinct Labs and their SP1 zkVM's practical implementation offer a viable blueprint for what this future looks like. By embracing RISC-V, Ethereum not only addresses its scalability bottlenecks; it also positions itself as the foundational trust layer for 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 ChainCatcher's job openings