Vitalik Buterin has proposed a long-term overhaul to Ethereum’s execution environment to replace the Ethereum Virtual Machine with RISC-V, a standardized and extensible instruction set architecture.
The proposal, shared in the Ethereum Magicians forum on April 20, outlines a multi-phase shift to improve proving efficiency and simplify the execution layer, without changing core abstractions like accounts, storage, or cross-contract calls.
The change would retain Solidity and Vyper as primary development languages, which would be adapted to compile to RISC-V.
Per Buterin, while writing contracts directly in Rust would be technically possible, readability concerns and developer familiarity with existing languages 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, preserving backward compatibility.
Execution bottlenecks and long-term scaling
Buterin identified execution as one of Ethereum’s final long-term bottlenecks, after near-term issues are mitigated by EIPs such as delayed execution, block-level access lists, and distributed historical storage.
In particular, he pointed to proving costs in ZK-EVMs as the key constraint for future scalability. Analysis from Succinct’s ZK-EVM indicates that block execution alone accounts for nearly half of all prover cycles, while the remainder is 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 prover-optimized hash functions such as Poseidon, 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.
Coexistence, migration, and simplification paths
Multiple implementation pathways are under consideration. The most conservative would allow dual support for both EVM and RISC-V contracts, maintaining interoperable calls and shared access to persistent state. EVM contracts would continue to function and could call into or be called by RISC-V contracts via system calls mapped to traditional opcodes such as CALL, SLOAD, and SSTORE.
A more aggressive approach involves transforming existing EVM contracts into wrappers that delegate execution to an EVM interpreter written in RISC-V. Under this model, a contract’s bytecode would be replaced with logic that routes calls and execution parameters to a designated RISC-V interpreter contract, receives the return value, and forwards it to the caller.
An intermediate strategy proposes protocol-level support for virtual machine interpreters, enshrining this delegation process and enabling multiple execution formats to coexist. While EVM would be the first VM supported under this model, others, including Move, could be added in the future.
Each approach seeks to balance compatibility with long-term simplification. According to Buterin, incremental simplifications to the EVM, such as removing SELFDESTRUCT, have proven difficult due to complex edge cases and legacy behaviors.
A complete transition to RISC-V could enable a more maintainable base layer with minimal execution logic, comparable in compactness to projects like Tinygrad that enforce strict codebase limits.
Broader design philosophy and alignment with Beam Chain
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.
As posted on Ethereum Magicians, 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. 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.
Community response
Some community members raised strategic and technical reservations in response to Buterin’s proposal. Adam Cochran questioned the prioritization of L1 efficiency at the potential expense of L2 enablement, suggesting that enshrining RISC-V could narrow Ethereum’s modular roadmap.
He highlighted alternative proposals such as recursive proof aggregation, stateless commitment roots, and BLS signature unification, which could potentially offer broader systemic gains with fewer implementation costs.
Others, including Ben A Adams, Co-founder and CTO of Illyriad Games, and levs57, a web3 developer, pointed to performance trade-offs, particularly around hardware compatibility and the persistent role of precompiles.
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.
Mentioned in this article
