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.
The Ever-Growing Ethereum Mainnet
Demand for Ethereum transactions and smart contracts has skyrocketed over the last ~2 years. In 2021 alone, the number of DeFi users increased from ~150k to ~2M but at the same time, gas fees grew 16 times faster. As of 2023, the Ethereum mainnet routinely facilitates the transfer of tens of billions of dollars of value daily, with over $70B currently deposited in DeFi smart contracts. Right now, an Ethereum full node’s size is growing over 50% per year.

Every new transaction or state entry grows the cumulative state and burden on nodes. Ethereum researcher Sandra Johnson of ConsenSys:“The Ethereum world state contains all Ethereum accounts, their balances, deployed smart contracts and associated storage. New accounts are continually being added and new smart contracts are being deployed. Therefore, by design, the state size of Ethereum keeps growing ad infinitum. The implication of this unbounded state growth is that it takes longer and uses more space to spin up a new full node.”
A quick summary:
- History refers to all events that have occurred on the blockchain. It does not require quick access and can be stored on a hard drive. The 1 of N honesty assumption holds true in the long term.
- State refers to the current snapshot of account balances, smart contracts, etc. Full nodes currently need to have this information on hand to validate transactions. It is too large for RAM and a hard drive is too slow so it goes in SSD. High-throughput blockchains can cause the state to grow beyond what an average user can store on their device, which can lead to a loss of decentralization.
- The Ethereum network experiences a variety of transaction types such as transferring ETH, trading ETH for other assets, and minting NFTs. In 2021, the average daily transactions were approximately 1.3 million, which represented a 35% increase year over year.
- The concept of "users" in Ethereum's data structure is not clearly defined, but daily active addresses can be used as a proxy for engagement. This measure counts the number of unique addresses that were involved in at least one transaction on a given day. In 2021, there were an estimated 600,000 active addresses on the network each day, representing a 40% increase year over year.
There are currently close to ~220 million unique Ethereum addresses but if Ethereum is ever to realize its goal of becoming a truly global, decentralized settlement layer, it must find a way to efficiently store 10,000x the data. Storing the data more efficiently enables lower compute requirements for nodes. Thus, the more people that can afford to run nodes, the more people that can audit the system, thereby reducing the need to trust others and protect the integrity of the chain. Individuals that run their own nodes enjoy full self-sovereignty by verifying all transactions for themselves while also getting increased privacy benefits by not relying on third parties.

The Ethereum network wants more users! It just can’t keep storing its data in the same old way. Instead of allowing the state of the EVM to grow into infinity, new technical ideas have been proposed to remove inactive parts of the state.
Read the whole article here.
Statelessness
“stateless” does not really mean “no state”! What it actually means is that you made state someone else’s problem…” Ben Edgington, What’s New in Eth2
The term "stateless" in reference to an Ethereum client is somewhat misleading, as it implies the complete absence of a world state. In reality, the responsibility of provisioning and storing the Ethereum world state is transferred to another participant in the network. A stateless Ethereum client should have the capability to selectively choose which aspects of the state it wishes to keep up to date and maintain while also being able to disregard state that is not relevant to it. This approach allows for greater flexibility and scalability in the network, as well as a more efficient use of resources.
The ultimate objective is to establish a "stateless Ethereum," where validation can occur without the necessity of maintaining the entire Ethereum chain. Instead, validators will rely on data availability proofs and pre-constructed blocks to sustain the set of validators, unburdened by computational requirements, promoting decentralization and accessibility among validators. The block producers constructing the block will utilize a witness, which is a proof that consists of the relevant data necessary to execute the transactions contained within that block. Thus, clients will use this witness to validate the resulting state root from executing a block, requiring only specific portions of the affected state for execution instead of the entire state.
The main challenges in this design are the size and availability of the witness. The elimination of the need to maintain the state allows for significant savings in node resources, but this advantage is offset by the increased demand for data availability proofs and pre-constructed blocks to flow through the system. As the level of statelessness increases, the bandwidth requirements also increase proportionally. Thus, finding the right balance between statelessness and the need for proofs is crucial to optimize the overall performance of the network.
The first issue can be resolved by transitioning the state data structure in Ethereum from Merkle Patricia Tries to Verkle Trees (discussed below), a more efficient data structure for the polynomial commitments used in Ethereum post-merge. The second issue can be solved with PBS (discussed further below).
What are Verkle Trees?
Verkle trees are a more advanced data structure for state commitments in blockchain technology. These trees offer increased efficiency by reducing the size of proofs and lowering verification costs on-chain. Essentially, Merkle and Verkle trees are similar in structure but have distinct features that set them apart as data structures for state commitments.
In the Tendermint/Cosmos SDK structure, Merkle trees are utilized to share transaction data between nodes, specifically between full nodes and light nodes for the purpose of block verification. In this context, a light node receives a commitment from a full node and acquires a witness, allowing it to construct the root in the block header. In Ethereum, Merkle trees are utilized in the Execution layer, in which block headers consist of three roots of Merkle trees: the state root, the transaction root, and the receipt root. Additionally, Ethereum has a global state tree that updates over time, which increases in size as time goes on. This is one of the reasons why Ethereum is exploring the use of Verkle trees in future releases, as they can minimize the amount of state that full nodes are required to hold, which is referred to as statelessness (weak).
The primary differentiator between Verkle and Merkle trees is in how they organize their witnesses and as a result, their sizes. In Verkle trees, instead of providing all the nodes that share a parent, you only need to provide the path to the root. This means that in a wide tree, the path will be much smaller compared to all the sister nodes that would have to be provided in a Merkle tree commitment. Another added commitment that is needed in Verkle trees is vector commitments, which replace the functionality of the sister nodes in Merkle trees. This means that they provide verification that a certain child node is the correct node in the tree while only providing the path itself. This eliminates the need for sister nodes in proof construction, making Verkle trees more efficient than Merkle trees.
In summary, Verkle trees are a more efficient data structure for state commitments in blockchain technology, offering reduced proof sizes and lower verification costs on-chain. This is particularly relevant for Ethereum, where gas costs are currently high, and for scalability solutions in the works for Ethereum as a whole. Additionally, the use of Verkle trees mitigates the issue of state bloat, which hinders decentralization, by reducing the amount of state that full nodes are required to hold.

Simple Verkle Tree Implementation. Source: Coffee and Rain
The concept of state expiry borrows heavily from the concept of statelessness. In order to reactivate inactive portions of the state, nodes must present evidence. State expiry involves beginning a new tree on a regular basis (approximately once per year), enabling Verkle trees to be phased in over time.
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 there is no need for any entity, including block builders, 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.

