--- title: "Ataques de longo alcance em PoS: chaves históricas, risco de inicialização e checkpoints" description: "Um ataque de longo alcance em PoS apresenta um histórico alternativo assinado com autoridade histórica de validadores. Saiba quais nós estão expostos, o que o invasor precisa reproduzir e como checkpoints de subjetividade fraca e regras de sincronização específicas do protocolo limitam o risco." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Ataques de longo alcance em PoS: chaves históricas, risco de inicialização e checkpoints > Análise educacional sobre segurança de protocolos apenas. A resistência a ataques de longo alcance é específica do protocolo e da versão; obtenha dados de inicialização de fontes autenticadas e verificadas de forma independente antes de confiar em um nó recém-sincronizado ou que tenha ficado offline por muito tempo. ## Resposta direta Um ataque de longo alcance em um sistema de prova de participação tenta tornar crível um histórico conflitante usando autoridade de validadores que era válida em um passado distante. Uma forma comum, muitas vezes chamada de corrupção posterior, adquire ou compromete chaves pertencentes a validadores depois que eles saíram e suas garantias já não podem sofrer penalização. Como produzir assinaturas antigas não exige repetir o gasto de energia da prova de trabalho, o adversário pode construir um fork internamente consistente a baixo custo em relação ao custo histórico da cadeia honesta. O alvo costuma ser um nó sem uma visão autenticada recente: um nó iniciado pela primeira vez, um nó restaurado de um backup antigo ou um nó que ficou offline além do horizonte seguro de sincronização do protocolo. Um nó que observa a rede continuamente já conhece um ancestral finalizado ou protegido de outra forma e deve rejeitar um fork que entre em conflito com ele. Assim, um ataque de eclipse ou uma fonte de dados comprometida pode ampliar o ataque ao ocultar a visão honesta do nó em sincronização. Chaves históricas, sozinhas, não são uma ferramenta universal de falsificação. O histórico alternativo precisa satisfazer os domínios de assinatura, as transições de estado, a evolução do conjunto de validadores, as regras de tempo, as provas de finalidade ou seleção de cadeia e quaisquer restrições de evolução de chaves ou checkpoints do protocolo-alvo. Alguns protocolos PoS exigem um checkpoint recente de subjetividade fraca; outros definem inicialização orientada ao bloco gênese ou diferentes pressupostos de confiança e disponibilidade. Analise a cadeia, a rede, a versão do fork, o cliente e o modo de sincronização exatos, em vez de tratar “PoS” como um único mecanismo. Um checkpoint não é apenas um número de bloco conveniente. Ele vincula uma rede e um estado de consenso específicos a uma raiz ou hash em uma época, slot ou altura. Depois de autenticado, limita os históricos que o nó considerará. O restante da cadeia pode então ser verificado de acordo com as regras do protocolo a partir dessa âncora. Isso é subjetividade fraca: entrada externa limitada na inicialização, seguida de validação objetiva dentro do período pressuposto, e não confiança permanente na cabeça mais recente anunciada por um par. ## Caminho do ataque e da verificação 1. **Escolher um ponto de fork antigo.** O adversário identifica um estado histórico cuja autoridade de validadores mudou desde então ou se tornou difícil de autenticar de forma independente para um nó novo. 2. **Obter poder histórico de assinatura suficiente.** As chaves podem ser compradas, roubadas, retidas, recuperadas de backups ou expostas por sistemas de assinatura comprometidos depois que os validadores saem. O peso e os tipos de mensagem necessários são específicos do protocolo; possuir uma única chave antiga de proponente não é automaticamente suficiente. 3. **Construir uma alternativa válida para o protocolo.** O adversário produz blocos, votos, certificados e mudanças no conjunto de validadores que passam pelas verificações históricas do cliente da vítima. Qualquer transição de estado inválida, domínio incorreto, temporização impossível ou prova ausente ainda pode invalidar o fork. 4. **Estender e apresentar o fork.** A produção barata de assinaturas pode permitir ao adversário preencher um histórico longo, mas a contagem bruta de blocos não é decisiva. O ramo precisa vencer ou contornar o procedimento exato de seleção usado durante esse modo de sincronização. 5. **Controlar a visão de inicialização.** A vítima é isolada de um checkpoint recente autenticado ou de provas de pares honestos e recebe o histórico alternativo como único candidato ou candidato preferencial. 6. **Induzir confiança a jusante.** Se o nó aceitar o estado errado, seu RPC, carteira, indexador, monitor de ponte ou aplicativo pode informar saldos, eventos e membros do conjunto de validadores que são válidos para o protocolo no fork do invasor, embora a rede ativa siga outra cadeia. O defensor deve reproduzir o caminho ao contrário: autenticar uma âncora, confirmar sua identidade de cadeia e rede, verificar se a candidata descende dela, executar todas as verificações de consenso e transição de estado e comparar o estado finalizado ou selecionado entre infraestruturas independentes. Um download concluído não comprova que o histórico selecionado seja o canônico. ## Exemplo prático Suponha que o conjunto de validadores `V_old` controlasse uma cadeia PoS hipotética na época `120,000`. Anos depois, mais de `2/3` desse peso histórico saiu e já não está exposto a penalidades do protocolo. Um adversário obtém essas chaves antigas e inicia um histórico conflitante imediatamente depois do checkpoint `C_old`. No ramo fabricado, o adversário assina os votos exigidos por esse protocolo hipotético, altera posteriormente os membros do conjunto de validadores e continua até a época `420,000`. A rede honesta também alcançou a época `420,000`, portanto números de época iguais ou um arquivo mais longo não indicam a um nó em inicialização qual ramo é canônico social e operacionalmente. A admissibilidade do ramo fabricado depende de todas as regras históricas do protocolo. O nó `N_live` observou o checkpoint finalizado legítimo `C_recent` na época `419,936`. Como o fork de ataque não descende de `C_recent`, `N_live` o rejeita. O nó `N_new`, porém, começa no bloco gênese, conecta-se apenas a pares adversários e não possui uma âncora recente autenticada. Se o protocolo e o modo de sincronização não conseguirem distinguir os históricos somente por suas provas internas, ele poderá aceitar o ramo de ataque. Fornecer a `N_new` o par autenticado `C_recent = (root, 419,936)` altera o limite de decisão. O cliente deve exigir que o caminho de sincronização contenha esse checkpoint exato e falhar de modo fechado caso isso não seja possível. As épocas e o limiar de `2/3` do exemplo ilustram um projeto baseado em finalidade; não são parâmetros universais de PoS nem configurações atuais de uma rede específica. ## Controles e checklist de revisão ### Projeto do protocolo - Documente o modelo exato de segurança contra ataques de longo alcance: corrupção posterior, rotatividade de validadores, comprometimento adaptativo de chaves, isolamento da rede e disponibilidade de dados. - Defina quais estados finalizados nunca podem ser revertidos e como a escolha do fork trata um conflito com uma âncora confiável localmente. - Limite saídas, retiradas e rotatividade do conjunto de validadores para que os pressupostos de segurança continuem relevantes enquanto a assinatura conflitante ainda possa ser detectada e penalizada. - Especifique o período de subjetividade fraca ou o pressuposto alternativo de segurança da sincronização como uma derivação do estado atual e das constantes do protocolo, não como um valor de calendário eterno. - Considere assinaturas com evolução de chaves ou segurança futura quando o projeto do protocolo permitir; a exclusão comum de chaves é uma boa prática, mas não é uma defesa completa do consenso. - Teste separadamente a primeira sincronização, a sincronização por checkpoint, a restauração de snapshots e a recuperação após longo período offline. Uma regra segura de escolha de fork ao vivo não torna a inicialização automaticamente segura. ### Inicialização e operação do nó - Registre antes da sincronização a raiz do checkpoint ou o hash do bloco, a época ou altura, o ID da cadeia, a rede, a versão do fork, o horário de aquisição e o provedor. - Obtenha âncoras por canais autenticados e compare várias fontes realmente independentes. Vários sites apoiados por um único nó ou operador não são independentes. - Rejeite checkpoints obsoletos, malformados, da rede errada ou conflitantes. Não recorra silenciosamente a uma sincronização sem âncora quando a validação falhar. - Exija que a cadeia sincronizada contenha a âncora exata e verifique todos os descendentes com os clientes de consenso e execução pretendidos. - Use diversidade de pares, clientes, operadores e RPC; monitore condições de eclipse, divergência de raízes finalizadas, reversões incomuns e falha prolongada de finalidade. - Verifique novamente a âncora depois de restaurar um banco de dados ou backup antigo e atualize-a dentro do período seguro documentado pelo protocolo. ### Confiança do aplicativo - Não libere depósitos, mensagens de ponte ou negociações irreversíveis apenas porque um RPC recém-sincronizado informa sucesso. - Concilie a identidade da cadeia, o checkpoint finalizado e a ancestralidade dos eventos em nós independentes antes de uma ação de grande impacto. - Mantenha o histórico de consenso separado da verdade do aplicativo: uma cadeia canônica não comprova a correção do oráculo, a segurança do contrato, a disponibilidade de dados fora do protocolo nem a solvência do custodiante. - Prepare uma política de interrupção para checkpoints finalizados ou âncoras confiáveis conflitantes. Essa condição pode indicar falha de consenso, dados de inicialização corrompidos ou rede errada e não deve ser resolvida automaticamente pela escolha do ramo mais longo. ## Equívocos comuns - **Toda cadeia PoS é vulnerável da mesma forma.** A resistência a ataques de longo alcance depende da evolução dos validadores, das assinaturas, da finalidade, da escolha de fork, dos checkpoints e dos pressupostos de sincronização do protocolo. - **Chaves antigas podem reescrever qualquer transação sem restrições.** O invasor ainda precisa produzir um histórico aceito por todas as regras de validação da vítima; a autoridade histórica só é necessária em algumas construções de ataque e pode não ser suficiente. - **A cadeia com mais blocos, épocas ou assinaturas é legítima.** A seleção usa validade, peso, certificados e âncoras específicos do protocolo, não uma comparação universal de comprimento. - **A finalidade, sozinha, permite que um nó iniciado no bloco gênese identifique a cadeia social.** Dois históricos finalizados e internamente válidos podem ser ambíguos para um nó sem uma visão recente autenticada; a finalidade protege um nó que já conhece o checkpoint pertinente. - **A penalização sempre impede o ataque.** Validadores que retiraram todos os fundos podem não ter garantias restantes para penalizar, e as provas precisam ser atribuíveis e processadas enquanto as penalidades ainda puderem ser aplicadas. - **Um checkpoint significa confiar para sempre em uma empresa.** A confiança pode ser limitada a uma âncora recente específica e reduzida por distribuição autenticada, verificações cruzadas independentes e posterior verificação local. - **Excluir chaves de validadores que saíram resolve o problema do protocolo.** O apagamento seguro reduz o risco de comprometimento, mas regras robustas de consenso e inicialização devem tolerar que algumas chaves históricas se tornem disponíveis. ## Tópicos relacionados - [Finalidade](/pt-br/crypto/finality/) - [Regras de escolha de fork](/pt-br/crypto/fork-choice-rule/) - [Prova de participação](/pt-br/crypto/proof-of-stake/) - [Filas de saída e retirada de validadores](/pt-br/crypto/validator-exit-withdrawal-queue/) - [Subjetividade fraca](/pt-br/crypto/weak-subjectivity/) ## Fontes - [Subjetividade fraca no Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (acesso: 2026-08-21) - [Especificações de consenso do Ethereum: guia de subjetividade fraca](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md) - Ethereum Foundation (acesso: 2026-08-21) - [Ataques e defesas na prova de participação do Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (acesso: 2026-08-21) - [Casper, o dispositivo amigável de finalidade](https://arxiv.org/abs/1710.09437) - arXiv (acesso: 2026-08-21) - [Ouroboros Genesis: blockchains de prova de participação combináveis com disponibilidade dinâmica](https://eprint.iacr.org/2018/378) - IACR Cryptology ePrint Archive (acesso: 2026-08-21) - [Projeto do Ouroboros Genesis](https://ouroboros-consensus.cardano.intersectmbo.org/docs/references/miscellaneous/genesis_design/) - Intersect (acesso: 2026-08-21) Source: https://wiki.fcontext.com/pt-br/crypto/long-range-attack/index.mdx