Sincronizzazione blocks-first

Oggi nessuno sincronizza più così, e il motivo è aritmetico. Un download strettamente sequenziale non può usare più della velocità di upload di un solo peer, e già nel 2015 la catena era troppo grande perché potesse concludersi in tempi ragionevoli. La tecnica sopravvive come ripiego nel protocollo e come fonte di confusione nella documentazione vecchia.

Come funziona

Stato: la sincronizzazione blocks-first è stata superata dalla sincronizzazione headers-first in Bitcoin Core 0.10.0, pubblicata il 16 febbraio 2015. I messaggi che usava fanno ancora parte del protocollo peer-to-peer e ricevono ancora risposta, ma nessun client attuale si basa su di essi per mettersi al passo.

Lo scambio era un ciclo tra due macchine. Il tuo nodo inviava un messaggio getblocks con gli hash dei blocchi che già aveva. Il peer rispondeva con un inventario che elencava fino a 500 hash dei blocchi successivi. Il tuo nodo chiedeva quei blocchi con getdata, li riceveva, convalidava ciascuno per intero e poi inviava un altro getblocks per chiedere cosa veniva dopo. E così per diverse migliaia di volte.

Da quel progetto derivarono tre problemi. Non c'era parallelismo, perché non aveva senso chiedere a un secondo peer blocchi che non ti era ancora stato detto esistessero, quindi l'intera sincronizzazione avanzava alla velocità del peer con cui stavi parlando in quel momento. Non c'era modo di sapere quanto mancasse, dato che la catena si rivelava 500 hash alla volta, ed è per questo che i client vecchi non potevano mostrare una barra di avanzamento significativa. E un peer lento o ostile poteva semplicemente farti arrivare i dati col contagocce, senza che il tuo nodo avesse un modo economico per capire che altrove era disponibile una catena migliore.

La sincronizzazione headers-first ha risolto tutti e tre i problemi separando la prova economica da quella costosa. Scarica e verifica prima la catena delle intestazioni, 27 megabyte per l'intera storia a dicembre 2014, e conosci sia la forma della catena migliore sia la sua lunghezza prima di scaricare una sola transazione. I corpi dei blocchi possono poi essere richiesti a molti peer contemporaneamente. L'effetto collaterale fu che i blocchi iniziarono ad arrivare fuori ordine e a essere scritti su disco fuori ordine, ed è per questo che la directory dei dati creata dalla versione 0.10.0 non può essere letta da nulla di più vecchio.

Dove lo vedi

La sincronizzazione blocks-first la incontrerai nella documentazione più che nel software.

Il materiale di riferimento scritto prima del 2015, compresa buona parte del materiale per sviluppatori ancora in circolazione, descrive il ciclo sequenziale come se fosse il funzionamento di bitcoin. Non lo è, e le pagine che descrivono una sincronizzazione iniziale come un download sequenziale da un solo peer sono semplicemente superate. Bitcoin Core continua a rispondere alle richieste getblocks a beneficio di client molto vecchi o insoliti, quindi i messaggi compaiono nelle catture dei pacchetti e nelle specifiche del protocollo.

Per chi gestisce un nodo oggi non c'è nulla da configurare e nulla da scegliere. Il tuo client scarica prima le intestazioni perché ogni implementazione mantenuta fa così.

Sincronizzazione blocks-first vs sincronizzazione headers-first

La sincronizzazione blocks-first e la sincronizzazione headers-first differiscono in ciò che chiedono per primo, e tutto il resto ne deriva. La blocks-first richiedeva blocchi completi in sequenza e apprendeva la forma della catena strada facendo, quindi scopriva la catena migliore e la scaricava nello stesso passaggio lento. La headers-first divide il lavoro: stabilisce quale catena porta più proof of work usando 80 byte per blocco, poi raccoglie i corpi in parallelo da chiunque sia disposto a inviarli. La convalida applicata a ogni blocco è identica in entrambi i casi. A cambiare è stato l'ordine delle operazioni, e solo questo ha portato una sincronizzazione iniziale da settimane a ore.