Eclipse es aislamiento de red, no una evasión de las reglas de consenso. Un Full Node sigue rechazando datos inválidos, pero puede sufrir retrasos, censura o permanecer en una rama válida antigua.
El atacante debe controlar las rutas relevantes de la víctima, no solo establecer una conexión. Una conexión funcional a un par honesto puede romper el control completo. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
El estudio de Heilman y sus coautores de 2015 examinó llenar tablas con direcciones atacantes y capturar la reconexión. El resultado depende de recursos e implementación; un experimento histórico no prueba la versión actual. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Core v29.0 — addrman]
El atacante elige qué bloques y transacciones entran o salen. Puede retener mensajes y observar el origen de transacciones aun sin mayoría de cómputo. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
Un Full Node sigue comprobando firmas, scripts y emisión. El aislamiento no valida un bloque inválido, pero la validación no revela un bloque válido que nunca llega. [Bitcoin Developer Guide — Block Chain]
Sin nuevos bloques honestos, el nodo puede quedarse en una punta antigua; un minero aislado puede malgastar trabajo en una rama abandonada por el resto. Disponibilidad y actualidad difieren de validez. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
Un receptor puede ver confirmaciones en una rama válida atacante y descubrir su reorganización al reconectarse. Esa rama aún requiere Proof of Work; inventar una cifra de confirmaciones no engaña por sí solo a un Full Node. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Developer Guide — Block Chain] [Bitcoin Optech — Eclipse attacks]
Agrupar direcciones y diversificar rutas salientes reduce concentración. Distintas direcciones pueden pertenecer al mismo adversario; diversidad no garantiza independencia. [Bitcoin Core v29.0 — addrman] [Bitcoin Core v29.0 — Peer connections]
Bitcoin Core utiliza conexiones de prueba feeler y conexiones adicionales de retransmisión de bloques para buscar rutas. Las primeras prueban direcciones, las segundas pueden aportar cabeceras; ninguna garantiza por sí sola terminar el aislamiento. [Bitcoin Core v29.0 — Peer connections]
Un par conocido configurado manualmente puede añadir una ruta, pero exige confianza en su disponibilidad y conectividad. Más conexiones mediante un solo proveedor no necesariamente son rutas independientes. [Bitcoin Developer Guide — P2P Network] [Bitcoin Optech — Eclipse attacks]
Eclipse apunta a un nodo o grupo elegido; una partición más amplia separa regiones enteras de la red. La defensa estudia rutas y modelo adversario, no solo cuántas conexiones están abiertas. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]
Para obtener la imagen más completa, lee esta entrada junto con Ataque Sybil, Propagación de bloques, Retransmisión compacta, Consenso de Nakamoto. También enlazan con esta entrada Doble gasto, Ataque Sybil, Neutrino.