You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

Understanding Ethereum's intrinsic architecture requires a deep dive into its state dynamics. In Ethereum's universe, the term 'state' encapsulates the status of all accounts, contracts, balances, nonces, and stored data. 

Merkle Tree

Central to Ethereum's operational design is the Merkle Patricia trie. A sophisticated version of the conventional Merkle tree, this trie is a repository for key-value pairs. Notably, the root hash of this trie provides a succinct representation of Ethereum's comprehensive state. Merkle Trees are generated through multiple rounds of hashing. The initial data begins at the bottom (of the image) and is combined with the other data and hashed together to create the parent hash on the rung above. These hashes are pooled (of the same size) and hashed again until a single (root) node remains. A Merkle tree's aim is to enable Merkle proofs, which prove a piece of data exists in the underlying dataset without requiring the broadcasting of the complete dataset.

Source

Merkle trees can store all key-value pairs for all Ethereum addresses. The keys relate to both public and smart contract addresses, and their respective values describe their current state.

However, as the Ethereum ecosystem evolves with additional accounts, contracts, and transactions, its state expands exponentially. Current statistics peg the state's expanse at over 1TB, with an annual accretion rate measuring in tens of gigabytes. This relentless state growth is, arguably, a crux in the discourse on decentralization.

The swelling magnitude of Ethereum's state has profound implications:

1. Synchronization Delays: New nodes face the Herculean task of synchronizing by processing historical state alterations. This elongated synchronization, sometimes spanning weeks, poses significant challenges for new node integrations, thereby jeopardizing decentralization.

2. Elevated Hardware Demands: A burgeoning state necessitates augmented storage, superior memory, and enhanced processing capacities. Simplistically, a fully operational Ethereum node today mandates an SSD boasting a 1-2TB storage potential. Such stipulations sideline a considerable segment of potential node operators due to accessibility constraints.

3. Bandwidth Consumption: Enhanced state dimensions mandate increased bandwidth, given that new block broadcasts need to be inclusive of the state alterations. This intensified bandwidth usage directly translates to cost escalations for node managers.

4. Verification Lags: The act of verifying blocks is inherently tethered to the state's size. With every transaction demanding multiple storage interactions, an expansive state curtails the number of feasible transactions per unit of time.

5. Incessant Storage Implications: Ethereum's architecture currently lacks any deletion mechanism for obsolete or redundant state data. This inherent design feature implies that every piece of state data, once integrated, assumes permanence, leading to inexorable state growth.

The Verge

The Verge is a portion of Ethereum's overall roadmap. It will work to enhance Ethereum's scalability and optimize storage utilizing Verkle Trees, a type of mathematical proof improving upon the currently used Merkle proofs. By decreasing the amount of data that validators must store on their computers in order to execute operations, node sizes will decrease, and more users will be able to serve as validators. This will boost network decentralization and security.

The Purge

The Purge aims to reduce blockchain "bloat" and make it easier for anyone to run a full node. By pruning past data, the Purge will reduce hardware needs and streamline storage for PoS validators. It will reduce the amount of historical data validators must retain, making it simpler to operate a node. Together with The Verge, we strive to reduce the quantity of historical data required for validators. The ultimate objective is to develop a "stateless Ethereum" in which validators can verify blocks without having to store the whole Ethereum chain.

Stateless Clients: A Deep Dive

At their core, stateless clients enable block verification without the need to access Ethereum's entire state. Instead, these clients leverage cryptographic tools known as "witnesses." At the heart of a stateless client's operation lies its unique approach to data storage: it retains merely block headers and state roots, excluding the full state data. These block headers encapsulate vital data, notably the state trie's root hash post-block processing.

When a new block awaits verification, the client acquires a "witness" alongside the block, essentially a set of Merkle proofs substantiating the validity of specific state updates from transactions. These Merkle proofs encapsulate critical state values, such as updated account balances or contract storage. The client then juxtaposes the witness against the last recognized state root, verifying the congruence of state transitions. Post-verification, the client adopts the new state root from the block header as a reference for the subsequent block.

The embrace of stateless clients carries transformative implications:

• Rapid Synchronization: Stateless clients bypass the need to revisit historical state modifications, streamlining the synchronization process.

• Conservative Storage Needs: The exclusive need for block headers curtails storage demands considerably.

• Bandwidth Efficiency: The transfer of solely block headers and witnesses curbs bandwidth consumption.

• Swift Verification: Witnesses, containing only pertinent state fragments, expedite the verification procedure.

• Light Client Compatibility: The stateless client's architecture aligns seamlessly with the light client paradigm.

State Expiry

Statelessness reduces the load on validators significantly, but it does not actually reduce state itself, which remains a massive burden on the Ethereum network. State Expiry schemes aim to address the issue of state bloat in blockchain technology. State expiry mitigates this by allowing for the removal of the long-term inactive state. It sets a default expiration date for all data and requires explicit renewal. This allows for inactive data to be revived, but it requires a proof that the data is currently part of the inactive state. State could then be later resuscitated by submitting a proof (and paying a fee) by navigating through a party with the full blockchain history. This remains true for both individuals and other protocols, i.e., L2 protocols.

Proof generation for state expiry requires access to the inactive state, which brings the concept of statelessness into play. The idea behind state expiry is that instead of holding the entire state, nodes can trustlessly operate the EVM using only proofs. This reduces the amount of state that nodes are required to hold and mitigates the issue of state bloat, which hinders decentralization.

Ethereum is attempting to achieve weak statelessness meaning state is no longer required for block validation. Instead, state will only be required by the block builders, which already necessitate substantial hardware requirements.

Strong vs. Weak Statelessness

The concept of strong statelessness posits that no entity, including block builders, needs to maintain the state of the network. While this idea holds appeal from a theoretical perspective, in practice, the complete elimination of state storage is not a viable solution. An alternative approach, known as weak statelessness, suggests that the majority of nodes do not need to store the state of the Ethereum Virtual Machine (EVM), as they can verify blocks through the use of proofs. However, the generation of these proofs still necessitates the retention of the EVM state by block builders. Currently, block producers and verifying nodes are one and the same, which renders weak statelessness ineffective.

Fortunately, there is a solution in development known as Proposer-Builder Separation (PBS). Under this system, block builders become a specialized entity that provides pre-built blocks to proposing nodes or validators. With PBS, we can implement weak statelessness without compromising decentralization, as the requirement for state storage is constrained to a potentially centralized group of block builders. The combination of weak statelessness and PBS allows for the benefits of statelessness to be realized without sacrificing the principles of protocol-wide decentralization. For more on PBS, check out this article.