- Vitalik Buterin proposes replacing Ethereum’s EVM with RISC-V to improve prover efficiency and reduce execution bottlenecks.
- The new model maintains compatibility between existing EVM and new RISC-V contracts for smooth developer experience and interoperability.
- RISC-V integration could simplify Ethereum’s execution layer and align it with future scalability and zero-knowledge proof developments.
Ethereum cofounder Vitalik Buterin has outlined a new path for the execution layer of the network, recommending that Ethereum shift away from the existing Ethereum Virtual Machine (EVM) architecture to RISC-V. The plan is designed to simplify operations, improve scalability, and minimize future costs.
Transition to RISC-V: A Shift in Ethereum’s Core Execution Layer
Vitalik Buterin proposed the concept in an in-depth blog post, explaining why EVM should be replaced by RISC-V. In Buterin’s view, that change would help solve some serious bottlenecks in Ethereum’s execution layer without compromising on known features for contracts.
In this proposed model, core abstractions such as accounts, storage access, and contract calls would remain intact. Opcodes like SLOAD, SSTORE, BALANCE, and CALL would be transformed into system calls under RISC-V. This setup ensures continuity and ease of adaptation for developers.
Buterin noted that although smart contracts could be written in Rust, most developers would likely continue using Solidity or Vyper. These languages would integrate RISC-V as a backend, allowing for smooth transitions without changing developer workflows. Existing EVM contracts would remain functional and interoperable with new RISC-V contracts.
Enhancing ZK-EVM Efficiency Through Architecture Overhaul
A key reason behind the proposed transition lies in the inefficiencies within current ZK-EVM proving systems. Buterin provided data showing that a large share of proving cycles is spent on block execution, state root computation, and witness handling.
He emphasized that many of these cycles could be reduced by optimizing the structure of Ethereum’s state tree. By switching from Keccak-based Merkle Patricia trees to binary trees using a prover-friendly hash function like Poseidon, proving speeds could increase dramatically. Worthy to note, Poseidon offers hashing speeds of up to 2 million hashes per second on standard hardware, compared to 15,000 for Keccak.
This optimization alone would not suffice. Block execution still accounts for approximately half of total prover cycles. Buterin argued that giving developers access to the RISC-V virtual machine directly, bypassing the need for EVM interpretation, could yield 100x efficiency gains in specific scenarios.
Compatibility Measures and Developer Experience
To maintain compatibility, the proposal outlines several approaches. The most conservative method supports both EVM and RISC-V contracts concurrently, enabling seamless communication between them. Contracts written for EVM would still function and interact with RISC-V counterparts through syscalls.
A more radical approach would wrap legacy EVM contracts with a RISC-V interpreter. In this case, the original EVM code would be handled by a RISC-V-based interpreter contract. Calls to the legacy contract would be redirected through the interpreter, maintaining expected functionality.
An intermediate option would introduce a new protocol feature allowing multiple virtual machine interpreters. While EVM would be the default interpreter, this structure could later accommodate additional VMs such as Move. All implementations would be written in RISC-V, further unifying the execution layer.
Simplifying the Execution Layer Specification
Buterin pointed out that one of Ethereum’s challenges is the complexity of its execution layer. Previous efforts to remove features such as SELF DESTRUCT have proven difficult. He proposed that reducing the execution logic to a compact, consistent RISC-V model could simplify the protocol dramatically.
The idea aligns with broader goals in Ethereum’s development roadmap, including the Beam chain, which aims to simplify consensus. This new execution model could achieve similar results on the computation side. Simplifying the system could also improve maintainability and security over time.
A reference to Tinygrad, a project enforcing strict codebase limits, was used to illustrate the value of minimalism. Ethereum, Buterin argued, could benefit from similar principles, reducing the code complexity of its core systems.
Ethereum’s Pectra Upgrade and Roadmap Context
The proposed shift to RISC-V aligns with other ongoing improvements to Ethereum, including the upcoming Pectra upgrade scheduled for May. This upgrade is expected to bring enhancements to scalability and efficiency at the block level.
Buterin contextualized the RISC-V idea within Ethereum’s long-term goals. Short-term scaling will rely on EIPs such as block-level access lists and EIP-4444. Medium-term improvements are tied to statelessness and ZK-EVM development. In the long run, the execution layer becomes a primary area for progress, and RISC-V could play a central role.
The network’s aim to maintain a competitive block production market and improve zero-knowledge proving capabilities makes the RISC-V transition a timely consideration. By aligning the gas schedule with proof complexity, the network could steer away from expensive precompiles and toward more efficient smart contract structures.
Ethereum continues to explore pathways that enhance its infrastructure while preserving core developer experiences. The proposal to adopt RISC-V marks a major potential step in that evolution, balancing innovation with backward compatibility.
