Vitalik Buterin's radical proposal: replace Ethereum EVM with RISC-V, is ZK the ultimate solution for scalability?

Author | GaryMa Wu said Blockchain

Introduction

Vitalik Buterin, the co-founder of Ethereum, recently proposed a long-term plan in the Ethereum Magicians community: to replace the current execution layer virtual machine (EVM) with the open-source RISC-V instruction set architecture. He likened this idea to the consensus layer's Beam Chain, believing it to be the only potential path to achieving breakthroughs in execution layer performance and simplifying protocol logic. Especially regarding the efficiency of zero-knowledge proofs (ZK Proof), Vitalik expects that replacing the EVM could achieve up to a 100-fold optimization increase. This proposal aims to address the current bottlenecks Ethereum faces in ZK proof efficiency, block construction complexity, data availability, and other aspects.

This article will use plain language to analyze the motivations, technical details, implementation pathways, and challenges of the proposal, discuss its impact on the existing scaling routes of Ethereum, and review community reactions and similar attempts.

1. Current limitations of EVM and advantages of RISC-V

The issue of EVM:

Outdated architecture: EVM uses a 256-bit stack structure, which is incompatible with modern CPUs, resulting in low efficiency when executing ZK-EVM.

ZK Proof Bottleneck: As stated by Succinct, ZK-EVM uses about half of its resources to execute the EVM itself, limiting the efficiency of ZK proofs.

Poor maintainability: Accumulation of complex functions over the years has led to chaotic specifications, making it difficult to abolish SELFDESTRUCT.

Development limitations: Non-standard instruction set restricts cross-language support, making it difficult for mainstream languages to efficiently compile into EVM bytecode.

Advantages of RISC-V:

High performance: RISC-V is a reduced instruction set for real CPUs, hardware-friendly, and can be used for JIT optimization or even hardware acceleration.

ZK Optimization: Directly generating circuits for RISC-V instructions in ZK proofs is simpler than proving EVM operations.

Mature toolchain: Supports mainstream languages such as Rust/C/C++, lowering the development threshold and expanding the ecosystem.

General standards: Already adopted by blockchains such as Nervos CKB, with successful cases.

Vitalik pointed out that instead of compiling the EVM into RISC-V in the ZK-EVM, it is better to directly use RISC-V as the contract execution architecture, fundamentally improving execution efficiency and scalability potential.

2. Replacement Path and Challenges: How to Migrate from EVM?

Three Replacement Options:

Dual VM coexistence (most conservative): EVM and RISC-V run in parallel, new contracts can optionally use RISC-V, ensuring compatibility during the transition period.

On-chain interpreter solution (radical): All EVM contracts are interpreted and executed by on-chain RISC-V contracts.

Interpreter plugin mechanism (compromise): Treat the interpreter as a protocol element, allowing for the future insertion of other VMs (such as Move).

Technical challenges faced in implementation:

Performance degradation risk: RISC-V needs to be simulated on x86 chips, which may initially result in lower efficiency than the optimized EVM.

Gas pricing needs to be restructured: a new Gas model must be defined for RISC-V instructions to ensure fairness and security.

Secure sandbox design: restrict system calls, prevent code self-modification, ensure deterministic execution.

Development tool adaptation: It is necessary to update the compiler, debugger, and security audit tools to support RISC-V bytecode.

Migration Compatibility Issues: Some contracts rely on EVM features, so migration requires careful design of compatibility layers or fallback mechanisms.

Vitalik favors Plan A as a transitional path and promises that the old and new contracts will maintain interoperability, ensuring that the developer experience remains unchanged and users experience a seamless upgrade.

3. Impact on existing scalability routes: Will RISC-V replace L2, data sharding, etc.?

The answer is negative: RISC-V is infrastructure optimization and will not replace the existing scalability route.

Layer 2：

Rollup is still the main force for Ethereum's scalability, RISC-V improves the processing efficiency of L1 and the ZK verification performance, rather than directly expanding throughput.

Faster L1 verification can help Rollup submit data at a lower cost and more quickly, improving overall scalability.

Data Sharding and EIP-4844:

Data availability bottlenecks still need to be addressed by EIP-4844 (blob) and Danksharding, and RISC-V does not affect on-chain data capacity.

Changes to the execution architecture do not alter the data storage requirements of L1.

FaaS, MEV:

Independent of virtual machine architecture, it will not become obsolete due to the advancement of RISC-V.

Summary: RISC-V is the "engine swap", L2/sharding is the "road expansion network", both are different dimensions and do not contradict each other.

4. Community Feedback and Related Attempts

Community Disputes:

Supporters: believe that this is a necessary strategic upgrade to address performance challenges such as those posed by Solana/Sui, and it will help attract traditional developers.

Conservatives: Concerned about the difficulty of implementation, historical burdens, high costs of ecological toolchain updates, and questioning the input-output ratio of resource investment.

Similar project references:

Move VM (Aptos/Sui): A brand new resource-oriented VM with strong language safety, but not compatible with EVM.

FuelVM: A new VM designed for parallel processing, paired with the language Sway, with limited compatibility.

WASM (Stylus): Introduced WASM as a contract language in L2, now implemented in Arbitrum, with practical feasibility.

Nervos CKB: The use of RISC-V as a contract VM on the mainnet sets a precedent, providing practical reference for Ethereum.

Vitalik's proposal of RISC-V does not mean rejecting other options; he believes that future interpreter mechanisms can also be used to incorporate VMs like Move and WASM, creating a diverse execution ecosystem.

V. Future Impact Outlook: If Ethereum switches to RISC-V

Developer Experience:

Languages such as Solidity/Vyper can still be used; the compiler backend has changed, not the language itself.

It may open up new languages like Rust/C for writing contracts, but migration is not mandatory.

Operating Costs and Performance:

The improvement in execution efficiency will lead to a higher Gas limit and lower fees.

RISC-V contracts may reduce dependence on precompiled contracts, and the Gas model is closer to the cost of ZK proofs.

Ecological Compatibility and Development:

During the coexistence period of dual VMs, existing contracts can continue to operate, and new contracts will gradually adopt RISC-V.

The infrastructure needs to support the new bytecode format, which may trigger changes in inter-chain compatibility (such as the retention issues of BSC and Polygon).

Security and Stability:

The new architecture requires extensive testing and formal verification to enhance protocol reliability.

A more streamlined execution layer is beneficial for auditing and attack surface control.

Conclusion

Vitalik proposed to replace the Ethereum EVM with RISC-V, representing Ethereum's deep consideration of future performance limits and protocol simplicity. This proposal is still in the early discussion stage, and its implementation is expected to be a multi-year process that needs to overcome various challenges in technology, community, and ecology. It is not about overturning the existing roadmap but rather reinforcing the foundation and preparing for the future.

As Vitalik said: "To achieve an order-of-magnitude improvement, this radical change may be the only viable path."

We might as well see it as a bet on the future, and also a deep exploration of whether the "underlying is worth reshaping."

Reference source: