Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

State growth and storage

Ethereum's state is the part of the chain that every full node must keep. It grows with every account created and every storage slot written, and the proposals that address it aim to let a node validate without holding all of it.

Last reviewed 2026-09-21Source: Ethereum Yellow Paper, ethereum.org state documentation and EIP-4444Mechanism descriptions only; no state-size figures are claimed.

The state trie

Ethereum's world state is a mapping from addresses to account objects, and it is committed to as a Merkle-Patricia trie. Each account's storage is committed to in its own trie, and the root of that trie is recorded in the account. The root of the state trie is the single 32-byte value that a block header carries, and it is what commits the entire state: change one storage slot anywhere and the state root changes.

The trie structure is what makes proofs possible. A node can produce a proof that an account has a particular balance, or that a storage slot holds a particular value, by supplying the trie nodes along the path from the root to that leaf. A verifier that holds only the state root can check the proof without holding the rest of the state. That is the property light clients depend on, and it is the reason the state is committed to as a tree rather than as a flat database.

The structure also explains why state growth is a structural concern rather than a storage-cost concern. Trie nodes are shared between accounts whose paths overlap, so the cost of adding an account is not simply the size of its data; it depends on how much of its path is already present. And because a slot that is written once and never cleared remains part of the state, the state is a record of everything that has ever been written and not deleted, not a record of what is currently in use.

What storage costs and why

The storage operations a contract can perform and how the protocol prices them.
OperationHow it is pricedWhy
Reading a slotA modest fixed costThe value is already in the state; the work is a lookup
Writing a slot that was zeroThe highest storage costThe slot becomes part of the state every node must carry
Overwriting a slot that held a valueLower than a zero-to-nonzero writeThe slot is already in the state; only its value changes
Clearing a slot back to zeroA partial refundThe state shrinks, so part of the original cost is returned
Creating an accountA fixed cost plus the code's per-byte costA new account adds a leaf to the state trie and its code to the database

Last reviewed 2026-09-21Source: Ethereum Yellow Paper, Appendix GGas constants are set by the protocol and change through hard forks.

The pricing is designed to make a contract pay for the state it creates. A write that adds a new slot to the state is charged far more than a write that changes an existing one, because the first increases what every node must store and the second does not. The refund for clearing a slot is the mirror of that: a contract that deletes data it no longer needs returns part of the state to the network, and the protocol pays it back for doing so.

The refund mechanism has been adjusted more than once because it created its own problems. A refund large enough to matter can be gamed by a contract that writes and clears state within a single transaction, collecting the refund without ever leaving the state smaller. The protocol caps the refund as a fraction of the transaction's total gas for that reason, and the cap has been tightened over time. The general lesson is that pricing state correctly is harder than it looks, because the cost of a write is borne by every future node while the benefit accrues to the contract that made it.

The cost structure has a practical consequence for contract design. A contract that stores a value per user pays the highest storage cost for every user it acquires, and it pays it once. A contract that stores a commitment to a batch of user data pays once for the batch and lets users prove their own entries against the commitment. The second pattern is more complex to write and cheaper to run, and it is the reason merkle-root patterns are common in contracts that expect many users.

Statelessness and history expiry

Two distinct problems are often discussed together under the heading of state growth, and separating them makes the proposals easier to read. The first is the live state: the accounts and storage slots that a node needs in order to validate a new block. The second is history: the blocks and receipts that a node keeps so that it can answer questions about the past. The live state must be available to validate; history need only be retrievable.

History expiry addresses the second problem. The proposal is that a node should not be required to keep every historical block forever, because the chain's history is only needed for serving queries and for syncing a new node, and both of those can be served by a smaller number of archival nodes. A node that expires old history keeps the recent window and relies on the network for anything older. The trade-off is that the network's ability to answer historical queries then depends on enough participants choosing to keep the data.

Statelessness addresses the first problem, and it is the harder of the two. The idea is that a validator should be able to check a block without holding the state the block touches, by receiving a witness — the trie nodes along the paths the block reads and writes — alongside the block. If the witness is sufficient, the validator can recompute the affected part of the state root and confirm the block is valid without storing the state at all. The proposals differ in how the witness is produced and who is responsible for it, and none of them is deployed. They are best described as an active area of research rather than as a scheduled change.

Sources and references

The trie structure, the storage pricing and the proposals described above are taken from Ethereum's specification and its public improvement proposals.

Related reading