Ethereum Co-Founder Proposes RISC-V for 100x Efficiency Gains

Vitalik Buterin, the co-founder of Ethereum, has proposed a significant overhaul to the blockchain's execution environment. The proposal, shared on the Ethereum Magicians forum, suggests replacing the Ethereum Virtual Machine (EVM) with RISC-V, a standardized and extensible instruction set architecture. This shift aims to improve proving efficiency and simplify the execution layer without altering core abstractions such as accounts, storage, or cross-contract calls.

The proposal outlines a multi-phase transition that would retain Solidity and Vyper as primary development languages, adapting them to compile to RISC-V. While writing contracts directly in Rust is technically feasible, concerns about readability and developer familiarity suggest that Rust will not replace Solidity at the application layer. Existing EVM contracts would continue to operate and interact fully with new RISC-V-based contracts, ensuring backward compatibility.

Buterin identified execution as one of Ethereum’s final long-term bottlenecks, highlighting proving costs in ZK-EVMs as a key constraint for future scalability. Analysis indicates that block execution alone accounts for nearly half of all prover cycles, with the remainder consumed by witness data handling and state tree operations. While state-related overhead can be reduced by shifting from Keccak-based Patricia trees to binary trees with optimized hash functions, block execution efficiency will remain limiting unless the EVM is addressed directly.

Buterin noted that ZK-EVMs already compile to RISC-V under the hood, suggesting that exposing RISC-V as the primary VM could eliminate a layer of abstraction and yield efficiency gains. Some test scenarios reportedly show 100x improvements in prover performance by bypassing EVM translation altogether.

Multiple implementation pathways are under consideration. The most conservative approach would allow dual support for both EVM and RISC-V contracts, maintaining interoperable calls and shared access to persistent state. A more aggressive approach involves transforming existing EVM contracts into wrappers that delegate execution to an EVM interpreter written in RISC-V. An intermediate strategy proposes protocol-level support for virtual machine interpreters, enshrining this delegation process and enabling multiple execution formats to coexist.

Each approach seeks to balance compatibility with long-term simplification. A complete transition to RISC-V could enable a more maintainable base layer with minimal execution logic, comparable in compactness to projects that enforce strict codebase limits. The proposal aligns with ongoing efforts like the beam chain initiative, which aims to simplify Ethereum’s consensus mechanism. The RISC-V plan would bring parallel improvements to the execution layer, enabling the network to pursue modularity and reduced complexity across both domains.

Buterin characterized the proposal as a radical but possibly necessary step toward realizing long-term L1 efficiency and simplicity. While active EIPs and statelessness frameworks address short- and medium-term scalability improvements, Ethereum’s future as a performant and sustainable protocol may hinge on architectural changes of this magnitude. No timeline has been announced for any implementation phase, and the Ethereum community is expected to engage in further discussion to evaluate trade-offs, tooling impact, and developer migration paths as part of a longer deliberation cycle.

The proposal remains exploratory and is intended to open a broader conversation about the direction of Ethereum’s execution environment over the coming years. Some community members raised strategic and technical reservations in response to Buterin’s proposal. Concerns included the difficulty of optimizing low-level RISC-V instructions back into efficient 256-bit operations and doubts about whether current zk-RISC-V systems are sufficiently mature or auditable to justify a foundational shift. Buterin responded by downplaying the extent to which the EVM’s 256-bit word size constrains execution, stating that most values in practice are smaller, typically u32, u64, or u128, which compilers can efficiently map to RISC-V instructions. He reiterated that today’s ZK-EVMs already operate as RISC-V environments embedding an EVM interpreter, framing direct exposure of RISC-V as a way to remove redundant layers. While acknowledging stack management and jumps as potential friction points, he maintained that eliminating interpretive overhead remains a net gain.