Pruning and Archive Nodes

Pruning is the process of discarding data a node no longer needs. Understanding what is safe to discard clarifies a lot of confusion about node requirements.

What can be pruned

Historical blocks, beyond a retention window. A node with current state can validate every future block without them.

Historical state, meaning the state at past blocks. Only the current state is needed for validation.

Receipts and logs older than the retention window, though pruning these removes the ability to answer queries about past events.

What cannot be pruned

Current state. Every balance and every storage slot, because the next transaction may touch any of them.

This is the binding constraint and it is why state growth is a harder problem than history growth.

What a pruned node can still do

Validate every new block independently. Serve your wallet with verified balances. Broadcast your transactions. Participate in the peer network.

In other words, everything an individual actually wants from a node.

What it cannot do

Answer historical queries. What was this balance at block one million. A pruned node does not know.

Serve historical blocks to peers. Which is a contribution to the network rather than a benefit to you.

Resync another node from scratch using its own data.

Why archive nodes exist

Block explorers, analytics providers and applications that need historical state all require it.

An archive node stores state at every block, which is substantially larger than storing it at one. The size difference is frequently an order of magnitude, and the storage requirement grows faster.

Most archive nodes are run by services rather than individuals, which is a form of centralisation in the data layer that receives less attention than consensus centralisation.

The practical recommendation

Run a pruned full node if you want verification and privacy. It is the configuration that provides what individuals want at the lowest cost.

Use a public explorer or a provider for historical queries, accepting that you are trusting them for that specific class of question while still verifying your own current balances yourself.

That split is reasonable: verification of what you hold is the part that matters, and it does not require history.

The storage planning note

Whatever you provision, plan for it filling. State grows continuously and history grows faster, and a node that runs out of disk stops validating.

Monitoring free space is the single most common operational requirement of running one, and it is the thing that most often causes a node to fall out of sync while its operator is not looking.