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

Author: Gray Lobster, Deep Tide TechFlow

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

In the past few years, whenever a new cryptographic operation was needed on the blockchain, the developers' first reaction was not to implement it in the EVM, but to request the addition of a "pre-compiled contract," a shortcut that bypasses the virtual machine and is hard-coded directly at the protocol layer.

On March 1st, Vitalik Buterin posted a long post on X, completely breaking the ice. His gist was: the whole point of Ethereum is its versatility; if the EVM isn't good enough, then we should address the problem head-on and build a better virtual machine.

He provided two specific surgical knives.

The first step: Change the "data structure"

The first change targets Ethereum's state tree. You can think of this as Ethereum's "ledger indexing system." Every time someone checks the balance or verifies a transaction, they have to scroll down this tree.

The problem is that the tree is currently too "fat" . Ethereum uses a structure called a "hexa-forked Keccak Merkel Patricia tree" (the name sounds like a spell). Vitalik's EIP-7864 proposes to replace it with a simpler binary tree.

To illustrate: Previously, querying a piece of data required repeatedly choosing directions at a six-way intersection; now, it only requires left and right. What's the result? The Merkel branch length is reduced to a quarter of its original length. For lightweight clients, the bandwidth required for data verification is significantly reduced.

But Vitalik wasn't satisfied with just changing the shape of the tree. He also wanted to change the "font on the leaves," which is the hash function. There were two candidate solutions: Blake3 and Poseidon.

• Blake3 provides a stable speed boost;
• Poseidon is more radical, theoretically increasing proof efficiency by dozens of times, but its security still requires further auditing.

It's worth noting that this scheme actually replaces Verkle Trees, which had been discussed in the community for many years. Verkle was once the preferred scheme for the hard fork in 2026, but it gradually fell out of favor from mid-2024 because the elliptic curve cryptography it relies on is threatened by quantum computing, and the binary tree scheme took over.

The second step: Change the "virtual machine," turning the EVM into a smart contract.

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

RISC-V is an open-source instruction set that originally had nothing to do with blockchain, but now it is used internally by almost all ZK proof systems. Vitalik's logic is straightforward: since the prover is already speaking RISC-V, why should the virtual machine speak another language and then add a translator in between? Removing the translation layer naturally increases efficiency.

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

He planned a three-step approach: First, run pre-compiled contracts on the new virtual machine and rewrite 80% of the existing pre-compiled contracts with the new VM code; second, allow developers to directly deploy contracts on the new virtual machine and run them in parallel with the EVM; third, the EVM will be retired, but not disappear—it will be rewritten as a smart contract that runs on the new virtual machine, achieving full backward compatibility.

Existing car owners don't need to change cars. Only the engine has been quietly replaced; the steering wheel remains the same.

How important are these two things combined? Vitalik gave a figure: the state tree and the virtual machine together account for more than 80% of Ethereum's proof bottleneck. In other words, without addressing these two components, Ethereum's scaling in the ZK era will be stagnant.

Arbitrum disagrees: You can't force delivery drivers to drive forklifts just because warehouses use them.

But this is not a story that everyone agrees on.

Last November, Offchain Labs, the core development team of Arbitrum, published a detailed technical rebuttal. The core argument of the four researchers was that while RISC-V is indeed suitable for ZK proofs, it is not suitable for contract "delivery formats".

They raised a key distinction: the "Delivery Instruction Set" (dISA) and the "Proof Instruction Set" (pISA) do not need to be the same thing. Your warehouse is most efficient with forklifts, but that doesn't mean your delivery person should also use a forklift to deliver goods to your doorstep.

Offchain Labs advocates using WebAssembly (WASM) for the contract layer, and its reasons are quite solid: WASM is highly efficient on standard hardware, while most Ethereum nodes do not run RISC-V chips, and a forced switch would mean the need for an emulator; WASM has a mature type security verification mechanism; and WASM's toolchain ecosystem has been tested in practice in billions of execution environments.

More importantly, they're not just talking the talk. Offchain Labs has already run a prototype on Arbitrum: using WASM as the contract delivery format, then compiling it into RISC-V for ZK proofs. The two layers do their own work without interfering with each other.

They also raised a thought-provoking risk: the technology in the ZK proof field is changing rapidly, with the RISC-V implementation recently switching from 32-bit to 64-bit. If RISC-V is soldered onto Ethereum's L1 now, what if a better proof architecture emerges in two years? Betting on a rapidly moving bullseye is not Ethereum's style.

A larger context: Level 2 infants are beginning to "wean" from their dependence on external care.

To understand this proposal, a broader context is needed.

Just a month ago, Vitalik publicly questioned whether Ethereum still needed a "dedicated L2 roadmap," triggering a collective response from the L2 camp. Ben Fisch, CEO of Espresso Systems, aptly put it to CoinDesk: Vitalik's point is that the initial purpose of L2 was to help Ethereum scale, but now that Ethereum itself needs to become faster, the role of L2 naturally needs to change.

Interestingly, instead of panicking, L2 blockchains have begun to actively "de-Ethereumize." Jing Wang, co-founder of OP Labs, likened L2 to an independent website, while Ethereum is the underlying open settlement standard. Polygon CEO Marc Boiron put it more bluntly: the real challenge is not scaling, but creating a unique block space for real-world scenarios like payments.

In other words, Vitalik's major overhaul of the execution layer is a technological footnote to a larger trend: Ethereum is regaining control over its core capabilities, while L2 layers are being forced, or rather, finally finding their own reason for independent existence.

Is this feasible?

Vitalik himself admitted that there is currently no broad consensus in the developer community regarding virtual machine replacement . State tree reforms are more mature , with EIP-7864 already having a concrete draft and an implementation team. But RISC-V replacing the EVM? This is still at the "roadmap" stage, far from being written into code.

However, Vitalik made an impressive statement last week: Ethereum has already changed its jet engine once in flight (referring to The Merge), and can change it about four more times in the future— 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 specifics of the two hard forks have not yet been finalized, state tree reform and execution layer optimization are the main themes.

Ethereum's story has never been about "whether it can or cannot". From PoW to PoS, from L1 all-in to Rollup hub, it has proven that it has the ability and courage to dismantle its engine at an altitude of 10,000 meters.

This time, the work involves something deeper—not adding new features, but digging up the old foundation and re-pouring the concrete. Is this a well-thought-out renovation, or a bottomless pit that gets more and more complicated? We'll probably find out in 2027.

But at least one thing is certain: Ethereum doesn't intend to be a "patched-up old system" in the ZK era. As for how to remove the patches and what engine to replace it with, the debate itself may be more valuable than the conclusion.