Vitalik's radical idea: what does replacing the Ethereum EVM with RISC-V mean?

Written by: GaryMa Wu says Blockchain

Introduction

Ethereum co-founder Vitalik Buterin 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 compares this idea to the consensus layer's Beam Chain, believing it to be the only potential path to breakthrough performance in the execution layer and simplify protocol logic. Especially in terms of zero-knowledge proof (ZK Proof) efficiency, Vitalik expects that replacing the EVM could achieve up to a 100-fold optimization improvement. The proposal aims to address the current bottleneck issues in Ethereum concerning ZK proof efficiency, block construction complexity, and data availability.

This article will use plain language to analyze the motivations, technical details, implementation path, and challenges of the proposal, discuss its impact on the existing scalability route 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 inefficiency when executing ZK-EVM.

ZK Proof Bottleneck: As stated by Succinct, about half of the resources of ZK-EVM are used for executing the EVM itself, which limits the efficiency of ZK proofs.

Poor maintainability: Over the years, the accumulation of complex functions has led to disorganized specifications, making it difficult to abolish SELFDESTRUCT.

Development is restricted: Non-standard instruction set limits 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 real CPU's reduced instruction set, hardware-friendly, and can be used for JIT optimization and 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.

Universal standards: Existing blockchains such as Nervos CKB have adopted this, 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 solutions:

Dual VM Coexistence (Most Conservative): EVM and RISC-V run in parallel, with new contracts optionally using 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:

Execution performance degradation risk: RISC-V needs to be simulated on x86 chips, which may result in initial efficiency lower than that of the optimized EVM.

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

Secure sandbox design: limit system calls, prevent self-modifying code, ensure deterministic execution.

Development tools 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; migration requires careful design of compatibility layers or fallback mechanisms.

Vitalik favors Option One as a transitional path and promises that the new and old contracts will remain interoperable, ensuring that the developer experience remains unchanged and users will experience the upgrade seamlessly.

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

The answer is negative: RISC-V is an infrastructure optimization and will not replace the existing scaling routes.

Layer 2:

Rollup is still the main force for Ethereum scaling, RISC-V improves the processing efficiency of L1 and 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, RISC-V does not affect on-chain data capacity.

Changing the execution architecture does not alter the data storage requirements of L 1.

FaaS, MEV:

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

Summary: RISC-V is "Engine Swap", L2/Sharding is "Road Network", both have different dimensions and are parallel without conflict.

4. Community Feedback and Related Attempts

Community Discrepancy:

Supporters: believe this is a necessary strategic upgrade to address performance challenges such as Solana/Sui, which helps attract traditional developers.

Conservatives: Concerned about implementation difficulties, historical burdens, high costs of updating ecological toolchains, and questioning the return on investment of resource allocation.

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 L 2, now implemented in Arbitrum, with practical feasibility.

Nervos CKB: The mainnet uses RISC-V as a contract VM 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 insert VMs such as Move, WASM, etc., to build a diverse execution ecosystem.

5. Future Impact Outlook: What if Ethereum switches to RISC-V?

Developer Experience:

Languages like Solidity/Vyper can still be used; the compiler backend has changed, not the languages themselves.

It may allow new languages like Rust/C to write contracts, but migration is not mandatory.

Operating Costs and Performance:

The improvement in execution efficiency will bring higher Gas limits and lower fees.

RISC-V contracts may reduce reliance on precompiled contracts, and the Gas model is closer to ZK proof costs.

Ecological Compatibility and Development:

During the coexistence period of the two 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 inter-chain compatibility changes (such as the retention or removal 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's proposal to replace Ethereum EVM with RISC-V represents Ethereum's deep thinking about future performance limits and protocol simplicity. The proposal is still in the early stages of discussion, and implementation is expected to be a multi-year process that will span multiple technical, community, and ecological challenges. It is not about overturning the existing course, but about strengthening 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, as well as a deep exploration of whether the underlying layer is worth reshaping.