Riscos de pontes: validadores, multisig e ataques de repetição

2026-08-24

Uma ponte não move nada. Ela faz uma afirmação em uma cadeia e convence uma segunda cadeia a agir com base nela, e todo rombo em ponte é essa segunda cadeia acreditando em uma afirmação que deveria ter recusado. Por isso vale organizar o risco de pontes por suposição de confiança, e não por nome de produto: em que a cadeia de destino acredita, e o que seria preciso para fazê-la acreditar em algo falso. Este artigo percorre cinco fontes estruturais, dos conjuntos externos de validadores às chaves de atualização.

A pergunta que organiza qualquer ponte

A própria documentação para desenvolvedores da Ethereum comprime a segurança de uma ponte em uma única pergunta: quem verifica o sistema? Taxas, velocidade e número de cadeias conectadas ficam todos a jusante dela.

A mecânica quase não varia. Algo acontece na cadeia de origem. Alguma parte atesta que aconteceu. Um contrato na cadeia de destino confere esse atestado contra uma regra e, se ele passar, libera ou emite. Tudo o que um atacante quer está do outro lado dessa regra.

A documentação separa os desenhos em duas famílias. Pontes confiáveis são verificadas de fora: por uma federação com multisig, um sistema de computação multipartes ou uma rede de oráculos. Pontes sem confiança se apoiam nas cadeias que conectam e nos validadores dessas cadeias, sem acrescentar uma suposição nova. A primeira família compra conectividade e velocidade e paga em segurança: uma ponte protegida por validadores externos costuma ser mais fraca do que uma protegida nativamente pelas próprias cadeias.

O valor em jogo torna essa troca implacável. Até agosto de 2022, a Chainalysis havia contado 13 invasões distintas a pontes entre cadeias, somando cerca de 2 bilhões de dólares, algo em torno de 69% de tudo o que foi roubado em cripto naquele ano até aquele momento. Pontes atraem ataques porque concentram as garantias exatamente no ponto em que uma única regra é conferida.

É por isso que as seções abaixo estão organizadas por suposição, e não por incidente. Duas pontes com nomes diferentes e o mesmo modelo de verificação falham do mesmo jeito, e saber os nomes não diz nada sobre aquela que você está prestes a usar.

Um conjunto externo de validadores é um sistema que você não auditou

O desenho confiável mais comum coloca um conjunto de N partes entre as duas cadeias. Elas observam a cadeia de origem, assinam um atestado de que um evento ocorreu, e o contrato de destino aceita se ao menos M dessas assinaturas verificarem. O contrato não tem nenhuma outra opinião sobre a realidade.

A consequência é direta: quem controla M chaves consegue emitir. Pegue um conjunto de 9 com limiar de 5. Um atacante com 5 chaves não precisa de falha no contrato, nem de fraqueza em qualquer uma das cadeias, nem de nenhuma checagem adicional. Enquanto ele esvazia a ponte, ela faz exatamente aquilo para que foi construída.

Repare em qual segurança você está de fato comprando. O conjunto de validadores é um sistema próprio, com seus operadores, suas máquinas e seus incentivos, e não herda nada das cadeias que liga. Uma ponte verificada por um conjunto externo é tão forte quanto esse conjunto e nada além disso, por maiores que sejam as duas redes de cada lado.

Então as perguntas que valem são perguntas de composição. Quem são esses N, e eles chegam a ser divulgados? São organizações distintas ou uma organização rodando nove máquinas? Quanto vale M? Os membros têm algo em jogo que possa ser tomado deles se assinarem uma mensagem falsa? E quem pode mudar a composição, porque um conjunto que uma única chave reescreve é uma ponte de assinatura única fantasiada de comitê.

Um limiar só conta se as chaves falharem de forma independente

M de N é uma afirmação sobre independência, não uma conta. Cinco de nove só é significativamente mais difícil do que um de um se essas nove chaves puderem falhar de nove maneiras não relacionadas.

Muitas vezes não podem. Chaves guardadas dentro de uma mesma empresa compartilham um processo de contratação, uma imagem de notebook, uma VPN, um serviço de chaves em nuvem e uma única interface de assinatura. Se uma única mensagem de phishing alcança os nove titulares, ou se uma conta em nuvem guarda cinco delas, N é um número em um painel e o N real está mais perto de 1.

Elevar o limiar não conserta isso, e custa algo. Com M alto, perder algumas chaves deixa a ponte sem conseguir assinar nada: nada é roubado, mas nada se move também, e quem tem ativos do lado errado espera. Todo limiar é uma escolha entre fácil demais de roubar e fácil demais de congelar.

A superfície de assinatura merece tanta atenção quanto a custódia. Quem assina aprova dados que em geral não consegue ler, então, se a interface mostra um resumo simpático enquanto os bytes embaixo dizem outra coisa, signatários honestos produzem uma assinatura maliciosa válida. A assinatura às cegas transforma um comitê M de N em um carimbo M de N, e nenhum limiar protege disso.

Clientes leves e verificação otimista apostam em coisas diferentes

Os desenhos de confiança minimizada removem o conjunto externo, mas não removem a confiança: eles a realocam. Duas famílias fazem quase todo o trabalho.

A verificação por cliente leve coloca um cliente da cadeia de origem dentro da cadeia de destino. O destino guarda o estado de consenso da origem e confere se o evento alegado está provado contra ele. No IBC, cada lado de uma conexão usa o cliente leve da outra cadeia para verificar as mensagens que chegam, de modo que a suposição se reduz ao consenso da cadeia de origem mais a correção do código do cliente. A versão mais nova do IBC diz isso de forma explícita: um cliente é apenas um modelo de verificação, e pode igualmente ser um cliente leve, um multisig ou um verificador de provas. O rótulo não é a suposição; o tipo de cliente é.

A verificação otimista faz o caminho oposto: aceita a mensagem provisoriamente e dá a qualquer um uma janela para provar que ela é falsa. A suposição é que ao menos um vigilante está rodando, tem fundos e consegue colocar uma transação de contestação antes de a janela fechar. Um vigilante fora do ar, sem gás ou censurado durante a janela equivale a nenhum vigilante.

Nenhuma das famílias é de graça, e os custos são estruturais, não acidentais. Clientes leves custam gás e engenharia para cada par de cadeias, e um bug no cliente é um bug na própria regra. Desenhos otimistas conectam barato, mas fazem cada usuário honesto cumprir um atraso escolhido pelo projetista. A documentação da Ethereum nomeia os dois custos diretamente: limites de conectividade nas pontes com cliente leve e de velocidade nas otimistas.

Repetição é uma mensagem válida contada duas vezes

Uma mensagem de ponte é uma autorização. Repetição é o ataque em que uma autorização de fato emitida é apresentada de novo: uma segunda vez no mesmo lugar, ou uma primeira vez onde nunca deveria valer. Nada é forjado. Os mesmos bytes válidos são simplesmente reaproveitados.

A correção canônica está na própria história da Ethereum. A EIP-155 dobra o chain ID para dentro dos dados que são hasheados e assinados, de modo que uma assinatura feita para uma cadeia não verifica em outra. Repare em como isso chegou: o formato antigo de seis elementos continuou válido, ou seja, essa proteção é algo que quem assina escolhe adotar, e não algo que o formato garanta.

Para as mensagens estruturadas que as pontes de fato carregam, a EIP-712 define um separador de domínio. Ele pode levar um nome, uma versão, o chain ID e o endereço do contrato verificador, além de um salt como separador de última instância, e diz que uma carteira deveria se recusar a assinar quando o chain ID não bate com a cadeia em que o usuário realmente está. Outra cadeia, outro contrato, outra versão, outra mensagem. É isso que separação de domínio significa na prática: colocar o destino dentro daquilo que foi assinado.

A separação de domínio ainda não impede que a mesma mensagem seja entregue duas vezes ao mesmo destino. A própria EIP-712 diz isso: o padrão cobre a assinatura e não inclui proteção contra repetição, então as aplicações precisam recusar a duplicata ou tornar idempotente a ação autorizada. Esse trabalho cabe a um nonce, a um número de sequência ou a um registro de mensagens já consumidas.

O IBC mostra o padrão inteiro montado. Entrega exatamente uma vez é uma propriedade declarada do protocolo: cada pacote carrega um número de sequência, a cadeia receptora escreve um recibo sob esse número, e um pacote cujo recibo já existe é recusado. A especificação observa que esse é o mesmo problema de números de sequência das mensagens assinadas, só que com o cliente leve no papel de signatário. Verificar sem deduplicar é meia ponte.

Riscos de pontes organizados por suposição de confiança: conjuntos externos de validadores, limiares de multisig, cliente leve e verificação otimista, repetição de mensagens e chaves de atualização

As chaves de atualização estão acima de qualquer outra suposição

Tudo acima descreve a regra que uma ponte aplica hoje. A chave de atualização decide quem pode substituir essa regra amanhã.

A maioria dos contratos de ponte é proxy, e a ERC-1967 padroniza onde um proxy guarda sua fiação: um slot de armazenamento para o endereço de implementação ao qual ele delega, outro para o endereço de admin autorizado a trocar essa implementação. Uma transação do admin aponta o proxy para código novo, e código novo pode definir validade como bem entender.

Isso faz da chave de atualização um superconjunto de todos os outros riscos desta página. Um conjunto de validadores de nove chaves, um cliente leve, uma janela de contestação: tudo isso pode ser trocado por quem controla o slot de admin. O teto honesto da segurança de uma ponte é o mais fraco entre o modelo de verificação e o caminho de atualização.

O consolo é que justamente esse dá para conferir. O padrão diz onde olhar e pede que mudanças nesses slots emitam eventos: Upgraded quando a implementação muda e AdminChanged quando o admin muda. Leia o slot de admin. Veja se ele guarda uma única conta externa, um multisig ou um timelock, e, se for timelock, quanto dura o atraso e quem pode cancelar.

Pausas e mudanças de parâmetro merecem a mesma leitura. O poder de parar uma ponte ou de elevar um limite de transferência é menor do que o de reescrever as regras, mas ainda é uma chave na mão de alguém, e uma ponte que pode ser pausada pode ser pausada com sua transferência no meio do caminho.

Em resumo

O risco de ponte se organiza com clareza assim que você pergunta quem verifica. Um conjunto externo de validadores é um sistema à parte cujo limiar é o seu orçamento de segurança, e esse limiar só se sustenta se as chaves por trás dele puderem falhar de forma independente. Clientes leves deslocam a suposição para o consenso da cadeia de origem e a correção do código do cliente; desenhos otimistas a deslocam para ao menos um vigilante seguir vivo e sem obstáculos durante toda a janela. Proteção contra repetição é uma exigência separada: o destino tem de fazer parte do que foi assinado, e cada mensagem precisa de uma sequência ou de um recibo. Acima de tudo isso está a chave de atualização, capaz de trocar o resto em uma única transação. São essas cinco respostas, e não a marca na interface, que você confia ao usar uma ponte.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- Desvinculação e saques do staking: como recuperar seus tokens

- Descentralização de validadores: coeficiente de Nakamoto, diversidade de clientes e concentração

- Economia de validadores: comissão, receita de taxas e ponto de equilíbrio

Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em agosto de 2026; consulte as informações oficiais mais recentes.