Author | GaryMa Wu Says Blockchain
Introduction
Ethereum co-founder Vitalik Buterin recently proposed a long-term initiative 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 potential only path to achieving breakthroughs in execution layer performance and simplifying protocol logic. Particularly in terms of zero-knowledge proof (ZK Proof) efficiency, Vitalik anticipates that replacing the EVM could achieve up to a 100-fold optimization improvement. This proposal aims to address the current bottlenecks Ethereum faces in ZK proof efficiency, block construction complexity, and data availability.
This article will explain the motivations, technical details, implementation paths, and challenges of this proposal in layman's terms, explore its impact on Ethereum's existing scaling routes, and review community reactions and similar attempts.
I. Limitations of the Current EVM and Advantages of RISC-V
Problems with EVM:
Outdated architecture: The EVM uses a 256-bit stack structure, which is incompatible with modern CPUs, leading to inefficiencies when executing ZK-EVM.
ZK proof bottleneck: As noted by Succinct, about half of the resources in ZK-EVM are used to execute the EVM itself, limiting ZK proof efficiency.
Poor maintainability: Over the years, complex features have accumulated, leading to chaotic specifications, making it difficult to abolish features like SELFDESTRUCT.
Development limitations: The non-standard instruction set restricts cross-language support, making it challenging for mainstream languages to efficiently compile into EVM bytecode.
Advantages of RISC-V:
High performance: RISC-V is a streamlined instruction set for real CPUs, hardware-friendly, and can be used for JIT optimization or even hardware acceleration.
ZK optimization: Generating circuits directly from RISC-V instructions in ZK proofs is simpler than proving EVM operations.
Mature toolchain: Supports mainstream languages like Rust/C/C++, lowering development barriers and expanding the ecosystem.
Universal standard: Already adopted by blockchains like Nervos CKB, with successful case studies.
Vitalik pointed out that instead of compiling the EVM into RISC-V in ZK-EVM, it would be better to use RISC-V directly as the contract execution architecture, fundamentally improving execution efficiency and scalability potential.
II. Replacement Path and Challenges: How to Migrate from EVM?
Three Replacement Options:
Dual VM coexistence (most conservative): EVM and RISC-V run in parallel, allowing new contracts to 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 future insertion of other VMs (like Move).
Technical challenges in implementation:
Execution performance degradation risk: RISC-V may need to be simulated on x86 chips, potentially resulting in lower initial efficiency than an optimized EVM.
Gas pricing needs reconstruction: A new Gas model must be defined for RISC-V instructions to ensure fairness and security.
Security sandbox design: Limiting system calls, preventing self-modifying code, and ensuring deterministic execution.
Development tool adaptation: Updating compilers, debuggers, and security audit tools to support RISC-V bytecode.
Migration compatibility issues: Some contracts depend on EVM features, requiring careful design of compatibility layers or fallback mechanisms during migration.
Vitalik favors option one as a transitional path and promises that new and old contracts will maintain interoperability, ensuring a consistent developer experience and a seamless upgrade for users.
III. Impact on Existing Scaling Routes: Will RISC-V Replace L2, Data Sharding, etc.?
The answer is no: RISC-V is an infrastructure optimization and will not replace existing scaling routes.
Layer 2:
Rollup remains the main force for Ethereum scaling; RISC-V improves L1 processing efficiency and ZK verification performance, rather than directly expanding throughput.
Faster L1 verification can help Rollup submit data at lower costs and faster speeds, enhancing 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.
Changes in execution architecture do not alter L1's data storage requirements.
FaaS, MEV:
Unrelated to the virtual machine architecture, they will not become obsolete due to the advancement of RISC-V.
In summary: RISC-V is an "engine swap," while L2/sharding is a "road network," with both dimensions being different yet parallel.
IV. Community Feedback and Related Attempts
Community Divisions:
Supporters: View this as a necessary strategic upgrade to address performance challenges from Solana/Sui, helping to attract traditional developers.
Conservatives: Concerned about implementation difficulties, historical burdens, and the high costs of updating the ecosystem toolchain, questioning the cost-benefit ratio of resource investment.
Similar Project References:
Move VM (Aptos/Sui): A new resource-oriented VM with strong language safety but incompatible with EVM.
FuelVM: A new VM designed for parallel processing, paired with the Sway language, with limited compatibility.
WASM (Stylus): Introduced WASM as a contract language in L2, already implemented in Arbitrum, demonstrating practical feasibility.
Nervos CKB: A precedent for using RISC-V as a contract VM on the mainnet, providing practical reference for Ethereum.
Vitalik proposed that RISC-V does not mean rejecting other options; he believes that future interpreter mechanisms could also be used to insert VMs like Move, WASM, etc., to build a diverse execution ecosystem.
V. Future Impact Outlook: What If Ethereum Switches to RISC-V
Developer Experience:
Languages like Solidity/Vyper can still be used, with changes occurring in the compiler backend rather than the languages themselves.
It may open up new languages like Rust/C for writing contracts, but migration will not be mandatory.
Operating Costs and Performance:
Improvements in execution efficiency will lead to higher Gas limits and lower fees.
RISC-V contracts may reduce reliance on precompiled contracts, with a Gas model more closely aligned with ZK proof costs.
Ecosystem Compatibility and Development:
During the dual VM coexistence period, existing contracts can continue to run, while new contracts gradually adopt RISC-V.
Infrastructure will need to support the new bytecode format, which may trigger inter-chain compatibility changes (e.g., BSC, Polygon retention issues).
Security and Stability:
The new architecture will require extensive testing and formal verification to enhance protocol reliability.
A more streamlined execution layer will facilitate auditing and control of attack surfaces.
Conclusion
Vitalik's proposal to replace the Ethereum EVM with RISC-V represents a deep reflection on Ethereum's 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, requiring overcoming multiple technical, community, and ecological challenges. It is not about overturning the existing route but rather 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 consider it a bet on the future and a profound exploration of whether the underlying structure is worth reshaping.
Source Reference:
https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
