Le gossip pair-à-pair

Curiosité

1. Comment un nouveau nœud dans un réseau vide trouve-t-il son premier pair ?
2. Comment un nouveau bloc parvient-il à atteindre des milliers de nœuds en quelques secondes, sans que personne ne le coordonne ?
3. Qu’est-ce qui empêche un attaquant d’isoler un nœud du reste du réseau ?

Explorer

1. Bitcoin fonctionne comme un réseau pair-à-pair décentralisé dans lequel chaque nœud complet tient un état indépendant. Pour le rejoindre, un nouveau nœud doit établir des connexions TCP avec des pairs existants. Le mainnet utilise le port 8333 pour ces connexions. La découverte initiale repose sur des seeds DNS, gérés par des membres de longue date de la communauté et répertoriés dans le logiciel, ainsi que sur des adresses de secours codées en dur. Une fois connecté, un nœud peut demander des adresses avec « getaddr » et les reçoit dans des messages « addr », ce qui lui permet de découvrir d’autres participants actifs et d’élargir dynamiquement son ensemble de pairs.
2. Bitcoin Core gère une topologie précise : 8 connexions sortantes en relais complet (full-relay) pour la propagation des transactions et des blocs, plus 2 connexions en relais de blocs uniquement (block-relay-only) afin de réduire la consommation de bande passante. Il autorise jusqu’à 125 connexions au total, entrantes et sortantes. Cette structure assure la redondance : si un pair se déconnecte ou ne répond plus, le nœud reste connecté grâce aux autres. Les connexions block-relay-only ne transportent ni transactions ni adresses, ce qui complique la tâche d’un observateur cherchant à cartographier la topologie du réseau.
3. La propagation des données suit un mécanisme d’annonce. Lorsqu’un nœud reçoit une nouvelle transaction, il l’annonce par un message « inv » (inventaire) contenant le hash mais pas les données ; les nouveaux blocs sont aujourd’hui généralement annoncés par l’envoi direct de l’en-tête ou d’un bloc compact. Les pairs qui reçoivent cette annonce constatent qu’ils ne possèdent pas l’objet et envoient une requête « getdata ». Le détenteur initial transmet alors les données complètes. Ce processus en deux étapes évite d’inonder le réseau de données volumineuses et redondantes avant que les pairs n’aient confirmé leur intérêt, ce qui assure une utilisation efficace de la bande passante dans l’ensemble du système distribué.
4. Les blocs compacts (BIP152), introduits en 2016, optimisent encore ce processus. Comme la plupart des transactions d’un bloc sont déjà connues des pairs grâce à la propagation via le mempool, envoyer le bloc complet est du gaspillage. Un nœud envoie plutôt l’en-tête du bloc ainsi que de courts identifiants (6 octets chacun) pour ses transactions, accompagnés de la transaction coinbase ; le récepteur reconstitue le bloc à partir de son propre mempool et ne demande que les quelques transactions qui lui manquent. Cela réduit considérablement la latence de propagation des blocs et permet au réseau d’atteindre le consensus plus rapidement, même avec de forts volumes de transactions.
5. Les attaques par éclipse montrent la fragilité de la diversité des pairs. Heilman et al. (2015) ont montré qu’un attaquant qui prend le contrôle de toutes les connexions d’un nœud peut l’isoler du réseau honnête et lui présenter une fausse vision de la chaîne. Bitcoin Core a adopté leurs contre-mesures dès la version 0.10.1, notamment les connexions de sondage (feeler connections) et une éviction plus prudente dans la table d’adresses, puis a ajouté des connexions d’ancrage (anchor connections) qui persistent après un redémarrage. Fonctionner uniquement via Tor peut rendre un nœud plus facile, et non plus difficile, à éclipser.
6. Vérifiez la connectivité de votre nœud en exécutant « bitcoin-cli getpeerinfo » dans un terminal connecté à une instance locale de Bitcoin Core. Le résultat indique, pour chaque pair, son adresse, son « connection_type » (par exemple outbound-full-relay ou block-relay-only), sa version logicielle et son niveau de synchronisation (« synced_headers », « synced_blocks »). Un nœud en bonne santé présente une dizaine de connexions sortantes : huit full-relay et deux block-relay-only.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Bitcoin Developer Guide, 'P2P Network' section
• Heilman et al., 'Eclipse Attacks on Bitcoin's Peer-to-Peer Network' (USENIX Security 2015)
• BIP152: Compact Block Relay