Vous installez Bitcoin Core sur un ordinateur portable et le lancez pour la première fois. Le carnet d’adresses est vide. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il n’y a aucun compte à ouvrir, aucun serveur d’entreprise à appeler. Le programme connaît sept noms d’hôte inscrits dans son code source, chacun entretenu par un contributeur identifié, et, à partir d’eux, il établit 10 connexions sortantes avec des machines qu’il a choisies lui-même : 8 qui relaient tout et 2 qui ne relaient que les blocs. Personne ne les lui a attribuées. C’est un réseau pair à pair de blockchain au travail, et la suite de cette leçon suit les trois questions que se pose un nœud tout neuf : comment trouver des inconnus, comment une nouvelle traverse des milliers de machines qui ne se font pas confiance, et que peut faire un attaquant de cette route.
La leçon précédente expliquait ce qu’est un nœud et ce qu’il stocke. Ici, le nœud est acquis, et la chaîne qu’il conserve aussi (le fonctionnement d’une blockchain et le contenu d’un bloc ont chacun leur leçon). On reste ici sur les fils qui relient les nœuds entre eux.
Ce que le réseau pair à pair d’une blockchain remplace
Dans un système client-serveur, votre application bancaire parle à la banque. Le serveur détient les données, décide qui entre et peut être éteint par celui qui l’exploite. Dans un système pair à pair, chaque machine demande et répond. Aucune adresse n’est privilégiée : il n’y a donc pas de porte unique où frapper, ni d’opérateur unique à mettre hors ligne ou à sommer d’obéir.
Deux systèmes plus anciens montrent pourquoi les détails comptent. Napster faisait circuler les fichiers musicaux directement entre utilisateurs mais, comme l’a décrit la cour d’appel fédérale du neuvième circuit en février 2001, un logiciel sur ses propres serveurs tenait l’index de recherche de qui possédait quoi, et ces serveurs communiquaient l’adresse internet de l’hôte. Cette pièce centrale le rendait facile à arrêter : une décision ultérieure relève que Napster a désactivé les transferts de fichiers et que le tribunal de première instance a ordonné de les laisser coupés jusqu’à ce qu’il soit satisfait. BitTorrent est allé plus loin. Ses trackers restaient centraux ; la spécification BEP 5, d’Andrew Loewenstern et Arvid Norberg, a donc fait de chaque participant un petit tracker grâce à une table de hachage distribuée de type Kademlia : identifiants de 160 bits, distance XOR, compartiments de 8 nœuds et quatre types de requêtes.
Le livre blanc de Bitcoin fixait une tâche plus dure que l’une ou l’autre : une « version purement pair à pair de la monnaie électronique » (formule traduite de l’anglais). Partager un morceau de musique tolère un pair malhonnête, car le pire qui puisse arriver est un mauvais fichier. Se mettre d’accord sur qui possède quoi, non. C’est pourquoi un nœud vérifie tout ce qu’il reçoit, et pourquoi la conception décrite dans le livre blanc demande si peu au réseau lui-même. Sa section 5 dit, en substance, que les diffusions de nouvelles transactions n’ont pas forcément besoin d’atteindre tous les nœuds. Les messages peuvent arriver en retard, se perdre ou être envoyés par des menteurs, et le système doit tenir quand même.
Une précision sur le mot « ouvert » : cette leçon porte sur les chaînes publiques, où chacun peut entrer. Les blockchains privées ont une liste de membres agréés et évitent la plupart des problèmes ci-dessous, en réintroduisant un opérateur.
Trouver le premier pair quand personne ne vous donne de liste
Bitcoin : sept noms DNS, une liste fixe et un carnet d’adresses local
Un nouveau nœud Bitcoin Core commence par le DNS. D’après son code source actuel, il connaît sept « seeds » (graines), comme seed.bitcoin.sprovoost.nl et dnsseed.emzy.de. Il en interroge trois à la fois, après une attente de 11 secondes quand il connaît moins de 1 000 adresses, et chaque réponse n’est qu’une liste d’adresses de nœuds. Si le DNS ne donne rien, le programme se rabat, au bout d’environ une minute, sur une liste d’adresses fixes compilée dans la version.
Le démarrage n’est donc pas entièrement sans confiance, et le projet le dit dans ses règles. L’opérateur d’une graine doit suivre une politique écrite : les résultats doivent être constitués « exclusivement de nœuds Bitcoin choisis équitablement et en état de marche » (traduction). Une graine malhonnête pourrait quand même remettre à un nouvel arrivant une liste empoisonnée, d’où l’intérêt d’en interroger plusieurs, tenues par des personnes différentes. Après le premier lancement, les graines comptent peu. Le nœud tient son propre carnet d’adresses, appelé addrman, et apprend de nouvelles adresses auprès de ses pairs par des messages addr, dans la limite de 1 000 par message et à un rythme plafonné à 0,1 adresse par seconde et par pair.
Le carnet comprend deux tables. La table « new » contient les adresses entendues de tiers : 1 024 compartiments de 64 entrées, soit 65 536 places. La table « tried » contient les adresses que le nœud a réellement jointes : 256 compartiments de 64, soit 16 384 places. Environ toutes les 2 minutes en moyenne, une connexion éphémère de test, dite « feeler », vérifie une adresse non confirmée et la fait passer dans l’autre table si elle répond. Un nœud à l’écoute annonce aussi sa propre adresse environ une fois toutes les 24 heures, pour continuer d’être redécouvert.
Ethereum : nœuds d’amorçage, table distribuée et fiches signées
Les clients Ethereum embarquent quelques nœuds d’amorçage (bootnodes) codés en dur, utilisés seulement pour présenter un nouvel arrivant. La page de réseau d’ethereum.org (en anglais) décrit deux couches depuis la fusion (The Merge), chacune avec son réseau. Les clients d’exécution font leur découverte en UDP, aujourd’hui avec Discv4, une table de type Kademlia, tandis qu’un passage à Discv5 est en cours, et ils dialoguent par devp2p (RLPx) en TCP. Les clients de consensus utilisent Discv5 avec libp2p. Discv5 est, selon sa propre spécification, « vaguement inspiré de la table Kademlia » (traduction). Il stocke des Ethereum Node Records : de petites fiches signées avec une identité, un numéro de séquence qui augmente à chaque changement et des données clé-valeur, comme le réseau du client et les sous-réseaux qu’il suit.
La différence avec Bitcoin tient à la méthode. Le carnet d’adresses de Bitcoin est un tas de rumeurs, filtré par l’essai. La découverte d’Ethereum est une recherche structurée : un nœud demande des pairs de plus en plus proches d’un identifiant cible, puis filtre selon ce que dit la fiche.
Solana : points d’entrée et calendrier publié
Solana a moins besoin de découverte que les autres, sur un point. Un validateur Agave démarre avec une ou plusieurs adresses d’entrée (entrypoints) et remplit à partir de là une table de gossip, et l’ordre des producteurs de blocs est calculé à l’avance : les nœuds mettent à jour leur calendrier des leaders à chaque frontière d’époque, environ tous les deux jours, selon une analyse de Helius (en anglais). Une machine qui sait qui produit les prochains blocs sait où envoyer ses messages, et cela façonne toute la section sur la diffusion plus bas.
| Réseau | Premier contact | Découverte continue | Transport |
|---|---|---|---|
| Bitcoin | 7 graines DNS, puis adresses fixes | Diffusion d’adresses (addr), tables locales | TCP, port 8333 ; v2 chiffré (BIP 324) ; Tor, I2P, CJDNS |
| Ethereum, couche d’exécution | Nœuds d’amorçage codés en dur | Discv4 en UDP, migration vers Discv5 | devp2p (RLPx) en TCP |
| Ethereum, couche de consensus | Nœuds d’amorçage | Discv5 en UDP | libp2p : QUIC d’abord, TCP aussi |
| Solana | Adresses d’entrée données au démarrage | Table de gossip, plus un calendrier des leaders publié | QUIC vers les leaders ; shreds via Turbine |
Combien de voisins garde un nœud, et lesquels
Le nombre de pairs ressemble à de l’intendance. C’est une décision de sécurité. Les connexions sortantes, celles que votre nœud a choisies, sont les plus précieuses, car un attaquant ne peut pas simplement les prendre en composant votre numéro. Bitcoin Core les garde peu nombreuses et stables : 8 en relais complet et 2 en relais de blocs seulement, plus un feeler de temps à autre, et un pair supplémentaire de type blocs seulement essayé environ toutes les 5 minutes en moyenne. Les places sortantes sont remplies depuis des groupes de réseaux différents, afin qu’une petite plage d’adresses IP ne puisse pas toutes les occuper.
Le chiffre le plus visible a changé il y a quelques jours. La limite totale par défaut était de 125 depuis des années, et beaucoup de guides plus anciens l’indiquent encore. Bitcoin Core 32.1, publié le 28 octobre 2026, écrit dans ses notes de version que la valeur par défaut est passée de 125 à 200 (« has increased from 125 to 200 »). Le tag 32.0 n’a jamais été publié complètement : la 32.1 est donc la première version publique à porter ce changement. La place gagnée sert à accueillir des pairs entrants de type blocs seulement, les pairs qui relaient des transactions peuvent occuper au plus 50 % des places entrantes, et les connexions sortantes automatiques restent ce qu’elles étaient. Dans l’instantané de Bitnodes du 2 novembre 2026, 9 h 01 UTC, d’après un décompte des user agents, 3 071 des 18 526 nœuds joignables annonçaient la version 32 et les autres un logiciel plus ancien ou un autre client : les deux limites sont donc en vigueur sur le réseau.
| Client (au 2 novembre 2026) | Valeur par défaut | Remarque |
|---|---|---|
| Bitcoin Core 32.1 | 200 connexions ; 8 sortantes en relais complet et 2 en blocs seulement | 125 jusqu’à la version 31 ; les valeurs au-delà de 2 000 sont ramenées à ce plafond |
| Geth 1.17.10 | MaxPeers 50 | Ratio de numérotation de 3 : environ un tiers des pairs sont sortants |
| Lighthouse 8.3.2 (client de consensus) | Cible de 200 pairs | Valeur par défaut du client, pas une règle du protocole |
Ce sont des valeurs par défaut dans des logiciels. Aucun protocole ne les impose, et un opérateur peut les modifier.
La diffusion : comment un bloc traverse le réseau
Bitcoin : annoncer, demander, livrer
Le schéma de base tient en trois messages. Un nœud qui a du nouveau envoie inv, un inventaire de hachages. Un pair à qui il en manque un répond getdata. Le premier nœud envoie alors les données. Annoncer un hachage avant d’envoyer les octets évite que le réseau transporte la même transaction de nombreuses fois sur chaque lien. Le prix à payer est un aller-retour par saut, et en 2013, Decker et Wattenhofer (en anglais) ont constaté que cet aller-retour dominait le délai des transactions, dont 96 % pesaient alors moins de 1 ko.
Les annonces de transactions sont aussi retardées volontairement. Dans le code actuel, un nœud les regroupe avec des délais aléatoires de 2 secondes en moyenne vers les pairs sortants et de 5 secondes vers les pairs entrants. Ce délai coûte du temps et achète de la discrétion : il brouille l’identité du pair qui a entendu la nouvelle en premier. La version 32.1 conserve la limite de relais par défaut de 14 transactions par seconde, majorée d’un facteur 2,5 pour les pairs sortants, et ajoute un plafond de 12 Mo par tranche de 10 minutes.
Les blocs ont reçu un traitement différent. Le BIP 152, celui des blocs compacts, s’appuie sur un fait : un pair a déjà vu la plupart des transactions d’un nouveau bloc, dans son mempool (une leçon ultérieure traitera du mempool). L’émetteur envoie donc une esquisse faite d’identifiants courts, et le récepteur reconstruit le bloc en ne réclamant que ce qui manque. La FAQ de Bitcoin Core de juin 2016 (en anglais) donnait 9 ko en moyenne pour reconstruire un bloc de 1 Mo. En mode haute bande passante, un nœud demande à quelques pairs (trois au plus, dans le code actuel) de lui pousser les nouveaux blocs sans attendre d’être sollicités.
Erlay tente de faire pour les transactions ce que les blocs compacts ont fait pour les blocs, en remplaçant la plupart des annonces individuelles par une comparaison périodique des ensembles de deux pairs. Un élément de 2025 listé sur la page thématique de Bitcoin Optech dit qu’il pourrait économiser 100 Mo par jour de bande passante pour un nœud, soit 20 % de la bande passante totale pour certains nœuds. Il n’est pas déployé. Le BIP 330 reste à l’état de brouillon. Dans la version 32.1, le code existe mais il est désactivé par défaut, derrière une option réservée au débogage. Une discussion ouverte en février 2026 demande s’il vaut la peine de continuer ; elle était toujours ouverte à sa dernière mise à jour, le 20 août 2026.
Ethereum : des hachages pour les transactions, gossipsub pour les blocs
Depuis la fusion, la propagation des blocs relève de la couche de consensus. Le réseau d’exécution échange surtout des transactions, avec une idée proche de celle de Bitcoin : NewPooledTransactionHashes annonce des hachages et les pairs récupèrent les corps de transaction qui leur manquent.
La couche de consensus utilise gossipsub sur libp2p, et la spécification en donne les chiffres. Chaque nœud entretient un maillage d’environ 8 pairs par sujet (entre 6 et 12) et envoie des métadonnées plus légères à 6 autres, sur un battement de 0,7 seconde. Les sujets répartissent le trafic par nature : beacon_block pour les blocs, beacon_aggregate_and_proof pour les votes agrégés, 64 sous-réseaux d’attestation pour les votes individuels et, depuis la bifurcation Fulu, 128 sous-réseaux pour les colonnes de données. Un nœud n’a pas besoin de tout entendre. C’est ainsi que la couche s’accommode d’un ensemble de validateurs trop grand pour que chacun écoute tous les autres.
Solana : un arbre plutôt qu’une foule
Solana abandonne le gossip pour les données de bloc. Son leader découpe le bloc en shreds et les envoie dans Turbine, un arbre reconstruit pour chaque shred par un brassage pondéré par la mise, de sorte que les validateurs les plus dotés tendent à se trouver plus près du sommet. Dans le code d’Agave, chaque nœud retransmet à 200 autres au plus, et un shred fait 4 sauts au maximum. Le codage à effacement compense les pertes : avec 32 shreds de données et 32 shreds de code, l’exemple de la documentation, qui suppose 15 % de perte de paquets, donne une réussite du bloc d’environ 0,99.
Turbine reste la conception actuelle. La page Alpenglow d’Anza, datée du 29 octobre 2026, indique que le nouveau consensus est en production sur le mainnet-beta, avec 10/21 comme jalon, et place Rotor, qui remplacerait l’arbre par un seul saut de relais, parmi ce qui vient ensuite. Elle ne donne aucune date pour Rotor.
Les transactions empruntent une autre route. Solana n’a pas de mempool public au sens de Bitcoin : les nœuds RPC envoient une transaction en QUIC directement au leader actuel et au suivant, connus grâce au calendrier. Le service d’envoi de transactions d’Agave transmet à 2 leaders par défaut et réessaie toutes les 2 secondes. Le nom de cette approche, tiré des billets des fondateurs de 2019, est Gulf Stream, bien que Helius n’en ait trouvé qu’une seule mention anodine dans le code : à lire comme l’étiquette d’un comportement.
Pourquoi la latence est un paramètre de sécurité
Ce qui a été mesuré
Des mesures de propagation existent, mais elles ne partagent pas une même définition. Le tableau les met côte à côte et ne doit pas se lire comme une série unique : les lignes Bitcoin chronomètrent le moment où les nœuds reçoivent un bloc, alors que la ligne d’ethPandaOps mesure la dispersion après que la première sentinelle l’a vu.
| Étude | Réseau | Médiane | Queue de distribution | Taux de fourches ou d’orphelins |
|---|---|---|---|---|
| Decker et Wattenhofer, 2013 | Bitcoin | 6,5 s (moyenne 12,6 s) | 5 % des nœuds attendent encore après 40 s | 1,69 % observé, 1,78 % modélisé |
| Fechner et coll., publié en 2022 | Bitcoin | 0,454 s (moyenne d’environ 4,1 s) | 5 % des nœuds au-delà de 15,8 s | 0,014 % à 0,127 % selon les quatre chaînes |
| ethPandaOps, du 25 avril au 2 mai 2026 | Ethereum | 104 ms (9 ko) à 348 ms (environ 238 ko) | p99 de 427 ms à 1 248 ms | Non mesuré |
| Chainbound, novembre 2025 | Ethereum | Non donnée | Validation du bloc au p99 égale ou supérieure à l’échéance de 4 s, selon le nombre de blobs | 584 blocs sur 216 000 créneaux, soit 0,27 % |
L’amélioration de Bitcoin est considérable. En 2013, le nœud médian attendait 6,5 secondes un bloc. Dans l’article de Fechner, Chandrasekaran et Makkes, « la majorité des pairs, dans les quatre blockchains, apprennent l’existence d’un bloc fraîchement miné en moins d’une seconde » (traduction). Leurs réserves : un seul observateur à Amsterdam, en IPv4 uniquement, qui voyait environ 27 % des nœuds Bitcoin joignables. Les blocs compacts sont arrivés entre les deux études, avec d’autres changements du logiciel.
Du retard au bloc orphelin
Le retard compte à cause de ce que font les mineurs pendant qu’ils attendent. Deux mineurs trouvent des blocs valides presque au même instant, chacun envoie le sien, et le réseau garde deux visions pendant un moment. Les nœuds continuent de travailler sur le premier reçu. Quand le bloc suivant tombe d’un côté, la chaîne qui porte le plus de preuve de travail l’emporte et les nœuds de l’autre côté se réorganisent. Le bloc perdant est dit obsolète : valide, mais plus rattaché à la chaîne, et la récompense du mineur disparaît avec lui. Ce sont les réorganisations dont parlent les articles, et c’est pourquoi une confirmation est une probabilité qui croît (pourquoi les vieux blocs deviennent difficiles à modifier va plus loin).
Decker et Wattenhofer voulaient vérifier si le délai de propagation est la cause principale des fourches. Leur modèle en prédisait 1,78 % et ils en ont observé 1,69 % sur 10 000 blocs à partir de la hauteur 180 000. Ils ont ensuite fait tourner un client modifié, servant de plaque tournante, connecté en moyenne à 3 048 nœuds, avec quelques changements de relais en prime. Entre les hauteurs 200 000 et 210 000, le taux de fourches est tombé à 0,78 %.
Ethereum montre la même cause sous d’autres règles. Ses attesteurs en preuve d’enjeu doivent voir un bloc avant une échéance fixée à 4 secondes après le début du créneau, si bien qu’un bloc tardif peut perdre ses votes. Chainbound a compté 584 blocs orphelins sur 216 000 créneaux en novembre 2025, et son billet (en anglais) montre une validation qui, dans la queue de distribution, atteint cette échéance. ethPandaOps, dans un rapport du 6 mai 2026 portant sur 50 318 blocs, concluait que l’échéance d’attestation de 4 secondes n’est menacée pour aucune tranche de taille présente aujourd’hui sur le mainnet (traduction). Les deux constats ne se contredisent pas : l’un regarde la validation avec des blobs, l’autre la dispersion après la première observation.
Les attaques qui visent le réseau, pas la chaîne
Les attaques sur le consensus font les gros titres, et peut-on pirater une blockchain les traite. Celles qui suivent visent autre chose : ce qu’un nœud parvient à entendre. Aucune ne peut obliger un nœud complet à accepter un bloc invalide, car il contrôle lui-même chaque règle.
Sybil : un acteur, mille visages
John Douceur l’a nommée dans un article de janvier 2002 : si une seule entité défaillante peut présenter plusieurs identités, elle peut contrôler une fraction substantielle du système (traduction). Il a aussi montré que, sans autorité centrale, de telles attaques restent possibles sauf hypothèses irréalistes. Les blockchains acceptent ce résultat et placent le coût là où il compte : le pouvoir de vote demande de la puissance de calcul ou une mise. La couche réseau n’a pas ce prix. Une identité de pair coûte une adresse IP ; compter les nœuds prouve donc peu de choses, et une majorité de nœuds ne signifie rien pour le consensus.
Éclipse : encercler un seul nœud
Une attaque par éclipse dirige toutes les connexions d’une victime vers l’attaquant. Heilman, Kendler, Zohar et Goldberg ont montré en 2015 qu’un adversaire disposant d’assez d’adresses IP pouvait monopoliser toutes les connexions entrantes et sortantes d’un nœud Bitcoin victime (traduction). Leurs chiffres, pour le logiciel de l’époque : un botnet de 4 600 machines pouvait éclipser une victime avec au moins 85 % de probabilité quelle que soit la taille du réseau, 32 blocs /24 distincts (8 192 adresses) pouvaient faire de même, et 400 machines suffisaient contre leurs propres nœuds en service. L’astuce consistait à remplir le carnet d’adresses d’adresses de l’attaquant, à attendre le redémarrage du nœud, puis à prendre toutes les places.
Que gagne l’attaquant ? La victime peut être privée de blocs, ou voir une version de la chaîne valide mais périmée. Un commerçant qui accepte des paiements non confirmés peut subir une double dépense, puisque sa transaction n’atteint jamais personne d’autre (une leçon ultérieure traitera de la double dépense). Si des mineurs éclipsés entrent dans le tableau, l’article décrit des courses de blocs, une puissance de minage fractionnée, un minage égoïste facilité et des doubles dépenses même après N confirmations.
Les auteurs ont prévenu les développeurs de Bitcoin Core en février 2015, et trois de leurs contre-mesures ont été livrées dans bitcoind 0.10.1, dont une multiplication par quatre du nombre de compartiments. Du code ultérieur en a ajouté d’autres : des pairs réservés aux blocs, qui en révèlent moins sur la topologie du nœud puisqu’ils ne relaient ni adresses ni transactions ; deux pairs d’ancrage enregistrés à l’arrêt et essayés en premier au redémarrage ; les feelers ; et le fichier facultatif -asmap, qui classe les pairs par opérateur de réseau plutôt que par plage d’adresses IP. Les chiffres de 2015 ne valent plus pour le logiciel actuel.
Détournement BGP et partition du réseau
Le routage d’internet repose sur la confiance entre opérateurs, au travers du protocole BGP (Border Gateway Protocol). Apostolaki, Zohar et Vanbever ont mesuré ce que cela signifiait pour Bitcoin dans un article de 2017. D’après les données du projet de 2015 et 2016, 13 fournisseurs d’accès hébergeaient 30 % du réseau, et 60 % de toutes les connexions possibles passaient par 3 fournisseurs. Ils ont calculé que le détournement de moins de 100 préfixes BGP pouvait isoler jusqu’à 47 % de la puissance de minage, c’est-à-dire une partition : deux camps qui minent chacun de leur côté jusqu’à ce que celui qui porte le moins de travail perde ses blocs à la reconnexion. Une attaque de retard plus subtile, menée par un attaquant placé sur le trajet du trafic, pourrait retenir un bloc loin d’une victime jusqu’à 20 minutes sans rompre la connexion.
L’article est prudent sur ce qui a été démontré. Les auteurs n’ont détourné que leurs propres nœuds sur le réseau réel, où tout le trafic a basculé vers la route de l’attaquant en 1,5 minute. Ils ont testé une coupure 50-50 sur un banc d’essai de 1 050 clients, pas sur Bitcoin lui-même, et les deux camps se sont vite reconnectés. Pour l’internet réel, ils ont examiné des données BGP d’octobre 2015 à mars 2016 : le trafic destiné à au moins 100 nœuds Bitcoin par mois était dévié, et à 447 nœuds (environ 7,8 % du réseau) en novembre 2015. C’est une exposition, pas la preuve d’une attaque contre Bitcoin. Une note de bas de page avertit que chaque détournement « a pu viser d’autres services dans la même plage d’adresses IP » (traduction).
Un cas voisin montre la même faiblesse autour de la chaîne. Le 24 avril 2018, eNET (AS10297) a annoncé des routes plus spécifiques pour les adresses Route 53 d’Amazon pendant près de deux heures, à partir d’environ 11 h 05 UTC. Le trafic est arrivé sur un serveur DNS malveillant à Chicago, et Cloudflare a rapporté que les utilisateurs de MyEtherWallet étaient envoyés vers une copie factice du site, qui présentait un certificat TLS signé par une autorité inconnue. Les victimes devaient passer outre cet avertissement avant que leurs identifiants soient volés. C’était du DNS plus du BGP contre une interface web, sans toucher à la couche pair à pair.
| Attaque | Source | Ressource | Effet | Parades |
|---|---|---|---|---|
| Sybil | Douceur, 2002 | De nombreuses identités | Part démesurée d’une vue du réseau | Votes coûteux (travail, mise) ; diversité des pairs |
| Éclipse | Heilman et coll., 2015 | 4 600 machines ou 32 blocs /24 (logiciel de 2015) | La victime ne voit que l’attaquant | Tables plus grandes, ancrages, feelers, pairs réservés aux blocs, asmap |
| Partition ou retard BGP | Apostolaki et coll., 2017 | Moins de 100 préfixes détournés | Réseau coupé ou retardé | Connexions diversifiées, trafic chiffré, propositions de relais comme SABRE |
| DNS et BGP contre une application | Internet Society, 2018 | Un réseau qui annonce de fausses routes | Utilisateurs envoyés vers un faux site | Filtrage des routes ; attention aux avertissements de certificat |
Ce que changent Tor, I2P et le chiffrement pour la vie privée
Un réseau pair à pair n’est pas anonyme par défaut. Un nœud sur l’internet ordinaire montre son adresse IP à chacun de ses pairs, et un pair qui observe les horaires peut deviner quel nœud a envoyé une transaction le premier. Les réponses de Bitcoin viennent par couches.
Le transport chiffré, le BIP 324, est activé par défaut depuis Bitcoin Core 27.0, en avril 2024. Il cache le contenu à un espion passif et oblige un attaquant à devenir actif. Son chiffrement n’est pas authentifié par conception : il ne prouve donc pas qui se trouve à l’autre bout.
Tor et I2P cachent l’adresse IP elle-même. L’instantané de Bitnodes du 2 novembre 2026 à 9 h 01 UTC liste 7 841 adresses onion et 4 624 adresses I2P, contre 5 453 en IPv4 et 601 en IPv6. Une adresse n’est pas une machine : un même opérateur peut se cacher derrière plusieurs d’entre elles. CJDNS en comptait 7, et les notes de la 32.1 disent que le projet envisage de l’abandonner.
Dandelion, la proposition de faire passer une transaction par un chemin privé avant de la diffuser, n’est jamais entrée dans Bitcoin Core. Le BIP 156 a le statut Closed (clos). Ce qui a été livré à la place, dans la version 31.0, est un mode facultatif -privatebroadcast pour sendrawtransaction : il envoie chaque transaction par Tor ou I2P, une connexion par transaction, de sorte que les destinataires n’apprennent pas l’origine et que deux transactions ne puissent pas être reliées. Il est désactivé par défaut, et la version 32.1 a corrigé une fuite possible de l’adresse de l’émetteur dans ce mode.
Lire l’état du réseau aujourd’hui
Cet instantané donnait 18 526 nœuds joignables au total, au bloc 974 233, et le chiffre demande des réserves. Il compte les machines qui acceptent des connexions entrantes. Les nœuds derrière une box domestique ou un pare-feu sont invisibles, et un même opérateur peut tenir plusieurs adresses. Bitnodes indique lui-même qu’il est en cours de reconstruction indépendante sous un nouvel opérateur, et son décompte est bruité : les huit instantanés jusqu’à 9 h 01 UTC allaient de 18 526 à 18 899. Ainsi, 18 526 n’est ni le nombre de nœuds ni le nombre de parties indépendantes. Chainbound citait environ 20 000 nœuds sur le mainnet d’Ethereum pour la fin de 2025.
L’hébergement est l’autre lecture. Dans l’étude de Fechner, Amazon hébergeait 7,7 % des nœuds Bitcoin observés, Google 3,78 %, Digital Ocean 3,3 % et OVH 2,24 %, et 5,17 % se trouvaient dans des réseaux d’opérateurs publics. Ces parts sont anciennes et couvrent une partie du réseau, et l’étude elle-même ne juge significative la part d’aucun fournisseur pour Bitcoin. Elles reposent pourtant sur le même internet dont la section sur BGP a décrit le routage.
Si vous faites tourner un nœud, vous pouvez inspecter votre propre coin du réseau. Deux commandes montrent les connexions par type et par réseau, et le transport utilisé par chaque pair.
bitcoin-cli -netinfo 4
bitcoin-cli getpeerinfoRepérez le nombre de connexions sortantes et les champs connection_type et transport_protocol_type. La leçon sur les nœuds donne les notes sur le matériel et la synchronisation. Trois points à surveiller : combien de nœuds passent à la valeur par défaut de 200 connexions, si la discussion sur Erlay aboutit à une décision, et quand Anza datera Rotor. Les notes de la 32.1 préviennent aussi que les anciennes configurations I2P perdront la prise en charge de l’ancien chiffrement ElGamal au plus tard à la version 34.
