Relais de bloc standard

Deux allers-retours et un mégaoctet ou plus, à chaque saut, pour des données que le destinataire possédait déjà en grande partie. Une étude de mesure de 2013 a chronométré le nœud médian prenant connaissance d'un nouveau bloc 6,5 secondes après sa découverte, avec une moyenne de 12,6 secondes. Bitcoin Core a livré le relais de blocs compacts dans la version 0.13.0 le 23 août 2016, et le relais standard est devenu la solution de repli.

Comment cela fonctionne

Le relais de bloc standard utilise trois messages et ne suppose rien sur ce que le nœud destinataire détient déjà.

Le découvreur envoie inv en nommant le hash du nouveau bloc ou, depuis l'arrivée du BIP130 dans Bitcoin Core 0.12.0, un message headers portant directement l'en-tête de 80 octets, ce qui épargne au pair un aller-retour getheaders distinct. Le destinataire vérifie s'il possède ce bloc. Sinon, il répond getdata. L'expéditeur transmet alors le message block : l'en-tête suivi de chaque transaction en sérialisation complète, dans la limite du budget de quatre millions d'unités de poids qui plafonne un bloc.

Le gaspillage saute aux yeux une fois énoncé. Un nœud en fonctionnement depuis des heures détient déjà presque toutes les transactions de ce bloc dans sa mempool, les ayant reçues une par une lors de leur diffusion. Le relais standard les renvoie toutes une seconde fois. Sur un bloc rempli de paiements ordinaires, cela représente bien plus d'un mégaoctet de transfert redondant, par pair, par bloc.

Les conséquences n'étaient pas seulement esthétiques. Une propagation lente augmente le taux de blocs obsolètes, car un mineur qui n'a pas encore entendu parler d'un nouveau bloc continue à travailler sur l'ancienne tête. Les blocs obsolètes coûtent plus cher aux petits mineurs qu'aux gros, puisqu'une grande pool est informée de ses propres blocs instantanément. Un relais plus rapide était donc un argument de décentralisation autant qu'un argument d'efficacité, et il a motivé à la fois le BIP152 et les réseaux de relais dédiés que les grandes pools exploitent entre elles.

Le relais standard n'a pas disparu. C'est ce qui se produit quand un pair n'a jamais négocié les blocs compacts, quand la reconstruction compacte échoue et que les transactions manquantes ne peuvent pas être complétées, et tout au long du téléchargement initial de la blockchain, où un nœud en cours de synchronisation demande des blocs complets par getdata à plusieurs pairs à la fois, jusqu'à seize en cours par pair dans Bitcoin Core.

Où le voit-on

Le relais de bloc standard est plus visible pendant qu'un nœud rattrape son retard que lorsqu'il est à jour.

Pendant une synchronisation initiale, les getdata de blocs dominent le trafic et les compteurs par message de getpeerinfo le montrent clairement. Une fois que le nœud atteint la tête de chaîne, ces compteurs se taisent et les compteurs de blocs compacts prennent le relais. Une machine sur une liaison lente ou avec peu de pairs retombe plus souvent sur le relais standard, et le symptôme est une tête de chaîne qui accuse une ou deux minutes de retard sur ce qu'affiche un explorateur public.

Relais de bloc standard vs relais de blocs compacts

Le relais standard envoie le bloc ; le relais compact en envoie une description et laisse le destinataire reconstruire le reste. Un cmpctblock porte l'en-tête, un nonce et un identifiant court de six octets pour chaque transaction, si bien qu'un bloc contenant quelques milliers de paiements peut être décrit en moins de vingt kilooctets au lieu de bien plus d'un mégaoctet. Le destinataire fait correspondre ces identifiants avec sa propre mempool, demande ce qui manque avec getblocktxn et assemble le bloc localement. La validation qui suit est identique : le relais compact change la façon dont les octets arrivent, jamais ce qui compte comme un bloc valide.