Written by: Gray Lobster, Deep Tide TechFlow

Ethereum developers have an unspoken habit: if we can avoid touching the EVM, we will.

In recent years, whenever a new cryptographic operation is needed on-chain, the developers' first response is not to implement it in the EVM, but to apply for the addition of a "precompiled contract," which is a shortcut that bypasses the virtual machine and is hard-coded directly into the protocol layer.

On March 1, Vitalik Buterin posted a long thread on X, shattering this layer of ambiguity. His main point was: the entire meaning of Ethereum lies in its universality; if the EVM is not good enough, we should directly address this issue and build a better virtual machine.

He provided two specific scalpel-like solutions.

The First Cut: Change the "Data Structure"

The first change targets Ethereum's state tree. You can understand this as Ethereum's "ledger indexing system," where every time someone checks the balance or verifies a transaction, they have to traverse this tree downwards.

The problem is, this tree is now too "fat." Ethereum uses a structure called "six-way Keccak Merkle Patricia Tree" (the name sounds like a spell). Vitalik proposed EIP-7864 to replace it with a more streamlined binary tree.

For example: previously, to look up a piece of data, you had to repeatedly choose a direction at a six-way intersection; now it will only involve left and right. What is the result? The length of the Merkle branch is directly reduced to a quarter of its original size. For light clients, the bandwidth needed to verify data significantly decreases.

But Vitalik is not satisfied just changing the shape of the tree. He also wants to change the "font on the leaves of the tree," which refers to the hash function. The candidate options are two: Blake3 and Poseidon. Blake3 can bring stable speed improvements; Poseidon is more radical and theoretically can boost proof efficiency by several times, but its security requires more audits.

Notably, this solution effectively replaces the Verkle Trees that had been discussed by the community for years. Verkle was once the preferred choice for a hard fork in 2026, but due to the underlying elliptic curve cryptography facing quantum computing threats, it began to lose favor from mid-2024, allowing the binary tree solution to rise in prominence.

The Second Cut: Change the "Virtual Machine," Transform EVM into a Smart Contract

The second change is bolder and more controversial: to replace the EVM with a long-term RISC-V architecture.

RISC-V is an open-source instruction set originally unrelated to blockchain, but now almost all ZK proof systems internally use it. Vitalik's logic is straightforward: since provers are already speaking RISC-V, why should the virtual machine speak another language, adding a translation layer in between? Removing the translation layer will naturally improve efficiency.

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

He outlined three steps: the first step is to run precompiled contracts on the new virtual machine and rewrite 80% of the existing precompiled using new VM code; the second step allows developers to directly deploy contracts on the new virtual machine to run in parallel with the EVM; the third step retires the EVM, but it won't disappear—it will be rewritten as a smart contract running on the new virtual machine, achieving full backward compatibility.

Old vehicle owners do not need to switch cars. The engine quietly changes, while the steering wheel remains the same.

How important are these two changes combined? Vitalik provided a figure: the state tree and virtual machine together account for over 80% of Ethereum's proof bottleneck. In other words, if these two areas are untouched, Ethereum's scalability in the ZK era will remain stagnant.

Arbitrum Disagrees: You Cannot Let Couriers Drive Forklifts Just Because Warehouses Use Them

But this is not a story where everyone is nodding in agreement.

In November last year, Arbitrum's core development team, Offchain Labs, issued a detailed technical rebuttal. The core argument of the four researchers was: RISC-V is indeed suitable for ZK proofs, but it is not suitable for the "delivery format" of contracts.

They made a key distinction that "delivery instruction set" (dISA) and "proof instruction set" (pISA) do not need to be the same thing. Your warehouse may use forklifts for maximum efficiency in moving goods, but that doesn’t mean couriers should also drive forklifts to deliver to your doorstep.

Offchain Labs advocates using WebAssembly (WASM) for the contract layer, with solid reasoning: WASM executes efficiently on standard hardware, while most Ethereum nodes do not run RISC-V chips; forcing a switch means needing an emulator; WASM has a mature type safety verification mechanism; and the WASM toolchain ecosystem has been field-tested in billions of execution environments.

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

They also raised a thoughtful risk: the technological changes in the ZK proof field are rapid, and recently the RISC-V implementation has switched from 32-bit to 64-bit. If RISC-V is cemented in Ethereum L1 now, what if a better proof architecture emerges two years later? Betting on a rapidly changing target is not Ethereum's style.

A Broader Context: L2s Begin "Weaning Off"

Understanding this proposal also requires a broader context.

Just a month ago, Vitalik publicly questioned whether Ethereum still needed a "dedicated L2 roadmap," prompting a collective response from the L2 camp. Ben Fisch, CEO of Espresso Systems, aptly said to CoinDesk: Vitalik's point is essentially that the original purpose of L2 was to help Ethereum scale, and now that Ethereum itself is looking to speed up, the positioning of L2 naturally has to change.

Interestingly, the L2s have not panicked; instead, they have begun actively "de-Ethereumizing." 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 is not scaling, but creating unique block space for real scenarios like payments.

In other words, Vitalik’s major overhaul of the execution layer represents a technical footnote to a larger trend: Ethereum is reclaiming control over its core capabilities, while the L2s are either being forced or finally finding their justification for independent existence.

Can This Succeed?

Vitalik himself admits that the virtual machine replacement does not yet have broad consensus in the developer community. The state tree reform is more mature, with EIP-7864 already having a specific draft and advancing team. But replacing EVM with RISC-V? That is still at the "roadmap" stage, far from being written into code.

However, Vitalik made a striking statement last week: Ethereum has already changed its jet engine once in mid-flight (referring to The Merge), and it could still change about four more times—state tree, streamlined consensus, ZK-EVM verification, virtual machine replacement.

The Ethereum Glamsterdam upgrade is expected to roll out in the first half of 2026, followed closely by Hegota. The specific content of these two hard forks has not yet been finalized, but the state tree reform and execution layer optimization are established main lines.

The story of Ethereum has never been about "can or cannot." From PoW to PoS, from L1 all-in to Rollup-centric, it has proven its capability and courage to disassemble engines at high altitudes.

This time, it is deeper: not about adding new features, but digging up and re-pouring the old foundation. Whether this is a long-term renovation or a never-ending complexity is a question that might only be answered by 2027.

But one thing is certain: Ethereum does not intend to be an "old system with patches" in the ZK era. As for how to dismantle the patches and what model the engine should be replaced with, the debate itself may be more valuable than the conclusion.