Ethereum is about to undergo a major overhaul, and the core issue is how to handle the EVM.

Recently, Vitalik raised an interesting topic. Up to now, Ethereum developers have preferred to avoid directly modifying the EVM whenever new cryptographic operations are needed, instead hardcoding pre-compiled contracts into the protocol layer. It was a kind of workaround strategy. But Vitalik sees this as not a fundamental solution.

He proposed two main approaches. The first is to change the state tree from the current hexagonal structure to a simpler binary tree (EIP-7864). This would reduce the length of Merkle branches to a quarter, significantly decreasing data verification bandwidth for lightweight clients. The second is more radical: replacing the EVM itself with a RISC-V architecture. The logic is simple — ZK proof systems already use RISC-V, so why should the virtual machine be written in a different language? Removing the translation layer naturally improves efficiency.

Interestingly, Arbitrum disagrees with this. Off-chain rollup teams have provided specific rebuttals, arguing that RISC-V is good for proofs but not suitable for contract delivery formats. Instead, they suggest using WASM for the contract layer and RISC-V only for proof generation. They claim to have already prototyped this on Arbitrum.

Looking at the bigger picture, this also relates to redefining the roles of L2 and Ethereum. Since Vitalik questioned the need for dedicated L2 roadmaps, L2s are increasingly moving toward independence from Ethereum. Polygon CEO said the real challenge isn’t scalability but creating unique block spaces for each L2.

So, will this actually happen? Vitalik himself admits there’s no broad consensus on replacing the EVM at this point. The state tree overhaul is at a more mature stage (with specific drafts and teams), but the RISC-V transition is still in the roadmap phase. However, he made an interesting remark — Ethereum has already replaced its engine once with The Merge, and in the future, it could do about four more upgrades, including state tree changes, simplified consensus algorithms, ZK-EVM verification, and virtual machine replacements.

The Glimmer upgrade is scheduled for release in the first half of this year, followed by the Hegatha upgrade. While details are not yet finalized, the main themes are expected to be state tree restructuring and execution layer optimization.

Ultimately, this isn’t just patchwork; it’s about tearing down the foundation and rebuilding from scratch. The commitment to not remaining outdated in the ZK era is evident. The results should be visible by 2027.