Eclipse est un isolement réseau, pas un contournement des règles de consensus. Un Full Node rejette toujours les données invalides, mais peut être retardé, censuré ou maintenu sur une ancienne branche valide.
L’attaquant doit capturer les chemins réseau pertinents de la victime, pas seulement établir une connexion. Un lien fonctionnel avec un pair honnête peut perturber son contrôle total. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
L’étude de Heilman et ses coauteurs de 2015 examinait le remplissage des tables d’adresses et la capture de la reconnexion. Le résultat dépend des ressources et de l’implémentation ; une expérience historique ne teste pas la version actuelle. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Core v29.0 — addrman]
L’attaquant choisit quels blocs et transactions entrent ou sortent. Il peut retenir des messages et observer l’origine des transactions, même sans majorité de calcul. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
Un Full Node vérifie toujours signatures, scripts et émission. L’isolement ne rend pas valide un bloc invalide, mais la validation ne révèle pas un bloc valide qui n’arrive jamais. [Bitcoin Developer Guide — Block Chain]
Sans nouveaux blocs honnêtes, le nœud peut rester à une ancienne pointe ; un mineur isolé peut gaspiller du travail sur une branche abandonnée ailleurs. Disponibilité et actualité diffèrent de validité. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
Un destinataire peut voir des confirmations sur une branche valide de l’attaquant, puis sa réorganisation au retour de la connexion. Cette branche exige encore Proof of Work ; inventer un nombre de confirmations ne trompe pas à lui seul un Full Node. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Developer Guide — Block Chain] [Bitcoin Optech — Eclipse attacks]
Le regroupement des adresses et la diversité des chemins sortants réduisent la concentration. Des adresses distinctes peuvent appartenir au même adversaire ; diversité ne garantit pas indépendance. [Bitcoin Core v29.0 — addrman] [Bitcoin Core v29.0 — Peer connections]
Bitcoin Core utilise des connexions d’essai feeler et des connexions supplémentaires de relais de blocs pour chercher d’autres chemins. Les premières testent des adresses, les secondes peuvent apporter des en-têtes ; aucune ne garantit seule la fin de l’isolement. [Bitcoin Core v29.0 — Peer connections]
Un pair connu configuré manuellement peut ajouter un chemin, mais demande confiance dans sa disponibilité et sa connectivité. Plus de connexions chez un fournisseur unique ne signifie pas forcément des chemins indépendants. [Bitcoin Developer Guide — P2P Network] [Bitcoin Optech — Eclipse attacks]
Eclipse vise un nœud ou un groupe choisi ; une partition plus large sépare des régions entières du réseau. La défense examine les chemins et le modèle adverse, pas seulement le nombre de connexions ouvertes. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
Pour une vision complète, lisez aussi Sybil attack, Block propagation, Compact block relay, Nakamoto consensus. Cette entrée est également citée par Double dépense, Sybil attack, Neutrino.