Case Study 2: Ethereum's State Growth — 1 Trillion State Objects and Counting

Background

When Ethereum launched on July 30, 2015, its global state was pristine: a handful of accounts created in the genesis block, with a total state size measured in kilobytes. A modest laptop could store the entire thing in RAM. Ten years later, the picture is radically different. Ethereum's state has ballooned to over 1.4 billion distinct state objects — account entries plus contract storage slots — occupying hundreds of gigabytes on disk. The state trie, the data structure that organizes all of this data, has become one of the largest authenticated data structures ever maintained by a decentralized network.

This case study examines the practical reality of Ethereum's state growth: what is growing, why it is growing, who is affected, and what the community is doing about it. The stakes are high. If state growth continues unchecked, running a full Ethereum node will eventually require hardware that only well-funded organizations can afford — and a blockchain where only corporations can verify the state is not meaningfully decentralized.

The Anatomy of Ethereum's State

To understand why state growth is a problem, we must first understand what the "state" actually contains.

Account State

Every Ethereum account — both externally owned accounts (EOAs) and contract accounts — occupies space in the state trie. Each account entry stores four fields:

• Nonce: 8 bytes (uint64, though most accounts use far fewer)
• Balance: 32 bytes (uint256, denominated in wei)
• Storage root: 32 bytes (the root hash of the account's storage trie; empty for EOAs)
• Code hash: 32 bytes (the Keccak-256 hash of the account's code; hash of empty for EOAs)

Including the 20-byte address as the key and the trie overhead (branch nodes, extension nodes, leaf nodes), each account occupies roughly 100-150 bytes in the state trie. With approximately 270 million addresses that have appeared on the Ethereum network, account entries alone consume tens of gigabytes.

But account entries are the smaller part of the problem.

Contract Storage

Each contract account can have an arbitrarily large key-value store — its storage trie. The keys and values are both 256 bits (32 bytes), and the storage trie can contain any number of entries. Some contracts are modest: a simple token contract might store a few thousand balances. Others are enormous: Uniswap V3's factory contract alone has millions of storage entries tracking liquidity positions, fee tiers, pool addresses, and cumulative tick data.

As of 2025, the aggregate storage across all contract accounts accounts for the vast majority of Ethereum's state size. A relatively small number of contracts — major DeFi protocols, popular token contracts, NFT collections, and bridge contracts — account for a disproportionate share of total storage.

The Numbers

The following figures, drawn from Ethereum node operators and researchers who have analyzed the state trie, paint a stark picture:

The difference between "pruned" and "archive" is critical. A pruned full node stores only the current state — the latest snapshot of every account and every storage slot. An archive node stores every historical state — the state as it existed at every block in Ethereum's history. Archive nodes are necessary for some use cases (historical queries, block explorers, data analysis) but require specialized hardware.

Why State Only Grows

In most databases, unused data can be cleaned up. Old records can be archived. Expired entries can be deleted. Ethereum's state does not work this way — at least not automatically.

The Persistence Problem

When a smart contract writes a value to storage, that value persists until it is explicitly overwritten or deleted by the contract's own code. There is no garbage collection, no automatic expiry, no time-to-live. A storage slot written in 2016 and never accessed since still occupies space in the state trie, and every full node must store it.

This design was intentional. Ethereum's state is a commitment — the state root in each block header commits to every byte of the current state. If state could disappear without an on-chain transaction, the commitment property would break. A node could not verify the state root without having the complete state.

The Incentive Misalignment

The gas cost structure creates a perverse incentive. Writing to a new storage slot costs 20,000 gas. Clearing a storage slot (setting it to zero) provides a gas refund of 4,800 gas (after EIP-3529). This means the incentive to clean up state is roughly 24% of the incentive to create it. And even this understates the problem: the gas refund only benefits the account that clears the storage. If a user deploys a contract that creates millions of storage entries and then abandons the contract, no one has an economic incentive to clean up the mess.

Consider a concrete example. In 2016, a series of "state-bloat attacks" deliberately created millions of empty accounts on the Ethereum network by sending 0-value transactions to new addresses. Each new account cost roughly 25,000 gas (about $0.02 at the time) to create but would persist in the state trie permanently. The attacker spent a few thousand dollars and bloated the state by several gigabytes — a cost that every node operator bears indefinitely.

The Spurious Dragon hard fork (November 2016) cleaned up some of this damage by removing approximately 20 million empty accounts. But this was a one-time protocol-level intervention, not a sustainable solution.

The DeFi Amplifier

DeFi protocols have dramatically accelerated state growth since 2020. Each new liquidity pool on Uniswap creates a new contract with its own storage. Each user's liquidity position is a storage entry. Each token approval is a storage entry. Each yield farming vault, each lending position, each NFT mint — all of it writes to the state trie.

The composability that makes DeFi powerful also makes state growth additive. When a user interacts with a yield aggregator that interacts with a lending protocol that interacts with a DEX, each layer in the stack may create or modify storage entries. A single user transaction can touch dozens of contracts and modify hundreds of storage slots.

Who Is Affected: The Node Operator's Burden

Hardware Requirements

Running an Ethereum full node in 2025 requires:

• CPU: Modern multi-core processor (8+ cores recommended). State trie operations are CPU-intensive, particularly during sync.
• RAM: 32 GB minimum, 64 GB recommended. The state trie should ideally fit in RAM for acceptable performance. Clients that cannot cache the state in memory see dramatically slower block processing.
• Storage: 2 TB+ NVMe SSD. Mechanical hard drives are functionally unusable — the random read patterns of trie traversal produce unacceptable latency. The entire state must be on SSD.
• Bandwidth: 25 Mbps+ sustained. State sync requires downloading and verifying hundreds of gigabytes, and ongoing operation requires propagating blocks and transactions.

This hardware costs approximately $2,000-4,000 for a dedicated machine. While not prohibitive for enthusiasts or businesses, it is far from the "Raspberry Pi node" ideal that some in the community aspire to.

Sync Times

A new node joining the network must obtain the current state. There are several sync strategies:

• Full sync: Download and re-execute every block from genesis. This verifies the entire history but takes weeks on modern hardware and is impractical for most users.
• Snap sync (Geth): Download the current state trie directly from peers, then verify it against the latest block's state root. This takes 6-12 hours with good hardware and bandwidth.
• Checkpoint sync (consensus layer): Start from a recent finalized checkpoint rather than genesis. This is safe because finality is guaranteed by the PoS consensus mechanism. Combined with snap sync for the execution layer, this gets a node operational in hours.

Even with checkpoint and snap sync, the initial download is substantial: 200+ GB of state data plus 500+ GB of historical blocks. And if the node operator's internet connection is interrupted during sync, the process may need to restart from a recent checkpoint.

The Centralization Risk

As hardware requirements increase, the demographics of node operators shift. Individual hobbyists with modest hardware are squeezed out. Cloud-hosted nodes (AWS, Google Cloud, Hetzner) become a larger fraction of the network. This creates several risks:

• Cloud provider concentration: If a significant fraction of nodes runs on a single cloud provider, that provider has de facto power over the network. A terms-of-service change, a government order, or an infrastructure failure could take down many nodes simultaneously.
• Geographic concentration: Cloud infrastructure is concentrated in a few regions (US East, US West, Western Europe). Nodes in these regions have low latency to each other but higher latency to the rest of the world, potentially creating "fast" and "slow" participation tiers.
• Economic concentration: As running a node becomes more expensive, only entities with economic incentives (validators earning staking rewards, businesses needing reliable access) continue to operate nodes. The "altruistic node operator" — someone who runs a node purely to support the network — becomes rarer.

Proposed Solutions

Verkle Trees

The most impactful near-term solution is the transition from Merkle Patricia Tries to Verkle Trees. Proposed by John Kuszmaul in 2018 and championed by Vitalik Buterin and Dankrad Feist for Ethereum, Verkle trees use polynomial or inner product commitments instead of hash-based commitments.

The key advantage is proof size. In an MPT, a proof that a particular account has a particular state requires providing all the sibling hashes along the path from the leaf to the root — typically several kilobytes. In a Verkle tree, the proof is a single vector commitment that is approximately 100-200 bytes, regardless of tree depth.

Why does proof size matter? Because small proofs enable stateless clients. A stateless client does not store the state at all. Instead, each block comes with "witnesses" — proofs that the state accessed during block execution has the values claimed. The stateless client verifies these witnesses against the state root (which is in the block header) and trusts that the state is correct.

If Verkle trees make stateless clients practical, the hardware requirements for participating in the network drop dramatically. A stateless client needs only enough storage for the block headers and the current block's witnesses — a few megabytes instead of hundreds of gigabytes.

The Verkle tree transition is actively being developed and is part of Ethereum's "Verge" roadmap milestone. It is one of the most technically complex upgrades since the Merge because it requires migrating the entire state trie from one data structure to another on a live network.

State Expiry

State expiry would introduce a "freshness" requirement for state objects. Accounts and storage slots that have not been accessed for a defined period (proposals range from one to three years) would be moved to an "expired" state. They would no longer be part of the active state trie and would not need to be stored by full nodes.

If a user needs to access expired state — for example, to spend ETH from an account they have not touched in three years — they would need to provide a Merkle proof (witness) of the expired state's existence with their transaction. This proof would be generated from historical state data maintained by archival services.

State expiry is conceptually simple but practically complex:

• User experience: Users who leave their wallets untouched for years would need to obtain witnesses before they could transact. This requires infrastructure for storing and serving historical state.
• Smart contract compatibility: Existing contracts were not designed with state expiry in mind. A contract that reads a storage slot written three years ago and never refreshed would fail if that slot has expired.
• The "two-tree" problem: During the transition period, some state would be in the new, expiry-aware trie and some in the old trie. Managing this dual state adds complexity.

Despite these challenges, some form of state expiry is widely considered inevitable. The question is when and how, not whether.

EIP-4444: History Expiry

While not directly about state, EIP-4444 would allow nodes to stop storing and serving historical block data older than one year. This would not affect state (which is always current) but would significantly reduce the total storage required for a full node — from potentially tens of terabytes to a more manageable amount.

Historical data would be preserved by specialized archival nodes, data providers (like Etherscan and The Graph), and distributed storage networks (like IPFS and Portal Network). EIP-4444 reflects a philosophical shift: not every node needs to store all of history; only enough nodes need to store history that it remains accessible.

Client-Level Optimizations

While protocol-level solutions are under development, client teams have made substantial progress in optimizing state storage at the software level:

• Erigon (formerly Turbo-Geth) uses a flat key-value database (MDBX) instead of storing the trie structure on disk. The trie is computed on the fly during block execution. This reduces storage requirements by roughly 60% compared to Geth's default storage format.
• Geth's path-based storage (PBSS) introduced in 2023 reorganized how Geth stores the state trie on disk, reducing database size and improving sync performance.
• Reth (a new Rust-based Ethereum client) was designed from the ground up with state efficiency in mind, using modern database techniques to minimize storage overhead.

These optimizations buy time but do not solve the fundamental problem — state grows monotonically, and optimizations have limits.

A Day in the Life: Running a Full Node in 2025

To make the state growth problem concrete, consider the experience of running a full Ethereum node in 2025:

Setup: You purchase a dedicated machine: AMD Ryzen 7, 64 GB RAM, 4 TB NVMe SSD, gigabit Ethernet. Total cost: approximately $3,000.

Initial sync: You install Geth (execution layer) and Lighthouse (consensus layer). Checkpoint sync for the consensus layer takes about 15 minutes. Snap sync for the execution layer begins downloading the state trie — 180+ GB over several hours. The total sync time is approximately 8-12 hours with a good internet connection.

Steady state: Once synced, your node processes new blocks every 12 seconds. Each block updates the state trie — modifying account balances, writing contract storage, creating new accounts. Your SSD writes increase. Your RAM usage stays around 40 GB as Geth caches the "hot" parts of the state trie.

Maintenance: Every few months, you need to prune the state database to reclaim space from accumulated trie updates. Pruning requires stopping the node for several hours (offline pruning) or accepting degraded performance (online pruning). Geth's newer PBSS mode reduces the need for pruning but does not eliminate it.

Growth: Each quarter, you notice the database has grown by 15-30 GB. At this rate, your 4 TB SSD will be sufficient for about three more years before you need to upgrade.

The question: Is this sustainable? For you, a technically skilled enthusiast with $3,000 to invest, probably yes. For the millions of users who would need to run nodes to make Ethereum truly decentralized? Almost certainly no.

The Philosophical Dimension

The state growth problem is not merely technical. It touches on fundamental questions about what a blockchain is and whom it serves.

The full node maximalist position holds that running a full node should be accessible to any individual with consumer hardware. Only then can users independently verify the blockchain's state without trusting anyone. State growth that prices out individual operators is an existential threat to this vision.

The pragmatic position holds that not every user needs to run a full node. Light clients, stateless clients, and trusted data providers can serve most users' verification needs. As long as a sufficient number of full nodes exist (thousands, not millions), the network remains meaningfully decentralized.

The economic position notes that running a full node has always been a cost borne by altruistic or economically motivated operators. Validators earn staking rewards. Businesses need reliable node access. If these incentives keep enough nodes online, consumer hardware accessibility is a nice-to-have, not a requirement.

These positions are not fully reconcilable. The Ethereum community continues to debate the right balance between accessibility and functionality, and the state growth problem is one of the sharpest points of tension.

Current Status and Outlook

As of 2025, the Ethereum community is actively working on multiple fronts:

• Verkle trees are in active development, with test implementations running on devnets. The transition is expected to be one of the most significant upgrades since the Merge.
• Portal Network, a decentralized protocol for serving historical data, is being developed as infrastructure for EIP-4444.
• Client optimizations continue to improve the state of the art. Reth, Erigon, and Geth compete on efficiency, driving improvements across the ecosystem.
• State expiry research continues, with multiple proposals under discussion. No concrete timeline has been set.

The state growth problem is solvable. The technical solutions are understood; the challenge is implementation, coordination, and managing the transition on a live network — challenges that the Ethereum community demonstrated it could handle with the Merge.

Discussion Questions

1. If you were designing Ethereum from scratch today, would you include any mechanism to prevent unbounded state growth? What would it look like, and what tradeoffs would it introduce?

2. State rent (charging accounts for the state they occupy) was proposed and rejected. What were the likely user experience concerns? Can you design a version of state rent that would be acceptable to users?

3. The "full node maximalist" position holds that consumer hardware must always be sufficient to run a full node. Is this realistic as blockchain usage grows? What is the minimum number of full nodes needed for a network to be "decentralized enough"?

4. Cloud providers (AWS, Hetzner) host a significant fraction of Ethereum nodes. What risks does this concentration create? What could be done to mitigate them?

5. If Verkle trees succeed in enabling stateless clients, what are the implications for the relationship between storage and verification? Could a network function securely if no single entity stores the complete state?