Vitalik Buterin once again stands at the forefront of Ethereum technology, this time proposing a bold idea capable of shaking the entire Ethereum execution layer: replacing the existing Ethereum Virtual Machine (EVM) with RISC-V. Over the past decade, EVM has become synonymous with smart contract platforms; it is the foundation on which Solidity and Vyper code run, and the underlying 'engine' relied upon by Rollup and L2 architectures. However, in Vitalik's view, this 'engine' has gradually exposed numerous issues that are incompatible with modern demands.
Original text: https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
So why RISC-V? Why propose it now? What grand vision and technical challenges lie behind this?
First, although EVM is solid, it is structurally 'aging'. EVM uses a 256-bit stack structure, essentially designed as a virtual computing architecture for blockchain security and determinism, yet this architecture diverges significantly from the way modern world CPUs operate, making any ZK (zero-knowledge) proof-based system require significant resources when attempting to simulate EVM—spending vast resources to prove 'this code runs like EVM', rather than performing actual business logic processing.
Thus, the bottleneck currently faced by ZK-EVM has emerged: it is slow, not because ZK technology itself is not advanced enough, but because it has to simulate a virtual machine that is not sufficiently simple and hard to prove. Ironically, in these ZK systems, EVM code is often 'converted' to another format for processing—RISC-V.
Vitalik's proposal is a logical step: 'Since all ZK systems ultimately have to translate EVM into RISC-V, why not let smart contracts run natively on RISC-V?' It's like typing in pinyin and having to convert it to Chinese characters every time, until one day someone finally says, 'Can we recognize voice input directly?'
RISC-V is a real-world instruction set architecture used for CPUs, characterized by its simplicity, modularity, and open-source nature. Its design philosophy is modern, and it has a mature hardware and software ecosystem supporting it. It is naturally suited for generating ZK circuits—within the ZK world, proving the correctness of a RISC-V instruction is much simpler than proving an EVM instruction. Vitalik cited data from several experimental projects, believing that if RISC-V were directly used as the contract execution architecture, ZK proof speeds would increase by 50 to 100 times, meaning that generating a proof for an Ethereum block, which currently takes several minutes, could be reduced to a few seconds, representing a qualitative leap for Ethereum L1 and various Rollups.
Of course, the familiar Solidity and Vyper languages can still be retained; however, their compiled target language will no longer be EVM bytecode, but RISC-V instructions. In other words, for most developers, this is almost an 'unnoticed replacement', and they may not even realize that the underlying architecture has changed. Vitalik also proposed three compatibility paths to address transitional challenges:
Dual virtual machines coexist: EVM and RISC-V exist simultaneously, allowing new contracts to choose RISC-V while old contracts remain unchanged. This is the safest and most compatible approach.
On-chain interpreter encapsulation: running EVM as a 'subsystem' on RISC-V, effectively simulating EVM on-chain using RISC-V. This method is radical yet unified.
Interpreter plug-in mechanism: allowing the protocol layer to support multiple virtual machines (such as future Move VM, WASM, etc.), with RISC-V as the default option but not exclusive, providing extensibility.
There are clearly significant technical challenges as well. For instance, the Gas model of RISC-V needs to be redesigned; how to ensure the deterministic execution of smart contracts without standard library support; and many security tools, debuggers, and auditing frameworks must be redeveloped. Ecological reconstruction is a considerable undertaking that cannot be underestimated.
At the community level, this proposal has sparked immense discussion. Radicals believe this is exactly the strategic upgrade Ethereum needs to compete with emerging high-performance chains like Solana, Sui, and Aptos, marking a necessary step towards 'next-generation Ethereum'; while conservatives are concerned about the implementation difficulties and engineering costs, fearing that the ecological migration costs are hard to estimate and could lead to compatibility chaos and toolchain disruptions.
Sui co-founder Sam Blackshear even publicly stated that if he were to redesign blockchain, he would directly adopt the Move language, as Move is stronger in resource management and security. However, he also acknowledged that for the current Ethereum, RISC-V is a realistic and reasonable alternative.
It is worth noting that Ethereum does not intend to use RISC-V to 'replace scaling solutions'. Layer 2, EIP-4844 data sharding, MEV mitigation solutions, etc., will continue to advance. RISC-V is more about underlying improvements at the 'engine replacement' level, rather than direct scaling methods. However, this new engine may allow Ethereum's future scaling to run faster, more steadily, and more effortlessly.
Vitalik's proposal is not something like 'Ethereum 2.5' that can go live tomorrow; it is more like a long-term directional roadmap: in the coming years, when the toolchain is ready and community consensus is established, RISC-V may gradually become Ethereum's true 'new core'.
In this era where all founders have long retreated behind the scenes and only market noise remains, Vitalik is still willing to 'write proposals himself', delving into technical details to drive a structural transformation that could open up a hundredfold space for on-chain computing efficiency. This dedication and persistence is one of the underlying reasons Ethereum continues to lead.
Guardians, do you support this decision?
