Ethereum's RISC-V Gambit: Why Vitalik Wants to Rip Out the EVM and What It Means for Every dApp Developer

What if the engine powering $600 billion in smart contracts was holding Ethereum back by orders of magnitude? That is the provocative thesis Vitalik Buterin put forward in April 2025 — and doubled down on in March 2026 — when he proposed gradually replacing the Ethereum Virtual Machine (EVM) with RISC-V, an open-source CPU instruction-set architecture. The move could unlock 100x efficiency gains in zero-knowledge proving, but it also threatens to reshape the developer experience, ignite an architecture war with WebAssembly advocates, and force the entire Ethereum ecosystem to rethink what a blockchain virtual machine should look like.

The EVM's Hidden Tax

The EVM was revolutionary in 2015. A 256-bit stack machine designed for trustless computation, it gave birth to an ecosystem of 4,000+ decentralized applications and made "smart contract" a household term. But a decade of production use has exposed structural limitations that no amount of incremental optimization can fix.

The core problem is overhead. The EVM runs as a software interpreter on modern 64-bit CPUs, translating every opcode through an abstraction layer that was never designed for raw performance. For ordinary transaction execution, this overhead is manageable. For zero-knowledge proof generation — the technology Ethereum's roadmap increasingly depends on — it is devastating.

Today's ZK provers already work by translating EVM bytecode into RISC-V internally before generating proofs. This double translation introduces what Buterin describes as an "800x overhead" in zkVM proving times. The state tree and the VM together account for more than 80 percent of the bottleneck in efficient proving, meaning that no matter how fast provers get, the EVM itself remains the ceiling.

Enter RISC-V: The 100x Opportunity

RISC-V is an open-source instruction-set architecture (ISA) born from two decades of CPU research at UC Berkeley. Unlike proprietary architectures from ARM or Intel, RISC-V is modular, extensible, and royalty-free. Its register-based design maps cleanly onto modern hardware, and its simplicity — a minimal RISC-V interpreter can be written in a few hundred lines of code — makes it ideal for formal verification.

The performance case is compelling. By executing smart contracts natively in RISC-V rather than interpreting EVM bytecode, Ethereum could:

• Eliminate the double-translation penalty: ZK provers would no longer need to convert EVM to RISC-V before generating proofs, potentially reducing proving overhead by 50–100x.
• Simplify the protocol: System operations like SLOAD and CALL would become syscalls rather than custom opcodes, reducing the attack surface and maintenance burden.
• Leverage existing tooling: RISC-V already has mature GCC and LLVM compilers, QEMU emulators, and formally verified toolchains — a support ecosystem the EVM can never match.
• Align with the ZK ecosystem: Major zkVMs including Succinct's SP1, RISC Zero, a16z's Jolt, Axiom's OpenVM, and Polygon's Miden are all built on RISC-V, creating a natural convergence point.

The numbers from production systems back this up. Succinct's SP1 Hypercube can generate zero-knowledge proofs for Ethereum blocks in under 12 seconds on 16 NVIDIA RTX 5090 GPUs. RISC Zero's R0VM 2.0 cut proof times from 35 minutes to 44 seconds. These gains were achieved while still working through the EVM translation layer — native RISC-V execution would amplify them further.

The Three-Phase Migration Plan

Buterin's proposal is not a reckless rewrite. It is a carefully staged migration designed to maintain backward compatibility throughout:

Phase 1 — Precompile Replacement: RISC-V code replaces roughly 80% of Ethereum's existing precompiled contracts. These are the cryptographic and arithmetic operations (like elliptic curve pairings and SHA-256 hashing) that currently exist as hardcoded native functions. By implementing them in RISC-V, the protocol becomes more auditable and extensible without sacrificing performance.

Phase 2 — Dual VM Deployment: Developers gain the ability to deploy smart contracts compiled to RISC-V bytecode alongside existing EVM contracts. Solidity and Vyper code would be compiled to RISC-V rather than EVM bytecode — the developer experience remains familiar, but the execution layer changes underneath.

Phase 3 — EVM Retirement: The EVM itself becomes a smart contract written in RISC-V. Every existing EVM contract continues to run exactly as before, executed by this "EVM-in-RISC-V" interpreter. The only user-facing change would be shifts in gas costs as the new architecture reprices operations.

This final phase is the most elegant part of the proposal. Rather than breaking backward compatibility, it preserves it entirely — the EVM does not disappear; it becomes a library running on a more efficient foundation.

The EIP-7864 Companion: Binary State Trees

In March 2026, Buterin expanded the proposal with EIP-7864, which addresses the other half of the proving bottleneck: Ethereum's state tree. The current hexary Keccak Merkle Patricia Tree would be replaced with a binary tree using a more efficient hash function — either Blake3 or a Poseidon variant.

The impact is substantial:

• Merkle branches become four times shorter, cutting data bandwidth for light clients like Helios
• Hash function substitution delivers an additional 3–100x improvement in proving efficiency
• Combined with the VM change, the two upgrades target the 80%+ of proving costs that currently constrain Ethereum's scaling

Buterin's sequencing is deliberate: binary trees first (potentially in the Glamsterdam or Hegota upgrades in 2026), followed by VM replacement once the proving infrastructure matures.

The WASM Counter-Argument

Not everyone is convinced RISC-V is the right answer. In November 2025, researchers from Offchain Labs — the team behind Arbitrum — published a detailed technical rebuttal arguing that WebAssembly (WASM) is the better long-term choice.

Their core argument hinges on an important distinction: the "Delivery ISA" (the format in which contracts are stored and distributed) and the "Proof ISA" (the format used for ZK proving) do not need to be the same. Offchain Labs is already demonstrating this in practice — Arbitrum blocks, including WASM-based Stylus smart contracts, are ZK-proven by compiling WASM to RISC-V at proof time.

The WASM camp raises several concerns:

• Hardware compatibility: Most Ethereum nodes lack RISC-V CPUs and would require emulation, while WASM runs natively across billions of execution environments.
• Ecosystem lock-in: Enshrining RISC-V on L1 could lock Ethereum into a specific proving technology just as better alternatives emerge.
• Tooling maturity: WASM's tooling ecosystem is battle-tested across web browsers, cloud infrastructure, and edge computing.
• Emerging alternatives: WASM-based ZK-VMs like Ligero's Ligetron are already demonstrating advantages that hardware-focused ISAs may not match.

The debate is far from settled. Both sides agree that the EVM needs to evolve; they disagree on whether the execution format should optimize for proving (RISC-V) or for deployment flexibility (WASM).

Polkadot's Parallel Bet

Ethereum is not the only blockchain embracing RISC-V. Polkadot's JAM protocol, progressing toward its 1.0 specification, uses PolkaVM — an ahead-of-time recompiler based on RISC-V — as its execution engine. The JAM mainnet upgrade is targeted for Q1 2026, with block speeds increasing 10x to 500-millisecond blocks.

Polkadot's Revive project combines the RISC-V PolkaVM backend with a fully compliant EVM interpreter, allowing developers to choose between Ethereum compatibility and maximum Polkadot performance. This dual-mode approach mirrors the transition period Buterin envisions for Ethereum's Phase 2.

The convergence is notable: two of blockchain's largest ecosystems independently concluded that RISC-V offers the best path forward for high-performance smart contract execution.

What Changes for Developers

For the average Solidity developer, the immediate impact is surprisingly small. In the RISC-V future:

• Solidity and Vyper survive: Developers continue writing in familiar languages. The compiler backend changes from EVM bytecode to RISC-V bytecode, but the source code and development workflow remain largely the same.
• New language options emerge: Rust — the language already dominant in Solana, Polkadot, and NEAR development — becomes a first-class citizen for Ethereum smart contracts. This could attract developers from competing ecosystems.
• Gas costs shift: Operations will be repriced to reflect RISC-V execution costs rather than EVM opcode costs. Some operations become cheaper; others may become more expensive.
• Testing and tooling adapt: Frameworks like Hardhat and Foundry would need RISC-V compilation targets, though the existing LLVM infrastructure makes this more tractable than building EVM tooling from scratch.

The bigger change is philosophical. Ethereum's execution layer moves from a bespoke, blockchain-specific virtual machine to a general-purpose computing architecture backed by decades of academic research and industry tooling. This is not just a performance upgrade — it is a bet that blockchains should converge with mainstream computing rather than maintain separate infrastructure.

The Road Ahead

The RISC-V proposal does not yet have consensus within the Ethereum development community. The Glamsterdam and Hegota upgrades expected in 2026 will likely prioritize the state tree changes from EIP-7864, with VM replacement remaining a longer-term goal.

But the direction of travel is clear. The ZK proving ecosystem has already standardized on RISC-V. The performance data is unambiguous. And the backward-compatibility design means Ethereum can make this transition without breaking a single existing contract.

The real question is not whether Ethereum will eventually move beyond the EVM, but how quickly the community can align on the replacement — and whether RISC-V or WASM wins that debate. For developers building on Ethereum today, the message is reassuring: your Solidity contracts will keep running no matter what. But the smartest builders are already preparing for a world where Ethereum speaks RISC-V natively, and the 100x proving efficiency that comes with it.

BlockEden.xyz provides enterprise-grade RPC and API infrastructure for Ethereum and leading Layer 2 networks. As the execution layer evolves, our infrastructure adapts — ensuring developers can build on the cutting edge without managing the complexity underneath. Explore our Ethereum API services to future-proof your dApp infrastructure.