Ritrasmissione standard dei blocchi

Due viaggi di andata e ritorno e un megabyte o più, a ogni salto, per dati che il ricevente in gran parte aveva già. Uno studio di misurazione del 2013 ha rilevato che il nodo mediano veniva a conoscenza di un nuovo blocco 6,5 secondi dopo la sua scoperta, con una media di 12,6 secondi. Bitcoin Core ha introdotto la ritrasmissione dei blocchi compatti nella versione 0.13.0 il 23 agosto 2016, e la ritrasmissione standard è diventata il ripiego.

Come funziona

La ritrasmissione standard dei blocchi usa tre messaggi e non dà per scontato nulla di ciò che il nodo ricevente ha già.

Chi trova il blocco invia un messaggio inv che indica l'hash del nuovo blocco oppure, da quando BIP130 è arrivato in Bitcoin Core 0.12.0, un messaggio headers che porta direttamente l'intestazione di 80 byte, risparmiando al peer un viaggio di andata e ritorno separato con getheaders. Il ricevente verifica se ha quel blocco. Se non ce l'ha, risponde con getdata. Il mittente trasmette quindi il messaggio block: l'intestazione seguita da ogni transazione in serializzazione completa, entro il limite di quattro milioni di unità di peso che fissa la dimensione massima di un blocco.

Lo spreco è evidente appena lo si enuncia. Un nodo in funzione da ore ha già nella sua mempool quasi tutte le transazioni di quel blocco, avendole ricevute una per una quando sono state diffuse. La ritrasmissione standard le invia tutte una seconda volta. Su un blocco pieno di pagamenti ordinari si tratta di ben più di un megabyte di trasferimento ridondante, per ogni peer, per ogni blocco.

Le conseguenze non erano solo estetiche. Una propagazione lenta aumenta il tasso di blocchi obsoleti, perché un miner che non ha ancora saputo di un nuovo blocco continua a lavorare sulla vecchia punta della catena. I blocchi obsoleti costano di più ai piccoli miner che ai grandi, dato che un grande pool viene a conoscenza dei propri blocchi all'istante. Una ritrasmissione più rapida era quindi una tesi di decentralizzazione oltre che di efficienza, e ha spinto sia il BIP152 sia le reti di ritrasmissione dedicate che i grandi pool gestiscono tra loro.

La ritrasmissione standard non è scomparsa. È ciò che accade quando un peer non ha mai negoziato i blocchi compatti, quando la ricostruzione compatta fallisce e le transazioni mancanti non possono essere recuperate, e durante l'intero download iniziale dei blocchi, in cui un nodo in sincronizzazione richiede blocchi completi tramite getdata a più peer contemporaneamente, con fino a sedici in corso per peer in Bitcoin Core.

Dove la vedi

La ritrasmissione standard dei blocchi si nota soprattutto mentre un nodo si sta mettendo in pari, non quando è già in pari.

Durante una sincronizzazione iniziale, il traffico è dominato dai getdata per i blocchi, e i contatori per messaggio di getpeerinfo lo mostrano chiaramente. Una volta che il nodo raggiunge la punta, quei contatori si fermano e subentrano i contatori dei blocchi compatti. Una macchina su un collegamento lento o con pochi peer ricorre più spesso alla ritrasmissione standard, e il sintomo è una punta che resta indietro di un minuto o due rispetto a ciò che mostra un explorer pubblico.

Ritrasmissione standard dei blocchi vs ritrasmissione dei blocchi compatti

La ritrasmissione standard invia il blocco; quella compatta ne invia una descrizione e lascia che il ricevente ricostruisca il resto. Un cmpctblock porta l'intestazione, un nonce e un identificatore breve di sei byte per ogni transazione, così un blocco con qualche migliaio di pagamenti può essere descritto in meno di venti kilobyte invece di ben più di un megabyte. Il ricevente confronta quegli identificatori con la propria mempool, richiede ciò che manca con getblocktxn e assembla il blocco localmente. La validazione successiva è identica: la ritrasmissione compatta cambia come arrivano i byte, mai ciò che conta come blocco valido.