ETH tackles 80% proving bottleneck as Vitalik proposes binary state tree and long-term RISC-V VM swap.
Summary
- EIP-7864 replaces the hexary keccak Merkle Patricia Tree with a unified binary state tree using BLAKE3 (or a future Poseidon2), cutting Merkle proof size by about 75% and branches by 3–4x.
- Page-based storage groups 64–256 adjacent slots so early-slot dapps can save over 10k gas per transaction, while simpler, more uniform depth improves auditing and sets up future state expiry.
- Long-term, Vitalik proposes replacing the EVM with a RISC-V VM, arguing state tree plus VM drive over 80% of proving cost and that a RISC-V stack would align with existing ZK provers, reduce precompiles, and keep old contracts via staged migration.
Ethereum (ETH) co-founder Vitalik Buterin has proposed two technical changes aimed at addressing proof-efficiency challenges in the blockchain network, according to a proposal outlined in EIP-7864 and related documentation.
The near-term proposal, designated as EIP-7864, would replace Ethereum’s current hexary keccak Merkle Patricia Tree with a binary tree structure utilizing a more efficient hash function. The existing hexary structure was designed for priorities that differ from the proving-heavy architecture Ethereum developers are currently pursuing, according to the proposal.
The binary tree structure would produce Merkle branches that are four times shorter than the current system, as binary operations require 32 times log(n) compared to hexary’s 512 times log(n) divided by 4, according to technical specifications in the proposal.
The reduction would decrease costs for client-side branch verification and reduce data bandwidth requirements for tools including Helios and private information retrieval systems by the same factor, the proposal states.
Proving efficiency gains would extend beyond branch length improvements. The proposal indicates that shorter branches would deliver a three to four times improvement, separate from hash function optimization. Implementing blake3 instead of keccak could provide an additional three times improvement, while a Poseidon variant could potentially deliver 100 times improvement, though additional security analysis is required before Poseidon deployment, according to the document.
The binary tree design includes a page-based storage system that groups adjacent storage slots into pages of 64 to 256 slots, approximately 2 to 8 kilobytes. The block header and the first 1 to 4 kilobytes of code and storage would share the same page, allowing contracts that read from initial storage slots to benefit from batch efficiency rather than individual access costs. The proposal estimates this could save more than 10,000 gas per transaction for decentralized applications that load data from initial storage slots, which represents a substantial portion of active deployed contracts.
Binary trees offer simpler implementation and auditing processes, according to the proposal. The structure provides more predictable access depth across contracts of varying sizes, reducing variance in execution costs, and creates space for embedding metadata required for future state expiry development.
The longer-term proposal involves replacing the Ethereum Virtual Machine with a more efficient virtual machine such as RISC-V. The proposal argues that the EVM’s architecture is not optimized for a proving-heavy blockchain and that replacing it would address fundamental inefficiencies rather than managing them through accumulated precompiles and workarounds.
Buterin’s proposal cites four advantages of RISC-V over the EVM. First, raw execution efficiency: RISC-V outperforms the EVM to a degree that would eliminate the need for many precompiles, as underlying computations could run efficiently within the VM itself. Second, prover efficiency: zero-knowledge provers are currently written in RISC-V, creating natural alignment with existing proving infrastructure. Third, client-side proving: a RISC-V VM would enable users to generate zero-knowledge proofs locally about account interactions with specific data, enabling privacy and verification applications not currently supported by the EVM without external tools. Fourth, simplicity: a RISC-V interpreter can be implemented in several hundred lines of code, according to the proposal.
The deployment roadmap outlined in the proposal includes three stages. In the first stage, a new virtual machine, potentially RISC-V, would handle precompiles only, with current and new precompiles becoming code blobs in the new VM. In the second stage, users could deploy contracts directly in the new VM. In the third stage, the EVM would be retired and reimplemented as a smart contract written in the new VM, preserving backwards compatibility for existing contracts with the primary change being gas cost adjustments, which are expected to be overshadowed by concurrent scaling developments.
Buterin characterizes both changes as addressing the same fundamental challenge from different angles. The state tree and the VM together account for more than 80 percent of the bottleneck in efficient proving, according to the proposal. Addressing either component without the other leaves the larger problem partially unresolved, while addressing both would produce a protocol structurally aligned with the zero-knowledge-proof-heavy architecture Ethereum has been developing, rather than retrofitting that architecture onto infrastructure designed for different requirements.
The proposal acknowledges that the VM replacement does not currently represent consensus within the Ethereum development community, describing it as a change that will become more apparent once state tree modifications are completed. The proposal presents the changes as sequential: binary trees first, followed by VM replacement once proving infrastructure matures around the new state structure. The EVM has accumulated complexity through years of incremental additions, and the proposal states that meeting Ethereum’s functionality requirements necessitates addressing the VM rather than continuously implementing workarounds.
