Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
Resposta direta
Um ataque eclipse isola um nó-alvo dos pares honestos ao controlar todas as suas conexões de rede, ou uma quantidade suficiente delas. O invasor pode então atrasar, suprimir ou retransmitir seletivamente blocos e transações, fazendo com que a vítima enxergue uma visão da rede moldada por ele.
A vítima pode continuar validando assinaturas, prova de trabalho e todas as demais regras de consenso. Isso não torna sua visão completa nem atualizada. Um nó de validação completa pode rejeitar dados inválidos e, ainda assim, ser mantido em um ramo válido, porém desatualizado, ser impedido de ver uma transação conflitante ou ser induzido a uma interpretação errada do que a rede mais ampla aceitou.
Isso difere de um ataque majoritário contra toda a rede. O invasor tem como alvo um nó ou um conjunto limitado de nós na camada ponto a ponto e não precisa controlar a maior parte do poder de mineração ou da participação da rede. Um ataque Sybil pode auxiliar um ataque eclipse fornecendo muitas identidades ou endereços controlados pelo invasor, mas os conceitos não são idênticos: Sybil descreve a multiplicação de identidades; eclipse descreve o isolamento bem-sucedido da visão de informações da vítima.
Como funciona o isolamento
Clientes ponto a ponto descobrem endereços candidatos, armazenam esses endereços, selecionam pares de saída, aceitam alguns pares de entrada e se reconectam após falhas ou reinicializações. Os algoritmos exatos variam conforme o cliente e a versão. O invasor procura uma forma de direcionar uma quantidade suficiente dessas decisões para a infraestrutura que controla.
Um caminho de ataque típico tem 4 etapas:
- Preparar pares controlados pelo invasor. O invasor opera nós ou identidades acessíveis por endereços que provavelmente serão tratados como distintos pelas regras de seleção de pares da vítima.
- Influenciar o conjunto de candidatos. Pares maliciosos anunciam endereços controlados pelo invasor ou tentam, de outras formas, expulsar entradas honestas do gerenciador de endereços da vítima. A viabilidade prática depende do desenho dos buckets, das regras de agrupamento de rede, dos limites de frequência e da qualidade dos endereços já armazenados.
- Provocar ou aguardar a reconexão. Uma reinicialização, a rotatividade de conexões, uma negação de serviço ou uma interrupção de roteamento pode levar o alvo a substituir pares honestos. O isolamento é mais fácil quando o alvo tem poucos caminhos independentes ou começa com um banco de dados de endereços deficiente.
- Monopolizar e filtrar. Quando as conexões relevantes da vítima passam a levar ao invasor, ele retransmite apenas os blocos e as transações escolhidos, muitas vezes respeitando as regras de consenso para evitar rejeição imediata.
O estudo da USENIX de 2015 demonstrou essa classe de ataque contra a implementação ponto a ponto do Bitcoin usada na época e descreveu consequências como gasto duplo baseado em confirmações, auxílio à mineração egoísta e bifurcações adversárias. Suas estimativas específicas de recursos e seus detalhes de cliente são históricos, não constantes universais para o Bitcoin Core atual nem para outras redes.
Clientes modernos podem elevar o custo do isolamento por meio de armazenamento de endereços aleatório e segmentado, diversidade de fontes de pares, conexões de teste, conexões de saída ou de retransmissão de blocos protegidas, âncoras preservadas entre reinicializações, regras de expulsão e limites para a retransmissão de endereços. Essas são mitigações em camadas, não provas de que ataques eclipse sejam impossíveis.
Exemplo de pagamento e resposta
Suponha que o nó de um comerciante receba um pagamento e exiba 6 confirmations. Um invasor que tenha isolado esse nó pode mostrar a ele um ramo válido mantido em caráter privado que contenha o pagamento, enquanto uma transação conflitante é aceita na rede honesta. Se o comerciante liberar bens irreversíveis com base apenas no nó isolado, a contagem exibida não comprova que a rede honesta confirmou o pagamento.
A resposta ao incidente deve preservar evidências antes de realizar mudanças disruptivas:
- Registre a ponta da cadeia informada, o trabalho acumulado, os hashes de blocos recentes, a lista de pares, a direção das conexões, o tipo de rede, o sistema autônomo mapeado quando disponível e os horários do último bloco recebido.
- Compare a ponta e o estado da transação com nós operados de forma independente, acessados por caminhos de rede e administrativos realmente separados. Exploradores públicos só são úteis se a infraestrutura deles também for independente.
- Pause a liquidação de alto valor ou a liberação automatizada quando visões independentes divergirem. Mais confirmações da mesma visão isolada não resolvem o problema.
- Migre para software e configuração reconhecidamente confiáveis, investigue DNS, roteamento, firewall, proxy e comprometimento do host, e reconstrua o estado dos pares segundo o procedimento de recuperação documentado pelo cliente.
- Reconecte gradualmente e verifique se os pares, os grupos de rede, a chegada de blocos, o trabalho da cadeia e as observações de transações se diversificam. Não restaure às cegas um banco de dados de pares possivelmente contaminado.
- Preserve os registros e encaminhe o caso para a equipe de segurança do nó ou do protocolo. Uma suspeita de eclipse pode coincidir com interrupções comuns, incidentes de roteamento ou uma invasão mais ampla do host.
No Bitcoin Core 30.0, getpeerinfo expõe campos como network, mapped_as, inbound, last_block, synced_headers, synced_blocks e connection_type. Esses campos ajudam na investigação, mas nenhum deles comprova o isolamento por si só. O monitoramento deve estabelecer uma referência normal e correlacionar a concentração de pares com observações independentes da cadeia.
Riscos e controles
- Gasto duplo contra um recebedor: podem ser mostradas à vítima confirmações em um ramo controlado pelo invasor. Exija observação independente para entregas de alto valor ou irreversíveis e defina limites que reflitam o risco de liquidação.
- Interrupção de minerador ou validador: um operador isolado pode trabalhar com informações desatualizadas, perder receita ou ajudar um ramo adversário. Monitore o trabalho da cadeia, a atualidade da ponta e a diversidade de pares fora do nó de produção.
- Censura seletiva: o invasor pode ocultar transações ou atrasar blocos sem enviar dados inválidos. Gere alertas para intervalos incomuns na chegada de blocos e divergências entre observadores independentes.
- Falha de ponte, oráculo e RPC: serviços fora da cadeia que confiam em um único nó upstream podem retransmitir um estado desatualizado ou deixar de detectar uma reorganização. Use várias fontes de dados com administração e conexão de rede independentes, além de regras explícitas de quórum e atualidade.
- Falsa confiança na quantidade de conexões: 20 pares controlados por uma organização, uma rede ou uma fonte de endereços podem oferecer menos independência do que um conjunto diverso menor. Meça a diversidade, não apenas a quantidade.
- Centralização por meio de pares fixos: um único par confiável configurado manualmente pode contornar um conjunto de candidatos contaminado, mas cria um ponto único de falha. Se âncoras fixas forem adequadas, use vários caminhos operados de forma independente e preserve conexões aleatórias.
Operadores de nós devem manter atualizadas as versões do cliente que ainda recebem suporte, entender os padrões de gerenciamento de pares específicos do cliente, proteger o acesso administrativo e monitorar tanto a topologia de entrada quanto a de saída. Operadores de pagamentos e protocolos devem separar assinatura, transmissão, observação da cadeia e decisões de liberação, para que um único nó isolado não possa autorizar sozinho uma ação irreversível.
Equívocos comuns
- Um nó completo não pode ser enganado. Um nó completo rejeita dados inválidos segundo o consenso; ele não sabe automaticamente que pares honestos estão ocultando uma cadeia válida melhor.
- Uma contagem alta de confirmações é sempre suficiente. As confirmações só têm significado em relação à visão da cadeia observada. A independência do caminho de observação importa quando o isolamento é plausível.
- Mais pares sempre resolvem o problema. Pares adicionais só ajudam quando sua propriedade, seus caminhos de rede, suas fontes de descoberta e seus modos de falha são suficientemente independentes.
- Ataques eclipse e Sybil são a mesma coisa. Recursos Sybil podem facilitar o isolamento, mas um ataque eclipse é o controle resultante da visão de pares da vítima.
- Um explorador de blocos coincidente comprova que o nó está íntegro. O explorador pode compartilhar um provedor upstream, um caminho de rede ou um domínio administrativo com o sistema afetado.
- Todo nó desatualizado está sob ataque. Defeitos de software, congestionamento, manutenção, falhas de roteamento e esgotamento de recursos podem produzir sintomas semelhantes. Trate o eclipse como uma hipótese a ser testada com múltiplos sinais.
Tópicos relacionados
Fontes
- Eclipse Attacks on Bitcoin’s Peer-to-Peer Network - USENIX Association (acessado em: 2026-08-20)
- Bitcoin Core RPC: getpeerinfo - Bitcoin Core (acessado em: 2026-08-20)
- Bitcoin Core: connection_types.cpp - Bitcoin Core (acessado em: 2026-08-20)