~/notes / node operation
State Growth: The Problem Nobody Has Solved
Every account and contract adds permanently to what nodes must store. Storage grows, node operators leave, and validation concentrates.
The scalability discussion is usually about throughput. The harder problem is storage, and it gets far less attention because it produces no dramatic moments.
What state is
The current condition of the network: every account balance, every contract’s storage, every token holding. Distinct from history, which is the record of how it got there.
History can be pruned. A node can discard old blocks and still validate new ones. State cannot be discarded, because every new transaction needs to be checked against the current state.
Why it only grows
Every new account adds an entry. Every contract deployment adds code and storage. Every token balance is a slot that persists.
Nothing removes entries at a comparable rate. An abandoned account with a dust balance occupies space permanently, and there are a great many of them.
The fee model charges for writing to state once, while the cost of storing it is borne by every node operator forever. That mismatch is the root of the problem.
The consequence
Node hardware requirements rise continuously. Sync times lengthen. The set of people willing to run a validating node shrinks, and validation concentrates among those who can afford it.
That concentration is the real cost. A network with rising node requirements is a network becoming gradually more centralised, slowly enough that it never produces a news event.
The proposed solutions
State expiry. Entries untouched for a long period become inactive and must be revived with a proof. Reduces the active set. Adds complexity and a poor experience for anyone with a long-dormant holding.
Statelessness. Nodes verify blocks using witnesses supplied alongside them rather than holding state themselves. Elegant, and it moves the burden to specialist providers, which has its own concentration implications.
Verkle trees. A commitment structure producing much smaller proofs than Merkle trees, which makes statelessness practical. Under active development on Ethereum.
Higher storage pricing. Charge more for writing to state, reflecting the perpetual cost. Straightforward, unpopular, and only affects new state rather than what already exists.
Rent. Ongoing payment to keep state alive. Economically coherent and repeatedly rejected as unacceptable for user experience.
Where things stand
No major network has deployed a comprehensive solution. Several are working toward statelessness with Verkle trees, which is the most promising direction and is years of engineering.
Meanwhile state continues to grow, and node requirements continue to rise.
Why it matters to a holder
Indirectly, and over long horizons.
The security properties people value in these networks depend on many independent parties validating. If validation becomes something only well-resourced operators do, the guarantee weakens, regardless of what the protocol permits.
This is not an imminent failure. It is a slow trend with no natural stopping point, and it is the strongest argument for paying attention to node count and hardware requirements when evaluating a chain rather than reading throughput figures.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.