Discussion of blockchain size usually focuses on the history of transactions, but the harder problem is the state. History can be archived; state has to stay accessible.
State and history are different objects
History is the ordered record of everything that happened. State is the result: current balances, contract storage slots, account nonces, the data needed to validate the next transaction.
A node can prune old history and still function, because it only needs the state that history produced. It cannot prune the state itself and keep validating.
So the working set that must sit on fast storage grows with every new account and every contract that writes a value it never deletes.
Storage is written once and read forever
Writing a value to contract storage costs a fee once. Every node then carries that value indefinitely, across every future block, at no further charge to whoever wrote it.
The mismatch between a one-off payment and an open-ended obligation is the root of the problem. Nothing in the fee makes the writer responsible for the ongoing cost.
Abandoned tokens, dead contracts and dust accounts therefore accumulate. They contribute nothing and are never cleaned up because no one is paying to keep them or to remove them.
Growth raises the cost of running a node
As state grows, lookups become slower and the hardware needed to keep up rises. Random access to a large database is the bottleneck, not raw processing.
Higher requirements mean fewer independent operators, and fewer operators means more reliance on hosted providers. Decentralisation erodes quietly through hardware cost rather than through any rule change.
This is why proposals to raise throughput are scrutinised for their effect on state growth as much as for bandwidth. More transactions per second means faster accumulation.
Rent and expiry have been proposed repeatedly
The obvious remedy is to charge for storage over time rather than once, so that unused data eventually expires unless someone pays to keep it.
The difficulty is that expiry breaks assumptions applications already rely on. A contract holding balances cannot simply have them vanish because no one topped up a rent account.
Variants keep the data recoverable by requiring a proof to revive expired entries, which shifts the burden from every node to whoever still cares about the entry.
Statelessness moves the data to the transaction
A different approach has each transaction carry a cryptographic proof of the state it touches, so validators verify against a small commitment rather than a full database.
Nodes then need very little storage, though someone still has to maintain the full state and generate proofs. The role divides rather than disappearing.
The trade is bandwidth and proof generation in exchange for storage, which suits an environment where disk access is the scarcer resource.