Inventaire

Annoncer d'abord, livrer sur demande. C'est ce schéma qui évite que le réseau ne se noie dans les doublons : chaque entrée coûte 36 octets, soit une étiquette de type de quatre octets plus un hash de 32 octets, et un seul message inv peut en transporter jusqu'à 50 000. Un pair qui détient déjà l'objet ne le demande jamais, et la bande passante n'est jamais dépensée.

Comment cela fonctionne

Une entrée d'inventaire est une paire : un nombre indiquant de quel type d'objet il s'agit, et le hash qui l'identifie.

Les codes de type sont de petits entiers. 1 désigne une transaction, 2 un bloc, 3 un bloc filtré de l'ancien système de filtres bloom, 4 un bloc compact, 5 une transaction identifiée par son hash witness. Activer le bit 0x40000000 en plus d'un type marque la variante porteuse de witness, si bien qu'un pair compatible segwit demande MSG_WITNESS_BLOCK là où un pair plus ancien aurait demandé un bloc ordinaire.

L'échange se déroule en trois étapes. Un nœud envoie inv en listant ce qui est nouveau. Le pair parcourt la liste, ignore tout ce qu'il reconnaît et répond avec getdata en ne nommant que ce qui lui manque. Le nœud envoie ces objets, un message chacun, ou notfound lorsque quelque chose a été entre-temps écarté. L'arithmétique derrière le plafond de 50 000 mérite d'être remarquée : 50 000 entrées à 36 octets font 1 800 000 octets, largement sous le plafond de 4 000 000 octets d'un seul message, et Bitcoin Core porte une assertion à la compilation qui maintient ces deux constantes cohérentes entre elles.

Le minutage est un contrôle de confidentialité plutôt qu'un détail d'implémentation. Bitcoin Core n'annonce pas une transaction à l'instant où il en prend connaissance. Les annonces sont regroupées et diffusées selon une minuterie aléatoire d'en moyenne deux secondes vers les pairs sortants et cinq vers les pairs entrants, afin qu'un observateur connecté à de nombreux nœuds ne puisse pas utiliser l'ordre d'arrivée pour déterminer où un paiement a commencé. Les blocs sautent complètement le délai, car il n'y a rien à cacher et que les secondes coûtent de l'argent.

Crier chaque hash à chaque pair coûte cher, et Erlay est le remède proposé : les pairs réconcilient périodiquement de brefs résumés de ce que chacun détient au lieu d'inonder toutes les directions d'identifiants.

Où vous le voyez

Les inventaires sont ce qu'il y a de plus bruyant sur l'interface réseau d'un nœud et de plus facile à observer.

L'appel getpeerinfo ventile le trafic par type de message, et inv figure presque toujours parmi les compteurs les plus élevés. Un nœud bien connecté consacre une part réelle de sa bande passante à annoncer des hash dont personne n'a finalement eu besoin. C'est aussi pourquoi un paiement apparaît sur un explorateur de blocs quelques secondes avant un autre : ce sont des observateurs distincts qui entendent des annonces distinctes venues de différentes parties du réseau.

Une habitude à désapprendre : un inv n'est pas un engagement. Un nœud peut annoncer une transaction puis l'expulser quelques minutes plus tard quand sa mempool se remplit, et il ne doit de correction à personne.

Inventaire vs mempool

Un inventaire est un message ; une mempool est un stock, et un seul des deux survit à l'instant. L'inv indique à un pair qu'un hash existe quelque part. La mempool est l'ensemble des transactions non confirmées qu'un nœud a réellement validées, garde en mémoire et est disposé à relayer ou à miner, dimensionnée à 300 Mo par défaut avec une politique d'expulsion qui écarte d'abord les moins chères. Observer la propagation de votre txid à travers les annonces inv vous dit que le réseau a entendu parler de votre paiement. Cela ne vous dit pas que quelqu'un le détient encore une heure plus tard.