Goodbye EVM? Vitalik is about to perform a "heart surgery" on Ethereum

Author: Gray Lobster, Deep Tide TechFlow

Ethereum developers have an unspoken habit: if they can avoid touching the EVM, they do.

In recent years, whenever a new cryptographic operation is needed on-chain, developers’ first response isn’t to implement it inside the EVM, but to propose adding a “precompiled contract” — a shortcut that bypasses the virtual machine and is hardcoded directly at the protocol layer.

On March 1, Vitalik Buterin posted a long message on X, completely breaking this mindset. His main point was: The entire significance of Ethereum lies in its versatility. If the EVM isn’t good enough, we should directly address that problem by building a better virtual machine.

He proposed two specific approaches.

First Approach: Change the “Data Structure”

The first change targets Ethereum’s state tree. You can think of this as Ethereum’s “ledger index system” — every time someone checks a balance or verifies a transaction, it involves traversing this tree.

The problem is, this tree is now too “bulky.” Ethereum currently uses a structure called “Hexary Keccak Merkle Patricia Tree” (a long name that sounds like a spell). Vitalik’s proposed EIP-7864 aims to replace it with a simpler binary tree.

For example: Previously, checking a piece of data involved repeatedly choosing directions at a six-way fork; now it’s just left or right. The result? The Merkle branch length is reduced to a quarter of the original. For light clients, this significantly decreases the bandwidth needed for verification.

But Vitalik isn’t satisfied with just changing the shape of the tree. He also wants to change the “font” on the leaves — that is, the hash function. There are two candidates: Blake3 and Poseidon.

• Blake3 offers stable speed improvements;
• Poseidon is more aggressive, theoretically boosting proof efficiency by dozens of times, but its security still needs more auditing.

It’s worth noting that this plan effectively replaces the previously discussed Verkle Trees. Verkle was the preferred solution for the 2026 hard fork, but due to its reliance on elliptic curve cryptography facing quantum threats, it started losing favor around mid-2024. The binary tree approach gained momentum as a result.

Second Approach: Replace the “Virtual Machine” and Turn EVM into a Smart Contract

The second change is bolder and more controversial: long-term replacement of the EVM with RISC-V architecture.

RISC-V is an open-source instruction set, originally unrelated to blockchain, but now used internally in almost all ZK proof systems. Vitalik’s logic is straightforward: since proof generators are already speaking RISC-V, why keep the virtual machine speaking a different language and add a translation layer? Removing that translation naturally improves efficiency.

A RISC-V interpreter only needs a few hundred lines of code. Vitalik says this is what a blockchain virtual machine should look like.

He outlined a three-step plan: first, run precompiled contracts on the new VM, rewriting 80% of existing precompiles with it; second, allow developers to deploy contracts directly on the new VM, running in parallel with EVM; third, retire the EVM — but not disappear — it will be rewritten as a smart contract running on the new VM, achieving full backward compatibility.

Old users don’t need to change their tools. It’s just the engine that’s quietly being replaced, while the steering wheel remains the same.

How important are these two initiatives? Vitalik provides a figure: state trees and virtual machines together account for over 80% of Ethereum’s proof bottleneck. In other words, without addressing these, Ethereum’s scalability in the ZK era will remain stagnant.

Arbitrum Disagrees: You Can’t Use a Forklift in the Warehouse and Expect the Courier to Use One Too

But this isn’t a story everyone agrees on.

Last November, Arbitrum’s core team at Offchain Labs published a detailed technical rebuttal. The main point from four researchers was: RISC-V is suitable for ZK proofs, but not for the “delivery format” of contracts.

They made a key distinction: “Instruction Set for Delivery” (dISA) and “Proof Instruction Set” (pISA) don’t have to be the same. Your warehouse might use a forklift for efficiency, but that doesn’t mean the courier should also use a forklift to deliver to your door.

Offchain Labs advocates using WebAssembly (WASM) as the contract layer, with solid reasoning: WASM runs efficiently on standard hardware, whereas most Ethereum nodes don’t run RISC-V chips, meaning an emulator would be needed; WASM has mature type safety verification; and its tooling ecosystem has been tested in billions of executions.

More importantly, they’re not just talking — Offchain Labs has already prototyped this: using WASM as the contract delivery format, then compiling it into RISC-V for ZK proofs. The two layers work independently, without interference.

They also raised a risk worth considering: ZK proof tech is evolving rapidly. Recently, RISC-V implementations shifted from 32-bit to 64-bit. If we lock RISC-V into Ethereum L1 now, what if better proof architectures emerge in a couple of years? Betting on a moving target isn’t in Ethereum’s style.

A Larger Context: L2s Are Starting to “Wean Off”

To understand this proposal, we need a broader perspective.

Just a month ago, Vitalik publicly questioned whether Ethereum still needs a “dedicated L2 roadmap,” sparking a collective response from the L2 community. Ben Fisch, CEO of Espresso Systems, told CoinDesk: Vitalik’s point is that L2s were initially meant to help scale Ethereum, but now that Ethereum itself is getting faster, the role of L2s must evolve.

Interestingly, rather than panic, L2s are actively “de-Ethereum-izing” themselves. Jing Wang, co-founder of OP Labs, compared L2s to independent websites, with Ethereum as the underlying open settlement standard. Polygon CEO Marc Boiron put it more plainly: the real challenge isn’t scaling, but creating dedicated block space for real-world use cases like payments.

In other words, Vitalik’s major changes to execution layers reflect a larger trend: Ethereum is reclaiming control over its core capabilities, while L2s are being forced or finally finding their own reasons to exist independently.

Can This Work?

Vitalik admits that replacing the virtual machine doesn’t yet have broad community consensus. The state tree reform is more mature, with concrete drafts and teams pushing it forward. But replacing EVM with RISC-V? That’s still in the “roadmap” stage, far from coding.

However, Vitalik gave an impressive statement last week: Ethereum has already swapped its jet engine once during The Merge, and can do about four more — state trees, streamlined consensus, ZK-EVM verification, and virtual machine replacement.

Ethereum’s Glamsterdam upgrade is expected in the first half of 2026, followed by Hegota. The specifics of these two hard forks aren’t finalized yet, but state tree reform and execution layer optimization are the main themes.

Ethereum’s story has never been about “whether it can.” From PoW to PoS, from L1 to rollups, it has proven its ability and courage to disassemble its engine at high altitude.

This time, the changes go deeper — not adding new features, but excavating and rebuilding the old foundation. Is this a carefully planned renovation or an endless, increasingly complex overhaul? The answer probably won’t be clear until 2027.

But one thing is certain: Ethereum doesn’t intend to be a “patched old system” in the ZK era. How to patch and what engine to replace it with — this debate, perhaps, is more valuable than the conclusion itself.