MSG_BLOCK

Quattro byte di tag di tipo decidono quale di diversi formati di blocco arriva. Il tipo 2 indica quello originale: un'intestazione di 80 byte seguita da ogni transazione per intero, con i dati witness rimossi, fino ai quattro milioni di unità di peso che un blocco può contenere. Un nodo che si allinea alla catena invia migliaia di queste richieste e ben poco altro.

Come funziona

MSG_BLOCK è un numero, non un messaggio, e ha significato solo dentro le voci da 36 byte con cui si costruiscono i messaggi inv e getdata.

Una voce è un tipo di quattro byte seguito da un hash di 32 byte, e il tipo indica al destinatario che cosa nomina l'hash. Inviare un getdata con una voce di tipo 2 significa: ho l'hash di questo blocco, mandami il blocco. Il peer risponde con un messaggio block, oppure con notfound se non può fornirlo. Un nodo potato restituisce notfound per tutto ciò che ha già cancellato, ed è per questo che un peer potato non serve a chi si sincronizza da zero.

Il tipo 2 da solo ora significa qualcosa di più ristretto di un tempo. Da quando il segregated witness è stato attivato nel 2017, un blocco richiesto in questo modo arriva nella vecchia serializzazione con i dati witness rimossi, cosa necessaria per continuare a servire il software più vecchio. Ogni nodo che intende validare il blocco ha bisogno di quei witness, perciò imposta il bit 0x40000000 e chiede invece la variante con witness. Tra due peer moderni il codice semplice compare soprattutto nelle richieste provenienti da software che nessuno ha aggiornato.

Anche l'annuncio è cambiato. Il BIP130 ha introdotto l'annuncio diretto delle intestazioni, e da Bitcoin Core 0.12.0 un nuovo blocco viene normalmente annunciato con un messaggio headers anziché con un inv, quindi questo codice di tipo ora vive soprattutto dal lato richiedente della conversazione.

Bitcoin Core non corre avanti senza limite durante il download. Mantiene una finestra di 1.024 blocchi oltre l'ultimo che ha validato, così un singolo peer che si blocca non può lasciare il nodo con una coda illimitata di blocchi che non ha modo di collegare.

Dove lo vedi

Le richieste di blocchi dominano il traffico di un nodo esattamente una volta, durante la prima sincronizzazione, e poi quasi mai più.

La catena ha superato 840.000 blocchi all'halving del 20 aprile 2024 e cresce di circa 144 blocchi al giorno, quindi una macchina che parte da zero ne scarica quasi un milione prima di essere al passo. Puoi osservarlo con getpeerinfo, che conta i byte per tipo di messaggio per ogni peer, oppure nel log con -debug=net. Una volta che il nodo raggiunge la punta quei contatori tacciono e subentra il traffico dei blocchi compatti.

MSG_BLOCK vs MSG_CMPCT_BLOCK

MSG_BLOCK e MSG_CMPCT_BLOCK differiscono tanto in dove sono ammessi quanto in ciò che recuperano. Il tipo 2 è ammesso in un inv e in un getdata, può essere inviato a qualsiasi peer senza accordi preventivi e funziona per un blocco di qualsiasi età. Il tipo 4 è ammesso solo in un getdata, può essere inviato solo a un peer che ha già offerto blocchi compatti con un messaggio sendcmpct e in Bitcoin Core viene servito solo per i cinque blocchi più recenti. Chiedi qualcosa di più profondo con il tipo 4 e ricevi comunque un messaggio block completo.