Vitalik Buterin Proposes Binary State Trees and RISC-V Improvements to Improve Ethereum’s Execution Layer

TLDR

EIP-7864 proposes to replace Ethereum's Hexari Kecak tree with a binary structure, reducing the Merkel branch size by 75%.

Blake3 and Poseidon hash functions can speed up Ethereum's verifiability by up to 100x with the current Keck arrangement.

Replacing EVM with RISC-V reduces the translation layer of the ZK prover, reducing the protocol's verification bottleneck by more than 80%.

The three-level RISC-V release maintains full EVM backward compatibility while bypassing legacy infrastructure through a modern contract wrapper.

Improvements to Ethereum's execution layer are at the center of a detailed proposal from Vitalik Buterin. Ethereum's founder recently shared an overview of two major technical changes.

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

Together, they represent the most extensive architecture of Ethereum's base layer in years.

Binary Trees: The Structural Transformation of the Ethereum State

The tree transformation of the state is among the most technically realistic ideas that Buterin listed. It focuses on EIP-7864, which proposes to replace the existing hexari keccak Merkle Patricia Tree with a binary tree structure.

The new design uses a more efficient hash function. Buterin said on Social X that this switch would produce four times fewer Merkel branches than the current setup.

Shorter branches make client-side authentication cheaper. Devices like Helios and PIR will see a 4x reduction in data bandwidth costs.

In addition, varying the hash function adds additional efficiency gains. Blake3 can deliver roughly three times the speed on the keccak, while the Poseidon variant can achieve a 100-fold improvement, although further safety evaluation is needed there.

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

Many decentralized applications that read frequently from the first few storage locations can save more than 10,000 gas per transaction.

VM Changes: Case of replacing EVM

Buterin made a sharp argument for EVM replacing itself in the long run. It pointed to a pattern where developers try to avoid EVM as much as possible, treating it as a hindrance rather than a feature.

For him, this defeats the whole purpose of Ethereum. He argues that the fix is ​​building a better virtual machine rather than adding more solutions.

His preferred candidate is RISC-V, the same architecture that most ZK developers already use. The reason is straightforward: if the provers were already written in RISC-V, making the new VM RISC-V removes the entire translation layer.

The RISC-V interpreter requires only a few hundred lines. Buterin describes this blockchain VM as a “must-see”.

He proposed a three-stage model. The new VM handles presets first, replacing roughly 80% of today's presets with new VM code. Users gain the ability to directly deploy NewVM contracts.

Eventually, the EVM will be retired and become a smart contract written into the new VM, maintaining full backward compatibility for existing users except for gas cost shifts.

What this means for Ethereum's validator infrastructure.

Buterin speaks directly to why these changes are important beyond aesthetics. Together, state trees and VMs account for more than 80% of the authentication bottleneck.

Fixing both is a prerequisite for any meaningful client-side authentication. Without these changes, ZK applications would need to maintain their own trees that would need to be written to the Ethereum state, adding complexity and cost.

A binary tree transformation allows Ethereum's native state to be provably compatible. That opens the door for ZK applications to work directly with Ethereum storage instead of building around it.

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

Buterin acknowledged that VM changes are more speculative and do not yet have widespread consensus. However, he expressed confidence that once the state's roadmap is laid out, replacement of EVMs will be an obvious choice.

Its framework layouts both evolve as practical needs rather than theoretical refinements, tied directly to the network's ability to scale workloads across a variety of use cases.