Compact Blocks permet de transmettre les blocs Bitcoin selon BIP 152 en répétant moins de données. Ni le bloc lui-même ni ses règles ne sont allégés : le destinataire doit retrouver tout le contenu et le vérifier avant de l’accepter.
Anna veut envoyer un nouveau bloc à Pierre, mais il possède déjà beaucoup de ses transactions. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Les renvoyer toutes serait répétitif. Le mécanisme Compact Blocks fournit plutôt l’en-tête du bloc et une liste de repères courts permettant de retrouver les transactions connues. L’en-tête est une courte partie du bloc qui contient les informations essentielles, dont une référence au bloc précédent et une empreinte des transactions. Pour les lecteurs techniques : ces repères occupent 48 bits, soit 6 octets, et sont obtenus en tronquant le résultat de la fonction SipHash-2-4. Ses paramètres sont dérivés de l’en-tête et d’un nombre supplémentaire pour ce transfert, appelé nonce. Le repère n’est donc pas un nom permanent de transaction pour tout le réseau Bitcoin. [1] [2] [7]
Une liste ne remplace pas tout. Anna envoie certaines transactions complètes avec leur position dans le bloc. L’exemple habituel est la Coinbase Transaction, la première transaction du bloc, qui attribue la récompense minière ; elle n’a aucun rapport avec la plateforme du même nom. Créée pour ce bloc précis, elle ne se trouve normalement pas parmi les transactions en attente de Pierre. Entrées complètes et repères courts se complètent lors de la reconstruction. [1] [2]
Le Mempool de Pierre est sa collection locale de transactions connues mais pas encore confirmées dans sa chaîne acceptée. Il calcule les mêmes repères courts pour les transactions disponibles et cherche les correspondances avec la liste d’Anna. Il ne suppose pas que tout le monde possède la même collection. Un repère court pouvant parfois désigner plusieurs transactions, une correspondance ne prouve pas encore définitivement que le contenu est correct. [1] [2]
Si certaines positions restent vides ou ambiguës, Pierre demande les transactions concernées par leur position. La requête s’appelle getblocktxn et la réponse contenant les transactions, blocktxn. Inutile de retenir ces noms : l’essentiel est de demander les vraies données plutôt que de deviner le contenu. Un aller-retour supplémentaire prend du temps. Si la reconstruction échoue, il est possible de télécharger le bloc entier. [1] [3]
Pierre doit retrouver les transactions exactes dans le bon ordre et contrôler leur lien avec l’en-tête. Un Merkle Tree résume les transactions dans une empreinte de contrôle et permet de vérifier ce lien. Mais un assemblage correct ne remplace pas l’examen des règles. Un Full Node est un logiciel avec lequel Pierre vérifie lui-même les règles de Bitcoin, notamment l’autorisation de dépenser les fonds et le montant de la récompense. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Le transfert compact n’accorde aucune dérogation à un bloc invalide. [1] [8]
Les nœuds voisins conviennent du mode avec sendcmpct. Dans l’option rapide, un message cmpctblock contenant les données de reconstruction annonce directement le nouveau bloc. Après les contrôles préliminaires requis, l’émetteur peut transmettre avant d’avoir achevé toutes les vérifications des transactions. Il doit notamment vérifier le raccordement à la chaîne validée, Proof of Work comme preuve du travail de calcul, et le lien de l’en-tête avec les transactions. Le destinataire vérifie toujours le bloc intégralement avant de l’accepter dans son historique. [1] [4]
L’autre option annonce d’abord un bloc déjà validé au moyen de inv ou headers. Pierre demande ensuite les données compactes s’il en a besoin. Cela peut éviter l’envoi inutile d’un bloc déjà obtenu ailleurs, au prix d’une étape de communication supplémentaire. Les deux modes peuvent économiser des données par rapport au renvoi de toutes les transactions. Ils diffèrent par le moment de l’envoi et la nécessité d’une demande préalable, pas par le niveau de validité du bloc. [1] [7]
Deux transactions différentes peuvent avoir le même repère court : c’est une collision. Comme deux personnes aux mêmes initiales, l’abréviation ne suffit plus à les distinguer. Selon l’endroit où survient le problème, le logiciel réclame des précisions ou télécharge le bloc entier. Une collision ne casse pas les signatures de Bitcoin et ne rend pas valide un bloc invalide. Il faut vérifier le contenu réel, pas seulement la concordance des repères. [1] [2]
La version 2 du protocole compact prend en charge SegWit, qui sépare les signatures et d’autres données de vérification dans une partie witness. Elle utilise wtxid, un identifiant incluant ces données, plutôt que txid, qui ne les inclut pas. Les transactions complètes voyagent avec les données witness requises selon BIP 144. Elles ne sont donc pas abandonnées pour donner l’impression d’un envoi plus petit. La version du protocole de transmission n’est pas non plus le numéro de version du bloc. [1] [6]
Si Anna et Pierre connaissent beaucoup de transactions communes, le bloc circule avec bien moins de données répétées. Cela aide aussi une connexion domestique à supporter l’arrivée soudaine d’un bloc. Avec peu de transactions communes, les demandes supplémentaires réduisent l’économie. L’objectif principal est de limiter les données transmises ; une livraison plus rapide est un bénéfice possible, pas une promesse d’attente nulle ou de message de taille fixe. Cela ne crée aucune nouvelle limite de taille des blocs Bitcoin. [5] [7]
Pour une vision complète, lisez aussi Block Propagation, Initial Block Download, Eclipse Attack, vByte, Bitcoin, Transaction coinbase. Cette entrée est également citée par Stale Block, Eclipse Attack, Selfish Mining, Block Propagation.