I noticed that in Ethereum, over the past few years, a curious tradition has developed: instead of improving the virtual machine itself, developers simply bypass it through pre-compiled contracts. But Vitalik doesn’t stop there. Recently, he released a detailed plan on how to rebuild all of this from scratch.

The first part of the plan concerns Ethereum’s state tree. To simplify, it’s like an indexing system through which the system constantly searches for data. The problem is that the current structure — the same six-way Keccak Merkle tree — is too bulky. EIP-7864, proposed by Vitalik, replaces it with a binary tree. Instead of choosing from six directions, you just choose left or right. The result? The length of the Merkle tree is reduced by four times. For light clients, this means a significant reduction in bandwidth requirements.

But that’s not all. Vitalik wants to change the hash function itself. There are two candidates on the table: Blake3, which offers stable acceleration, and Poseidon, which theoretically can increase proof efficiency by dozens of times, although its security is still under review. This plan essentially replaces Verkle Trees, which have been discussed by the community for years but lost popularity due to the threat of quantum computing.

The second step is even more ambitious: to replace the EVM architecture itself with RISC-V. The logic is simple — if ZK-proof systems already understand RISC-V, why should the machine use a different language? By removing the translation layer, everything automatically speeds up. Vitalik plans three phases: first, rewrite 80% of pre-compiled contracts on the new VM; then allow developers to deploy contracts directly; and finally, phase out the old EVM — but not delete it, instead rewrite it as a smart contract on the new machine. Old contracts will continue to operate, like a car with a replaceable engine.

Vitalik stated that the state tree and virtual machine together account for over 80% of Ethereum’s proof limitations. Without these changes, scaling in the ZK era simply won’t move forward.

But not everyone agrees. The Arbitrum Offchain Labs team published a detailed technical rebuttal. Their position: RISC-V is good for ZK proofs, but not necessarily ideal as a format for contracts. They drew a distinction between the instruction set for the (dISA) delivery and the instruction set for the (pISA) proof. In their view, these should not be the same. They propose WebAssembly for the contract layer, then compilation into RISC-V for proofs. They already launched a prototype on Arbitrum, and it works. Plus, they pointed out a risk: ZK technologies are evolving rapidly, and what will happen if RISC-V is fixed on L1 now, what will it be in two years?

This discussion takes place against the backdrop of a larger change. Vitalik recently questioned the necessity of a separate L2 roadmap for Ethereum. Interestingly, L2s didn’t panic but began actively rethinking their role. If Ethereum itself becomes faster, then L2s need to find their unique spaces — not just scaling, but real use cases.

Vitalik himself admitted that there is still no consensus on replacing the EVM. The state tree reform has advanced further — EIP-7864 already has a concrete draft. But switching to RISC-V? That’s still at the roadmap level. The Glamsterdam hard fork was expected in the first half of 2026, followed by Hegota. Specific details are not yet finalized, but the state tree reform and execution level optimization are definite directions.

Ethereum’s history has always been about what’s possible. From the transition from PoW to PoS, from L1 to Rollup — the system has already proven it’s ready to dismantle engines at ten thousand meters altitude. This time, it’s about deeper things: not adding features, but fundamentally overhauling the foundation. Is this a carefully planned renovation or a hole that’s getting deeper? The answer will come no earlier than 2027. But one thing is clear: Ethereum does not intend to be an old system with patches. This very debate about how to disassemble patches and what engine to install might be more valuable than any conclusion.