Vitalik Buterin Proposes EIP-7864 to Reduce Proving Costs by 80%

Ethereum co-founder Vitalik Buterin has unveiled a significant proposal, known as EIP-7864, aimed at improving the efficiency of proof verification within the blockchain network. This proposal suggests technical changes, including a new binary state tree structure and a potential transition to the RISC-V Virtual Machine, which together could lead to substantial reductions in proving costs and enhance overall system performance.

Key Takeaways

EIP-7864 Proposal: Vitalik Buterin proposes shifting from a hexary Merkle tree to a binary tree to increase proof efficiency in Ethereum.
Efficiency Gains: The new structure could lower costs and improve data bandwidth for tools by producing shorter Merkle branches.
RISC-V Virtual Machine: A long-term goal includes replacing the existing Ethereum Virtual Machine with RISC-V for better performance and reduced complexity.
Three-Stage Roadmap: The transition will occur in three stages, with a focus on maintaining backward compatibility with existing contracts.
Community Consensus: While the proposal has potential benefits, it requires further discussion within the Ethereum development community.

ETH tackles 80% proving bottleneck as Vitalik proposes binary state tree and long-term RISC-V VM swap.

Main Content

Ethereum co-founder Vitalik Buterin has introduced two critical technical modifications through a proposal known as EIP-7864. This proposal seeks to tackle the inefficiencies linked to proof verification on the Ethereum blockchain.

Immediate Changes: Binary State Tree

The primary focus of EIP-7864 is to replace Ethereum’s current hexary keccak Merkle Patricia Tree with a binary tree structure that utilizes a more efficient hashing function. The existing hexary setup was crafted with different priorities than the ones suited for the proof-heavy design that Ethereum developers are now targeting.

The binary tree structure is notable for yielding Merkle branches that are four times shorter than those produced by the current system. This is because binary operations result in significantly less computational complexity, calculated as 32 times log(n) for binary versus 512 times log(n) divided by four for hexary.

Moreover, achieving these shorter branches would not only cut down client-side branch verification costs dramatically but also lower data bandwidth requirements for tools such as Helios and private information retrieval systems.

Enhanced Proving Efficiency

Proving efficiency improvements are set to extend beyond mere branch length reductions. The proposal suggests that the new shorter branches could yield a three to fourfold increase in efficiency independently of hash function improvements. If the blake3 function is utilized instead of keccak, another threefold enhancement may be possible. Additionally, implementing a Poseidon variant might lead to up to 100 times better performance, although its deployment would necessitate further security evaluations.

The design implements a page-based storage approach that consolidates adjacent storage slots into groups ranging from 64 to 256 slots (approximately 2 to 8 kilobytes). This allows contracts that access early storage slots to gain from batch efficiency rather than incurring costs for individual access. The proposal estimates that utilizing this method could generate savings exceeding 10,000 gas per transaction for decentralized applications tapping into initial storage slots, which is significant for many actively deployed contracts.

Future Vision: RISC-V Virtual Machine

The proposal also outlines a long-term strategy to transition from the Ethereum Virtual Machine (EVM) to a more efficient option like RISC-V. The reasoning behind this shift is that the EVM's architecture does not cater well to a proof-heavy blockchain, and replacing it would rectify fundamental inefficiencies instead of merely patching them up through incremental precompiles and solutions.

Buterin emphasizes four key advantages of RISC-V compared to EVM:

Raw Execution Efficiency: RISC-V's superior performance could negate the need for many precompiles.
Prover Efficiency: Zero-knowledge provers designed in RISC-V would align well with the existing proving infrastructure.
Client-Side Proving: Implementing a RISC-V VM would allow users to create zero-knowledge proofs locally, enhancing privacy and verification without needing external tools.
Simplicity: A RISC-V interpreter can be constructed with a few hundred lines of code, leading to simpler implementations.

Deployment Roadmap

The proposal delineates a deployment strategy divided into three phases. In the initial phase, a new VM, possibly RISC-V, would manage only precompiles, converting current and new precompiles into code blobs within the new VM. The second phase allows users to deploy contracts directly in the new VM. Finally, in the third phase, the EVM would be phased out and reincorporated as a smart contract in the new VM, ensuring backward compatibility with existing contracts while primarily updating gas costs, which are expected to decrease with ongoing scalability improvements.

Buterin asserts that both proposed changes target the same underlying challenge from different angles. The state tree and the VM combined account for over 80% of the proofing efficiency bottleneck. Tackling either aspect without addressing the other would leave the key issue only partially resolved. In contrast, addressing both concurrently would create a system that aligns structurally with the zero-knowledge proof-centric architecture that Ethereum aims to cultivate, rather than forcing this model onto an infrastructure built for different purposes.

While the VM replacement proposal does not currently reflect consensus among the Ethereum developer community, it is positioned as a future necessity that will gain clarity once the state tree adjustments are finalized.