Snapshot e fast sync
Un nodo che entra in una catena vecchia di anni non deve riprodurre ogni blocco dal blocco 0. Segue la catena spine, scarica l'ultimo snapshot indicato dalla spine, lo verifica pezzo per pezzo e confrontandolo con i suoi peer, e poi applica solo i blocchi prodotti da allora. Questo è il fast sync. In nessun momento il nodo crede sulla parola a un sito web o a un singolo peer riguardo allo stato della catena.
Snapshot
Uno snapshot è l'intero stato della catena, ogni saldo, seggio e record, a una certa altezza. Ogni main_snapshot_interval blocchi, 172.800 blocchi o circa 30 giorni su mainnet, ogni nodo scrive uno snapshot dello stato com'era 760 blocchi sotto quell'altezza di attivazione. (Su devnet: ogni 240 blocchi, a 80 blocchi di profondità.) I nodi scaglionano il lavoro fino a 60 blocchi, ma lo snapshot di ogni nodo è identico byte per byte.
Lo snapshot è un unico documento CBOR che contiene le tabelle di stato della catena (57 in tutto), le intestazioni dei blocchi recenti, le transazioni recenti, le transazioni la cui conservazione è ancora pagata (vedi pagare per conservare i dati (longevità)) e le ricevute pubblicate di recente. È diviso in porzioni da 102.400 byte, ciascuna indicata dal suo hash SHA3-256. La lista di questi hash, con l'hash dell'intero file, l'altezza di riferimento, una scadenza e l'hash genesi della catena, forma il manifest, che un blocco della spine pubblica.
Nulla all'interno di uno snapshot è firmato. La sua autorità è il blocco spine che lo nomina: un blocco co-firmato da due terzi dei seggi, ciascuno dei quali ha prima confrontato il manifest con il proprio snapshot, hash per hash.
Ogni nodo conserva solo le sue tre generazioni di snapshot più recenti. Ogni snapshot dal blocco 0 è conservato dall'archiviazione decentralizzata, non da ogni nodo: le porzioni di ogni snapshot sono detenute da cinque nodi registrati scelti a sorte (vedi archivio e la lettura del passato).
Il fast sync, passo per passo
Un nodo tenta il fast sync quando è indietro di almeno 100 blocchi e detiene un manifest utilizzabile sopra la propria altezza. Deve detenere il blocco spine che contiene il manifest, con le sue firme. Il manifest più recente resta utilizzabile anche dopo la sua scadenza.
- Sincronizzare la spine. Un nodo molto indietro memorizza un blocco spine il cui riferimento si trova sopra la sua punta quando quel blocco porta la propria soglia di firme (due terzi, o più della metà per un blocco di ripiego). Ne verifica il contenuto in seguito, quando la sua catena principale raggiunge il riferimento, e si ferma con un allarme in caso di discrepanza.
- Scaricare le porzioni dai peer registrati connessi, in fino a 16 frammenti paralleli, verificando ogni porzione rispetto all'hash che la nomina.
- Verificare l'intero file rispetto all'hash del file completo indicato nel manifest.
- Caricare lo stato in un'unica transazione del database.
- Verificare un campione con i peer (vedi sotto).
- Applicare i blocchi rimanenti uno per uno, con la validazione completa, fino alla punta.
L'attestazione: verificare lo stato con i peer
Gli hash corrispondenti dimostrano che i byte sono quelli indicati dal manifest. Non dimostrano che quei byte siano il vero stato. I co-firmatari della spine confrontano già ogni manifest con il proprio snapshot; dalla versione 0.5.8 un nodo che entra aggiunge una verifica propria, nel caso gli sia stato consegnato un manifest falso.
Dopo il caricamento, il nodo sceglie fino a 8 account e 8 nodi del registro dal suo nuovo stato. La scelta è guidata dall'hash dello snapshot stesso, quindi ogni nodo che entra sceglie le stesse righe e un falsario non può sapere in anticipo quali rendere coerenti. Il nodo chiede a 3 peer registrati casuali il saldo di ogni account e la chiave e lo stato di ogni nodo all'altezza dello snapshot. Le risposte oneste su una stessa catena a una stessa altezza sono identiche.
- Almeno 2 peer sono d'accordo e nessuno contraddice: il nodo prosegue.
- Le contraddizioni non sono in minoranza: allarga il sondaggio a 7 peer e allora gli servono almeno 2 risposte concordi e almeno due terzi di quelli che rispondono.
- Altrimenti rifiuta lo snapshot e ripiega sulla sincronizzazione blocco per blocco.
Se rispondono troppo pochi peer, il nodo procede basandosi solo sugli hash.
Perché il risultato è affidabile
- Il blocco spine che nomina lo snapshot è stato co-firmato da due terzi dei seggi dopo che ciascuno ha confrontato il manifest con il proprio snapshot.
- Ogni porzione, e l'intero file, devono corrispondere agli hash del manifest.
- Un campione dello stato caricato viene verificato con peer registrati indipendenti, scelti a caso, ogni volta che ne rispondono abbastanza.
- Ogni blocco successivo allo snapshot viene validato per intero.
- La spine stessa può essere ancorata dal pin della release che arriva con la release del nodo.
Nessuno firma gli snapshot a mano, non ci si fida di alcun sito web, e nulla viene riprodotto dal blocco 0.