Vitalik Buterin Proposes Binary State Tree Migration and RISC-V VM Transition for Protocol Efficiency

Ethereum co-founder Vitalik Buterin published a detailed technical proposal advocating for two major protocol upgrades: transitioning from the current hexary Merkle Patricia Tree to a binary state tree structure, and eventually replacing the Ethereum Virtual Machine with a RISC-V-based architecture.

The proposals, outlined in a March 2026 post, aim to address proving efficiency bottlenecks, reduce data bandwidth requirements, and improve client-side verification capabilities. Buterin characterized the binary tree migration as an “omnibus” upgrade incorporating十年 of learning about state tree design, while positioning VM changes as a longer-term roadmap item that could make precompiles largely unnecessary and simplify the protocol architecture.

Binary State Tree Migration Proposed for Proving Efficiency Gains

Buterin outlined EIP-7864, currently under development, which would replace Ethereum’s existing hexary keccak Merkle Patricia Tree with a binary tree structure utilizing more efficient hash functions. The proposed change would reduce Merkle branch length by a factor of four, from 512*log(n)/4 to 32*log(n) bytes.

This reduction would decrease data bandwidth requirements for client-side verification tools including Helios and private information retrieval systems. Proving efficiency would improve by three to four times from shorter branches alone, with additional gains from hash function selection. Potential hash function candidates include blake3, offering approximately three times efficiency improvement over keccak, or Poseidon variants, which could provide 100x efficiency gains pending additional security analysis.

The binary tree design incorporates “page” grouping that combines adjacent storage slots into pages of 64 to 256 slots, representing 2 to 8 kilobytes of data. This structure allows storage access to achieve similar efficiency benefits as code loading and editing. Block headers and the first approximately 1 to 4 kilobytes of code and storage would reside in the same page, potentially saving more than 10,000 gas per transaction for decentralized applications that frequently access initial storage slots.

Additional benefits cited include reduced variance in access depth between large and small contracts, simpler implementation compared to hexary structures, and the ability to incorporate metadata bits needed for future state expiry implementations.

Virtual Machine Transition to RISC-V Architecture Considered

Buterin presented a case for replacing the Ethereum Virtual Machine with a RISC-V-based architecture, describing the EVM as facing limitations in meeting the needs of Ethereum’s general-purpose design. The proposal identifies multiple efficiency objectives for a new VM.

Raw execution efficiency improvements could eliminate most precompile requirements. Prover efficiency would increase, addressing current limitations where provers are written for RISC-V rather than EVM. Client-side proving capabilities would enable users to generate ZK-proofs about account behavior under specific data conditions. Implementation simplicity would be achieved through a RISC-V interpreter requiring only a few hundred lines of code.

A three-phase deployment roadmap was outlined. Phase one would restrict the new VM to precompile functions, with approximately 80 percent of existing precompiles and new ones implemented as NewVM code. Phase two would enable user deployment of NewVM contracts. Phase three would retire the EVM entirely, reimplementing it as a smart contract written in the new VM.

EVM users would maintain full backward compatibility through this transition, with gas cost changes being the primary difference, though Buterin noted these would be overshadowed by ongoing scaling work over subsequent years.

Protocol Evolution Context and Developer Considerations

Buterin characterized both proposals as addressing the largest bottlenecks in efficient proving, which together account for over 80 percent of proving overhead. The changes are described as mandatory for various client-side proving use cases.

The binary tree migration was framed as incorporating learnings from ten years of state tree design experience. The VM transition was positioned as more speculative and non-consensus at present, with Buterin stating that Ethereum would remain functional with only EVM plus GPU improvements, but that a better VM could make the protocol “beautiful and great.”

Both proposals face implementation timelines aligned with Ethereum’s long-term state roadmap, with the binary tree migration proceeding through EIP process and the VM transition considered a longer-term initiative pending completion of state tree changes.

FAQ: Ethereum Protocol Upgrade Proposals

What is the difference between the current Ethereum state tree and the proposed binary tree?

Ethereum currently uses a hexary Merkle Patricia Tree with keccak hashing. The proposed binary tree would use a binary structure with more efficient hash functions, reducing Merkle branch length by approximately four times. This decreases data bandwidth for client-side verification and improves proving efficiency. The binary design also groups storage slots into pages for more efficient access.

How would a transition from EVM to RISC-V affect existing Ethereum applications?

Under the proposed three-phase roadmap, existing EVM applications would maintain full backward compatibility throughout the transition. The EVM would eventually be reimplemented as a smart contract written in the new VM, allowing existing contracts to continue functioning. Gas costs would change, but these changes would be implemented alongside other scaling improvements.

What efficiency improvements could the new VM provide?

A RISC-V-based VM could offer raw execution efficiency sufficient to eliminate most precompile requirements, improved prover efficiency compared to current EVM implementations, and client-side proving capabilities enabling ZK-proof generation about account behavior. Implementation would be significantly simpler, with an interpreter requiring only hundreds of lines of code compared to current EVM complexity.