Vitalik Buterin proposed a long-term overhaul to the Ethereum execution environment to replace the Ethereum virtual machine with RISC-V, a standardized and extensible instructions architecture.
The proposal, shared in the Ethereum Magicians forum on April 20, describes a multi-shade change to improve the efficiency of the service and simplify the execution layer, without modifying basic abstractions such as accounts, storage or transversal calls.
The change would retain solidity and Vyper as primary development languages, which would be adapted to the compilation at RISC-V.
According to Buterin, although the drafting of contracts directly in Rust would be technically possible, the concerns of readability and the familiarity of developers with existing languages suggest that rust will not replace the solidity of the application layer. The existing EVM contracts would continue to work and interact fully with new contracts based on RISC-V, preserving compatibility behind.
Exception bottle of execution and long -term scale
Buterin has identified execution as one of the last long -term strangulation of Ethereum, after short -term problems are attenuated by EIP such as delayed execution, access lists at blocks and distributed historical storage.
In particular, he underlined the prouvance of costs in ZK-EVM as the key constraint of future scalability. The analysis of the ZKE-EVM of succinct indicates that the execution of blocks alone represents almost half of all the cycles of prover, while the rest is consumed by the manipulation of the data of the witnesses and the operations of state trees.
Although the general costs linked to the State can be reduced by passing from Patricia trees based on Keccak to binary trees with hash functions optimized by provers such as poséidon, the effectiveness of the execution of the blocks will remain limited unless the EVM is processed directly.
Buterin noted that ZKE-EVMS was already compiling with RISC-V under the hood, suggesting that RISC-V exposure as a primary VM could eliminate a layer of abstraction and efficiency efficiency gains. Some test scenarios would display 100x improvements in prover performance by completely bypassing the EVM translation.
Coexistence, migmation and fields
Several implementation routes are being studied. The most conservative would allow double support for EVM and RISC-V contracts, maintaining interoperable calls and shared access to the persistent state. EVM contracts would continue to operate and could call or be called by RISC-V contracts via system calls mapped to traditional opcodes such as CALL, SLOAD and SSTORE.
A more aggressive approach is to transform existing EVM contracts into packaging which delegate the execution to an EVM interpreter written in RISC-V. Within the framework of this model, the bytecode of a contract would be replaced by a logic which transports the appeals and the execution parameters to an designated RISC-V interpreter contract, receives the return value and transmits it to the appellant.
An intermediate strategy offers support at the protocol for virtual machinery interpreters, devoting this delegation process and allowing several execution formats to coexist. Although the EVM would be the first virtual machine 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 at the EVM, such as elimination of self -destruction, have proven to be difficult due to the cases of complex edges and inherited behaviors.
A complete transition to RISC-V could allow a more holdable base layer with a minimum logic of execution, comparable in compactness to projects like Tinygrad which apply strict code limits.
Wider and alignment philosophy with the beam chain
The proposal aligns with current efforts as the initiative of the beam chain, which aims to simplify the consensual mechanism of Ethereum. The RISC-V plan would make improvements parallel to the execution layer, allowing the network to continue modularity and reduced complexity in both areas.
As displayed on Ethereum Magicians, Buterin described the proposal as a radical but perhaps necessary to achieve long-term efficiency and simplicity in L1. While active FPIs and state -free executives deal with short and medium -term scalability improvements, the future of Ethereum as a powerful and durable protocol may depend on the architectural changes of this magnitude.
No calendar has been announced for any implementation phase. The Ethereum community should engage in more in -depth discussions to assess the compromises, the impact of the tools and the development routes of developers as part of a longer deliberation cycle.
The proposal remains exploratory and aims to open a wider conversation on the Ethereum execution environment department in the coming years.
Community response
Some members of the community have raised strategic and technical reservations in response to Buterin’s proposal. Adam Cochran has questioned the hierarchy of the efficiency of L1 at the potential costs of activation L2, which suggests that RISC-V consolidation could reduce the modular roadmap of Ethereum.
He highlighted alternative proposals such as recursive evidence, the roots of commitment without state and the unification of BLS signature, which could potentially offer wider systemic gains with less implementation costs.
Others, including Ben A Adams, Co-founder and CTO of Illyriade Games, and Levs57, a web 3 developer, underlined the compromises of performance, in particular around the material compatibility and the persistent role of the pre-compile.
The concerns included the difficulty of optimizing low-level RISC-VS instructions in efficient 256-bit operations and doubts as to whether the current ZK-RISC-V systems are sufficiently mature or verifiable to justify a fundamental change.
Buterin responded by minimizing the extent to which the size of the EVM 256-bit words limits execution, indicating that most of the values in practice are smaller, generally U32, U64 or U128, that compilers can effectively map the RISC-V instructions.
He reiterated that Zk-EVM today already works as RISC-V environments incorporating an EVM interpreter, supervising the direct exposure of RISC-V as a means of eliminating redundant layers. While recognizing the management of the battery and jumps as potential friction points, he argued that the elimination of general interpretation costs remains a net gain.
