Changes to “The archive and reading the past”
#147 (zoobc.how, 2026-10-26 21:37 UTC) → #1084 (zoobc.how, 2026-10-27 00:42 UTC): Seed article updated
+ Ordinary ZooBC nodes keep only recent history: 30 to 60 days of blocks and their three newest snapshots. The archive answers 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.
− 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
…
## The archive
+ From version 0.5.8 it is the decentralised storage, not every node, that keeps every snapshot from block 0. Each snapshot's chunks are held by five registered nodes chosen by lot (`storage_replication`), as for the pieces of any stored file ([[storage-pool]]). Every node keeps only its last three snapshots; no node keeps them all.
+
+ No single machine holds the history, so no single operator can lose it or withhold it. An archive server run by one organisation, even the ZooBC Foundation, would be exactly that single point. Nothing is thrown away either: the archive goes back to the very first snapshot.
+
+ Holding archive chunks is part of a registered node's storage duty. Each storage epoch, 10 % of the longevity pool is paid in equal parts to the nodes that prove the sampled chunks ([[the-pools]]).
− > [!design] **Planned design.** The decentralised storage keeps every snapshot from block 0. Each snapshot's pieces are held by a few registered nodes chosen by lot, five by default (`storage_replication`), as for any stored file ([[storage-pool]]). Every node keeps only its last snapshots; no node keeps them all.
− >
− > No single machine holds the history, so no single operator can lose it or withhold it. An archive server run by one organisation, even the ZooBC Foundation, would be exactly that single point. Nothing is thrown away either: the archive goes back to the very first snapshot.
− >
− > The design will be revised before it is built. How the holders are chosen and how they are paid are not fixed yet, and the archive builds on fast sync from the spine.
+ 
− 
## Reading the past
+ A reader who wants the state at a past time walks the spine back to the snapshot taken at that time and reads its manifest. It fetches the snapshot's chunks from their holders and checks each one against its hash in the manifest, so a holder cannot slip in a false chunk. Then it reassembles the snapshot, checks the hash of the whole, and rebuilds the state at that height: every balance, seat and record of that moment. No single node holds the history, and no archival node is needed.
− > [!design] **Planned design.** A reader who wants the state at a past time walks the spine back to the snapshot taken at that time and reads its manifest. It fetches the snapshot's pieces from their holders and checks each one against its hash in the manifest, so a holder cannot slip in a false piece. Then it reassembles the snapshot, checks the hash of the whole, and rebuilds the state at that height: every balance, seat and record of that moment. No single node holds the history, and no archival node is needed.
+ 
− 
+ 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 chunk shows at once.
− 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
…