MSG_BLOCK

Quatre octets d'étiquette de type décident lequel de plusieurs formats de bloc arrive. Le type 2 désigne l'original : un en-tête de 80 octets suivi de chaque transaction en entier, les données témoin retirées, jusqu'aux quatre millions d'unités de poids qu'un bloc peut contenir. Un nœud qui rattrape la chaîne envoie des milliers de ces requêtes et presque rien d'autre.

Comment cela fonctionne

MSG_BLOCK est un nombre et non un message, et il n'a de sens qu'à l'intérieur des entrées de 36 octets à partir desquelles les messages inv et getdata sont construits.

Une entrée est un type de quatre octets suivi d'un hash de 32 octets, et le type indique au destinataire ce que le hash désigne. Envoyer un getdata avec une entrée de type 2 revient à dire : j'ai le hash de ce bloc, envoyez-moi le bloc. Le pair répond par un seul message block, ou par notfound s'il ne peut pas le fournir. Un nœud élagué renvoie notfound pour tout ce qu'il a déjà supprimé, ce qui explique qu'un pair élagué soit inutile à quelqu'un qui se synchronise depuis zéro.

Le type 2 pris seul signifie désormais quelque chose de plus étroit qu'autrefois. Depuis l'activation de la séparation des témoins en 2017, un bloc demandé de cette façon revient dans l'ancienne sérialisation, les données témoin retirées, ce qui était nécessaire pour continuer à servir les logiciels plus anciens. Tout nœud qui veut valider le bloc a besoin de ces témoins, il positionne donc le bit 0x40000000 et demande plutôt la variante témoin. Entre deux pairs modernes, le code simple apparaît surtout dans les requêtes de logiciels que personne n'a mis à jour.

L'annonce a évolué elle aussi. Le BIP130 a introduit l'annonce directe d'en-têtes, et depuis Bitcoin Core 0.12.0 un nouveau bloc est normalement annoncé par un message headers plutôt que par un inv, si bien que ce code de type vit désormais surtout du côté demandeur de la conversation.

Bitcoin Core ne prendra pas indéfiniment de l'avance pendant le téléchargement. Il garde une fenêtre de 1 024 blocs au-delà du dernier qu'il a validé, afin qu'un seul pair qui bloque ne puisse pas laisser le nœud avec une file illimitée de blocs qu'il n'a aucun moyen de connecter.

Où le voir

Les demandes de blocs dominent le trafic d'un nœud exactement une fois, lors de sa première synchronisation, puis presque jamais ensuite.

La chaîne a dépassé 840 000 blocs au halving du 20 avril 2024 et croît d'environ 144 blocs par jour, si bien qu'une machine qui démarre à zéro en récupère près d'un million avant d'être à jour. Vous pouvez l'observer avec getpeerinfo, qui compte les octets par type de message pour chaque pair, ou dans le journal avec -debug=net. Une fois que le nœud atteint la pointe, ces compteurs se taisent et le trafic de blocs compacts prend le relais.

MSG_BLOCK vs MSG_CMPCT_BLOCK

MSG_BLOCK et MSG_CMPCT_BLOCK diffèrent autant par les endroits où ils sont autorisés que par ce qu'ils récupèrent. Le type 2 est légal dans un inv et dans un getdata, peut être envoyé à tout pair sans arrangement préalable et fonctionne pour un bloc de n'importe quel âge. Le type 4 n'est légal que dans un getdata, ne peut être envoyé qu'à un pair ayant déjà proposé des blocs compacts par un message sendcmpct et, dans Bitcoin Core, n'est servi que pour les cinq blocs les plus récents. Demandez quelque chose de plus profond avec le type 4 et c'est un message block complet qui revient quand même.