Technical debt piling up, Ethereum chooses to "start over" with RISC-V

Author: jaehaerys.eth

Translation: TechFlow

Summary

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

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

• Current zkEVMs rely on interpreters, causing 50–800x performance slowdown;

• Precompiles make the protocol more complex and riskier;

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

RISC-V’s solutions:

• Minimalist design (~47 base instructions) + mature LLVM ecosystem (supporting Rust, C++, Go, etc.);

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

• Features a formal SAIL specification (vs. the ambiguous Yellow Paper) → enables rigorous verification;

• Hardware proof paths (ASICs/FPGAs) are already under testing (SP1, Nervos, Cartesi, etc.).

The migration will occur in three phases:

1. Replace EVM with RISC-V as a precompile (low-risk test);

2. Era of dual virtual machines: EVM and RISC-V coexist with full interoperability;

3. Re-implement EVM within RISC-V (Rosetta strategy).

Ecosystem impact:

• Optimistic Rollups (e.g., Arbitrum and Optimism) must rebuild fraud-proof mechanisms;

• ZK Rollups (e.g., Polygon, zkSync, Scroll) gain massive advantages → cheaper, faster, simpler;

• Developers can directly use language libraries like Rust, Go, and Python at L1;

• Users enjoy ~100x cheaper proving costs → paving the way to Gigagas L1 (~10,000 TPS).

Ultimately, Ethereum will evolve from a “smart contract virtual machine” into a minimal, verifiable trust layer for the internet, with the ultimate goal of “zk-snarkifying everything.”

Ethereum at a Crossroads

Vitalik Buterin once said: “The endgame includes… zk-snarkifying everything.”

The inevitable conclusion of zero-knowledge proofs (ZK) is clear: Ethereum is rebuilding itself from scratch, with ZK at its core. This marks the technical endgame of the protocol — achieving its final form through restructuring L1, driven by high-performance zkVMs supported by core development teams like Succinct.

With this vision as the endpoint, Ethereum stands at the most critical architectural turning point since its inception. The discussion is no longer about incremental upgrades but a complete overhaul of its computational core — replacing the Ethereum Virtual Machine (EVM). This move is foundational to the broader “Lean Ethereum” vision.

The Lean Ethereum vision aims to systematically simplify the entire protocol by breaking it into three core modules: Lean Consensus, Lean Data, and Lean Execution. Within Lean Execution, the central question is: Has the EVM, the engine that powered the smart contract revolution, become the main bottleneck for Ethereum’s future?

As Justin Drake of the Ethereum Foundation noted, Ethereum’s long-term goal has always been to “snarkify everything,” a powerful tool capable of strengthening every layer of the protocol. However, for years this goal felt like an “unreachable blueprint,” because achieving it required real-time proving. Now, as real-time proving becomes feasible, the theoretical inefficiency of the EVM has turned into an urgent practical problem.

This article will analyze the technical and strategic arguments for migrating Ethereum L1 to the RISC-V instruction set architecture (ISA). This step promises unprecedented scalability, simplifies the protocol, and aligns Ethereum with the future of verifiable computing.

What Exactly Is Changing?

Before discussing “why,” we must first clarify “what” is changing.

The EVM (Ethereum Virtual Machine) is the execution environment for Ethereum smart contracts, often called the “world computer” that processes transactions and updates blockchain state. For years, its design was revolutionary, laying the foundation for DeFi and NFT ecosystems. Yet, this nearly decade-old custom architecture has accumulated significant technical debt.

In contrast, RISC-V is not a product but an open standard — a free, universal processor design “alphabet.” As Jeremy Bruestle emphasized at Ethproofs, its key principles make it an ideal fit:

• Minimalism: RISC-V’s base instruction set is extremely simple, containing only about 40–47 instructions. As Jeremy put it, this makes it “almost perfectly suited for our use case of a super-minimal general-purpose machine.”

• Modular Design: More complex features are added via optional extensions. This is crucial because it keeps the core simple while allowing functionality to scale without imposing unnecessary complexity on the base protocol.

• Open Ecosystem: RISC-V enjoys robust, mature toolchain support, including the LLVM compiler, enabling developers to use mainstream languages like Rust, C++, and Go. As Justin Drake noted: “The tooling around compilers is incredibly rich, and building compilers is extremely hard… so having access to these toolchains is immensely valuable.” RISC-V allows Ethereum to freely inherit these ready-made tools.

The Interpreter Overhead Problem

The push to replace the EVM stems not from a single flaw, but from a convergence of fundamental limitations that can no longer be ignored in a ZK-centric future. These include performance bottlenecks within ZK systems and growing internal protocol complexity that increases risk.

The Interpreter Overhead Problem

The most urgent driver of this transition is the inherent inefficiency of the EVM within zero-knowledge proof systems. As Ethereum moves toward a model where L1 state is verified via ZK proofs, prover performance becomes the biggest bottleneck.

The issue lies in how current zkEVMs operate. They do not generate zero-knowledge proofs directly over the EVM; instead, they prove an interpreter of the EVM, which itself is compiled into RISC-V. Vitalik Buterin bluntly identified this core issue:

“…if the zkVM implementation compiles EVM execution into something that eventually becomes RISC-V code, why not just expose the underlying RISC-V directly to smart contract developers? That would completely eliminate the overhead of the outer VM layer.”

This extra interpretation layer causes massive performance loss. Estimates suggest it can lead to 50 to 800 times slower performance compared to proving native programs. Even after optimizing other bottlenecks (e.g., switching to Poseidon hashing), this “block execution” layer still consumes 80–90% of total proving time, making the EVM the final and most stubborn barrier to scaling L1. By removing this layer, Vitalik estimates execution efficiency could improve by up to 100x.

The Technical Debt Trap

To compensate for the EVM’s poor performance in specific cryptographic operations, Ethereum introduced precompiles — specialized functions hard-coded into the protocol. While pragmatic at the time, this solution has now created what Vitalik Buterin calls a “terrible” situation:

“Precompiles have been disastrous for us… they greatly bloat Ethereum’s trusted codebase… and they’ve led us to several near-consensus failures.”

The complexity is staggering. Vitalik illustrated that the wrapper code for a single precompile (like modexp) is more complex than the entire RISC-V interpreter, despite the precompile logic being even more convoluted. Adding new precompiles requires slow, politically contentious hard forks, severely hindering innovation for applications needing new cryptographic primitives. Vitalik reached a clear conclusion:

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

Ethereum's Architectural Technical Debt

The EVM’s core design reflects the priorities of a past era, ill-suited to modern computing demands. The EVM adopted a 256-bit architecture to handle cryptographic values, but this is highly inefficient for the 32-bit or 64-bit integers typically used in smart contracts. This inefficiency is especially costly in ZK systems. As Vitalik explained:

“When using smaller numbers, you don’t actually save any resources, but the complexity increases two to fourfold.”

Beyond this, the EVM’s stack-based architecture is less efficient than the register-based designs of RISC-V and modern CPUs. It requires more instructions to perform the same tasks and makes compiler optimization significantly harder.

These issues — ZK proving bottlenecks, precompile complexity, and outdated architectural choices — collectively form a compelling and urgent case: Ethereum must move beyond the EVM to embrace a more future-ready technical architecture.

The RISC-V Blueprint: Rebuilding Ethereum’s Future on Stronger Foundations

RISC-V’s advantage lies not just in the EVM’s shortcomings but in the intrinsic strength of its design philosophy. Its architecture provides a robust, simple, and verifiable foundation, ideal for a high-stakes environment like Ethereum.

Why Open Standards Beat Custom Designs

Unlike a custom ISA requiring a ground-up software ecosystem, RISC-V is a mature open standard offering three key advantages:

Mature Ecosystem

By adopting RISC-V, Ethereum leverages decades of collective progress in computer science. As Justin Drake explained, this gives Ethereum direct access to world-class tools:

“There’s an infrastructure component called LLVM, a suite of compiler toolchains that allow you to compile high-level programming languages into one of several backend targets. One of the supported backends is RISC-V. So if you support RISC-V, you automatically support all high-level languages that LLVM supports.”

This drastically lowers the development barrier, enabling millions of developers familiar with Rust, C++, and Go to easily participate.

Minimalist Design Philosophy RISC-V’s minimalism is an intentional feature, not a limitation. Its base instruction set contains only about 47 instructions, keeping the VM core extremely lean. This simplicity offers major security benefits, as a smaller trusted codebase is easier to audit and formally verify.

De Facto Standard in Zero-Knowledge Proofs More importantly, the zkVM ecosystem has already made its choice. As Justin Drake pointed out, data from Ethproofs shows a clear trend:

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

Among ten zkVMs capable of proving Ethereum blocks, nine have chosen RISC-V as their target architecture. This market convergence sends a strong signal: Ethereum’s adoption of RISC-V is not speculative but aligned with a standard already validated and embraced by projects building its ZK future.

Built for Trust, Not Just Execution

Beyond its broad ecosystem, RISC-V’s internal architecture is particularly well-suited for secure, verifiable systems. First, RISC-V has a formalized, machine-readable specification — SAIL. This is a massive leap forward from the EVM’s specification, primarily documented in natural language in the Yellow Paper. The Yellow Paper has ambiguities, while the SAIL spec provides a “gold standard” enabling critical mathematical correctness proofs essential for protecting high-value protocols. As Alex Hicks of the Ethereum Foundation (EF) noted at Ethproofs, this allows zkVM circuits to be directly “verified against the official RISC-V specification.” Second, RISC-V includes a privileged architecture — an often-overlooked but vital security feature. It defines different privilege levels, primarily user mode (for untrusted apps like smart contracts) and supervisor mode (for trusted “execution kernels”). Diego from Cartesi explained this in depth:

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

Under RISC-V, smart contracts running in User Mode cannot directly access blockchain state. Instead, they must request access via a special ECALL (environmental call) instruction to a trusted kernel running in Supervisor Mode. This creates a hardware-enforced security boundary, more robust and easier to verify than the EVM’s purely software-based sandbox model.

Vitalik’s Vision

This transition is envisioned as a gradual, multi-phase process to ensure stability and backward compatibility. As Ethereum founder Vitalik Buterin outlined, this approach aims for “evolutionary” rather than “revolutionary” change.

Phase One: Precompile Replacement

The initial phase takes the most conservative approach, introducing limited functionality of the new VM. As Vitalik Buterin suggested: “We could start using the new VM in limited scenarios, such as replacing precompiles.” Specifically, new EVM precompiles would be paused, with required functionality implemented instead via whitelisted RISC-V programs. This allows the new VM to be tested in production on mainnet under low-risk conditions, with Ethereum clients acting as intermediaries between the two execution environments.

Phase Two: Dual VM Coexistence

The next stage involves “opening the new VM directly to users.” Smart contracts can be marked to indicate whether their bytecode is EVM or RISC-V. A key feature is seamless interoperability: “Contracts of both types can call each other.” This will be enabled via system calls (ECALL), allowing the two VMs to cooperate within the same ecosystem.

Phase Three: EVM as a Simulated Contract (“Rosetta” Strategy)

The ultimate goal is protocol minimization. In this phase, “we implement the EVM as a program within the new VM.” A standardized EVM becomes a formally verified smart contract running atop the native RISC-V L1. This ensures permanent support for legacy applications while allowing client developers to maintain only one simplified execution engine, drastically reducing complexity and maintenance costs.

Ripple Effects Across the Ecosystem

The shift from EVM to RISC-V is more than a core protocol change — it will profoundly impact the entire Ethereum ecosystem. This transformation will reshape developer experience, fundamentally alter the competitive landscape for Layer-2 solutions, and unlock new economic validation models.

Rollup Realignment: The Battle Between Optimistic and ZK

Adopting RISC-V execution at L1 will affect the two main types of Rollups very differently.

Optimistic Rollups (e.g., Arbitrum, Optimism) face architectural challenges. Their security model relies on re-executing disputed transactions on the L1 EVM to resolve fraud proofs. If the L1 EVM is replaced, this model collapses entirely. These projects face tough choices: either undertake massive engineering efforts to design a fraud-proof system for the new L1 VM, or fully decouple from Ethereum’s security model.

In contrast, ZK Rollups gain a major strategic advantage. Most ZK Rollups already use RISC-V as their internal ISA. An L1 that “speaks the same language” enables tighter, more efficient integration. Justin Drake envisions “native rollups”: L2s becoming specialized instances of the L1’s own execution environment, leveraging the L1’s built-in VM for seamless settlement. This alignment brings several changes:

Simplified Tech Stack: L2 teams no longer need complex bridging mechanisms between internal RISC-V execution and the EVM.

Tool and Code Reuse: Compilers, debuggers, and formal verification tools developed for the L1 RISC-V environment can be directly reused by L2s, dramatically cutting development costs.

Aligned Economic Incentives: L1 gas fees will more accurately reflect the actual cost of RISC-V-based ZK verification, creating a more rational economic model.

A New Era for Developers and Users

For Ethereum developers, this transition will be gradual, not disruptive.

Developers will gain access to a broader, more mature software development ecosystem. As Vitalik Buterin noted, they will “be able to write contracts in Rust, and these options can coexist.” At the same time, he predicts “Solidity and Vyper will remain popular for a long time due to their elegant design for smart contract logic.” Leveraging mainstream programming languages and their vast libraries via the LLVM toolchain will be revolutionary. Vitalik likens it to a “NodeJS-style experience,” where developers use the same language for on-chain and off-chain code, unifying development.

For users, this transition will ultimately deliver a lower-cost, higher-performance network. Proving costs are expected to drop by ~100x, from several dollars per transaction to mere cents or less. This translates directly into lower L1 and L2 settlement fees. This economic feasibility unlocks the vision of a “Gigagas L1,” targeting ~10,000 TPS and paving the way for more complex, high-value on-chain applications.

Succinct Labs and SP1: Building the Proven Future Today

Ethereum is poised for takeoff. “Scaling L1, scaling blocks” is a strategic priority within the EF protocol cluster. Significant performance improvements are expected within the next 6–12 months.

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

Teams like Succinct Labs are already demonstrating RISC-V’s theoretical advantages in practice, providing strong evidence for this proposal.

SP1, developed by Succinct Labs, is a high-performance, open-source zkVM based on RISC-V, validating the feasibility of this new architectural approach. SP1 adopts a “precompile-centric” philosophy, elegantly solving EVM’s cryptographic bottlenecks. Unlike traditional reliance on slow, hardcoded precompiles, SP1 offloads intensive operations like Keccak hashing to specially designed, hand-optimized ZK circuits, invoked via standard ECALL instructions. This combines the performance of custom hardware with software flexibility, delivering a more efficient and scalable solution for developers.

The real-world impact of Succinct Labs is already evident. Their OP Succinct product uses SP1 to add ZK capabilities (ZK-ify) to Optimistic Rollups. As Succinct co-founder Uma Roy explained:

“Rollups using the OP Stack no longer need to wait seven days for finality and withdrawals… now confirmation happens in about an hour. This speed boost is fantastic.”

This breakthrough solves a key pain point across the entire OP Stack ecosystem. Additionally, Succinct’s infrastructure — the Succinct Prover Network — is designed as a decentralized proving market, showcasing a viable economic model for future verifiable computing. Their work is not just a proof of concept but a practical blueprint for the future, exactly as described in this article.

How Ethereum Reduces Risk

One major advantage of RISC-V is that it makes the holy grail of formal verification — mathematically proving system correctness — achievable. The EVM’s specification, written in natural language in the Yellow Paper, is difficult to formalize. RISC-V, however, has an official, machine-readable SAIL specification, providing a clear “golden reference” for its behavior.

This paves the way for stronger security. As Alex Hicks of the Ethereum Foundation noted, work is already underway to “formally verify zkVM RISC-V circuits against the official RISC-V specification extracted into Lean.” This is a landmark achievement, shifting trust from error-prone human implementations to verifiable mathematical proofs, opening a new frontier in blockchain security.

Key Risks of the Transition

Despite its many advantages, a RISC-V-based L1 introduces new complex challenges.

Gas Metering

Creating a deterministic and fair gas model for a general-purpose ISA remains an unsolved problem. Simple instruction counting is vulnerable to denial-of-service attacks. For example, attackers could design programs that repeatedly trigger cache misses, consuming high resources at minimal gas cost. This poses serious threats to network stability and economic integrity.

Toolchain Security and “Reproducible Builds”

This is the most critical and often underestimated risk in the transition. The security model shifts from relying on an on-chain VM to depending on off-chain compilers (like LLVM), which are extremely complex and known to contain bugs. Attackers could exploit compiler vulnerabilities to transform seemingly benign source code into malicious bytecode. Moreover, ensuring that on-chain compiled binaries exactly match public source code — the “reproducible builds” problem — is extremely difficult. Minor differences in build environments can produce different binaries, undermining transparency and trust. These issues pose severe challenges to developer and user security.

Mitigation Strategies

The path forward requires a multi-layered defense strategy.

Phased Rollout

Adopting a gradual, multi-stage transition plan is central to risk management. By first introducing RISC-V as a precompile replacement, then running it alongside EVM in a dual-VM environment, the community can accumulate operational experience and build confidence in low-risk settings, avoiding irreversible changes. This incremental approach provides a stable foundation for technical transformation.

Comprehensive Audits: Fuzzing and Formal Verification

While formal verification is the ultimate goal, it must be combined with continuous, rigorous testing. As Valentine from Diligence Security demonstrated during an Ethproofs call, their Argus fuzzing tool uncovered 11 critical soundness and completeness vulnerabilities in leading zkVMs. This shows that even the best-designed systems may harbor flaws only detectable through adversarial testing. Combining fuzzing with formal verification strengthens system security.

Standardization

To prevent ecosystem fragmentation, the community must adopt a single, standardized RISC-V configuration. This will likely be RV64GC with a Linux-compatible ABI, as it enjoys the broadest support across mainstream languages and tools, maximizing the new ecosystem’s potential. Standardization enhances developer efficiency and lays a solid foundation for long-term growth.

Ethereum’s Verifiable Future

The proposal to replace the Ethereum Virtual Machine (EVM) with RISC-V is not a minor upgrade but a fundamental restructuring of Ethereum’s execution layer. This ambitious vision aims to resolve deep scalability bottlenecks, simplify protocol complexity, and align the platform with the broader ecosystem of general-purpose computing. Despite immense technical and social challenges, the long-term strategic benefits justify this bold endeavor.

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

• Performance gains from a ZK-native architecture vs. the urgent need for backward compatibility;

• Security benefits from protocol simplification vs. the inertia of EVM’s massive network effects;

• Power of a universal ecosystem vs. risks from relying on complex third-party toolchains.

Ultimately, this architectural shift will be key to fulfilling the promise of “Lean Execution” and is a cornerstone of the “Lean Ethereum” vision. It transforms Ethereum’s L1 from a simple smart contract platform into an efficient, secure settlement and data availability layer, purpose-built to support the vast universe of verifiable computing.

As Vitalik Buterin put it, “The endgame is… providing ZK-snarks for everything.”

Projects like Ethproofs provide objective data and collaborative platforms for this transition, while teams like Succinct Labs, through the real-world application of their SP1 zkVM, offer actionable blueprints for this future. By embracing RISC-V, Ethereum not only solves its own scalability bottlenecks but positions itself as the foundational trust layer for the next generation of the internet — powered by SNARKs, the third great cryptographic primitive after hashes and signatures.

Software for a proven world, ushering in a new era of crypto.

Learn more:

Vitalik’s explanation: Watch here

ETHProofs Fourth Discussion: Watch here