Vitalik Proposes Major Changes to Ethereum's Virtual Machine and State Tree

Article by Gray Lobster, Deep潮 TechFlow

Ethereum developers have an unspoken habit: avoid the EVM whenever possible.

Over the past few years, whenever a new cryptographic operation was needed on-chain, developers' first response was not to implement it within the EVM, but to request the addition of a "precompiled contract"—a shortcut that bypasses the virtual machine by hardcoding the operation directly at the protocol level.

On March 1, Vitalik Buterin posted a long thread on X, completely laying bare the issue. He essentially said: The entire purpose of Ethereum lies in its generality; if the EVM isn’t good enough, we should directly address the problem and build a better virtual machine.

He presented two specific scalpels.

The first change targets Ethereum's state tree, which you can think of as Ethereum's "ledger index system" — every time someone checks a balance or verifies a transaction, they traverse down this tree.

The problem is that this tree has become too "fat." Ethereum uses a structure called a "hexary Keccak Merkle Patricia Tree" (a name that sounds like a spell). Vitalik’s EIP-7864 proposes replacing it with a simpler binary tree.

For example: Previously, when you looked up a piece of data, you had to keep choosing directions at a six-way intersection; now, you only have to choose left or right. What’s the result? The Merkle branch length is reduced directly to one-quarter of its original size. For lightweight clients, the bandwidth required to verify data drops significantly.

But Vitalik isn’t satisfied with just changing the shape of the tree—he also wants to change the “font on the leaves,” meaning the hash function. Two candidates are under consideration: Blake3 and Poseidon. Blake3 offers consistent speed improvements, while Poseidon is more aggressive, theoretically boosting proof efficiency by dozens of times, though its security still requires further auditing.

It is worth noting that this solution has effectively replaced Verkle Trees, which had been the preferred option for the 2026 hard fork after years of community discussion. However, due to vulnerabilities in the underlying elliptic curve cryptography against quantum computing threats, Verkle Trees began to lose favor from mid-2024, allowing binary tree solutions to rise in prominence.

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

RISC-V is an open instruction set that originally had no connection to blockchain, but now it is used internally by nearly all ZK proof systems. Vitalik’s logic is straightforward: if the prover is already speaking RISC-V, why should the virtual machine speak a different language and require an additional translation layer in between? Remove the translation layer, and efficiency naturally improves.

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

He outlined a three-step plan: First, run precompiled contracts on the new virtual machine and rewrite 80% of the existing precompiles using the new VM code; second, allow developers to deploy contracts directly on the new virtual machine, running in parallel with the EVM; third, retire the EVM—not by eliminating it, but by rewriting it as a smart contract that runs on the new virtual machine, ensuring full backward compatibility.

Long-time owners don’t need to change cars—just the engine has been quietly replaced, while the steering wheel remains the same.

How important are these two things together? Vitalik gave a number: the state tree and virtual machine together account for over 80% of Ethereum’s proof bottleneck. In other words, without addressing these two components, Ethereum’s scaling in the ZK era would be standing still.

But this isn't a story where everyone nods in agreement.

In November last year, Offchain Labs, the core development team behind Arbitrum, published a detailed technical rebuttal. The four researchers' central argument was that RISC-V is indeed suitable for ZK proofs, but it is not suitable as a "delivery format" for smart contracts.

They made a key distinction: the delivery instruction set (dISA) and the proof instruction set (pISA) do not need to be the same thing. Your warehouse may operate most efficiently with a forklift, but that doesn’t mean your delivery person needs to drive a forklift to your doorstep.

Offchain Labs advocates using WebAssembly (WASM) for the smart contract layer, with compelling reasons: WASM executes efficiently on standard hardware, whereas most Ethereum nodes do not run RISC-V chips, and forcing a switch would require emulators; WASM has mature type-safety verification mechanisms; and WASM’s tooling ecosystem has been battle-tested in billions of execution environments.

More importantly, they didn’t just talk about it—Offchain Labs has already run a prototype on Arbitrum: using WASM as the contract delivery format, then compiling it to RISC-V for ZK proofs. Each layer handles its own task without interfering with the other.

They also raised a thought-provoking risk: technology in the ZK proof space is evolving extremely rapidly—recently, RISC-V implementations have switched from 32-bit to 64-bit. If RISC-V is now permanently hardcoded into Ethereum L1, what if a better proof architecture emerges in two years? Betting on a rapidly moving target isn’t Ethereum’s style.

To understand this proposal, a broader context is needed.

Just a month ago, Vitalik publicly questioned whether Ethereum still needed a "dedicated L2 roadmap," prompting a collective response from the L2 community. Ben Fisch, CEO of Espresso Systems, told CoinDesk: "What Vitalik really means is that L2s were originally intended to help Ethereum scale, and now that Ethereum itself is getting faster, the role of L2s naturally needs to evolve."

Interestingly, rather than panicking, L2s have begun proactively "de-ethereumizing." Jing Wang, co-founder of OP Labs, compares L2s to independent websites, with Ethereum serving as the underlying open settlement standard. Marc Boiron, CEO of Polygon, puts it even more bluntly: the real challenge isn't scaling—it's creating unique block space for real-world use cases like payments.

In other words, Vitalik’s recent major overhaul of the execution layer is a technical footnote to a broader trend: Ethereum is reclaiming control over its core capabilities, while L2s are being forced—or finally finding—their own independent purpose.

Vitalik himself has acknowledged that there is currently no broad consensus in the developer community on replacing the virtual machine. State tree reforms are more mature, with EIP-7864 already having a concrete draft and a dedicated team advancing it. But replacing the EVM with RISC-V? That’s still in the “roadmap” stage, far from being implemented in code.

However, Vitalik gave an impressive statement last week: Ethereum has already replaced its jet engine once while in flight (referring to The Merge), and it can do so about four more times—state tree, simplified consensus, ZK-EVM verification, and virtual machine replacement.

The Ethereum Glamsterdam upgrade is expected to launch in the first half of 2026, followed by Hegota. While the exact details of both hard forks have not been finalized, state tree reform and execution layer optimizations are confirmed as the core focus.

The story of Ethereum has never been about "whether it can." From transitioning from PoW to PoS, from being L1-all-in to becoming Rollup-centric, it has proven its ability and courage to disassemble engines at 10,000 meters.

What’s being changed this time is something deeper—not adding new features, but digging up the old foundation and pouring it anew. Is this a carefully planned renovation, or a bottomless pit of increasing complexity? The answer will likely not be clear until 2027.

But at least one thing is certain: Ethereum has no intention of being a "patched-up legacy system" in the ZK era. As for how to dismantle the patches and what engine to replace it with, the debate itself may be more valuable than the conclusion.