Ethereum Is Getting a New Engine
TechFlow Selected TechFlow Selected
Ethereum Is Getting a New Engine
This time, we’re tackling something much deeper—not adding new features, but excavating and re-pouring the old foundation.
Navigating Web3 tides with focused insightsBy Gray Lobster, TechFlow
Ethereum developers share an unspoken habit: Avoid touching the EVM if at all possible.
Over the past few years, whenever a new cryptographic operation was needed on-chain, developers’ first instinct wasn’t to implement it inside the EVM—but rather to propose adding a “precompile”: a shortcut hardcoded directly into the protocol layer, bypassing the virtual machine entirely.
On March 1, Vitalik Buterin published a lengthy post on X, definitively shattering this tacit consensus. His core message: Ethereum’s entire value lies in its universality—if the EVM isn’t up to the task, we should confront the issue head-on and build a better virtual machine.
He proposed two concrete surgical interventions.
First Cut: Replace the “Data Structure”
The first change targets Ethereum’s state trie—a structure you can think of as Ethereum’s “ledger index system.” Every time someone checks a balance or verifies a transaction, they must traverse this tree downward.
The problem? The current trie is too “bloated.” Ethereum uses a structure called a “6-ary Keccak Merkle Patricia Trie”—a mouthful that sounds like incantation. Vitalik’s EIP-7864 proposes replacing it with a leaner binary trie.
Analogy: Previously, retrieving data required repeatedly choosing among six directions at each junction; now, only left or right remains. Result? Merkle branch length shrinks to one-quarter of its original size—dramatically reducing bandwidth requirements for light clients.
But Vitalik doesn’t stop at merely changing the tree’s shape. He also wants to change the “font on the leaves”—i.e., the hash function. Two candidates are under consideration: Blake3 and Poseidon. Blake3 delivers steady performance gains; Poseidon is more radical—potentially boosting proof efficiency by dozens of times—but requires further security audits.
Notably, this proposal effectively supplants Verkle Trees, long debated in the community for years. Verkle Trees had been the leading candidate for the 2026 hard fork, but since their underlying elliptic-curve cryptography faces quantum-computing threats, they began losing favor starting mid-2024—clearing the path for the binary-trie solution.
Second Cut: Replace the “Virtual Machine”—Turn the EVM Into a Smart Contract
The second change is bolder—and far more contentious: gradually replacing the EVM with a RISC-V-based architecture.
RISC-V is an open-source instruction set originally unrelated to blockchain—but today, nearly every ZK proof system internally relies on it. Vitalik’s logic is direct: If provers already speak RISC-V, why force the VM to speak another language—and add translation overhead in between? Removing that translation layer naturally boosts efficiency.
A RISC-V interpreter needs only a few hundred lines of code. That, says Vitalik, is what a blockchain virtual machine should look like.
He outlines a three-phase roadmap: First, run precompiles on the new VM—rewriting ~80% of existing precompiles in the new VM’s code. Second, allow developers to deploy contracts natively on the new VM alongside the EVM, running in parallel. Third, retire the EVM—not by deleting it, but by reimplementing it as a smart contract running atop the new VM, ensuring full backward compatibility.
Existing users won’t need to switch vehicles—only the engine will be quietly upgraded, while the steering wheel stays exactly the same.
How significant are these two changes combined? Vitalik offers a telling figure: Together, the state trie and the virtual machine account for over 80% of Ethereum’s proof bottleneck. In other words, without addressing these two components, Ethereum’s scalability in the ZK era would remain stagnant.
Arbitrum Disagrees: “You Can’t Make Delivery Drivers Operate Forklifts Just Because Warehouses Use Them”
Yet this isn’t a universally applauded story.
Last November, Offchain Labs—the core development team behind Arbitrum—published a detailed technical rebuttal. Four researchers argued that while RISC-V is indeed well-suited for ZK proving, it is ill-suited as a “delivery format” for smart contracts.
They introduced a crucial distinction: The “delivery instruction set” (dISA) and the “proof instruction set” (pISA) need not be identical. Forklifts maximize warehouse logistics efficiency—but that doesn’t mean delivery drivers should operate them all the way to your doorstep.
Offchain Labs advocates WebAssembly (WASM) for the contract layer, citing solid reasons: WASM executes efficiently on standard hardware, whereas most Ethereum nodes do not run RISC-V chips—forcing a switch would require emulation; WASM has mature type-safety verification mechanisms; and its toolchain ecosystem has been battle-tested across billions of execution environments.
More importantly, they aren’t just theorizing. Offchain Labs has already deployed a working prototype on Arbitrum: using WASM as the contract delivery format, then compiling it to RISC-V for ZK proving—keeping both layers independent and purpose-built.
They also raise a sobering risk: ZK-proving technology evolves extremely rapidly—RISC-V implementations have recently shifted from 32-bit to 64-bit. If RISC-V is now permanently baked into Ethereum L1, what happens if a superior proving architecture emerges in two years? Betting on a moving target contradicts Ethereum’s ethos.
A Broader Context: L2s Are Weaning Themselves Off Ethereum
To fully grasp this proposal, we need a wider lens.
Just one month ago, Vitalik publicly questioned whether Ethereum still needs a “dedicated L2 roadmap,” triggering collective responses from the L2 ecosystem. Ben Fisch, CEO of Espresso Systems, told CoinDesk: “Vitalik’s point is essentially that L2s were initially designed to scale Ethereum—but now that Ethereum itself is becoming faster, the role of L2s must evolve accordingly.”
Interestingly, rather than panicking, L2s are 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 carving out unique blockspace tailored to real-world use cases like payments.”
In other words, Vitalik’s overhaul of the execution layer serves as a technical footnote to a broader trend: Ethereum is reclaiming control over its core capabilities, while L2s are finally finding—or being forced to find—their own independent raison d’être.
Will This Happen?
Vitalik himself concedes that VM replacement currently lacks broad developer-community consensus. State trie reform is more mature: EIP-7864 already has a concrete draft and dedicated implementation team. But RISC-V replacing the EVM? That remains strictly on the “roadmap”—far from actual code.
Still, Vitalik offered a striking remark last week: Ethereum has already replaced one jet engine mid-flight (referring to The Merge), and it can likely replace roughly four more—state trie, consensus simplification, ZK-EVM verification, and VM replacement.
The Glamsterdam upgrade is scheduled for early 2026, followed closely by Hegota. While final contents of both hard forks remain undetermined, state trie reform and execution-layer optimization are confirmed central pillars.
Ethereum’s story has never been about “can it be done?” From PoW to PoS, from L1-centricity to rollup centrality, it has repeatedly proven its ability—and audacity—to disassemble engines at 10,000 meters.
This time, however, it’s targeting something deeper—not adding features, but excavating and recasting the foundation itself. Is this a carefully planned renovation—or an ever-deepening rabbit hole of complexity? The answer may only emerge by 2027.
But one thing is certain: Ethereum refuses to become a “patchwork legacy system” in the ZK era. As for how those patches get removed—or which engine model replaces the old one—the debate itself may prove more valuable than any final conclusion.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
深潮TechFlow
