~/notes / node operation
What a Node Actually Stores
State, history and indexes are three different things with very different sizes. The distinction explains most of the confusion about node requirements.
Published node storage requirements vary wildly for the same network. The reason is that different node types store different things.
The three categories
State. The current condition of the network: every account balance, every contract’s storage, every token holding. Required to validate new blocks, because each transaction must be checked against current state.
History. The record of every block and transaction. Required to reconstruct state from scratch and to answer historical queries. Not required to validate new blocks once you have current state.
Indexes. Derived data structures that make queries fast. Not part of consensus at all; built by nodes that need to serve queries.
The node types
Pruned full node. Current state plus recent history. Validates everything going forward. The smallest configuration that provides full verification.
Full node with history. State plus complete block history. Larger, and can serve historical data to peers.
Archive node. State at every historical block, not just the current one. Substantially larger, sometimes by an order of magnitude, and required for historical queries about past balances.
Light client. Block headers only, verifying inclusion with proofs supplied by full nodes.
Why the numbers differ so much
Published requirements frequently quote archive node sizes, which are the largest configuration and which almost no individual needs.
A pruned full node is the relevant number for someone who wants to verify their own transactions without trusting a provider, and it is considerably smaller.
What grows and what does not
History grows monotonically. Every block adds to it, permanently.
State grows too, and more slowly, because it only increases when new accounts and storage slots are created.
Pruning removes history and not state. A pruned node still carries the full current state and that is the part that cannot be discarded, because validating the next block requires it.
This is why state growth is the harder long-term problem: history can be dropped, state cannot.
The practical choice
For most individuals, a pruned full node provides everything they actually want: independent verification of their own balances and transactions, and privacy from query providers.
Archive configurations are for services that answer historical queries. Running one as an individual is a large cost for a capability you will not use.
The privacy argument
A wallet connected to a third-party endpoint reveals every address it holds to that provider, continuously.
Running your own node removes that, and it is the benefit most users would actually notice if they thought about it. The working balance at a platform with real on-chain withdrawals is a different arrangement entirely, where the venue knows your identity by design and the privacy question does not arise in the same form.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.