RISC-V may become the future alternative to Ethereum Virtual Machine

Recently, the co-founder of Ethereum proposed a long-term proposal to replace the current execution layer virtual machine (EVM) with the open-source RISC-V instruction set architecture. This idea has been likened to the consensus layer's Beam Chain and is considered the potential only pathway to achieve breakthroughs in execution layer performance and simplify protocol logic. Especially in terms of zero-knowledge proof (ZK Proof) efficiency, it is expected that replacing the EVM could achieve up to 100 times optimization improvement. The proposal aims to address the current bottleneck issues of Ethereum in ZK proof efficiency, block construction complexity, and data availability.

Limitations of Current EVM and Advantages of RISC-V

The issue with EVM:

1. Outdated architecture: EVM uses a 256-bit stack structure, which is incompatible with modern CPUs, resulting in low efficiency when executing ZK-EVM.
2. ZK proof bottleneck: About half of the resources are used to execute the EVM itself, limiting the efficiency of ZK proofs.
3. Poor maintainability: Over the years, the accumulation of complex functions has led to a chaotic standard, making it difficult to abolish certain functions.
4. Development Limitations: Non-standard instruction set restricts cross-language support, making it difficult for mainstream languages to be efficiently compiled into EVM bytecode.

Advantages of RISC-V:

1. High performance: RISC-V is a reduced instruction set for real CPUs, hardware-friendly, and can be used for JIT optimization and even hardware acceleration.
2. ZK Optimization: Directly generating circuits for RISC-V instructions in ZK proofs is simpler than proving EVM operations.
3. Mature toolchain: Supports mainstream languages such as Rust/C/C++, lowering the development threshold and broadening the ecosystem.
4. General Standards: Some blockchain projects have adopted them, with successful cases.

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

Replacement Path and Challenges

Three replacement options:

1. 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.
2. On-chain Interpreter Scheme (Radical): All EVM contracts are interpreted and executed by on-chain RISC-V contracts.
3. Interpreter Plugin Mechanism (Compromise): Treat the interpreter as a protocol element, allowing the future insertion of other VMs.

Technical challenges faced in implementation:

1. Execution performance degradation risk: RISC-V needs to be simulated on x86 chips, which may result in initial efficiency being lower than that of the optimized EVM.
2. Gas pricing needs to be restructured: a new Gas model needs to be defined for RISC-V instructions to ensure fairness and security.
3. Secure sandbox design: restrict system calls, prevent self-modifying code, ensure deterministic execution.
4. Development tools adaptation: It is necessary to update the compiler, debugger, and security audit tools to support RISC-V bytecode.
5. Migration Compatibility Issues: Some contracts rely on EVM features, so migration requires careful design of compatibility layers or fallback mechanisms.

The co-founder of Ethereum favors Option One as the transitional path and promises that the new and old contracts will maintain interoperability, ensuring that the developer experience remains unchanged and users experience a seamless upgrade.

Impact on Existing Scalability Solutions

RISC-V is an infrastructure optimization and will not replace the existing scaling solutions.

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 validation can help Rollup submit data at a lower cost and more quickly, improving overall scalability.

Data Sharding and EIP-4844:

• The data availability bottleneck still needs to be resolved by EIP-4844 (blob) and Danksharding, while 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:

• Not related to the 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 Expansion Network", both are different dimensions and do not contradict each other.

Community Feedback and Related Attempts

Community Disagreement:

• Supporters: believe this is a necessary strategic upgrade to address challenges from other high-performance blockchains and helps attract traditional developers.
• Conservatives: Concerned about implementation difficulties, historical burdens, and high costs of updating ecological toolchains, questioning the resource input-output ratio.

Similar project references:

• Move VM: 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 Sway language, with limited compatibility.
• WASM (Stylus): Introducing WASM as a contract language in L2, which has been implemented in a certain L2 and is feasible in practice.
• A certain blockchain project: the use of RISC-V as a contract VM on the mainnet sets a precedent and provides practical reference for Ethereum.

The co-founder of Ethereum stated that the proposal of RISC-V does not mean rejecting other options; he believes that future interpreter mechanisms can also be used to integrate VMs such as Move and WASM, building a diverse execution ecosystem.

Future Impact Outlook

Developer Experience:

• Languages such as Solidity/Vyper can still be used, as the compiler backend has changed rather than the language itself.
• It may open up new languages such as Rust/C for writing contracts, but migration is not mandatory.

Operating Costs and Performance:

• Improved execution efficiency will bring 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:

• Existing contracts can continue to run during the dual VM coexistence period, and new contracts will gradually adopt RISC-V.
• The infrastructure needs to support the new bytecode format, which may cause inter-chain compatibility changes.

Security and Stability:

• The new architecture requires extensive testing and formal verification to enhance protocol reliability.
• A more streamlined execution layer is beneficial for audit and attack surface control.

Conclusion

The co-founder of Ethereum proposed replacing the Ethereum EVM with RISC-V, representing Ethereum's deep reflection on the future limits of performance and the simplicity of protocols. This proposal is still in the early discussion stage, and its implementation is expected to be a process that takes several years, requiring overcoming multiple 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 the co-founder of Ethereum 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."