The state growth problem in a modular blockchain ecosystem

Certain aspects of blockchains take centre stage on the road to scalability, while others fade into the background. State size is one aspect that, if ignored, will become a major bottleneck in a blockchain’s performance and overall health.

What is the state growth problem?

The state is like a current snapshot of the blockchain that contains data about address balances, smart contract balances & storage, and consensus-related data. State is distinct from history, which is a record of all past transactions. All nodes that participate in block production and verification must store the entire state. As the size of the state grows, it can present many bottlenecks. The issue can be reduced to a few key points.

  • A user only pays a single cost that burdens nodes forever as part of the state
  • Growing state size increases resource requirements for all nodes

Activity that caused large amounts of state growth when gas fees where cheap still burdens all nodes today. State that is no longer utilized is essentially wasted resources that nodes could otherwise spend on other network tasks or simply leave as unallocated resources. Since nodes are required to store the entire state, a growing state size increases the resources that nodes must allocate towards its storage – increasing the barrier to entry for node operation. The bottleneck of state size is exemplified by Ethereum, whose state size sits at around 130GB. Ethereum’s state size impedes increasing its block size because doing so would otherwise increase the rate of state grows, therefore further increasing the storage requirements of nodes.

Since state requires constant reads and writes, it can only get stored on SSDs and RAM, unlike history, which can utilize inexpensive HDDs. Due to Ethereum’s large state its reads are also slower and more burdensome for nodes as they take longer to traverse through the large tree. Ultimately, an ever-growing state will place an increasing burden and bottleneck on blockchains that is unviable long-term. State growth must be limited in order to handle these issues.

How Celestia minimizes the state growth

Unlike most blockchains, Celestia has no smart contract environment. Since smart contracts are one of the largest causes of state growth, Celestia won’t encounter the same growth problems that other blockchains face. Because of its minimal design, Celestia’s state will primarily consist of:

  • Account balances
  • Consensus-related data (validator set information)

Since this will only cause minimal growth, Celestia block producers and full nodes won’t be hampered by the state size. Additionally, Celestia will have some notion of stateless clients from the start as light nodes will be able to verify blocks statelessly through data availability sampling.

Since execution layers sit on top of Celestia and provide an environment for users to interact with applications, the problem of state growth remains for each execution layer. While all blockchains initially start with a small state size, unless addressed, execution layers on Celestia can face similar state growth problems to that of Ethereum.

Potential solutions to manage state growth

State expiry:

The chain determines a period of time where state that hasn’t been accessed during that period gets removed from the state. For example, an address that wasn’t within a year gets removed from the state. However, permanently removing state would cause issues, particularly with UX if users return to find their addresses or smart contracts are no longer available. To mitigate these negative externalities, expired state would have a way to be revived such that it can become part of the state again. A protocol for individuals to retrieve expired state would also be beneficial as nodes aren’t required to store expired state, so there’s the possibility that expired state may become unretrievable – this applies to all state management schemes.

State rent:

Addresses and contracts are charged an ongoing fee to remain as part of the state. Rent is like a type of state expiry, where the expiry period is determined when a user fails to pay rent to maintain their part of the state. Rent tackles both the cost burden and state size issue as nodes are compensated for continuously storing the state while also reducing its size.

Weak statelessness:

Only require block producers to store the entire state to validate blocks. For full nodes to verify the chain statelessly, a witness must accompany each block that allows them to execute the state transition. Ideally stateless nodes would have lower hardware requirements; therefore the size of the witness should be kept reasonably low. To reduce the witness size, the chain may need to change its tree structure if the existing tree produces sub-par witness sizes (as seen with Ethereum’s plans to switch to Verkle trees from its current Merkle Patricia tree).


How is Celestia planning to handle history growth problem? History expiry?