Author: Gray Lobster, Shenchao 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 lengthy thread on X, completely breaking the silence on this issue. He essentially said: The entire purpose of Ethereum is its generality; if the EVM isn’t good enough, we should directly address the problem and build a better virtual machine.
He provided two specific scalpels.
First cut: Replace "data structure"
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 is too "fat." Ethereum uses a structure called a "hexadecimal 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 repeatedly choose directions at a six-way intersection; now, it’s simplified to just left or right. 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 wasn’t satisfied with just changing the shape of the tree—he also wanted to change the “font on the leaves,” meaning the hash function. The two candidate options are Blake3 and Poseidon.
- Blake3 provides consistent speed improvements;
- Poseidon is more aggressive and could theoretically improve proof efficiency by dozens of times, but its security still requires further auditing.
It is worth noting that this proposal has effectively replaced Verkle Trees, which had been the preferred solution 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 gain momentum.
Second cut: Replace the "virtual machine" and turn the EVM into a smart contract.
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? Removing the translation layer naturally improves efficiency.
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 switch 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.
Arbitrum disagrees: You can't make a delivery driver operate a forklift just because the warehouse uses one.
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 researchers' central argument was that while RISC-V is indeed suitable for ZK proofs, it is not appropriate 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 driver needs to drive a forklift to your front door.
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 haven’t just talked about it—Offchain Labs has already deployed a prototype on Arbitrum: using WASM as the smart contract delivery format, then compiling it to RISC-V for ZK proof generation. Each layer operates independently without interfering with the other.
They also raised a noteworthy risk: the technology in the ZK proof space is evolving extremely rapidly—recently, RISC-V implementations have shifted from 32-bit to 64-bit. If RISC-V is now permanently hardcoded into Ethereum L1, what happens if a better proof architecture emerges in two years? Betting on a rapidly moving target isn’t Ethereum’s style.
A broader context: L2s are beginning to "wean off."
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 becoming faster, the role of L2s naturally needs to evolve."
Interestingly, rather than panicking, L2s have begun actively "de-ETHing." Jing Wang, co-founder of OP Labs, compares L2s to independent websites, with Ethereum serving as the underlying open settlement standard. Polygon’s CEO Marc Boiron puts it even more bluntly: the real challenge isn’t scaling—it’s creating unique blockspace 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.
Can this be done?
Vitalik himself has acknowledged that there is currently no broad consensus within the developer community on replacing the EVM. State tree reforms are more mature, with EIP-7864 already having a concrete draft and a dedicated team driving it forward. But replacing the EVM with RISC-V? That’s still at the "roadmap" stage, far from being implemented in code.
However, Vitalik made 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 specific 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." It has proven its ability and courage to dismantle engines at 10,000 meters—transitioning from PoW to PoS, and from an L1 all-in approach to a Rollup-centric model.
What’s being changed this time goes much deeper—not adding new features, but tearing up the old foundation and pouring a new one. Is this a carefully planned renovation, or a bottomless pit of increasing complexity? The answer may not be clear until 2027.
But at least one thing is certain: Ethereum has no intention of becoming a "patched-up legacy system" in the ZK era. As for how to dismantle the patches and what engine to install, the debate itself may be more valuable than the conclusion.