Future of Ethereum: Navigating ‘The Verge’

In his latest instalment of the series “Possible futures of the Ethereum protocol,” Vitalik Buterin, the co-founder of Ethereum, delves into the intricate and ambitious goals of the protocol’s next phase, dubbed “The Verge.”

The Verge stage aims to enhance the efficiency, security, and decentralisation of the Ethereum network.

Statelessness and reduced storage needs

One of the key objectives of The Verge is to enable nodes to verify Ethereum blocks without the necessity of storing the entire Ethereum state, including account balances, contract code, and storage, on their hard drives. This “stateless” approach could significantly reduce the storage requirements for nodes, making the network more accessible and less resource-intensive.

As Buterin notes, “a node could verify an Ethereum block without having any of the Ethereum state (account balances, contract code, storage…) on its hard drive.”

Running nodes on phones and smartwatches

A pivotal aspect of The Verge is the potential to run Ethereum nodes on devices as small as smartphones and smartwatches.

Currently, operating an Ethereum node is technically possible on a standard laptop, but the high data requirements make it impractical for many users. The Verge aims to change this by making fully-verifying the chain “so computationally affordable that every mobile wallet, browser wallet, and even smart watch is doing it by default.”

Buterin envisions a future where the verification of Ethereum blocks is no longer constrained by high storage needs, allowing even small devices to participate in the network. This would significantly lower the barriers to running Ethereum nodes, making solo staking much more accessible and enhancing the decentralisation of the network.

Historical data management

Currently, clients must store vast amounts of historical data, often exceeding several terabytes, which is a substantial burden. To mitigate this, Buterin suggests implementing solutions like EIP-4444, which involves storing historical data in torrent or Portal networks.

Additionally, there is a need to replace high-cost proof structures such as transaction lists and receipt trees with more efficient alternatives, such as the changes proposed by Ethan Kissling to move transaction and receipt structures to SSZ (Simple Serialize).

Security and proof systems

The Verge stage also focuses on enhancing security through the use of advanced proof systems. Buterin emphasises the importance of conducting more security analyses on hash functions like Poseidon, Ajtai, and other “STARK-friendly” hash functions. There is also a need for developing highly efficient STARK protocols that are compatible with traditional hash functions, such as those based on Binius or GKR.

“Further development is needed for ‘conservative’ (or ‘traditional’) hash functions with highly efficient STARK protocols, for example, based on Binius or GKR ideas,” Buterin explains.

Adoption of Verkle trees and STARKs

Initially, The Verge focused on adopting Verkle trees, a data structure that facilitates more compact proofs and enables the stateless verification of Ethereum blocks. However, the scope has since broadened to include the use of advanced cryptographic proofs like SNARKs (Succinct Non-Interactive Arguments of Knowledge) and STARKs (Scalable Transparent Arguments of Knowledge).

These technologies allow one party to prove they hold certain information without disclosing the details, making it possible to verify complex transactions swiftly on-chain.

Hardware and decentralisation

While advancements in proof generation hardware using GPUs, FPGAs, and ASICs are promising, especially for layer 2 solutions, Buterin cautions against relying too heavily on specialised hardware for layer 1. The goal is to maintain high decentralisation, ensuring that proof generation remains within the capabilities of a large subset of users.

“People strongly want to keep the first layer highly decentralised, which means proof generation must be within the capability range of a fairly large subset of Ethereum users,” Buterin states.

Gas costs and complexity

The introduction of Execution-Environment-Forgetful (EOF) mechanisms could simplify the implementation of multi-dimensional gas costs, a complexity that arises from handling non-passing complete gas in child calls.

“If EOF is introduced simultaneously, multi-dimensional Gas will become easier,” Buterin notes. “This is because one of the key complexities of multi-dimensional Gas for execution is handling non-passing complete gas in child calls, which EOF makes illegal (and native account abstraction will provide a protocol alternative for the main use case of current part-Gas child calls)”.

Balancing centralisation and security

The Verge stage requires careful balancing between centralisation and security. Buterin highlights the need for community consensus on the “standard” hardware requirements for provers. The question remains whether proving should be feasible for large-scale entities or if it should be accessible to high-end consumer laptops.

“Do we want high-end consumer laptops to be able to prove Ethereum blocks in 4 seconds? Something in between?” Buterin queries.

Backwards compatibility and gas cost changes

Any significant changes, particularly those affecting gas costs, must be carefully weighed to avoid disproportionate cost increases for certain applications, which could force developers to rewrite and redeploy code.

“Other deficiencies in other areas can be compensated for by making more aggressive gas cost changes, but this is more likely to increase costs disproportionately for certain applications and force developers to rewrite and redeploy code to remain economically viable,” warns Buterin.

The Verge is part of a long-term Ethereum consensus redesign

The Verge stage is part of a broader long-term redesign of Ethereum’s proof-of-stake consensus, with a focus on optimising for SNARK friendliness. This includes changes to single-slot finality, Orbit, and signature schemes.

Buterin emphasises that achieving effective consensus will take several years, aligning with the timeline needed for thorough security analyses and the implementation of “radical” hash functions like Poseidon.

Source link