L'archivio e la lettura del passato
I normali nodi ZooBC conservano solo la cronologia recente: da 30 a 60 giorni di blocchi e i loro tre snapshot più recenti. L'archivio risponde alle domande sul passato lontano, come il saldo di un account tre anni fa: ogni snapshot dal blocco 0, distribuito sull'archiviazione decentralizzata invece che conservato su una sola macchina, e verificabile byte per byte rispetto alla catena spine.
Che cosa conserva ogni nodo
Ogni 172.800 blocchi (circa 30 giorni) su mainnet, ogni nodo scrive uno snapshot: l'intero stato della catena, ogni saldo, seggio del registro e record, com'era 760 blocchi sotto quell'altezza. I nodi scaglionano il lavoro, ma i byte di ogni nodo sono identici. Uno snapshot è un unico documento CBOR, diviso in porzioni da 102.400 byte che prendono il nome dai loro hash SHA3-256. Il suo manifest, con l'hash dell'intero file, l'hash di ogni porzione e l'altezza di riferimento, viene pubblicato in un blocco della catena spine, la lenta catena di blocchi giornalieri co-firmata da due terzi dei seggi registrati.
Nulla in uno snapshot è firmato. La sua autorità è il blocco spine co-firmato che lo nomina, quindi uno snapshot è autentico chiunque lo serva, purché i suoi byte corrispondano agli hash del manifest. Gli snapshot sono anche il modo con cui un nuovo nodo entra rapidamente (snapshot e fast sync).
Ogni nodo conserva sul proprio disco solo le sue tre generazioni di snapshot più recenti. È tutto ciò che serve a un nodo per aiutare gli altri a entrare, e conservare ogni snapshot mai prodotto su ogni nodo costerebbe a ogni operatore più disco ogni mese. Anche i blocchi vecchi vengono eliminati (pruning della cronologia).
L'archivio
A partire dalla versione 0.5.8 è l'archiviazione decentralizzata, non ogni nodo, a conservare ogni snapshot dal blocco 0. Le porzioni di ogni snapshot sono detenute da cinque nodi registrati scelti a sorte (storage_replication), come i frammenti di qualsiasi file archiviato (pool di archiviazione decentralizzata). Ogni nodo conserva solo i suoi ultimi tre snapshot; nessun nodo li conserva tutti.
Nessuna singola macchina detiene la cronologia, quindi nessun singolo operatore può perderla o trattenerla. Un server di archivio gestito da un'unica organizzazione, fosse anche la ZooBC Foundation, sarebbe esattamente quel punto unico. E non viene buttato via nulla: l'archivio risale fino al primissimo snapshot.
Detenere porzioni dell'archivio fa parte del compito di archiviazione di un nodo registrato. A ogni epoca di archiviazione, il 10 % del pool di longevità viene pagato in parti uguali ai nodi che dimostrano le porzioni campionate (pool).
Leggere il passato
Chi vuole lo stato a un momento passato ripercorre la spine fino allo snapshot preso in quel momento e ne legge il manifest. Scarica le porzioni dello snapshot dai loro detentori e verifica ciascuna rispetto al suo hash nel manifest, così un detentore non può infilare una porzione falsa. Poi ricompone lo snapshot, verifica l'hash dell'insieme e ricostruisce lo stato a quell'altezza: ogni saldo, seggio e record di quel momento. Nessun singolo nodo detiene la cronologia, e non serve alcun nodo di archivio.
Le verifiche non richiedono alcuna fiducia nei detentori: la spine è co-firmata dai seggi, e i suoi manifest fissano l'hash di ogni porzione, quindi una porzione falsa si vede subito.
Altri modi per vedere il passato
- Un deposito di longevità mantiene una transazione scelta, e il suo blocco, su ogni nodo finché il deposito dura (pagare per conservare i dati (longevità)).
- Un operatore può conservare tutta la cronologia sul proprio nodo con
keep_all_history; è una scelta locale, non il comportamento predefinito. - I nodi di archivio eseguono un servizio di indicizzazione accanto a un nodo e servono la ricerca e le statistiche dell'explorer (explorer e i nodi di archivio).