Ethereum’s execution layer has come a long way, but it’s no secret: the EVM is starting to show its age. In a recent post, Vitalik Buterin proposes one of the boldest ideas yet for Ethereum’s long-term evolution:

Replace the Ethereum Virtual Machine (EVM) with RISC-V.

Yes — the same open-source instruction set architecture (ISA) that’s powering next-gen chips in the hardware world. But what does that even mean for Ethereum? And why would you want to swap out the EVM, the very engine that powers smart contracts?

Let’s break it down.

What’s the Proposal?

The core idea: rebuild Ethereum’s execution layer on top of RISC-V, a minimal and modular ISA that’s well-suited for clean and efficient computation — including proving with zero-knowledge systems.

Smart contracts would still be written in Solidity or Vyper. But instead of compiling down to EVM bytecode, they’d compile to RISC-V instructions.

Critically, core Ethereum abstractions — accounts, balances, storage, CALLs — stay intact. Devs wouldn’t feel much difference in the tooling. Under the hood, however, a huge architectural shift would be happening.

Why Change the EVM?

The EVM was built in 2014. It’s served Ethereum well, but it wasn’t designed for today’s needs — especially zk-rollup scalability and verifiability.

Here’s the core issue:

ZK-EVMs, which let us prove Ethereum state transitions, are slow and expensive to operate. A big chunk of this cost comes from proving EVM execution logic itself. For example:

• EVM deserialization

• State root calculations

• Execution of EVM opcodes

• Database access patterns

These are not ZK-friendly by default.

Interestingly, today’s zkEVMs already compile EVM logic down to RISC-V before generating proofs. This “EVM → RISC-V → proof” path introduces a lot of overhead.

So… why not skip the EVM?

Why not just let devs write contracts that target RISC-V directly, and eliminate the need to emulate EVM logic altogether?

Vitalik argues that this switch could lead to 10x–100x gains in ZK prover efficiency.

How Would It Work?

There are three main implementation paths, each with trade-offs:

1. Dual VM Support

Run both the EVM and a new RISC-V VM in parallel. Contracts can call across VMs, and developers can choose which VM to target.

Pros: Non-disruptive, backwards compatible
Cons: Increases complexity in the short term

2. EVM as a Contract (VM Interpreter)

Encapsulate the EVM inside a RISC-V contract. Legacy contracts become simple wrappers that delegate to this EVM interpreter.

Pros: Preserves all EVM behavior, simplifies L1 execution logic
Cons: Requires migration work and new tooling

3. Protocol-Level VM Abstraction

Enshrine the concept of VM interpreters in the protocol itself. EVM becomes the first “interpreter contract”, but the architecture allows others — like Move or WASM — in the future.

Pros: Future-proof, clean architecture
Cons: Requires protocol changes, introduces governance complexity

What Stays the Same?

This isn’t a rewrite from scratch. Ethereum still looks and feels like Ethereum.

• Storage operations (SLOAD, SSTORE)

• Cross-contract calls (CALL, DELEGATECALL)

• ETH balances

• Account abstraction

These would just be syscalls in a RISC-V VM environment.

Solidity and Vyper would still be used, just with new compiler backends that target RISC-V instead of EVM bytecode.

Why ZK Matters

Ethereum’s long-term scalability path hinges on ZK-proven computation. Rollups today are offloading execution, but in the future, the L1 itself will benefit from native zero-knowledge proofs.

To get there, we need:

• Faster provers

• Cleaner execution environments

• Simpler specs

The EVM, with its decades of accumulated technical debt, is holding this back. A RISC-V-based execution layer is designed to be provable, clean, and efficient from the ground up.

Why RISC-V?

• Open-source and widely adopted in hardware ecosystems

• Modular and minimal — easy to model in ZK circuits

• Battle-tested — used in production chains like Nervos CKB

• ZK compatibility — already used as a target for ZK-EVM compilation

It’s a natural fit for a future-proof execution layer.

Where Do We Go from Here?

This isn’t happening tomorrow. It’s a long-term research proposal, not a finalized roadmap item.

But the Ethereum community is already thinking about the next evolution of the protocol. Just as the “beam chain” concept simplifies the consensus layer, this proposal could do the same for the execution layer.

We’re entering a new era of modular, scalable, and verifiable chains. Ethereum staying at the forefront means questioning even its most foundational components — like the EVM.

Sometimes, the best way to scale the future… is to reimagine the past.

📌 Curious to dive deeper?
You can read Vitalik’s full post here.