[Keynotes] Possible futures of the Ethereum protocol, part 4: The Verge

This article explores Ethereum’s “Verge” initiative, which seeks to make running a fully-verifying Ethereum node more accessible and efficient, potentially enabling even devices as lightweight as smartwatches to participate in network validation. A key feature of blockchain is its decentralized nature, where any user can run a node and verify the blockchain’s accuracy. However, for this to work, it must be practical for a broad user base to run these nodes. Currently, this requires significant storage, making it challenging for everyday users to contribute to network security.

Goals of the Verge Initiative

The Verge focuses on stateless verification and optimized data structures to significantly reduce the storage and computational needs of Ethereum nodes. Stateless verification would allow nodes to validate blocks without storing the entire state data. Instead, nodes would rely on a “witness” attached to each block, containing both the data accessed by the block and a cryptographic proof that the data is correct.

Verkle Trees and Alternative Data Structures: Verkle trees, a data structure Ethereum is exploring, use elliptic curve-based vector commitments to produce compact proofs, reducing the proof size needed to validate blocks. This would make verifying transactions more accessible, even on devices with limited storage. However, Verkle trees are not resistant to quantum computing attacks and are complex to implement, prompting the Ethereum community to explore alternatives.

Potential Alternative: STARKed Binary Trees

STARK (Scalable Transparent Argument of Knowledge) proofs offer another pathway to lighter validation, enabling “stateless” verification. With STARKs, Ethereum could use binary hash trees for verification, further reducing proof sizes. However, this solution is computationally demanding and currently requires high-powered hardware. Techniques like GKR (Goldwasser-Kalai-Rothblum) have shown promise in improving the efficiency of STARKs, but they are still being developed.

The Challenges of Implementation

The Verge also addresses the challenge of high storage demands for Ethereum nodes. Currently, nodes need hundreds of gigabytes to store the blockchain’s state data, which grows every year. Stateless verification would eliminate the need to store the entire state, but implementing this shift involves revising Ethereum’s state tree structure (currently a hexary Merkle Patricia tree). Verkle and STARK trees are both promising but require complex tradeoffs between security, storage, and quantum resistance.

The remaining work includes analyzing new gas structures (as in EIP-4762) to balance network resource demands, improving the efficiency of cryptographic proof systems, and finalizing Ethereum’s transition to these new structures. Developers face decisions on which data structure to choose, with options varying in storage size, security assumptions, and compatibility with existing proof systems.

Future Impacts and Interactions with Other Roadmap Goals

Achieving statelessness would significantly lower the barriers for running an Ethereum node, supporting Ethereum’s decentralization and enabling solo staking with lower minimum balances. This change also aligns with history expiry efforts like EIP-4444, which aims to reduce Ethereum’s historical storage burden by moving data to decentralized storage networks like the Portal network.

In essence, the Verge aims to create an Ethereum that’s easier for a broad range of users to verify independently, reinforcing the decentralized ethos of blockchain technology while reducing storage and computational needs. This long-term approach will help Ethereum scale securely while making network validation accessible across a wide array of consumer devices.

Validity Proofs for EVM Execution

Goal:

The aim is for users to verify Ethereum blocks by downloading only part of the data (using data availability sampling) and confirming a small proof of block validity, allowing even resource-limited devices like phones to act as fully verifying Ethereum clients. Achieving this requires validity proofs (using SNARKs or STARKs) for the consensus (proof of stake) and execution (EVM) layers, with EVM execution being the more complex of the two.

How It Works:

In Ethereum, the EVM is defined as a state transition function (STF), processing each block’s data to produce a new state. For light clients, verifying an EVM transaction involves three main claims:

1. Verifying that the pre-state corresponds to a proof.
2. Ensuring the STF doesn’t access objects outside the proof.
3. Confirming the STF results in the new state.

These proofs would allow light clients to verify execution without needing to store the entire state, allowing for a more decentralized and accessible Ethereum network.

Challenges & Next Steps:

Currently, EVM validity proofs face hurdles in security and prover time:

• Security: Ensuring proof security might involve multiple prover implementations (like Ethereum’s multi-client strategy) or formal verification using theorem-proving tools to confirm proofs are correct.
• Prover Time: Today’s proving time for an average block is ~15 seconds. To reach the target 4 seconds, Ethereum would need:
• Parallelization: Splitting block computation per opcode rather than per transaction, ensuring memory consistency.
• Proof System Optimization: Systems like Orion and Binius could accelerate proofing.
• EVM Gas and Structure Optimization: Adjusting gas fees for costly operations and revising data structures to minimize prover bottlenecks.

Considerations:

To make validity proofs widely viable, Ethereum developers must balance security and decentralization with prover speed, addressing tradeoffs in hardware requirements, possible backward compatibility breaks, and consistency with Ethereum’s decentralization ethos.

Validity Proofs for Consensus

Goal:

For a completely SNARK-verifiable Ethereum, the consensus (proof-of-stake) operations need validity proofs, covering aspects like deposits, withdrawals, and validator updates. This is essential for low-resource clients to verify both EVM and consensus validity, enhancing network security.

How It Works:

The beacon chain (Ethereum’s consensus layer) also relies on a state transition function. Verifying a block entails proving operations like:

• Elliptic Curve Additions (ECADD) for verifying BLS signatures.
• Pairings and SHA256 hashing for updating state and validator balances.

These operations present substantial challenges due to high computation costs and the requirement to handle massive amounts of validator data.

Challenges & Next Steps:

Achieving efficient consensus validity proofs requires innovations in:

1. Hashing: Switching from SHA256 to Poseidon could improve speed by up to 100 times, critical for processing large validator data sets quickly.
2. Efficient Validator Shuffling: Storing validators adjacent in the state to minimize hash requirements.
3. Signature Aggregation: Leveraging recursive proofs to aggregate signatures and ease final proofing loads.

Implementation Strategy:

The path to consensus validity proofs will likely be incremental, coinciding with developments like single-slot finality and validator signature aggregation. Ethereum may adopt more sweeping redesigns in its consensus layer to prioritize STARK-friendliness and optimize for decentralized verification.

Conclusion and Roadmap Implications

Successfully implementing these validity proofs would allow nearly any device to serve as a verifying Ethereum client, aligning with Ethereum’s decentralized goals. Key roadmap interactions include layer 2 rollups, EVM gas optimizations, and the potential for higher L1 gas limits, with the ultimate outcome of making Ethereum more secure, scalable, and universally accessible.

You can read the full article on Vitalik Buterin website.