Sincronizzazione headers-first

Dividere il download in due è ciò che rende pratica una prima sincronizzazione. Bitcoin Core funziona così dalla versione 0.10.0, pubblicata a febbraio 2015, che ha trasformato il recupero dei blocchi da un'unica coda ordinata in un lavoro distribuito su ogni peer connesso. Se gestisci un tuo nodo per verificare il tuo saldo, è per questo che la sincronizzazione iniziale termina in ore anziché in giorni.

Come funziona

La sincronizzazione headers-first inizia chiedendo ai peer le intestazioni, non i blocchi.

Il nodo invia un messaggio getheaders che porta un localizzatore di blocchi, un elenco compatto di hash che descrive dove ritiene di trovarsi in quel momento. Un peer risponde con un messaggio headers che contiene fino a 2.000 intestazioni da 80 byte ciascuna, quindi una sola risposta copre circa due settimane di catena. Per ogni intestazione il nodo controlla che punti a un genitore che ha già e che il suo hash rispetti la difficoltà dichiarata dal suo campo nBits, poi chiede di nuovo dalla nuova punta finché nessun peer ha qualcosa di più recente da offrire.

Solo quando quello scheletro è a posto inizia il download dei corpi. Poiché il nodo conosce già l'hash di ogni blocco che vuole, può richiedere tratti diversi a più peer nello stesso momento invece di mettersi in coda dietro una sola connessione. Bitcoin Core limita quante richieste di blocchi lascia in sospeso con un singolo peer, sedici nel codice attuale, e disconnette un peer che blocca la finestra. I blocchi che arrivano prima dei loro genitori vengono semplicemente trattenuti, il che ha mandato in pensione la vecchia abitudine di parcheggiare dati non verificati sul disco.

Due salvaguardie accompagnano le intestazioni. Il software non adotta una catena finché le intestazioni che possiede non totalizzano più proof of work accumulato di una cifra minima compilata nella versione, così un peer non può attirare un nodo appena installato su una catena laterale economica fatta di blocchi facili. Separatamente, l'impostazione assumevalid indica un hash di blocco recente che accompagna ogni versione: le firme nei blocchi sepolti sotto di esso non vengono ricontrollate, il che elimina ore di calcoli su curva ellittica mentre ogni regola che dipende dallo stato attuale della catena resta applicata.

Dove lo vedi

La sincronizzazione headers-first si manifesta come due contatori che non coincidono mentre un nodo si mette in pari.

Esegui getblockchaininfo durante una prima sincronizzazione e il campo headers sarà molto avanti rispetto al campo blocks, spesso di centinaia di migliaia. Il client grafico dice la stessa cosa in parole semplici: può stimare un orario di fine solo dopo che sono arrivate le intestazioni, perché fino ad allora non sa quanto cammino gli resta. Osservare quei due numeri convergere è la barra di avanzamento onesta.

Il software leggero si ferma deliberatamente dopo la prima metà. Un wallet SPV, un client a filtri compatti o un nodo Lightning che funziona senza un proprio backend di catena conserva solo le intestazioni e vi sovrappone prove di Merkle o filtri. È proprio per questo che un wallet su smartphone può controllare la propria storia tramite dati mobili: le intestazioni sono piccole e di dimensione fissa, i corpi dei blocchi non sono né l'una cosa né l'altra.

Sincronizzazione headers-first vs sincronizzazione blocks-first

La sincronizzazione headers-first impara la forma della catena prima di scaricarne il contenuto, mentre la sincronizzazione blocks-first cercava di fare entrambe le cose insieme. Il metodo più vecchio inviava un messaggio getblocks, riceveva un inv con non più di 500 hash di blocco e li scaricava uno alla volta dal peer che rispondeva, così una sola connessione lenta rallentava tutto ciò che veniva dopo. Ciò che arrivava fuori ordine non aveva altro posto dove stare che un pool di attesa in memoria che un attaccante poteva riempire di dati inutili. Bitcoin Core non si sincronizza così da 0.10.0, anche se continua a comprendere quei messaggi perché il software più vecchio possa parlargli.