Um Eclipse Attack isola um nó de seus pares honestos, mantendo a conexão com o atacante. O Full Node, um programa que verifica as regras do Bitcoin por conta própria, continua fazendo essa verificação, mas pode receber apenas uma visão incompleta ou desatualizada da rede. O ataque não torna válidos dados inválidos: explora aquilo que o nó não consegue ver.
Ana recebe um pagamento em bitcoin e acompanha seu próprio nó: um computador com um programa que participa da rede Bitcoin. Ele mostra conexões ativas, mas um adversário controla todos os caminhos importantes para fora. As mensagens chegam, porém só as que o atacante permite. Essa é a essência de um Eclipse Attack. Uma conexão maliciosa normalmente não basta: um caminho funcional até um nó honesto pode trazer os blocos ocultados e romper esse controle. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. [1] [6]
Ethan Heilman, Alison Kendler, Aviv Zohar e Sharon Goldberg descreveram em 2015 ataques contra a rede Bitcoin da época. Estudaram como preencher as tabelas de um nó com endereços do atacante para que, ao se reconectar, ele só se ligasse aos computadores desse atacante. Exploraram a escolha de conexões sem quebrar os métodos matemáticos que protegem, por exemplo, as assinaturas digitais. O estudo também propôs defesas; seus resultados históricos não medem a chance de sucesso contra a versão atual do Bitcoin Core. [1] [7]
Depois de obter o isolamento, ele pode escolher quais blocos e transações entrega a Ana e quais retém. Também pode impedir a propagação das transações que ela própria envia ou observar sua origem. Controlar as conexões, por si só, não exige a maioria do poder de mineração. Isso não significa que todo ataque posterior seja gratuito: criar blocos novos, por exemplo, exige trabalho real. [1] [6]
O Full Node de Ana ainda verifica assinaturas, condições de gasto e a recompensa permitida ao minerador. Assinar significa aqui usar uma chave privada, um valor numérico secreto, para criar uma prova verificável de autorização do pagamento. Outras pessoas podem conferir a assinatura sem conhecer esse segredo. O nó de Ana não aceita uma transação defeituosa só porque veio da única fonte disponível. Mas a verificação não revela um bloco válido que nunca chegou. Da mesma forma, é possível reconhecer uma carta autêntica sem saber que alguém reteve todas as mais recentes. Validade e completude da informação disponível são questões diferentes. [5] [9]
O nó pode ficar no último bloco conhecido enquanto os outros seguem adiante. Um minerador isolado pode até continuar em um ramo abandonado e perder a recompensa esperada. Porém, esperar muito por um bloco não prova um ataque: a mineração é aleatória e uma falha comum também causa problemas. O que importa é a combinação de sinais, não apenas uma tela que demora a atualizar. [1] [5] [8]
Um atacante pode mostrar a Ana um ramo privado válido com seu pagamento enquanto gasta os mesmos fundos de outra maneira na rede geral. Quando a conexão volta, o nó pode adotar um ramo válido com mais trabalho acumulado: um Reorg, ou substituição de parte do histórico aceito. O pagamento do ramo abandonado pode deixar de estar confirmado. Mas o atacante precisa fornecer Proof of Work para seus blocos. Trata-se do resultado verificável de uma busca computacional custosa, exigido também para esses blocos. O trabalho necessário pode vir ainda de mineradores que o atacante isolou. Inventar um número de confirmações não engana um Full Node; o sucesso também depende da duração do isolamento e dos recursos do adversário. [1] [5] [6]
As defesas tentam impedir que todas as conexões acabem com o mesmo adversário. O Bitcoin Core agrupa endereços conhecidos e favorece a diversidade de rede ao selecionar conexões de saída. Um endereço IP identifica um ponto da rede ao qual o programa se conecta. IPs distintos, porém, podem pertencer ao mesmo operador ou passar pela mesma infraestrutura. Essas medidas reduzem a concentração e dificultam ataques, mas não provam a independência de cada par. [3] [4]
O Bitcoin Core usa conexões breves chamadas feeler para testar se outro endereço está acessível. Conexões adicionais de retransmissão de blocos têm outra função: podem trazer novos cabeçalhos — registros técnicos compactos dos blocos — e outra visão da continuidade da cadeia. Portanto, não é correto dizer que todo feeler baixa imediatamente o histórico atual. O código citado do Bitcoin Core 29.0 mostra essas defesas distintas; nenhuma garante sozinha o fim do isolamento. [4] [8]
Um par conhecido adicionado manualmente pode abrir outro caminho, desde que esteja disponível e realmente conectado ao restante da rede. Várias conexões por um mesmo provedor, contudo, podem não ser independentes. Faz sentido manter software com suporte e entender as configurações, em vez de copiar cegamente listas de endereços de terceiros. A verificação própria continua: confiar na disponibilidade de uma fonte não lhe dá permissão para enviar blocos inválidos. [2] [4] [6]
Em um Sybil Attack, um adversário usa muitas identidades, o que pode facilitar um Eclipse Attack. Eclipse descreve o isolamento bem-sucedido de um nó específico ou grupo escolhido em relação a fontes honestas. Uma divisão mais ampla separa regiões inteiras da rede e não precisa surgir desse modo. Para o usuário, o essencial é que um Full Node oferece verificação independente, mas também precisa de informações fora do controle do atacante. [1] [6]
Para ter uma visão mais completa, leia este verbete junto com Sybil Attack, Block Propagation, Compact Blocks, Nakamoto Consensus, Bitcoin, Full Node. Também há referências a este verbete em Gasto duplo, Byzantine Generals Problem, Nakamoto Consensus, Sybil Attack.