Recently, I noticed that Vitalik has once again put forward a series of fairly bold proposals about Ethereum’s underlying platform architecture. The interesting part here is that they’re not just small, incremental improvements, but a kind of “disassembling the engine” while the plane is already flying at an altitude of 10,000 meters.

The issue that Vitalik highlights is quite intriguing: Ethereum developers have long had the habit of avoiding using the EVM whenever possible. Whenever they need to add a new cryptographic operation, instead of implementing it inside the EVM, they request an additional “pre-compiled contract” to bypass the virtual machine entirely. This shows that the EVM is becoming a real bottleneck.

Vitalik proposes two major changes. The first is to overhaul Ethereum’s state tree—the “indexing system” that has to be searched through whenever you check balances or verify transactions. Currently, it uses a fairly complex Keccak Merkle Patricia Tree structure. Vitalik wants to replace it with a simpler binary tree, reducing the Merkle branch length to about a quarter. At the same time, he wants to change the hash function, which could be Blake3 or Poseidon. This change will significantly reduce the bandwidth required for light clients.

But the second change is the real “blockbuster”: replacing the EVM with an RISC-V architecture in the long run. The logic is very simple: if ZK proving systems are already using RISC-V, why should the virtual machine use a different language and add yet another translation layer between them? Remove this translation layer, and performance will automatically improve. Vitalik lays out a three-step plan: first run the pre-compiled contracts on the new virtual machine, then enable direct deployment, and finally “retire” the EVM by rewriting it as a smart contract that runs on the new virtual machine to ensure full compatibility.

What’s interesting is that Vitalik provides a number: the state tree and the virtual machine account for more than 80% of Ethereum’s proof bottleneck. In other words, if you don’t touch these two parts, Ethereum scaling in the ZK era will only go so far.

However, not everyone agrees. Offchain Labs—the team behind Arbitrum—has rebutted in fairly detailed fashion. They say RISC-V is indeed suitable for creating ZK proofs, but it’s not suitable as a “delivery format” for contracts. They draw a distinction between a “delivery instruction set” and a “proof instruction set”—the two don’t have to be the same. Offchain Labs proposes using WebAssembly (WASM) for the contract layer because WASM performs efficiently on standard hardware, has a secure data type verification mechanism, and the tools ecosystem has been tested in real practice billions of times. They’ve even deployed a prototype on Arbitrum: using WASM as the transaction format, and then compiling it into RISC-V to generate ZK proofs. The two layers operate independently.

Offchain Labs also points out a thought-provoking risk: ZK proving technology changes extremely fast. Recently, RISC-V has moved from 32-bit to 64-bit. If RISC-V is tightly coupled to Ethereum L1 right now, what happens two years later when a better architecture appears?

The bigger backdrop is that L2s are starting to “wean themselves off” Ethereum. A month ago, Vitalik asked whether Ethereum still needs a “dedicated L2 roadmap.” Instead of panicking, L2s are proactively “freeing themselves from Ethereum,” finding their own independent reasons to exist.

Vitalik also admits that replacing the EVM still has not yet reached broad consensus among the developer community. Overhauling the state tree is more mature, with a concrete draft, but replacing the EVM with RISC-V is still only at the “roadmap” stage. However, Vitalik has just announced that Ethereum has already changed its jet engine once (The Merge), and that it may add around four more changes afterward—covering the state tree, streamlining the consensus, ZK-EVM verification, and replacing the virtual machine.

The Glamsterdam upgrade is expected to be deployed in the first half of 2026, followed by Hegota. The overhaul of the state tree and optimization of the execution layer are among the main directions that have already been identified. The real question isn’t “whether it can be done,” but how to dismantle those patches. Ethereum has demonstrated this capability by moving from PoW to PoS, and from L1 being all-in to a central Rollup model. This time, it’s knocking out the old foundation to rebuild it, not merely adding new features. This is a long-term renovation, and the answer will probably become clear in 2027. But at least one thing is certain: Ethereum does not intend to become a “legacy system that needs patching” in the ZK era.