ZooBC wiki
Data and storage

The archive and reading the past

You are looking at an old version of this page: revision #79 by zoobc.how, 2026-10-26 20:39 UTC. See the current version

Ordinary ZooBC nodes keep only recent history: 30 to 60 days of blocks and their three newest snapshots. The archive is the planned answer to questions about the distant past, such as an account's balance three years ago: every snapshot since block 0, spread over the decentralised storage rather than kept on one machine, and checkable byte by byte against the spine chain.

What every node keeps

Every 172,800 blocks (about 30 days) on mainnet, each node writes a snapshot: the whole state of the chain, every balance, registry seat and record, as of 760 blocks below that height. Nodes stagger the work, but every node's bytes are identical. A snapshot is one CBOR document, cut into chunks of 102,400 bytes that are named by their SHA3-256 hashes. Its manifest, with the hash of the whole file, the hash of every chunk and the reference height, is published in a block of the spine chain, the slow chain of daily blocks co-signed by two thirds of the registered seats.

Nothing in a snapshot is signed. Its authority is the co-signed spine block that names it, so a snapshot is authentic whoever serves it, as long as its bytes match the manifest's hashes. Snapshots are also how a new node joins quickly (snapshots and fast sync).

Each node keeps only its three newest snapshot generations on its own disk. That is all a node needs to help others join, and keeping every snapshot ever made on every node would cost each operator more disk every month. Old blocks are pruned as well (pruning of history).

The archive

Planned design: one node keeps its last three snapshots; the archive keeps every snapshot since block 0, each piece on five nodes chosen by lot.
Planned design: one node keeps its last three snapshots; the archive keeps every snapshot since block 0, each piece on five nodes chosen by lot.

Reading the past

Planned design: walk the spine, read the manifest, fetch and check the pieces, rebuild the state.
Planned design: walk the spine, read the manifest, fetch and check the pieces, rebuild the state.

The checks need no trust in the holders: the spine is co-signed by the seats, and its manifests fix the hash of every chunk, so a false piece shows at once.

Other ways to see the past

  • A longevity deposit keeps one chosen transaction, and its block, on every node for as long as the deposit lasts (paying to keep data (longevity)).
  • An operator can keep all history on its own node with keep_all_history; that is a local choice, not the default.
  • Archival nodes run an indexing service beside a node and serve the explorer's search and statistics (explorer and archival nodes).

See also