Paradigm: The Challenges and Solutions of Ethereum State Growth
TechFlow Selected TechFlow Selected
Paradigm: The Challenges and Solutions of Ethereum State Growth
Ethereum can sustain its current level of state growth for many years.
Navigating Web3 tides with focused insightsAuthors: Storm Slivkoff, Georgios Konstantopoulos
Translation: Luffy, Foresight News
Ethereum's state growth and its relationship with the gas limit are widely misunderstood. It is commonly believed that state growth is Ethereum’s primary scaling bottleneck. However, discussions around state growth are often hindered by imprecise terminology and a lack of detailed quantitative evidence.
A data-driven approach can bring clarity to the issue of state growth. In this article, we leverage high-resolution datasets to understand the magnitude and shape of state growth. Along the way, we reach a surprising conclusion: modern consumer hardware can sustain current rates of state growth for at least a decade. Furthermore, considering ongoing improvements in both software and hardware, this runway could be extended indefinitely.
We believe Ethereum has a clear roadmap: 1) completely eliminate state growth as a scaling bottleneck; and 2) raise the gas limit to levels capable of supporting a globally scaled decentralized financial system. The goal of this article series is to develop a scientific methodology for understanding and shaping this scaling roadmap.
This article is Part 1 of a series on Ethereum scaling, focusing on state growth. Part 2 will cover historical growth, Part 3 on state access, and Part 4 on the gas limit.
What Is State Growth?
The term "state growth" is often used loosely to describe any Ethereum scaling bottleneck where data size exceeds node hardware capacity. However, state growth should not be thought of in such monolithic terms. Ethereum data comes in multiple forms, each interacting uniquely with underlying node hardware components. Therefore, using precise terminology to distinguish between different scaling bottlenecks is critical.
State refers to the set of data required to build and validate new Ethereum blocks. State consists of contract bytecode, contract storage, account balances, and nonces. History is the dataset a node needs to sync from genesis to the latest block, composed of blocks and transactions. State and history are non-overlapping datasets. From these definitions, at least three distinct phenomena place significant pressure on node hardware:
-
State growth: accumulation of new accounts, new contract bytecode, and new contract storage.
-
Historical growth: accumulation of new blocks and new transactions.
-
State access: the set of read/write operations used to build and validate blocks.
Each bottleneck relates uniquely to node hardware constraints. The four most relevant hardware limitations are:
-
Network I/O: the upload and download speed a node must maintain to achieve stable consensus with peers.
-
Storage size: the amount of data a node must store permanently to build, validate, and distribute blocks.
-
Memory size: the amount of data a node must cache in memory to stay synchronized with the head of the blockchain.
-
Storage I/O: the number of read/write operations per second a node must perform to stay in sync with the chain head.
The relationships between these bottlenecks and hardware constraints are illustrated in Figure 1.
Figure 1: Ethereum Scaling Bottlenecks
Starting from the top, every time Ethereum executes a transaction, all resources consumed by that transaction are priced in gas. Thus, Ethereum’s gas limit is a unidimensional metric that rate-limits all forms of on-chain activity. Downstream from the gas limit are block size and per-block operations. The more bytes per block, the faster history grows. The more I/O operations per block, the higher the state access rate—and typically, the greater the state growth rate as well.
Therefore, scaling bottlenecks relate to node hardware constraints as follows:
-
To support substantial state growth, nodes must have sufficient storage and memory capacity. If state becomes too large, it may either fail to fit on disk or prevent frequently accessed portions from fitting in memory, leading to performance degradation.
-
To support substantial historical growth, nodes must have sufficient network bandwidth to share large volumes of block data and sufficient storage capacity to retain that data.
-
To support substantial state access, nodes require ample memory to cache hot state and high storage I/O to support frequent read/write operations.
In particular, for state growth, the main challenge is ensuring that the rate of state expansion does not outpace continuous improvements in consumer hardware. Node memory and storage are finite resources, so they will eventually hit a ceiling unless state stops growing or hardware is regularly upgraded. Fortunately, memory and storage hardware have steadily improved over time. Nevertheless, accurate predictions about future improvements remain uncertain, and their rapid advancement should not be assumed to continue indefinitely.
Note that the upcoming EIP-4844 introduces data blobs that will alter some of these scaling dynamics. After EIP-4844, accumulated historical data on disk is expected to be significantly reduced, while network I/O during blob transmission may increase substantially.
In this article, we focus primarily on state size and state growth rate, rather than memory size and state access patterns. We will explore other topics in future work.
Composition of Ethereum State
The next step in understanding state growth is to examine the total size of state and the contribution of each component. Currently, Ethereum state totals approximately 245.5 GB. This figure was measured using a reth node, but numbers across different client implementations are roughly comparable, as shown in this spreadsheet. Accounts, contract bytecode, and contract storage occupy 14.1%, 4.3%, and 81.7% of state respectively.
Figure 2 shows how much state space is occupied by various smart contract protocols. In the chart below, the size of each contract category represents the number of bytes used by its storage slots and bytecode.
Figure 2: Ethereum State Distribution
The figures in Figure 2 represent the total number of bytes that node clients must store on disk, including data used for indexing and other storage overheads. The average storage size per account and per storage slot is 133.6 bytes and 191.3 bytes, respectively.
Key takeaways from Figure 2 include:
-
Tokens dominate state usage. ERC-20 and ERC-721 tokens are the largest contributors to Ethereum state, accounting for 27.2% and 21.6% respectively. Tokens consume so much state because each user balance for each token must be stored individually in a 32-byte storage slot. Consequently, half of Ethereum’s state scales proportionally with the total number of users and the total number of tokens held per user.
-
At least 7.4% of Ethereum state is dormant. Some of the largest contracts in Ethereum state are no longer active. These protocols were deployed when block and state space were far cheaper than today, including most protocols in gaming, gambling, scam categories, and many inactive DEXs such as IDEX, EtherDelta, and Oasis. Together, these protocols constitute at least 7.4% of Ethereum state. The true level of dormant state is even higher, as it also includes long-tail projects across ERC-20, ERC-721, and other categories.
-
L2 bridges occupy less than 2% of Ethereum state. By leveraging techniques like compression, ZK proofs, and improved encoding, L2 transactions use state more efficiently than mainnet. Despite occupying only 2% of mainnet state, L2s process over five times more transactions per second than the mainnet.
How Fast Is Ethereum State Growing?
The most important aspect of state growth is how the growth rate has changed over time. This rate reveals the severity of the state problem and its trajectory.
Figure 3 shows Ethereum’s state growth rate since its inception in 2015. These rates are calculated by summing contract bytecode and contract storage across each contract category.
Figure 3: Ethereum State Growth Over Time
Key insights from Figure 3 include:
-
Currently, state grows by approximately 2.62 GB per month—down from a peak of 5.99 GB/month. Extrapolating from these figures, total state size in five years would range between 396 GB and 606 GB. While one might describe the current growth rate as 12.8% annually, the absolute growth rate has been declining even as total state continues to grow, suggesting simple exponential models may not be appropriate.
-
Recent declines in state growth are primarily due to reduced NFT activity. Although one might expect some correlation between different types of network activity, there is surprisingly little correlation among individual state contributors. For example, although overall state growth has declined in recent years, ERC-20 state growth has actually increased year-over-year since 2020.
-
State growth is at its lowest level since 2021. This decline is somewhat surprising but makes sense given that state scales largely with new token balances. If state growth rates continue to fall, one might conclude Ethereum could support a higher gas limit. That may be true, but it’s important to remember: 1) under the current gas pricing model, nothing prevents another surge in growth rates; and 2) state is not the only bottleneck downstream of the gas limit.
What Is an Acceptable Level of State Growth?
We now know Ethereum state in terms of 1) size, 2) composition, and 3) growth rate. How do we determine an acceptable range for state growth? This question is complex, as it depends on both unpredictable market forces and philosophical choices about what trade-offs Ethereum should make.
Let’s start with the simplest model: assuming no future hardware improvements, how long can current state growth levels be sustained on typical consumer hardware? As shown in Figure 3, annual state growth in recent years has ranged between 31 GB/year and 72 GB/year. Today, common consumer hardware offers up to ~4TB of storage and ~64GB of RAM. Based on this, we can create a simple predictive model for storage and memory requirements:
-
Storage: Nodes currently need to store roughly 1TB of state data. In practice, this means many nodes use disks of at least 2TB. For simplicity, let’s ignore future historical growth, as if we were in a post-EIP-4444 world. We can then calculate runtime as (remaining storage capacity) / (state growth rate), as shown in this table. Thus, node storage hardware can support current state growth rates for over a decade without exhausting 2TB of space. At current growth levels, 4TB would suffice for nearly half a century.
-
Memory: Ethereum-on-arm users report a minimum viable memory of ~16GB for running an Ethereum node. Assuming memory demand scales linearly with state size, annual state growth of 30–72 GB translates to additional memory needs of 2–4.7 GB per year. Therefore, under current gas rates, 32GB RAM should last 3–8 years, and 64GB RAM should last 10–23 years.
This is a simplified model with many assumptions. Possible extensions include 1) historical growth, 2) nonlinear memory scaling, 3) decreasing hardware costs, 4) increasing gas limits, 5) opcode gas repricing, and 6) future architectural improvements to Ethereum. Each of these factors can interact nonlinearly and evolve over time. We will explore these model extensions in future work.
It must be emphasized that long-term sustainability is desirable. Even if modern hardware can support many years of operation, shortening the expected runtime should not be taken lightly. Any plan that accelerates state growth should include a substantial buffer to accommodate unpredictable changes in hardware or software environments.
How Can We Solve State Growth?
Numerous proposals have been put forward to address state growth. Three architectural improvements stand out: Rollups, Verkle Trees, and State Expiry. Together, these form a comprehensive roadmap for addressing short-, medium-, and long-term state growth challenges.
Short-term: Rollups do not solve state growth directly, but they alleviate network load. As seen in Figures 2 and 3, Rollups use state far more efficiently than the mainnet. Moving activity to L2 requires storing some state on mainnet—for user withdrawals—but the state footprint of L2 transactions is much smaller than that of mainnet transactions. Thus, Rollups enable more sustainable growth in total ecosystem activity. With the upcoming EIP-4844, Rollup adoption is expected to accelerate, as blobs will make Rollups significantly cheaper.
Medium-term: Verkle Trees address state growth for validator nodes, but not for nodes that must construct new transactions. Verkle Trees are a new data structure for Ethereum state that enable more efficient light clients and “stateless” nodes. These nodes can validate new blocks without knowing existing state values, eliminating the state growth burden for validators. Constructing new transactions still requires state access, but this is more sustainable because transaction construction is a task that can easily be distributed across many machines. In scope, Verkle Trees represent a major engineering effort likely to take years to implement.
Long-term: State expiry addresses state growth for all nodes, but requires additional infrastructure. State expiry allows nodes to discard inactive portions of state, as illustrated in Figure 2. Note that the term “state hibernation” may be more appropriate, as most existing proposals allow “expired” state to be restored via proofs. Concerns about losing expired state over time are mitigated by the fact that as long as history (blocks and transaction data) is preserved, state can be reconstructed. Thus, whatever solution is developed for EIP-4444’s historical data retention will also resolve state preservation. However, if Verkle Trees succeed in achieving their goals, state expiry may become unnecessary.
There are other solutions to state growth, including state rent and sharding, but historically these have raised concerns regarding user experience or soundness. For ultimate long-term solutions, combining these approaches may be necessary.
Conclusion
While state growth remains a key challenge in scaling Ethereum, we believe it is a solvable problem. Our analysis suggests Ethereum can sustain current rates of state growth for many years, providing ample breathing room for architectural upgrades.
We believe empirical methods are crucial for designing Ethereum’s gas limit and guiding Ethereum toward its ultimate scaling solution. This article is just one step toward that goal. There are other forms of data beyond state that also burden Ethereum nodes and constrain the gas limit. We hope to explore these other bottlenecks in future work.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Paradigm
