En-tête de message

Rien dans le protocole pair-à-pair ne se décrit lui-même, c'est donc l'enveloppe qui s'en charge. Ses quatre champs ne changent jamais de taille ni d'ordre, ce qui permet à un nœud de lire exactement 24 octets, de savoir combien d'autres arrivent et de couper la connexion devant tout ce qui annonce plus que les 4 000 000 octets que Bitcoin Core accepte. Vous n'en verrez jamais un, mais un en-tête mal formé est la raison pour laquelle une connexion pair-à-pair disparaît parfois sans explication.

Comment cela fonctionne

Les quatre champs de l'en-tête se lisent dans un ordre fixe, et chacun conditionne la suite.

Les octets 0 à 3 contiennent la chaîne de démarrage qui identifie le réseau. Les octets 4 à 15 contiennent la commande : un nom ASCII en minuscules complété par des octets nuls jusqu'à douze caractères, ce qui explique pourquoi chaque type de message dans bitcoin porte un nom bref et pourquoi cmpctblock, avec ses dix caractères, frôle le plafond. Les octets 16 à 19 contiennent la longueur de la charge utile sous forme d'entier non signé en petit-boutiste. Les octets 20 à 23 contiennent une somme de contrôle, les quatre premiers octets d'un double SHA-256 calculé sur la charge utile.

Placer la longueur avant la charge utile est la véritable sécurité de cette conception. Un nœud qui a consommé 24 octets sait déjà si l'expéditeur annonce quelque chose d'absurde, et Bitcoin Core refuse tout ce qui dépasse 4 000 000 octets et se déconnecte, sans allouer de mémoire tampon ni attendre des données qui pourraient ne jamais venir. Mettez la longueur après le corps et vous faites confiance à l'expéditeur pour s'arrêter.

La somme de contrôle mérite moins de considération qu'on ne lui en accorde. Quatre octets de hachage détectent un bit inversé sur une liaison défectueuse et ne servent à rien contre un pair qui ment, puisqu'un expéditeur hostile calcule simplement la somme de contrôle sur ce qu'il a choisi d'envoyer. L'intégrité dans bitcoin vient de la validation du contenu selon les règles de consensus, jamais de ce champ.

L'ensemble de la structure est facultatif dans les logiciels plus récents. Le transport en version 2 du BIP324 chiffre la connexion et remplace l'enveloppe en clair par un cadrage de longueur obscurci et un identifiant court d'un octet pour les types de messages les plus courants, si bien qu'un observateur passif ne peut plus lire les noms de commandes sur le réseau. Bitcoin Core l'a livré comme réglage facultatif dans la version 26.0 et l'a activé par défaut dans une version ultérieure.

Où le voir

Les en-têtes de message apparaissent dans les captures de paquets et dans les diagnostics d'un nœud.

Lancez Bitcoin Core avec -debug=net et le journal enregistre les types et les tailles de messages pour chaque pair, ce qui est le moyen pratique de voir ce que fait réellement une connexion. Les entrées PROCESSMESSAGE : INVALID MESSAGESTART signifient qu'un pair a envoyé des octets qui ne commençaient pas par la chaîne de démarrage de ce réseau, ce qui est presque toujours une mauvaise configuration à l'autre bout plutôt qu'une attaque. Le dissecteur bitcoin de Wireshark analyse les mêmes 24 octets pour étiqueter chaque trame.

En-tête de message vs en-tête de bloc

Un en-tête de message est un emballage de transport ; un en-tête de bloc est une donnée de consensus, et ils n'ont en commun que le mot. L'en-tête de message fait 24 octets, n'existe que le temps d'une livraison et est jeté dès que la charge utile a été lue. L'en-tête de bloc fait 80 octets, contient la version, le hachage du bloc précédent, la racine de Merkle, l'horodatage, la cible de difficulté et le nonce, et il est haché pour produire la preuve de travail qui nomme ce bloc de façon permanente. L'un est l'étiquette d'adresse sur un colis ; l'autre est ce qu'il contient.