Pruning of history

A chain that keeps every block forever makes every node pay to store all of its history. ZooBC nodes prune instead: below a horizon tied to the snapshots, they delete old blocks, transactions, ledger rows, receipts and superseded versions of records. Current state, such as balances, registry seats and dataset rows, is not pruned this way; only old history is. A running node on mainnet holds 30 to 60 days of blocks.

The horizon

Every 172,800 blocks (about 30 days) on mainnet, each node writes a snapshot of the state (snapshots and fast sync). The pruning horizon is the older of the two most recent snapshot reference heights. With only one snapshot, it is that height minus one interval, and nothing is pruned before a snapshot manifest exists. From version 0.5.8 the horizon may never run ahead of a pure formula that every node shares:

horizon(h) = floor(h ÷ interval) × interval − interval

With an interval of 172,800 blocks, the horizon trails the tip by one to two intervals. At height 500,000, for example, the horizon is at most 172,800, so the node keeps at least the 327,200 newest blocks, about 57 days. After the next snapshot, at 518,400, the horizon moves up by one interval and about 30 days remain.

Two more limits make pruning gentle. The newest 1,440 blocks (6 hours) are never pruned, whatever the horizon says, and a node removes at most 500 rows per table per block, so the work is spread out.

What stays below the horizon

Some blocks are kept however old they are:

• block 0;
• every block that carries a transaction whose paying to keep data (longevity) record still holds money, kept together with that transaction;
• the transactions funded as of the newest snapshot, held one interval longer so that the snapshot can carry them.

Snapshots carry those funded transactions and the headers of their blocks, so a node that joins from a snapshot holds them as well.

Other clocks

Pruning is not the only rule with a time span, and the numbers are easy to mix up:

The rollback limit says how far back the chain may reorganise; it deletes nothing.

Keeping more

• An operator can set keep_all_history in node.conf to keep pruned history locally. That is a local choice, not the default.
• Anyone can pay to keep one transaction with a paying to keep data (longevity) deposit.
• Archival nodes run an indexing service beside a node and serve the explorer (explorer and archival nodes).

State is trimmed by rent

Pruning of history leaves the current state alone. State shrinks another way, through rent. An account that cannot pay its account rent and pruning is pruned, dataset rows whose rent goes unpaid are deactivated, and a stored file whose deposit runs out is pruned. In each case the money left goes to the longevity pool, and no ZBC is lost.

See also

• Paying to keep data (longevity)
• Snapshots and fast sync
• The archive and reading the past
• Account rent and pruning
• Finality and rollback