Glossaire / Nœuds et logiciels
Message P2P
Aussi appelé Message réseau.
- Qu'est-ce que Message P2P ?
- Les messages P2P sont le vocabulaire fixe que les nœuds bitcoin utilisent pour se parler : de courtes commandes comme version, inv, getdata, tx et block, envoyées sur une connexion TCP en clair.
Aucun serveur central n'existe à appeler, donc toute la relation d'un nœud avec le réseau tient dans cette conversation. Bitcoin Core annonce la version de protocole 70016, ouvre ses connexions sur le port 8333, et tout le vocabulaire tient sur une page. Votre retrait atteint un mineur parce qu'une machine a dit tx à une autre, transmis quelques milliers de fois en quelques secondes.
Comment cela fonctionne
Chaque connexion s'ouvre par une poignée de main, puis se stabilise en un petit ensemble d'échanges récurrents.
La première chose que chaque partie envoie est version, qui porte le numéro de protocole qu'elle parle, ses indicateurs de service, l'heure courante, l'adresse qu'elle croit être celle de l'autre extrémité, un nonce aléatoire servant à détecter qu'elle s'appelle elle-même par accident, une chaîne d'agent utilisateur et la hauteur de la meilleure chaîne qu'elle connaît. Chaque partie répond verack. Tant que les deux ne l'ont pas fait, rien d'autre n'est traité.
Ce numéro de protocole est une échelle de fonctionnalités plutôt qu'un ornement. L'annonce directe d'en-têtes exige 70012, la négociation de blocs compacts exige 70014, l'annonce d'un bloc compact avant validation complète exige 70015, et la retransmission des transactions par identifiant de témoin exige 70016. Un nœud lit le numéro de son pair et s'abstient discrètement de proposer des capacités que ce pair ne peut pas utiliser, ce qui permet au réseau de se mettre à niveau sans bascule coordonnée.
Groupé par usage, le vocabulaire est court. Trouver des pairs : getaddr, addr et la forme addrv2 issue du BIP155, qui peut transporter des adresses Tor et I2P. Annoncer : inv et headers. Demander : getheaders, getdata, getblocks, mempool. Livrer : tx, block, cmpctblock, blocktxn, notfound. Entretien : ping, pong, sendheaders, sendcmpct, wtxidrelay et feefilter, ce dernier indiquant à un pair de ne pas prendre la peine de retransmettre les transactions sous un taux de frais donné.
Deux silences sont délibérés. Les commandes non reconnues sont ignorées plutôt que rejetées, ce qui permet à un nouveau type de message de se déployer progressivement sur un réseau que personne ne peut mettre à jour d'un coup. Et un pair n'a aucun moyen de vous dire pourquoi il a abandonné votre transaction : le message reject issu du BIP61 a été désactivé par défaut dans Bitcoin Core 0.18.0 et l'option a été supprimée entièrement dans 0.20.0, parce que les réponses étaient peu fiables, faciles à falsifier et couramment prises à tort pour des réponses faisant autorité.
Où le voir
Les messages P2P sont ce que votre propre nœud fait toute la journée, et ils sont faciles à observer.
Lancez Bitcoin Core avec -debug=net et le journal nomme chaque message à son arrivée. L'appel getpeerinfo indique, pour chaque connexion, les octets envoyés et reçus ventilés par type de message, ce qui est le moyen le plus rapide de découvrir qu'un pair vous fournit presque tout pendant que les autres restent inactifs. Diffuser un paiement depuis un portefeuille pointé vers votre propre nœud produit une petite séquence reconnaissable : un inv qui part, un getdata qui revient, un tx qui part en réponse.
Message P2P vs RPC
Bitcoin a deux interfaces et elles ne sont pas interchangeables. Le P2P est de nœud à nœud : sans authentification, sans chiffrement sauf si les deux extrémités négocient le transport v2, sur le port 8333, avec un vocabulaire qu'aucun participant isolé ne peut étendre. Le RPC est de programme à nœud : authentifié, local par défaut, sur le port 8332, avec une liste de méthodes qui change à chaque version. Un paiement que vous créez passe par les deux, entrant dans votre nœud comme appel RPC et en sortant comme message P2P, et seule la seconde moitié regarde qui que ce soit d'autre.