V God’s radical proposal: Replace Ethereum EVM with RISC-V, is ZK the final solution to expand capacity?
Reprinted from panewslab
04/23/2025·24DAuthor | GaryMa Wu Shuo Blockchain
introduction
Ethereum co-founder Vitalik Buterin recently proposed a long-term proposal in the Ethereum Magicians community: to replace the current execution layer virtual machine (EVM) with an open source RISC-V instruction set architecture. He compared this idea with the Beam Chain of the consensus layer, believing that it is the potential only path to implement performance breakthroughs in execution layer and simplify protocol logic. Especially in terms of ZK Proof efficiency, Vitalik expects to achieve up to 100 times optimization improvement by replacing EVM. The proposal aims to address the current bottlenecks of Ethereum in terms of ZK proof efficiency, block construction complexity, data availability, etc.
This article will use popular language to analyze the proposal's motivation, technical details, implementation paths and challenges, explore its impact on Ethereum's existing expansion route, and review community reactions and similar attempts.
1. Current limitations of EVM and advantages of RISC-V
EVM problems:
Old architecture: EVM uses a 256-bit stacked structure, which is incompatible with modern CPUs, resulting in inefficiency when executing ZK-EVM.
ZK Proof Bottleneck: As Succinct stated, about half of the resources of ZK-EVM are used to execute the EVM itself, limiting the efficiency of ZK Proof Efficiency.
Poor maintenance: Over the years, complex functions have accumulated and confusing specifications, such as SELFDESTRUCT, are difficult to abolish.
Restricted development: Non-standard instruction sets restrict cross-language support, making it difficult for mainstream languages to efficiently compile into EVM bytecode.
Advantages of RISC-V:
Performance Efficient: RISC-V is a thin set of instructions for real CPUs, hardware-friendly, and can be used for JIT optimization and even hardware acceleration.
ZK optimization: The RISC-V instruction generation circuit is directly generated in the ZK proof, which is easier to operate than the proof EVM.
The tool chain is mature: supports mainstream languages such as Rust/C/C++, with a lower development threshold and a wider ecosystem.
General Standard: Blockchains such as Nervos CKB have been adopted, with successful cases.
Vitalik pointed out that instead of compiling EVM into RISC-V in ZK-EVM, it is better to directly use RISC-V as a contract execution architecture to fundamentally improve execution efficiency and expansion potential.
2. Replacement paths and challenges: How to migrate from EVM?
Three alternatives:
Dual VMs coexist (most conservative): EVM and RISC-V run in parallel, and RISC-V can be used in new contracts to ensure compatibility during transition periods.
On-chain interpreter scheme (radical): All EVM contracts are instead executed by on-chain RISC-V contract interpretation.
Interpreter plugin mechanism (compromise): Use the interpreter as a protocol element, allowing for future insertion of other VMs (such as Move).
Technical challenges facing implementation:
Execution performance loss risk: RISC-V needs to be executed analogly on x86 chips, and may be less efficient than optimized EVMs in the early stage.
Gas pricing needs to be refactored: a new Gas model needs to be defined for the RISC-V instruction to ensure fairness and safety.
Security sandbox design: limits system calls, prevents code self-modification, and ensures deterministic execution.
Development tool adaptation: Compiler, debugger, security audit tools need to be updated, and RISC-V bytecode is supported.
Migration compatibility issues: Some contracts rely on EVM features, and migration requires careful design of compatibility layer or fallback mechanisms.
Vitalik prefers solution one as a transition path and promises that new and old contracts will remain interoperable, ensuring that the developer experience remains unchanged and users are not sensitive to upgrade.
3. Impact on the existing expansion route: Will RISC-V replace L2, data
sharding, etc.?
The answer is no: RISC-V is an infrastructure optimization and will not replace the existing expansion route.
Layer 2:
Rollup is still the main force in Ethereum expansion, and RISC-V improves L1's processing efficiency and ZK verification performance, rather than directly expanding throughput.
Faster L1 verification helps Rollup submit data at a lower cost and faster rate, improving overall scalability.
Data Sharding and EIP-4844:
Data availability bottlenecks still need to be resolved by EIP-4844 (blob) and Danksharding, and RISC-V does not affect the on-chain data capacity.
Changes in the execution architecture do not change the data storage requirements of L1.
FaaS, MEV:
It has nothing to do with the virtual machine architecture and will not fail due to RISC-V advancement.
Summary: RISC-V is the "change engine", and L2/slicing is the "road network". The two have different dimensions and are parallel.
4. Community feedback and related attempts
Community Differences:
Supporters: This is a necessary strategic upgrade to deal with performance challenges such as Solana/Sui, which will help attract traditional developers.
Conservatives: Worry about the difficulty of implementation, historical burden, and the cost of updating the ecological tool chain, and question the resource input-output ratio.
Similar project reference:
Move VM (Aptos/Sui): A brand new resource-oriented VM, with strong language security, but is not compatible with EVM.
FuelVM: A new VM designed for parallel processing, with language Sway, limited compatibility.
WASM (Stylus): The introduction of WASM as a contract language in L2 has now been implemented in Arbitrum, which is realistic and feasible.
Nervos CKB: Use RISC-V on the main network as a precedent for contract VMs, providing practical reference for Ethereum.
Vitalik's proposal of RISC-V does not mean that other options are rejected. He believes that the future interpreter mechanism can also be used to insert VMs such as Move and WASM to build a diversified execution ecosystem.
5. Future impact outlook: If Ethereum switches to RISC-V
Developer experience:
Languages such as Solidity/Vyper are still available, and the compiler backend changes rather than the language itself.
It is possible to open new languages such as Rust/C to write contracts, but it does not force migration.
Running cost and performance:
Improved execution efficiency will lead to higher Gas caps and lower fees.
RISC-V contracts may reduce dependence on precompiled contracts, and the Gas model is closer to the ZK proof cost.
Ecological compatibility and development:
The existing contracts can run continuously during the co-existence period of dual VMs, and the new contracts gradually adopt RISC-V.
The infrastructure needs to support new bytecode formats, which may cause changes in inter-chain compatibility (such as BSC, Polygon stay or leave issues).
Safety and stability:
The new architecture requires extensive testing and formal verification to improve the reliability of the protocol.
A simpler execution layer is conducive to auditing and attack surface control.
Conclusion
Vitalik proposes to replace Ethereum EVM with RISC-V, which represents Ethereum's in-depth thinking on future performance limits and protocol simplicity. This proposal is still in an early stage of discussion and is expected to be a process that lasts several years and needs to cross multiple challenges of technology, community and ecological. It is not to overturn the existing route, but to strengthen the foundation and prepare for the future.
As Vitalik put it: “To achieve orders of magnitude improvement, this radical change may be the only viable path.”
We might as well regard it as a bet on the future, and it is also an in-depth exploration of "whether the underlying layer is worth reshaping."
Reference source:
chaincatcher
