ActualitésCryptoLes développeurs de Bitcoin Core envisagent d'abandonner la prise en charge de CJDNS après qu'une vérification du seeder n'a révélé que sept nœuds sains

Les développeurs de Bitcoin Core envisagent d'abandonner la prise en charge de CJDNS après qu'une vérification du seeder n'a révélé que sept nœuds sains

Auteur: Coindoo·

Points clés

  • Une discussion sur GitHub a conduit les développeurs de Bitcoin Core à réévaluer si la prise en charge native de CJDNS a encore sa place dans le client.
  • Un test de 25 adresses CJDNS connues a relevé 22 poignées de main avec réponse, mais seulement sept pairs remplissaient les critères de propagation fiable des blocs et des transactions.
  • Les développeurs ont averti qu'un nœud fonctionnant uniquement via CJDNS avec un pool de pairs aussi réduit est plus exposé aux attaques par éclipse, où un attaquant peut isoler le nœud et fausser sa vision du réseau.
  • Les partisans du maintien de CJDNS estiment que sa faible utilisation pourrait refléter une intégration et une notoriété limitées, et qu'il pourrait encore servir de solution de secours si Tor ou I2P faisaient face à des blocages ou des pannes.
  • La suppression de CJDNS ne modifierait pas les règles de consensus de Bitcoin et n'empêcherait pas les opérateurs d'utiliser CJDNS de manière externe, mais elle mettrait fin à la gestion interne de ces connexions par Bitcoin Core.
Les développeurs de Bitcoin Core envisagent d'abandonner la prise en charge de CJDNS après qu'une vérification du seeder n'a révélé que sept nœuds sains

Aucun code n'a été supprimé et aucune décision finale n'a été prise, mais des indicateurs d'adoption durablement faibles ont conduit les contributeurs de Bitcoin Core à réexaminer les compromis pratiques de sécurité et d'ingénierie liés au maintien de réseaux superposés hérités au sein du client Bitcoin principal — un débat désormais centré sur la question de savoir si le réseau de routage chiffré CJDNS justifie encore sa place dans l'implémentation de référence.

Sept nœuds « bons » déclenchent un audit plus large de l'infrastructure

La discussion technique a commencé dans un ticket GitHub ouvert, où des développeurs se sont interrogés sur la pertinence pour Bitcoin Core de continuer à prendre en charge une couche de routage chiffrée qui ne présente presque aucun trafic réel documenté. L'objectif fondamental de l'ajout de couches de transport réseau alternatives à Bitcoin est la redondance : empêcher tout point unique de défaillance ou de censure au niveau du réseau. Cependant, les itinéraires redondants ne fonctionnent que si un maillage actif de pairs participe au réseau sous-jacent.

Lors de tests automatisés d'une configuration de nœud fonctionnant uniquement via CJDNS, le développeur de Core Marco Falke a signalé que son instance n'était pas parvenue à établir des connexions avec plus de trois ou quatre pairs distincts à un moment donné. Dans la continuité de cette observation, un autre contributeur a interrogé une base de données de seeders établie — les services d'amorçage qui fournissent aux nœuds fraîchement démarrés leurs premières adresses de pairs — contenant 25 adresses CJDNS connues. Sur les 25 adresses testées, 22 ont répondu aux poignées de main de base, mais seules sept remplissaient les critères techniques requis pour être classées comme pairs « bons » fiables pour la propagation active des blocs et des transactions.

Une seule requête de seeder ne représente pas un recensement absolu de tous les nœuds en fonctionnement dans l'ensemble de l'écosystème CJDNS ; des nœuds privés non annoncés et des pairs non indexés peuvent encore exister en dehors des listes publiques de seeders. Néanmoins, ces chiffres soulignent une réalité pratique sérieuse : un réseau superposé comptant moins d'une douzaine de cibles de routage accessibles ne parvient pas à fournir la redondance opérationnelle requise d'un nœud de production résilient. À titre de comparaison, des explorations publiques menées sur la durée ont dénombré les nœuds Bitcoin joignables annoncés via Tor en quelques milliers, contre les 25 adresses détenues par le seeder CJDNS.

Comprendre CJDNS : routage IPv6 chiffré contre règles de consensus

CJDNS est un réseau superposé maillé IPv6 chiffré qui utilise la cryptographie à clé publique pour l'allocation d'adresses et le routage distribué. En dehors de Bitcoin, le protocole est surtout connu comme couche de routage de Hyperboria, un réseau maillé communautaire géré par des bénévoles. Bitcoin Core a ajouté la prise en charge native de CJDNS dans la version 23.0 en 2022, permettant aux opérateurs de nœuds d'acheminer le trafic des pairs via CJDNS aux côtés d'IPv4, IPv6, Tor et I2P.

Selon la documentation de Bitcoin Core, CJDNS chiffre le trafic de bout en bout et peut rendre l'analyse et le filtrage du trafic plus difficiles. Ce n'est toutefois pas un réseau d'anonymat au même sens que Tor : les routeurs CJDNS intermédiaires peuvent toujours voir les adresses cryptographiques source et destination des paquets qu'ils transfèrent.

La proposition ne concerne que la manière dont Bitcoin Core trouve et se connecte aux pairs. La suppression de la prise en charge de CJDNS ne modifierait ni la validation des blocs, ni le minage, ni les règles de script, ni les formats de transaction ; les nœuds continueraient d'appliquer les mêmes règles de consensus Bitcoin.

La mécanique de sécurité d'une attaque par éclipse

Dans la sécurité des nœuds Bitcoin, le transport réseau et la sélection des pairs sont directement liés à l'intégrité des données. Le chiffrement masque le contenu des paquets aux tiers, mais il ne protège pas un nœud contre la réception d'informations fausses ou retardées si sa sélection de pairs est trop restreinte. Des pools de pairs clairsemés compromettent la sécurité en rendant nettement plus facile pour des acteurs malveillants l'isolement et la manipulation des nœuds fonctionnant uniquement via CJDNS.

La principale menace pesant sur les nœuds isolés est l'attaque par éclipse. Dans une attaque par éclipse, un adversaire compromet ou contrôle l'ensemble des connexions de pairs établies par un nœud cible. En cernant complètement le nœud cible, l'attaquant le partitionne effectivement du réseau Bitcoin mondial légitime. Depuis cette position, l'attaquant peut manipuler la vision de la blockchain de la victime en retardant les annonces de blocs, en censurant certaines transactions entrantes ou en tentant des attaques de double dépense contre des transactions non confirmées.

Avec un routage IPv4, IPv6 ou Tor standard, Bitcoin Core atténue les attaques par éclipse en établissant plusieurs connexions indépendantes sur des netgroups et des plages réseau divers ; par défaut, le logiciel maintient huit connexions sortantes de relais complet ouvertes simultanément. Lorsqu'un nœud fonctionne exclusivement sur un réseau ne comptant que sept pairs fiables — soit moins que ces emplacements sortants par défaut — le pool total de connexions disponibles est bien trop restreint : un attaquant n'a besoin que de très peu de ressources pour monopoliser toutes les connexions entrantes et sortantes d'un nœud fonctionnant uniquement via CJDNS, transformant une solution de repli sécuritaire prévue en un point de défaillance unique significatif.

Complexité du code et plaidoyer en faveur de la dépréciation

Outre les faibles chiffres d'adoption et les préoccupations de sécurité, les développeurs préconisant la suppression soulignent la charge de maintenance continue que le code CJDNS impose à l'ensemble du dépôt logiciel de Bitcoin Core.

Contrairement aux gestionnaires de protocole standard, l'intégration CJDNS n'est pas complètement isolée de la logique de connexion IPv6 standard. Comme CJDNS utilise des adresses IPv6 spécialement formatées, la base de code nécessite une logique de traitement personnalisée, des arguments de lancement dédiés comme -cjdnsreachable, ainsi que des solutions de contournement spécialisées pour les cas limites. Au fil du temps, les développeurs ont constaté que ces chemins logiques personnalisés introduisent des risques de bugs et compliquent les refactorisations courantes de la pile réseau. La couche de transport fait par ailleurs l'objet d'un développement actif, le transport chiffré v2 BIP 324 ayant été livré en option dans la version 26.0 et activé par défaut dans la version 27.0 — du nouveau code de connexion qui arrive pendant que des chemins hérités comme CJDNS sont réévalués.

Plusieurs contributeurs de Core ont formulé un « Concept ACK » en faveur de la dépréciation du protocole. Dans la terminologie du développement open source de Bitcoin Core, un « Concept ACK » indique qu'un contributeur souscrit à l'objectif général d'une proposition ; cela ne constitue ni un vote final, ni une fusion de code, ni un engagement immédiat à supprimer la fonctionnalité.

L'argument des réserves d'urgence à long terme

De l'autre côté du débat, les développeurs appelant à la prudence estiment que l'utilité d'un nœud ne devrait pas être jugée exclusivement sur la base des métriques de trafic actuelles. Le contributeur Jon Atack a fait remarquer que la découverte automatisée de pairs CJDNS n'a été intégrée à Core qu'au début de 2025. Avant cette mise à jour, les opérateurs de nœuds devaient configurer manuellement les adresses des pairs — un processus qui créait une barrière à l'entrée significative par rapport aux configurations en un clic disponibles pour Tor ou I2P.

Les partisans du maintien soutiennent que les faibles chiffres d'utilisation de CJDNS découlent d'un manque de notoriété auprès des utilisateurs et d'une intégration limitée dans les distributions logicielles de nœuds clés en main populaires, plutôt que d'un manque de valeur sous-jacente. Si des réseaux d'anonymisation publics majeurs comme Tor ou I2P devaient subir un blocage centralisé, des pannes d'infrastructure ou un filtrage de niveau étatique, des protocoles maillés alternatifs comme CJDNS pourraient fournir un canal de secours vital pour maintenir les connexions entre pairs.

Atack s'est également porté volontaire pour maintenir personnellement le code d'intégration CJDNS, répondant aux préoccupations concernant la charge de travail des développeurs. Les contributeurs de Core doivent maintenant décider s'ils préservent un itinéraire de transport alternatif pour les urgences exceptionnelles ou s'ils allègent la base de code en supprimant la logique réseau peu utilisée.

Ce qu'une éventuelle suppression signifie pour les opérateurs de nœuds

Si Bitcoin Core finit par supprimer l'intégration native de CJDNS dans une version future, le logiciel cessera simplement de gérer les connexions de pairs CJDNS en interne au niveau de la couche applicative. Ce changement n'empêcherait pas les opérateurs d'exécuter CJDNS de manière externe au niveau du système d'exploitation, et ne modifierait pas la manière dont le réseau Bitcoin dans son ensemble traite les transactions.

Les suppressions dans Bitcoin Core suivent généralement un processus lent et documenté — la dépréciation est signalée dans les notes de version et le code n'est retiré que lors d'une version majeure ultérieure, au rythme de publication d'environ six mois du projet — les points à surveiller sont donc le fil de discussion GitHub, toute pull request formelle de dépréciation, et l'éventuel effet de la découverte automatisée de pairs ajoutée en 2025 sur les chiffres d'adoption avant que les mainteneurs ne décident.

Pour la grande majorité des opérateurs de nœuds qui s'appuient sur des connexions IPv4, IPv6, Tor ou I2P standard, la suppression de CJDNS passerait totalement inaperçue. La discussion en cours reflète la philosophie d'ingénierie rigoureuse de Bitcoin Core : chaque ligne de code doit justifier son existence par une sécurité prouvée et une utilité active.

Cet article est fourni à titre d'information uniquement et ne constitue pas un conseil en investissement.

Source : Coindoo