Ethereum is about to upgrade its engine

This time, we’re tackling something deeper—not adding new features, but excavating and re-pouring the old foundation.

Article by: Gray Lobster, Deep Tide TechFlow

Ethereum developers have an unspoken rule: If it can be avoided, don’t touch the EVM.

Over the past few years, whenever a new cryptographic operation is needed on-chain, developers’ first response isn’t to implement it within the EVM, but to request an increase in “precompiled contracts,” a shortcut that bypasses the virtual machine and is hardcoded directly at the protocol level.

On March 1, Vitalik Buterin posted a long message on X, completely breaking through this mindset. His main point was: Ethereum’s entire significance lies in its versatility. If the EVM isn’t good enough, then we should directly address that problem and build a better virtual machine.

He proposed two specific “surgical” changes.

First Cut: Change the “Data Structure”

The first change targets Ethereum’s state tree. Think of this as Ethereum’s “ledger index system,” which is traversed every time someone checks a balance or verifies a transaction.

The problem is, this tree has become too “bulky.” Ethereum uses a structure called “Hexary Keccak Merkle Patricia Tree” (a long name that sounds like a spell). Vitalik’s proposed EIP-7864 aims to replace it with a simpler binary tree.

For example: Previously, checking a piece of data involved repeatedly choosing directions at a six-way fork; now, it’s just left or right. The result? The length of Merkle branches is reduced to a quarter of the original. For light clients, this significantly decreases the bandwidth needed for verification.

But Vitalik isn’t satisfied with just changing the shape of the tree. He also wants to change the “font” on the leaves—that is, the hash functions. There are two candidates: Blake3 and Poseidon. Blake3 offers stable speed improvements; Poseidon is more aggressive, theoretically boosting proof efficiency by dozens of times, but its security still needs more auditing.

It’s worth noting that this plan effectively replaces the Verkle Trees, which had been discussed by the community for years. Verkle was the preferred solution for the 2026 hard fork, but due to the underlying elliptic curve cryptography’s vulnerability to quantum attacks, it started losing favor around mid-2024. The binary tree approach has gained momentum as a result.

Second Cut: Replace the “Virtual Machine” and Turn EVM into a Smart Contract

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

RISC-V is an open-source instruction set, originally unrelated to blockchain, but now used internally in almost all ZK proof systems. Vitalik’s logic is straightforward: since provers are already speaking RISC-V, why have a different virtual machine and then translate between them? Removing the translation layer naturally improves efficiency.

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

He outlined a three-step plan: First, run precompiled contracts on the new VM, rewriting 80% of existing precompiles with it; second, allow developers to deploy contracts directly on the new VM, running in parallel with EVM; third, retire the EVM, but not eliminate it—rework it into a smart contract that runs on the new VM, achieving full backward compatibility.

Old users don’t need to switch. It’s just that the engine is quietly changing, while the steering wheel remains the same.

How important are these two changes? Vitalik provides a number: State trees and virtual machines together account for over 80% of Ethereum’s proof bottleneck. In other words, without touching these two areas, Ethereum’s scalability in the ZK era will remain stagnant.

Arbitrum disagrees: just because the warehouse uses a forklift doesn’t mean the courier should also drive a forklift

But this isn’t a story everyone agrees on.

Last November, Offchain Labs, the core team behind Arbitrum, published a detailed technical rebuttal. The four researchers’ main point was: RISC-V is indeed suitable for ZK proofs, but it’s not suitable as a “delivery format” for contracts.

They made a key distinction: “Instruction Set Architecture” (dISA) and “Proof Instruction Set” (pISA) don’t need to be the same. Your warehouse might be most efficient with a forklift, but that doesn’t mean the courier should also use a forklift to deliver to your door.

Offchain Labs advocates using WebAssembly (WASM) as the contract layer, with solid reasoning: WASM executes efficiently on standard hardware, and most Ethereum nodes don’t run RISC-V chips, meaning emulators would be needed; WASM has mature type safety verification mechanisms; and its toolchain ecosystem has been tested in billions of execution environments.

More importantly, they’re not just talking. Offchain Labs has already prototyped this on Arbitrum: using WASM as the contract delivery format, then compiling it into RISC-V for ZK proofs. Each layer does its own job, without interference.

They also raised a risk worth pondering: ZK proof technology is evolving rapidly. Recently, RISC-V implementations shifted from 32-bit to 64-bit. If Ethereum’s L1 is locked into RISC-V now, what if a better proof architecture emerges in a couple of years? Betting on a moving target isn’t Ethereum’s style.

A broader context: L2s are starting to “independent”

To understand this proposal, a bigger macro background is needed.

Just a month ago, Vitalik publicly questioned whether Ethereum still needs a “dedicated L2 roadmap,” sparking a collective response from the L2 community. Ben Fisch, CEO of Espresso Systems, told CoinDesk: Vitalik’s point is that L2s were originally meant to help scale Ethereum, but now that Ethereum itself is speeding up, the role of L2s naturally needs to evolve.

Interestingly, L2s are not panicked but are actively “de-ethereanizing.” Jing Wang, co-founder of OP Labs, compared L2s to independent websites, with Ethereum as the underlying open settlement standard. Marc Boiron, CEO of Polygon, put it more plainly: the real challenge isn’t scalability but creating unique block space for real-world use cases like payments.

In other words, Vitalik’s major overhaul of the execution layer signals a larger trend: Ethereum is reclaiming control over its core capabilities, while L2s are being forced—or finally finding—their own reasons to exist independently.

Can this happen?

Vitalik himself admits that replacing the virtual machine currently lacks broad developer consensus. The state tree reform is more mature, with concrete drafts and teams pushing forward. But replacing EVM with RISC-V? That’s still in the “roadmap” stage, far from actual code.

However, Vitalik gave an impressive statement last week: Ethereum has already swapped its jet engine once during The Merge, and can do about four more—state trees, streamlined consensus, ZK-EVM verification, and virtual machine replacement.

Ethereum’s Glamsterdam upgrade is expected to land in the first half of 2026, followed by Hegota. The specifics of these two hard forks are not finalized, but state tree reform and execution layer optimization are the main themes.

Ethereum’s story has never been about “whether it can.” From PoW to PoS, from L1 to rollups, it has proven its ability and courage to disassemble its engine at high altitude.

This time, it’s about deeper layers—not adding new features, but excavating and rebuilding the old foundation. Is this a carefully planned renovation or an endless sinkhole of complexity? The answer probably won’t be clear until 2027.

But one thing is certain: Ethereum does not intend to be a “patched old system” in the ZK era. As for how to patch and what engine to replace it with, the debate itself may be more valuable than the conclusion.