Un Eclipse Attack aísla un nodo de sus pares honestos mientras mantiene la conexión con el atacante. El Full Node, un programa que verifica las reglas de Bitcoin por sí mismo, sigue haciendo esa comprobación, pero puede recibir una visión incompleta o desactualizada de la red. El ataque no convierte datos inválidos en válidos: aprovecha lo que el nodo no puede ver.
Ana recibe un pago en bitcoin y observa su propio nodo: un ordenador con un programa que participa en la red Bitcoin. Este indica conexiones activas, pero un adversario controla todas sus vías importantes hacia el exterior. Llegan mensajes, aunque solo los que el atacante permite. Esa es la esencia de un Eclipse Attack. Una sola conexión maliciosa normalmente no basta: una vía operativa hacia un nodo honesto puede aportar los bloques ocultados y romper ese control. Un bloque agrupa transacciones en un lote que se añade al historial compartido. [1] [6]
Ethan Heilman, Alison Kendler, Aviv Zohar y Sharon Goldberg describieron en 2015 ataques contra la red Bitcoin de entonces. Estudiaron cómo llenar las tablas de un nodo con direcciones del atacante para que, al reconectarse, solo se conectara a los ordenadores de este. Aprovecharon la selección de conexiones sin romper los métodos matemáticos que protegen, por ejemplo, las firmas digitales. El estudio también propuso defensas; sus resultados históricos no miden la probabilidad de éxito contra la versión actual de Bitcoin Core. [1] [7]
Una vez logrado el aislamiento, puede decidir qué bloques y transacciones entrega a Ana y cuáles retiene. También puede impedir que sus propias transacciones se propaguen u observar su origen. Controlar las conexiones no exige por sí solo una mayoría de potencia minera. Eso no significa que todos los ataques posteriores resulten gratuitos: crear bloques nuevos, por ejemplo, requiere trabajo real. [1] [6]
El Full Node de Ana sigue verificando firmas, condiciones de gasto y la recompensa permitida al minero. Firmar significa aquí usar una clave privada, un valor numérico secreto, para crear una prueba verificable de autorización del pago. Los demás pueden comprobar la firma sin conocer ese secreto. El nodo de Ana no acepta una transacción defectuosa solo porque la haya enviado la única fuente disponible. Sin embargo, no puede descubrir mediante esa verificación un bloque válido que nunca recibió. Del mismo modo, puedes reconocer una carta auténtica sin saber que alguien retuvo todas las posteriores. Validez e integridad de la información disponible son preguntas distintas. [5] [9]
El nodo puede quedarse en el último bloque conocido mientras los demás continúan. Un minero aislado incluso puede seguir trabajando sobre una rama abandonada y perder la recompensa esperada. Pero esperar mucho un bloque no demuestra por sí solo un ataque: la minería es aleatoria y un fallo corriente también puede causar problemas. Importa la combinación de indicios, no únicamente una pantalla que tarda en actualizarse. [1] [5] [8]
Un atacante puede mostrar a Ana una rama privada válida con su pago mientras gasta los mismos fondos de otra forma en la red general. Al recuperar la conexión, el nodo puede adoptar una rama válida con más trabajo acumulado: un Reorg, es decir, sustituir parte del historial aceptado. El pago de la rama abandonada puede dejar de estar confirmado. Pero el atacante debe aportar Proof of Work para sus bloques. Estos bloques también necesitan ese resultado verificable, que se obtiene mediante una búsqueda computacional costosa. El trabajo necesario puede proceder asimismo de mineros a los que el atacante ha aislado. Inventar una cifra de confirmaciones no engaña a un Full Node; el éxito depende también de la duración del aislamiento y de sus recursos. [1] [5] [6]
Las defensas intentan evitar que todas las conexiones terminen en manos del mismo adversario. Bitcoin Core agrupa direcciones conocidas y fomenta la diversidad de red al seleccionar conexiones salientes. Una dirección IP identifica un punto de la red al que se conecta el programa. Aun así, distintas IP pueden pertenecer al mismo operador o pasar por la misma infraestructura. Estas medidas reducen la concentración y dificultan el ataque, pero no demuestran que cada par sea independiente. [3] [4]
Bitcoin Core usa conexiones breves llamadas feeler para comprobar si otra dirección es accesible. Las conexiones adicionales de retransmisión de bloques cumplen otra función: pueden traer nuevas cabeceras — registros técnicos breves de los bloques — y otra perspectiva sobre la continuación de la cadena. Por tanto, no es correcto afirmar que cada feeler descarga inmediatamente el historial actual. El código citado de Bitcoin Core 29.0 muestra estas defensas diferentes; ninguna garantiza por sí sola terminar con el aislamiento. [4] [8]
Añadir manualmente un par conocido puede abrir otra vía si está disponible y realmente conectado con el resto de la red. Sin embargo, varias conexiones por un mismo proveedor no tienen por qué ser independientes. Conviene mantener software con soporte y entender la configuración, en lugar de importar ciegamente listas de direcciones ajenas. La verificación propia se mantiene: confiar en la disponibilidad de una fuente no le autoriza a enviar bloques inválidos. [2] [4] [6]
En un Sybil Attack, un adversario actúa bajo muchas identidades, lo que puede facilitar un Eclipse Attack. Eclipse describe el aislamiento exitoso de un nodo concreto o un grupo elegido respecto de fuentes honestas. Una partición más amplia separa regiones enteras de la red y no tiene por qué surgir de ese modo. Para el usuario, lo importante es que un Full Node permite verificar por cuenta propia, pero también necesita información fuera del control del atacante. [1] [6]
Para obtener la imagen más completa, lee esta entrada junto con Sybil Attack, Block Propagation, Compact Blocks, Nakamoto Consensus, Bitcoin, Full Node. También enlazan con esta entrada Doble gasto, Byzantine Generals Problem, Nakamoto Consensus, Sybil Attack.