A few months ago, Vitalik shared a very interesting idea: Ethereum actually has deeper problems than it appears at first glance. Instead of constantly patching the EVM with new pre-compiled contracts, maybe it's time to rethink the architecture itself?

And he proposed two serious changes. The first concerns the state tree — the same Merkle tree that Ethereum uses as an indexing system for all balances and verifications. The problem is that the current structure, the so-called six-way Keccak Merkle Patricia tree, is simply too bulky. Each query requires traversing through many branches.

Vitalik suggests EIP-7864 — replacing it with a binary tree. It sounds simple, but the effect is impressive: the length of the Merkle tree is reduced by four times. For light clients, this means significantly less data to verify. But he didn't stop there — he also wants to change the hash function itself. Blake3 or Poseidon? Poseidon is more ambitious; theoretically, it could increase proof efficiency by tens of times, but security still needs to be verified.

The second move is much bolder — a long-term replacement of the EVM with RISC-V. The logic is straightforward: if ZK proof systems already understand RISC-V, why should the virtual machine use a different language? It just adds an unnecessary translation. The RISC-V interpreter requires only a few hundred lines of code — exactly what the blockchain interface should be.

There are three planned phases: first, to run pre-compiled contracts on the new VM; then, to allow developers to deploy contracts on the new machine alongside the EVM; and finally, to phase out the EVM, but not delete it — just rewrite it as a smart contract on the new platform. Old contracts will continue to operate unchanged.

Vitalik named a figure: the state tree and virtual machine together account for over 80% of Ethereum’s proof limitations. Without these changes, scaling in the ZK era will simply stall.

But not everyone agrees. The Arbitrum Offchain Labs team published a serious objection. They say: yes, RISC-V is great for ZK proofs, but that doesn’t mean contracts should be written in RISC-V. They proposed splitting this — WebAssembly for contracts, then compilation into RISC-V for proofs. Their argument: most Ethereum nodes do not run on RISC-V chips, WASM has proven security mechanisms, and the WASM tool ecosystem has been tested in billions of executions.

This is interesting because it points to a larger trend. Layer 2 solutions are beginning to realize that their role is changing. Ethereum itself is becoming faster, so Layer 2s are seeking their unique purpose — not just scaling, but creating specialized spaces for real-world scenarios.

Regarding whether this can be implemented — there is no consensus. The reform of the Merkle tree is more concrete; EIP-7864 already has a team. But replacing the EVM? That’s still on the roadmap. Hard forks Glamsterdam and Hegota are expected in the first half of 2026, but details are not finalized.

But Vitalik probably knows what he's doing. Ethereum has already changed one reactive engine mid-flight — The Merge. He’s prepared to change about four more. It’s not just adding features but fundamentally overhauling the core. Whether this will be a carefully planned renovation or an endless pit of complexity — the answer will likely only become clear in 2027.