TLDR:

• EIP-7864 proposes replacing Ethereum’s hexary keccak tree with a binary structure, cutting Merkle branch size by 75%.
  
• Blake3 and Poseidon hash functions could accelerate Ethereum’s proving efficiency by up to 100x over the current keccak setup.
  
• Replacing the EVM with RISC-V would reduce a ZK prover translation layer, cutting the protocol’s proving bottleneck by over 80%.
  
• A three-stage RISC-V rollout preserves full EVM backwards compatibility while retiring legacy infrastructure through a smart contract wrapper.

Ethereum execution layer improvements are at the center of a detailed proposal from Vitalik Buterin. The Ethereum co-founder recently shared a comprehensive breakdown of two major technical changes.

His post covers a transition to binary state trees and a long-term shift away from the EVM. Both changes target proving efficiency, client-side capabilities, and long-term protocol simplicity.

Together, they represent the most sweeping architectural rethink of Ethereum’s base layer in years.

Binary Trees: A Structural Overhaul of Ethereum’s State

The state tree change is among the most technically concrete proposals Buterin outlined. It centers on EIP-7864, which proposes replacing the current hexary keccak Merkle Patricia Tree with a binary tree structure.

The new design uses a more efficient hash function. Buterin noted on social X that this switch produces Merkle branches four times shorter than the existing setup.

Shorter branches make client-side verification cheaper. Tools like Helios and PIR would see a 4x reduction in data bandwidth costs.

On top of that, swapping out the hash function adds further efficiency gains. Blake3 could deliver roughly three times the speed over keccak, while a Poseidon variant could achieve 100 times the improvement, though more security review is needed there.

The binary design also groups storage slots into pages of 64 to 256 slots each. This allows storage to benefit from the same efficiency as code loading.

Many decentralized applications that frequently read from the first few storage slots could save over 10,000 gas per transaction as a result.

VM Changes: The Case for Replacing the EVM

Buterin made a pointed argument for replacing the EVM itself over the longer term. He pointed to a pattern where developers try to avoid the EVM whenever possible, treating it as an obstacle rather than a feature.

To him, this defeats the purpose of Ethereum’s generality. The fix, he argues, is building a better virtual machine rather than adding more workarounds.

His preferred candidate is RISC-V, the same architecture that most ZK provers already use. The reasoning is direct: if provers are already written in RISC-V, making the new VM be RISC-V removes an entire translation layer.

A RISC-V interpreter requires only a few hundred lines of code. Buterin described this as what a blockchain VM “should feel like.”

He proposed a three-stage rollout. The new VM would first handle precompiles, replacing roughly 80% of today’s precompiles with NewVM code. Users would then gain the ability to deploy NewVM contracts directly.

Finally, the EVM would retire and become a smart contract written in the new VM, preserving full backwards compatibility for existing users except for gas cost shifts.

What This Means for Ethereum’s Proving Infrastructure

Buterin was direct about why these changes matter beyond aesthetics. State trees and the VM together account for more than 80% of the proving bottleneck today.

Fixing both is essentially a prerequisite for any meaningful expansion of client-side proving. Without these changes, ZK applications that need to compose with Ethereum’s state must maintain their own separate trees, which adds complexity and cost.

The binary tree change allows Ethereum’s native state to become prover-friendly. That opens the door for ZK applications to work directly with Ethereum’s storage rather than building around it.

This would reduce the overhead that many privacy protocols and wallet applications currently carry.

Buterin acknowledged the VM changes remain more speculative and do not yet have broad consensus. However, he expressed confidence that once the state roadmap is in place, replacing the EVM will become the obvious choice.

His framing positions both changes as practical necessities rather than theoretical improvements, tied directly to the network’s ability to scale proving workloads across a wider range of use cases.