Ethereum developers share a tacit rule: avoid the EVM whenever possible.
In recent years, whenever a new cryptographic operation is needed on-chain, developers’ instinct has not been to implement it within the EVM, but to request a “precompiled contract”—a shortcut that bypasses the virtual machine and hardcodes the operation at the protocol layer.
On March 1, Vitalik Buterin posted a lengthy thread on X, openly breaking this unspoken rule. He essentially argued: Ethereum’s value lies in its generality. If the EVM falls short, we should address the problem directly and build a better virtual machine.
He proposed two specific solutions.
First Solution: Changing the “Data Structure”
The first change targets Ethereum’s state tree, which functions as the network’s ledger indexing system. Every time someone checks a balance or verifies a transaction, they traverse this tree.
The issue is that the current tree is too “bulky.” Ethereum uses a structure called the “hexary Keccak Merkle Patricia tree” (the name sounds like a spell). Vitalik’s EIP-7864 proposes replacing it with a more streamlined binary tree.
For comparison: previously, querying a piece of data meant repeatedly choosing among six directions at each junction. Now, it’s reduced to just left or right. The result? Merkle branch length shrinks to a quarter of its original size. For light clients, bandwidth requirements for data verification drop significantly.
Vitalik isn’t stopping at reshaping the tree. He also wants to change the “font on the leaves”—the hash function. The two candidates are Blake3 and Poseidon. Blake3 offers consistent speed improvements; Poseidon is more radical and could theoretically boost proof efficiency by dozens of times, though its security still needs further auditing.
Notably, this proposal replaces the previously discussed Verkle Trees. Verkle was the leading candidate for the 2026 hard fork, but its underlying elliptic curve cryptography faces quantum computing threats. Since mid-2024, Verkle has gradually fallen out of favor, allowing the binary tree solution to gain traction.
Second Solution: Changing the “Virtual Machine”—Turning EVM into a Smart Contract
The second change is even bolder and more controversial: replacing the EVM with the RISC-V architecture in the long term.
RISC-V is an open-source instruction set, originally unrelated to blockchain, but now nearly all ZK proof systems use it internally. Vitalik’s logic is clear: since provers already use RISC-V, why should the virtual machine use something else, requiring a translation layer? Removing that layer naturally improves efficiency.
A RISC-V interpreter requires only a few hundred lines of code. Vitalik argues this is what a blockchain virtual machine should be.
His plan has three steps: first, use the new virtual machine for precompiled contracts, rewriting 80% of existing precompiles with new VM code; second, allow developers to deploy contracts for the new VM, running in parallel with the EVM; third, retire the EVM—not by eliminating it, but by rewriting it as a smart contract running on the new virtual machine, achieving full backward compatibility.
Existing users don’t need to change their cars—only the engine is quietly replaced, while the steering wheel stays the same.
How significant are these two changes together? Vitalik offered a figure: the state tree and virtual machine together account for more than 80% of Ethereum’s proof bottleneck. Without addressing these two areas, Ethereum’s scaling in the ZK era would stall.
Arbitrum Disagrees: Just Because the Warehouse Uses Forklifts Doesn’t Mean Couriers Should Drive Forklifts
But not everyone agrees.
In November last year, Arbitrum’s core development team, Offchain Labs, published a detailed technical rebuttal. Their four researchers argued that while RISC-V is well-suited for ZK proofs, it’s not appropriate as the “delivery format” for contracts.
They introduced a key distinction: the “delivery instruction set” (dISA) and the “proof instruction set” (pISA) don’t need to be the same. Using forklifts in the warehouse may maximize efficiency, but that doesn’t mean couriers should use forklifts to deliver packages to your door.
Offchain Labs advocates for using WebAssembly (WASM) at the contract layer, citing strong reasons: WASM executes efficiently on standard hardware, and most Ethereum nodes don’t run RISC-V chips—forcing a switch would require emulators; WASM provides mature type safety verification; WASM’s toolchain ecosystem has been battle-tested across billions of execution environments.
Importantly, they’re not just theorizing. 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. The two layers operate independently.
They also raised a thought-provoking risk: ZK proof technology evolves rapidly, and recently RISC-V implementations shifted from 32-bit to 64-bit. If RISC-V is locked into Ethereum L1 now, 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 Begin “Weaning Off”
Understanding this proposal requires a bigger-picture perspective.
Just a month ago, Vitalik publicly questioned whether Ethereum still needs a “dedicated L2 roadmap,” prompting a collective response from the L2 ecosystem. Espresso Systems CEO Ben Fisch told CoinDesk: Vitalik’s point is that L2s were originally meant to help Ethereum scale, but now that Ethereum itself is getting faster, the role of L2s naturally changes.
Interestingly, instead of panicking, L2s are proactively “de-Ethereumizing.” OP Labs co-founder Jing Wang likened L2s to independent websites, with Ethereum as the underlying open settlement standard. Polygon CEO Marc Boiron put it bluntly: the real challenge isn’t scaling, but creating unique block space for real-world scenarios like payments.
In other words, Vitalik’s overhaul of the execution layer is a technical footnote to a larger trend: Ethereum is reclaiming control over its core capabilities, while L2s are being forced—or finally finding—their own reasons for independent existence.
Can This Succeed?
Vitalik himself admits that replacing the virtual machine hasn’t achieved broad developer consensus. The state tree reform is more mature, with EIP-7864 already having a draft and a dedicated team. But replacing EVM with RISC-V? That’s still at the “roadmap” stage, not yet close to being implemented.
However, last week, Vitalik made a memorable statement: Ethereum has already swapped out a jet engine mid-flight (referring to The Merge), and can do so about four more times—state tree, simplified consensus, ZK-EVM verification, and virtual machine replacement.
Ethereum’s Glamsterdam upgrade is expected in the first half of 2026, with Hegota following closely. The exact content of the two hard forks hasn’t been finalized, but state tree reform and execution layer optimization are confirmed as main themes.
Ethereum’s story has never been about “can it be done.” From PoW to PoS, from L1 all-in to Rollup-centric, it has proven its ability and courage to dismantle engines at cruising altitude.
This time, it’s about something deeper—not adding new features, but tearing up the old foundation and relaying it. Is this a carefully considered renovation, or an endlessly deepening pit of complexity? The answer likely won’t be clear until 2027.
But at least one thing is certain: Ethereum doesn’t intend to be a “patched old system” in the ZK era. As for how to remove the patches and what kind of engine to install, the debate itself may be more valuable than the conclusion.
Disclaimer:
-
This article is republished from TechFlow, with copyright belonging to the original author [Gray Lobster]. If you have any objections to this republication, please contact the Gate Learn team, who will handle the matter promptly according to relevant procedures.
-
Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute investment advice.
-
Other language versions of this article are translated by the Gate Learn team. Without explicit mention of Gate, do not copy, distribute, or plagiarize translated articles.
