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

Author | GaryMa Wu said Blockchain

Introduction

Vitalik Buterin, 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 compared this concept to the consensus layer’s Beam Chain, believing that this is the potential only path to achieve breakthroughs in execution layer performance and simplify protocol logic. Especially in terms of zero-knowledge proof (ZK Proof) efficiency, Vitalik anticipates that by replacing the EVM, an optimization improvement of up to 100 times could be achieved. This proposal aims to address the current bottlenecks in Ethereum regarding ZK proof efficiency, block construction complexity, and data availability.

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

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

Issues with 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, about half of the resources of ZK-EVM are used to execute the EVM itself, limiting the efficiency of ZK proofs.

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

Development is limited: 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, suitable 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++, lowers development barriers, and has a broader ecosystem.

General standards: Already adopted by blockchain 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): Treating 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 must 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: Needs to update compilers, debuggers, security auditing tools, and 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 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 that users will experience a seamless upgrade.

3. Impact on the existing expansion path: 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 route.

Layer 2:

Rollup is still the main force for Ethereum scaling, 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 faster speed, improving overall scalability.

Data Sharding and EIP-4844:

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

The changes in the execution architecture do not alter the data storage requirements of L1.

FaaS, MEV:

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

Summary: RISC-V is “engine replacement”, L2/sharding is “road expansion network”, the two dimensions are different and do not contradict each other.

4. Community Feedback and Related Attempts

Community Discrepancy:

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

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

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 mainnet uses RISC-V as a contract VM precedent, providing a 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.

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

Developer Experience:

Languages such as Solidity/Vyper can still be used; it’s the compiler backend that has changed, not the languages themselves.

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

Operating Costs and Performance:

Improvements in execution efficiency will lead to higher Gas limits 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 the dual VMs, existing contracts can continue to run, and new contracts will gradually adopt RISC-V.

The infrastructure needs to support the new bytecode format, which may trigger compatibility changes between chains (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 controlling the attack surface.

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 process that will take several years, requiring overcoming multiple challenges in technology, community, and ecosystem. It is not about overturning the existing path, but rather reinforcing the foundation and preparing for the future.

As Vitalik said, “This radical change may be the only viable path to achieve an order of magnitude improvement.”

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

Reference source: