I've noticed something interesting lately. Vitalik is coming back with quite radical proposals on Ethereum's architecture, and honestly, it's worth discussing.

So here it is, for years, Ethereum developers have had a kind of bad habit. Every time they needed a new cryptographic operation on-chain, instead of properly implementing it in the EVM, they simply bypassed the problem by adding precompiled contracts at the protocol level. It's like constantly tinkering instead of rebuilding the foundations. Vitalik essentially said: stop, enough is enough. If the EVM isn't good enough, we're not going to keep patching it. We're going to replace it.

He proposed two major changes. The first concerns Ethereum's state tree, which you can think of as the system that indexes the ledger. Currently, it's a complicated structure called a sextuple Keccak Merkle Patricia tree (yeah, the name is a bit crazy). The idea is to replace it with a simple binary tree. Specifically, instead of choosing your direction at a six-way intersection, you'd only have two options: left or right. Result? The length of Merkle branches decreases by about 75%. For light clients, that's huge in terms of bandwidth.

But Vitalik doesn't stop there. He also wants to change the hash function. Two candidates: Blake3 or Poseidon. Blake3 is sure but traditional. Poseidon is more ambitious; it could theoretically multiply proof efficiency by several tens of times, but more security audits are needed.

The second change is more controversial: replacing the EVM with RISC-V in the long term. RISC-V is an open-source instruction set, initially created for something else, but now used everywhere in ZK proof systems. The logic is simple: since all provers already speak RISC-V, why would the virtual machine use another language with an intermediate translation layer? That's inefficient. A RISC-V interpreter requires only a few hundred lines of code.

Vitalik presented a three-step plan: first, run precompiled contracts on the new virtual machine; second, allow developers to deploy directly on this new architecture alongside the existing EVM; and finally, remove the EVM but rewrite it as a smart contract on the new virtual machine. Zero compatibility breakage. That's elegant.

The figures he provided are striking: the state tree and the virtual machine together account for over 80% of Ethereum's proof bottleneck. In other words, without touching these two components, real scalability in the ZK era is out of reach.

But of course, it's not unanimous. Offchain Labs, the team behind Arbitrum, published a detailed technical refutation. Their argument: RISC-V is good for ZK proofs but not for serving as a contract delivery format. They make an important distinction: you don't need the delivery person to operate a forklift just because your warehouse uses one. They advocate for WebAssembly (WASM) for the contract layer, and honestly, their arguments are solid. WASM runs efficiently on standard hardware, whereas most Ethereum nodes don't run on RISC-V chips. Offchain Labs has even implemented a prototype: WASM for contracts, compiled into RISC-V for ZK proof. Two layers, each doing its job.

What’s interesting is the broader context. A few months ago, Vitalik questioned whether Ethereum even needs a dedicated Layer 2 roadmap. And Layer 2s aren’t panicking; they’re actively starting to "de-Ethereumize." Polygon and OP Labs now talk about Ethereum as an underlying settlement standard, not as their main infrastructure. It’s a real shift in direction.

Vitalik himself admits there’s no broad consensus yet on replacing the EVM. The state tree reform is more advanced with EIP-7864, which already has a concrete plan. But replacing the EVM with RISC-V? That’s still at the strategic plan stage, far from being integrated into the code.

What struck me is what he recently stated: Ethereum has already changed a jet engine in flight with The Merge, and it can do so about four more times. The state tree, simplified consensus, ZK-EVM verification, replacing the virtual machine. It’s ambitious.

The real question is: is this a thoughtful renovation or an ever-growing sinkhole? Impossible to say for now. But one thing’s certain: Ethereum has no intention of becoming an old patched-up system in the ZK era. How to dismantle the patches and what model to implement—this very debate might be more valuable than the final answer.