Vitalik Buterin’s Proposal: Replacing Ethereum’s EVM with RISC-V

In April 2025, Ethereum co-founder Vitalik Buterin unveiled a bold proposal to overhaul Ethereum’s core execution engine. He suggests replacing the Ethereum Virtual Machine (EVM) – the runtime that executes smart contracts – with RISC-V, an open-standard CPU instruction set architecture. Buterin argues this change could vastly improve efficiency (especially for zero-knowledge proofs) and simplify Ethereum’s execution layer in the long term. Importantly, this isn’t about abandoning Ethereum’s account model or smart contract languages; those remain the same. Instead, it’s about changing the low-level “machine language” in which contracts run. This introduction explains why Ethereum’s EVM faces challenges today, why RISC-V is being considered, how such a transition might work with minimal disruption, and what benefits and trade-offs come with this proposal.

Evolution of Ethereum’s Execution Layer –

Ethereum’s execution environment has remained largely the same since launch, but there have been attempts to improve it. Below is a brief timeline of key milestones in the evolution of Ethereum’s execution layer:

• 2015: Ethereum launches with the EVM as its smart contract runtime. The EVM is a 256-bit stack-based virtual machine custom-built for Ethereum.
• 2018: The Ethereum community explores eWASM (Ethereum-flavored WebAssembly) as a potential replacement for EVM in future Ethereum 2.0. This would allow smart contracts to run in a WebAssembly VM for better performance. However, the plan was never adopted on L1, and EVM remained in place.
• 2022: The Merge (Ethereum’s switch to Proof-of-Stake) occurs, still using the EVM for execution. The anticipated “Ethereum 2.0” changes to the execution engine were de-scoped in favor of focusing on scalability via Layer 2.
• 2023: Rise of ZK-EVMs – Layer 2 projects (e.g. Scroll, Polygon zkEVM) implement EVM-compatible rollups with zero-knowledge proofs. Notably, many ZK-EVM provers internally compile EVM bytecode into RISC-V instructions to generate proofs, because proving traditional EVM directly is inefficient. This demonstrated RISC-V’s advantages in practice for Ethereum-like computations.
• 2025: Vitalik Buterin proposes using RISC-V directly as Ethereum’s contract VM. This marks the first major L1 proposal to fundamentally change the execution layer since Ethereum’s inception.

Current EVM Inefficiencies

The Ethereum Virtual Machine has proven successful in enabling smart contracts, but it carries inefficiencies that are becoming more apparent as the network scales and new technologies (like zk-SNARKs) emerge. Key issues include:

• Execution Overhead: EVM executes contract bytecode in a stack-based, 256-bit architecture, which is not as efficient as standard CPU architectures. Complex arithmetic or loops run much slower on EVM than they would in native machine code. For example, executing intensive computations (like a large Fibonacci calculation) on the EVM can be up to 800× slower than on a native RISC-V machine. This overhead means higher gas costs for complex tasks.
• ZK-Proof Bottlenecks: As Ethereum pushes into zero-knowledge proofs (for zkRollups and privacy), the EVM has become a bottleneck for provers. Zero-knowledge circuits that prove Ethereum transactions essentially need to simulate EVM execution, which is costly. Recent data shows that roughly half of the proving time in zkEVM systems is spent on simulating EVM contract execution. Because of this, many zkEVM projects convert EVM bytecode into RISC-V to leverage simpler circuits. The need to emulate EVM for proofs adds complexity and slowing down proofs.
• Complexity and Maintenance: The EVM’s design is Ethereum-specific, with many opcodes (instructions) and quirks accumulated over years (e.g. specialized opcodes for SHA3, SELFDESTRUCT semantics, etc.). Making even minor changes to the EVM (such as removing or altering an opcode like SELFDESTRUCT) has proven very difficult without breaking backward compatibility. This complexity can hinder Ethereum’s evolution – the execution layer spec is fairly intricate, which increases the burden on client developers and auditors.
• Limited Tooling: Because EVM is unique to Ethereum, the developer tools and optimizations available are limited compared to those for mainstream hardware architectures. Smart contract languages (Solidity, Vyper) compile to EVM bytecode, but one cannot easily write an Ethereum smart contract in a general-purpose language like C or Rust and compile it to EVM without using special toolchains. This limits cross-pollination of optimizations from outside the Ethereum ecosystem.

Why RISC-V for Ethereum?

RISC-V (pronounced “risk-five”) is an open standard Reduced Instruction Set Computer (RISC) architecture gaining popularity in the computing world. It provides a simple, modular set of CPU instructions that anyone can implement, free of charge. By proposing RISC-V as the new execution environment for Ethereum smart contracts, Buterin hopes to leverage several advantages:

• Dramatically Improved Prover Efficiency: RISC-V’s simpler instructions are much friendlier for zero-knowledge proof generation. Proving basic RISC-V operations (simple adds, memory loads, etc.) is easier than proving complex EVM opcodes. Buterin notes that if contracts run directly on a RISC-V VM, the overall cost of generating zk-proofs could drop by over 100×. This is because today’s zkEVM systems already incur overhead translating EVM to RISC-V; cutting out the “middle man” (EVM) means fewer steps to prove. In fact, data shows EVM-based computation can be hundreds of times less efficient than native execution – for example, EVM running a heavy loop versus native RISC-V differed by up to 800× in one benchmark. By switching to RISC-V, Ethereum can tap directly into the performance of a leaner machine code, making zk-rollups and Layer 1 verification far more scalable.
• Standardization and Tooling: Unlike EVM, RISC-V is a standard ISA used widely in academia and industry. This means a vast ecosystem of development tools (compilers, debuggers, optimizers) already exists. Developers could potentially write smart contracts in languages like Rust or C and compile them to RISC-V, or continue using Solidity/Vyper which would target a RISC-V backend. The learning curve for most smart contract devs would be minimal – they might not even notice the change if their high-level language is compiled down to RISC-V instead of EVM. Meanwhile, Ethereum could benefit from decades of compiler optimizations and even special hardware support available for RISC-V. For instance, RISC-V supports extensions (like cryptographic instruction sets) which could accelerate hashing or signature verification in smart contracts​. In short, Ethereum’s execution layer would no longer be a niche custom VM, but align with a modern, well-supported architecture.
• Modularity and Future-Proofing: RISC-V’s modular design (a base instruction set with optional extensions) offers flexibility. Ethereum can start with a minimal RISC-V subset for smart contracts, and potentially enable certain extensions if needed (e.g., for arithmetic or cryptography) to optimize performance. Moreover, adopting RISC-V could open the door to supporting multiple languages/VMs on Ethereum. Buterin mentions the idea of a “VM interpreter” system where the EVM could be just one of many virtual machines running on top of the RISC-V base. In the future, new contract languages (for example, Facebook’s Move or WebAssembly-based contracts) could be supported by writing an interpreter for them in RISC-V. This modularization means Ethereum’s base layer would be agnostic – it executes RISC-V instructions, and any language can ride on top via compilation or interpretation. That kind of flexibility is hard to achieve with the EVM today.
• Simpler Execution Semantics: Replacing EVM with a clean, well-defined RISC-V model could greatly simplify Ethereum’s execution layer specification. Currently, Ethereum clients must implement the entire EVM spec with all its edge cases. If Ethereum instead uses RISC-V, much of the execution behavior is defined by the RISC-V standard, and Ethereum-specific logic could be reduced to a few syscalls (for blockchain-specific actions like accessing state, balances, etc. as “RISC-V syscalls” replacing opcodes like SLOAD, CALL). Vitalik believes that simplifying the execution layer in this way may be the only practical path to long-term sustainability, given how difficult incremental simplifications have been so far. A leaner core means fewer consensus-critical changes and easier maintenance over time.

RISC-V vs EVM: Efficiency Comparison

The table below highlights some differences between the current EVM and a RISC-V based VM in the context of Ethereum:

Backward Compatibility and Migration Plan

A crucial question is how to adopt RISC-V without disrupting the countless existing smart contracts and dApps running on Ethereum. Buterin’s proposal emphasizes a gradual transition with full backward compatibility. In practice, this could be achieved through a dual-VM approach and clever translation mechanisms:

• Dual VM Coexistence: Ethereum could support two virtual machines in parallel – the existing EVM and the new RISC-V VM. New smart contracts could be deployed targeting RISC-V, while all existing contracts remain on the EVM. The two environments would be able to call each other seamlessly. For example, a RISC-V contract could call into an EVM contract as if it were making a syscall or normal external call, and an EVM contract could call a RISC-V contract similarly. This two-way interoperability means developers wouldn’t have to migrate everything at once. Existing Solidity contracts keep running as is, and over time more projects might choose the RISC-V path for performance. During this period, Ethereum’s nodes would execute both EVM and RISC-V code, maintaining a unified state and account space.
• EVM Interpreter (Transitional Solution): Another option is to convert or “wrap” existing EVM contracts so that they internally run on the RISC-V VM. Buterin suggests deploying an EVM interpreter written in RISC-V. Essentially, the idea would be: each legacy contract’s bytecode could be replaced (at the protocol level) with a stub that invokes a generic EVM interpreter contract, passing it the contract’s code and input. The interpreter (running on the RISC-V VM) would then execute the EVM bytecode and return the result. This way, the Ethereum chain could eventually run all contract code on the RISC-V VM, even for old contracts, without those contracts needing to be manually rewritten. It’s a more radical approach, but it would unify execution under one engine (RISC-V) while still honoring the semantics of existing contracts.
• Phased Introduction: In either case, the shift to RISC-V would be done in phases. For example, a network upgrade (“fork”) could introduce the RISC-V VM as an option, while keeping EVM default. Developers could start deploying some contracts to RISC-V to test the waters. Over time – potentially years – if the RISC-V path proves stable and advantageous, the community might decide to make it the default for new contracts. The final step (if ever) could be deprecating the EVM once it’s mostly unused, but this would be far in the future. Buterin explicitly notes EVM will not be immediately phased out and both VMs should coexist for a long period. This cautious approach ensures that Ethereum’s existing ecosystem is not suddenly broken by the change.

Maintaining backward compatibility is paramount for trust. Users and developers should be able to choose when to opt in to the new system. By having a dual-VM or interpreter-based strategy, Ethereum can migrate to RISC-V gradually, with minimal disruption. In essence, Ethereum would add RISC-V as a new foundation while carrying the EVM on its shoulders until it’s safe to set it down.

Benefits and Trade-offs

Transitioning Ethereum’s execution layer to RISC-V offers clear benefits: vastly improved proving performance, alignment with industry standards, and a cleaner, more modular architecture. It could future-proof Ethereum by making the core simpler and more adaptable. If successful, this change might significantly lower Layer-1 gas costs for complex transactions (since proving and execution overhead would drop), and redefine the performance baseline for Ethereum compared to other chains. It’s a bold move that, as some have noted, could “reshape the execution efficiency of smart contracts” and help Ethereum maintain its competitive edge.

However, there are important trade-offs and challenges to consider:

• Engineering Complexity: Implementing a dual-VM system or an on-chain interpreter is non-trivial. Ethereum client software would need to integrate a RISC-V execution engine and ensure it deterministically replicates across all nodes. This adds development and maintenance work. Tooling and infrastructure (block explorers, debuggers, etc.) would need updates to understand RISC-V contract code.
• Transitional Overhead: In the interim period of supporting two VMs, node operators might face higher resource usage (as they must support executing both EVM and RISC-V transactions). There could be subtle bugs or security considerations in the inter-VM call interface that need thorough auditing.
• Performance on Native Hardware: One concern raised by developers is how well RISC-V code will run on the hardware that Ethereum nodes use today (mostly x86_64 CPUs). EVM, being high-level, has some operations (like 256-bit arithmetic) that Ethereum clients often optimize with native libraries or CPU extensions. If everything is expressed in RISC-V (which might be 64-bit based), those operations would break down into many smaller instructions. This could make normal block execution slower on actual hardware, unless just-in-time compilers or other optimizations are used. In other words, we trade off some L1 execution speed to gain proving speed. This trade-off will need to be measured and optimized – for example, clients might use a JIT compiler to translate RISC-V to x86 code on the fly for fast execution on miners/validators.
• Ecosystem Adoption: Even if the protocol supports RISC-V, the community must embrace it. Developers need to be confident to deploy contracts to a new VM. Audit tools and best practices will have to evolve. It might take time before RISC-V contracts are as battle-tested as EVM contracts. There could be resistance or slow uptake, especially if benefits are mostly seen in zk-proof contexts that many application developers don’t directly feel.
• Long-Term Maintenance: If Ethereum eventually fully migrates to RISC-V, it inherits the responsibility of maintaining a fork or version of the RISC-V spec for blockchain use. While RISC-V is stable, Ethereum might still need to decide which instruction set extensions to allow, how to handle upgrades, etc. The upside is Ethereum’s core execution logic could become simpler (a goal Vitalik highlighted: keeping base layer code small), but it shifts some complexity into higher layers (like the interpreter for EVM or other VMs).

Overall, the benefits appear to outweigh the downsides if executed carefully, but it will require careful coordination and testing. Ethereum underwent a similarly ambitious transition with The Merge (PoS), and that success gives confidence. Still, an execution layer change affects every contract and transaction, so it must be done with extreme caution and extensive community buy-in.

Conclusion

Vitalik Buterin’s proposal to replace the EVM with RISC-V represents a significant long-term vision for Ethereum’s evolution. It addresses pressing inefficiencies in today’s execution layer – especially in the context of zero-knowledge proofs and scalability – by aligning Ethereum with a lean, widely-supported machine architecture. The change promises a more efficient prover, a simplified execution model, and greater flexibility for the future of smart contracts. At the same time, it underscores Ethereum’s commitment to pragmatism: backward compatibility and gradual migration are integral to the plan, ensuring the network can continue to run smoothly throughout the transition.

If the Ethereum community eventually adopts this approach, it could mark one of the most fundamental upgrades in Ethereum’s history, akin to a “hardware swap” for the world computer’s CPU. But such a shift will require years of careful work, research, and consensus-building. The coming discussions and prototypes (for instance, Ethereum client teams experimenting with RISC-V execution, or testnets trying dual VM support) will provide valuable insights. This proposal invites researchers, developers, and stakeholders to re-imagine what the Ethereum execution layer can be when freed from its original design constraints.

In summary, moving from EVM to RISC-V could unlock new levels of performance and simplicity for Ethereum, helping ensure that the platform remains robust and adaptable for the decade ahead. It’s a bold bet on proven technology (RISC-V) to secure Ethereum’s place in a future where efficiency and modularity are key. As the idea matures, the community will weigh the benefits against the costs, but the very fact it’s on the table demonstrates Ethereum’s willingness to evolve. The execution layer that started in 2015 may not be the one Ethereum uses in 2030 – and that could be a change for the better.