Vitalik Announces Ethereum EVM and State Tree: A Radical Change Ahead

The past few weeks have sparked deep discussions within the Ethereum community about the most critical part of blockchain architecture. In the first quarter of 2025, Vitalik Buterin released a comprehensive analysis of how Ethereum should fundamentally change. His thesis is straightforward: the EVM and the state tree structure are insufficient for Ethereum’s future in the era of zero-knowledge proofs. The professional developer community has responded at various levels—from support to outright rejection of key proposals.

Why Change the EVM? The Major Performance Bottleneck

To understand the urgency of these changes, we need to identify where the current problems lie. For over ten years, the EVM (Ethereum Virtual Machine) has been the centerpiece of the Ethereum ecosystem. But as the network grows and advanced technologies like ZK proofs emerge, its limitations have become more apparent.

Vitalik provides a concrete diagnosis: the state tree and virtual machine architecture account for over 80 percent of the computational bottleneck in blockchain proofs. In other words, no matter how well other parts of the system perform, if these two are not addressed, Ethereum cannot scale properly in the future. It’s like trying to speed up a vehicle while the engine remains heavy and sluggish.

Two Main Steps: Structural Overhaul of the State Tree and Complete EVM Replacement

Vitalik proposes two interconnected solutions, which should not be viewed as only linked but as addressing different aspects of performance issues.

First Step: Replacing the State Tree with a Binary Structure

Currently, Ethereum uses a complex structure called the “hexary Keccak Merkle Patricia tree”—a name reflecting its complexity. The EIP-7864 proposal aims to replace this with a simpler binary tree structure.

The practical implications are significant. In the current system, locating a specific transaction or balance requires multiple decisions at each tree level—six possible directions per node. With a binary tree, there are only two options: left or right. The result is straightforward: the length of the Merkle branch reduces by up to four times.

For light clients and distributed verification systems, this is revolutionary. The bandwidth needed for data verification drops substantially. For end users, it means faster transaction verification and lower computational costs.

But Vitalik’s proposal doesn’t stop there. It also includes changing the hash function—the “font” of computation, so to speak. There are two candidates: Blake3 and Poseidon. Blake3 offers consistent performance improvements. Poseidon takes a more aggressive approach, theoretically increasing proof efficiency by several dozen times—but still requires more security audits before approval.

This choice also indirectly signals: Ethereum has moved away from the Verkle Trees approach, long discussed by the community. In 2024, concerns over quantum computing threats to elliptic curve cryptography reduced appetite for Verkle solutions, making the binary tree path more popular.

Second Step: Transitioning the EVM to RISC-V Architecture

The second proposal is broader and more controversial: a long-term replacement of the EVM with the RISC-V instruction set architecture.

RISC-V is an open-source, energy-efficient instruction set originally developed from academic research and now a standard in all zero-knowledge proof systems. Vitalik’s logic is elegant: if ZK proof generators speak RISC-V language, why should the blockchain virtual machine speak a different language and add a translation layer? Removing this redundant layer would immediately boost efficiency.

The technical implementation isn’t as complicated as it might seem. A RISC-V interpreter can be coded in a few hundred lines of code. For Vitalik, this aligns with the right design philosophy for blockchain: simplicity focused on performance.

The transition plan involves three phases:

1. Use the RISC-V virtual machine to run pre-compiled contracts. About 80 percent of existing pre-compiled contracts could be rewritten in RISC-V code.

2. Allow developers to deploy contracts directly on the new VM. The new system and the EVM would run side by side, enabling gradual migration.

3. Eventually, remove the EVM—though it won’t disappear entirely. It will be converted into a smart contract running on the RISC-V VM, ensuring full backward compatibility. Vitalik’s vision is poetic: the steering wheel remains the same for drivers, but the engine underneath has silently changed.

The Production Bottleneck: Without Changes to the EVM, No Scalability

The core argument is based on one number: 80 percent. This is the percentage of Ethereum’s proof bottleneck directly caused by the state tree and virtual machine architecture. Practically, this means all other optimizations have limited effect unless these two are addressed.

In the era of ZK-powered scaling, this architectural limitation will be a chain’s ankle. Ethereum sees itself needing to evolve beyond patchwork improvements.

Counter-Proposal: Arbitrum’s Challenge to the RISC-V Strategy

But the story isn’t just about consensus. Last November, Offchain Labs—the main developers of Arbitrum—published a detailed technical rebuttal.

Their key observation is nuanced and important: yes, RISC-V is ideal for ZK proofs, but it shouldn’t be the “execution format” for smart contracts. They make a critical distinction: “delivery instruction set” (dISA) and “proof instruction set” (pISA) don’t have to be the same.

Their analogy is practical: a warehouse operates most efficiently with a forklift, but that doesn’t mean a courier should also use a forklift to deliver a package to your door. Each tool has its proper context.

For contract execution, Offchain Labs advocates for WebAssembly (WASM) as a better solution. Their technical reasoning is solid:

First, WASM has proven high efficiency on standard hardware. Most Ethereum nodes do not run on RISC-V specialized chips, and emulation would introduce significant overhead.

Second, WASM has a mature, type-safe verification mechanism, proven in millions of execution environments worldwide.

Third, the WASM toolchain ecosystem is well-established, with extensive developer support.

More importantly, they don’t just theorize. Offchain Labs has built a prototype: using WASM as the contract delivery format, then compiling it to RISC-V for ZK proofs. Each layer performs its specialized task without conflict.

They also highlight a critical risk: ZK proof technology is rapidly evolving. RISC-V implementations have advanced from 32-bit to 64-bit in recent years. Locking RISC-V at the Ethereum L1 level now could be problematic if a superior proof architecture emerges in two years. Betting on a moving target isn’t Ethereum’s style.

Larger Industry Shift: Ethereum and Layer 2 Moving Apart

To fully understand this technical debate, we need to look at broader industry dynamics.

Recently, Vitalik expressed skepticism about the need for a “dedicated L2 roadmap for Ethereum.” This sparked a deep reflexive response from Layer 2 operators.

Ben Fisch, CEO of Espresso Systems, explained to the media: Layer 2 was originally meant to help Ethereum scale. But now that Ethereum itself is pursuing its own scaling improvements, the role of Layer 2 must evolve. It’s no longer just an auxiliary layer but a more independent ecosystem.

Layer 2 operators are not panicking. Instead, they are actively repositioning. OP Labs co-founder described Layer 2s as “independent websites,” while Ethereum remains the periodic settlement standard. Polygon’s CEO was more direct: the real challenge isn’t just scaling but building specialized block space for actual use cases—like payments infrastructure.

In other words, this major technical shift in Ethereum’s execution layer reflects a larger structural trend: Ethereum is returning to control of its core competencies, while Layer 2s are either pushed aside or ultimately discovering their own raison d’être.

Will This Become Reality? The Path Forward and Challenges

Vitalik himself admits there’s no broad consensus yet among developers on replacing the EVM. The state tree reform has a firmer foothold—EIP-7864 has a concrete draft and active development teams.

But the RISC-V EVM replacement? It’s still in the “roadmap” stage, far from actual code implementation.

However, Vitalik offered a confidence statement last week: Ethereum has already performed an engine change during the Merge. It can handle four more major changes—state tree optimization, simplified consensus, ZK-EVM verification, and VM replacement.

The timeline is beginning. Ethereum aims for the Glamsterdam upgrade in the first half of 2026, followed by Hegota. Technical details are still being finalized, but reforms to the state tree and execution layer are confirmed as primary directions.

The question isn’t “can or cannot.” Ethereum has repeatedly proven its capability—from PoW to PoS, from all-in on L1 to a rollup-centric ecosystem. The challenge is that these are not cosmetic architectural tweaks but fundamental rebuilds—rebuilding the foundation while the building is still operational. It’s not just feature addition but a complete replacement of the old architecture.

The technical debate itself—whether these changes are beneficial or lead to endless complexity—may be more valuable than the final resolution. Ethereum is consciously choosing not to be a patched legacy system in the ZK era. How to break the engine parts and what new model becomes standard will only be clear in 2027.