Author | GaryMa Wu talks about blockchain

introduction

Ethereum co-founder Vitalik Buterin recently proposed a long-term proposal in the Ethereum Magicians community: replace the current execution layer virtual machine (EVM) with the open source RISC-V instruction set architecture. He compared this idea to the Beam Chain of the consensus layer, believing that this is the only potential path to achieve a breakthrough in the performance of the execution layer and simplify the protocol logic. Especially in terms of zero-knowledge proof (ZK Proof) efficiency, Vitalik expects that by replacing EVM, up to 100 times of optimization can be achieved. The proposal aims to address the current bottlenecks of Ethereum in ZK proof efficiency, block construction complexity, data availability, etc.

This article will use plain language to analyze the motivations, technical details, implementation paths and challenges of the proposal, explore its impact on Ethereum’s existing expansion path, and review community reactions and similar attempts.

1. Limitations of current EVM and advantages of RISC-V

Problems with EVM:

Old 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 Succinct mentioned, about half of ZK-EVM's resources are used to execute the EVM itself, limiting the efficiency of ZK proofs.

Poor maintainability: Complex functions have accumulated over the years, and the specifications are confusing. For example, SELFDESTRUCT is difficult to abolish.

Development is limited: Non-standard instruction sets limit cross-language support, and mainstream languages ​​are difficult to efficiently compile into EVM bytecode.

Advantages of RISC-V:

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

ZK optimization: In ZK proof, circuits are directly generated for RISC-V instructions, which is simpler than proving EVM operations.

Mature tool chain: supports mainstream languages ​​such as Rust/C/C++, with lower development threshold and broader ecosystem.

Universal standard: It has been adopted by blockchains such as Nervos CKB and has successful cases.

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

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

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

Three replacement options:

Dual VM coexistence (most conservative): EVM and RISC-V run in parallel, and new contracts can use RISC-V to ensure 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): Use the interpreter as a protocol element, allowing other VMs (such as Move) to be plugged in in the future.

Technical challenges faced in implementation:

Risk of performance degradation: RISC-V needs to be simulated on x86 chips, and its initial efficiency may be lower than that of an optimized EVM.

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

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

Development tool adaptation: Compilers, debuggers, and security audit tools need to be updated to support RISC-V bytecode.

Migration compatibility issues: Some contracts rely on EVM features, so migration requires careful design of a compatibility layer or fallback mechanism.

Vitalik prefers Option 1 as the transition path and promises that the old and new contracts will maintain interoperability, ensuring that the developer experience remains unchanged and users have no sense of upgrading.

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

The answer is no: RISC-V is an infrastructure optimization and will not replace the existing capacity expansion route.

Layer 2:

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

Data Sharding and EIP-4844:

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

The 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 become invalid due to the advancement of RISC-V.

In summary: RISC-V is "changing the engine", and L2/sharding is "expanding the network". The two are different in dimensions and can run in parallel.

4. Community Feedback and Related Attempts

Community divisions:

Supporters: They believe this is a necessary strategic upgrade to address performance challenges such as Solana/Sui and will help attract traditional developers.

Conservatives: They worry about the difficulty of implementation, historical baggage, and high cost of updating the ecological tool chain, and question the resource input-output ratio.

Similar project references:

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

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

WASM (Stylus): WASM is introduced as a contract language in L2 and has been implemented in Arbitrum, which is feasible.

Nervos CKB: The precedent of using RISC-V as a contract VM on the mainnet provides a practical reference for Ethereum.

Vitalik's proposal of RISC-V does not mean rejecting other options. He believes that the interpreter mechanism can also be used to insert VMs such as Move and WASM in the future to build a diversified execution ecosystem.

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

Developer Experience:

Languages ​​like Solidity/Vyper can still be used, the compiler backend changes rather than the language itself.

It is possible to open up new languages ​​such as Rust/C to write contracts, but migration will not be forced.

Operating costs and performance:

Improved execution efficiency will result in higher gas limits and lower fees.

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

Ecological compatibility and development:

During the period of dual VM coexistence, 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 cause changes in inter-chain compatibility (such as the issue of whether BSC and Polygon should be retained).

Security and stability:

The new architecture requires extensive testing and formal verification to improve the reliability of the protocol.

A cleaner execution layer facilitates auditing and attack surface control.

Conclusion

Vitalik proposed to replace Ethereum EVM with RISC-V, which represents Ethereum's deep thinking on the future performance limit and protocol simplicity. This proposal is still in the early discussion stage, and it is expected that implementation will be a process that will take several years and will need to overcome multiple challenges in technology, community, and ecology. It is not to overturn the existing route, but to strengthen the foundation and prepare for the future.

As Vitalik said, “To achieve orders of magnitude improvements, this radical change may be the only viable path.”

We might as well regard it as a bet on the future and an in-depth exploration of whether the bottom layer is worth reshaping.

References:

https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617