Envoi de bloc non sollicité

Pousser sans y être invité est impoli dans la plupart des protocoles et correct dans celui-ci. Chaque aller-retour qu'un bloc passe en transit est du temps qu'un mineur passe à travailler sur une extrémité qui n'existe plus, c'est pourquoi le BIP152 a formalisé le raccourci : jusqu'à trois pairs choisis peuvent vous envoyer un bloc à l'instant où ils le reçoivent. Votre nœud le valide de toute façon depuis le début et ne doit rien à l'expéditeur.

Comment cela fonctionne

Deux choses différentes circulent sous le nom d'envoi de bloc non sollicité, l'une ancienne et informelle, l'autre spécifiée.

L'ancienne forme est simplement un message block qui arrive sans getdata correspondant. Le protocole ne l'a jamais interdit et les récepteurs ont toujours traité ces blocs, mais avec des conditions. Bitcoin Core vérifie la preuve de travail dans l'en-tête avant d'engager quoi que ce soit de coûteux, ne transmet pas le bloc plus loin avant de l'avoir entièrement validé et connecté à la meilleure chaîne, et traite un bloc qui ne se connecte à rien de connu comme une donnée à écarter plutôt qu'un problème à résoudre. Ces règles existent parce que les données non sollicitées ne coûtent rien à l'expéditeur et coûtent cher au récepteur, ce qui est la forme de toute attaque par déni de service dans le protocole.

La forme spécifiée est le mode haut débit du BIP152. Un nœud envoie à son pair un message sendcmpct dont le premier octet vaut 1, ce qui signifie : n'annoncez pas, envoyez directement. Ce pair peut alors transmettre un cmpctblock à l'instant où il entend parler d'un nouveau bloc, parfois avant d'avoir fini de le valider. Le BIP152 fixe un plafond strict de trois pairs de ce type et Bitcoin Core applique exactement cette limite, en conservant une liste d'au plus trois nœuds retenus pour avoir livré des blocs récents en premier. Trois est un compromis : assez de redondance pour qu'un pair lent ne puisse pas vous retarder, assez peu pour que vous ne receviez pas le même bloc par toutes vos connexions.

Comme une annonce en mode haut débit peut précéder la validation, le nœud récepteur la traite comme une déclaration plutôt que comme un fait. La preuve de travail est vérifiée en premier, étant la seule partie d'un bloc qui ne peut pas être falsifiée à bas coût, et tout le reste suit le chemin normal. La version de protocole 70015 existe précisément pour qu'un nœud puisse signaler qu'il ne pénalisera pas un pair pour avoir annoncé un bloc dont il s'avère ensuite qu'il n'avait pas été entièrement vérifié.

Où cela se voit

Les envois non sollicités se concentrent là où les secondes valent de l'argent.

Les pools de minage gardent des connexions directes entre eux et vers des réseaux de relais tels que FIBRE, conçus pour déplacer des blocs entre continents avec aussi peu de poignées de main que la physique le permet. Sur une machine ordinaire, l'appel getpeerinfo indique deux drapeaux par pair, bip152_hb_to et bip152_hb_from, qui montrent à quels pairs vous avez demandé de vous envoyer des blocs et lesquels vous ont demandé la même chose. En voir trois du premier type est normal, et trois est la limite.

Envoi de bloc non sollicité vs relais standard des blocs

Le relais standard des blocs et un envoi non sollicité diffèrent sur qui décide que des octets vont circuler. Avec le relais standard, c'est le récepteur qui demande, il maîtrise donc sa bande passante et peut refuser tout ce qu'il détient déjà. Avec un envoi, c'est l'expéditeur qui décide, ce qui économise un aller-retour mais donne à un tiers un levier sur vos ressources. La réponse de Bitcoin n'est pas de choisir : autoriser l'envoi, le plafonner à trois pairs que vous avez choisis vous-même, vérifier la preuve de travail avant d'engager le moindre coût, et valider le bloc en entier quelle que soit la politesse avec laquelle il est arrivé.