Como funcionam as pontes entre cadeias e por que $4 bilhões foram roubados delas

Introdução

As blockchains não se comunicam entre si. Ethereum não consegue ler o estado da Solana. Arbitrum não pode verificar uma transação na Avalanche. Cada cadeia mantém seu próprio livro-razão, seu próprio consenso e suas próprias regras de finalização. Esse isolamento é uma característica do design de segurança, mas cria um problema prático: os usuários possuem ativos em uma cadeia e querem usá-los em outra.

As pontes existem para resolver isso. Uma ponte é um sistema que permite que um usuário deposite ativos na cadeia A e receba ativos correspondentes na cadeia B. O conceito parece simples. A implementação é onde bilhões de dólares foram perdidos.

A dificuldade central é a verificação. Quando um usuário afirma ter depositado 100 ETH na Ethereum e pede 100 ETH na Arbitrum, alguém ou algo deve verificar se o depósito realmente aconteceu. O mecanismo escolhido para essa verificação determina o modelo de segurança da ponte, sua velocidade, seu custo e sua superfície de ataque. Como uma análise da Coinbase sobre os hacks de pontes observou, as falhas de segurança das pontes decorrem consistentemente da lacuna entre as suposições de confiança que uma ponte afirma e as suposições de confiança que realmente impõe.

Este guia cobre como as principais arquiteturas de ponte funcionam, por que cada um dos maiores exploits teve sucesso e o que verificar antes de confiar seus fundos a uma ponte.

Lock-and-mint: o mecanismo original da ponte

O design de ponte mais antigo e comum é o lock-and-mint. O mecanismo funciona em três etapas:

1. Bloquear. O usuário envia tokens para um contrato inteligente na cadeia de origem. Os tokens são bloqueados (mantidos) nesse contrato, não queimados ou transferidos.
2. Verificar. Um conjunto de validadores, retransmissores ou um oráculo observa o depósito na cadeia de origem e atesta sua validade na cadeia de destino.
3. Criar. Um contrato inteligente na cadeia de destino cria uma versão sintética do token bloqueado. O usuário recebe “ETH embrulhado” ou “USDC transferido” que representa uma reivindicação sobre o original bloqueado.

Para voltar, o processo se inverte: o usuário queima o token sintético na cadeia de destino, os validadores atestam a queima e os tokens originais são desbloqueados na cadeia de origem.

A segurança do lock-and-mint depende inteiramente da etapa de verificação. Se um atacante conseguir convencer a cadeia de destino de que um depósito ocorreu quando não ocorreu, ele pode criar tokens não lastreados. Isso é exatamente o que aconteceu nos maiores exploits de pontes.

O problema aritmético. As pontes lock-and-mint devem manter uma proporção de 1:1 entre os originais bloqueados e os sintéticos criados. Se 10.000 ETH estão bloqueados na Ethereum, exatamente 10.000 ETH transferidos devem existir na cadeia de destino. Qualquer discrepância significa que alguns tokens transferidos não têm lastro. Quando exploits criam sintéticos não lastreados, os últimos usuários a resgatar encontram o cofre vazio. Isso cria uma dinâmica de corrida bancária: uma vez que a notícia de um exploit se espalha, cada detentor do token embrulhado corre para resgatar, sabendo que apenas os primeiros a chegar receberão ativos reais.

Burn-and-mint: tokens nativos entre cadeias

Burn-and-mint elimina o problema do token embrulhado destruindo o original e criando um novo.

1. Queimar. O token é permanentemente destruído na cadeia de origem.
2. Verificar. O evento de queima é verificado na cadeia de destino.
3. Criar. Novos tokens são criados nativamente na cadeia de destino.

Esse modelo funciona apenas para tokens cujos emissores controlam a criação em várias cadeias. O Protocolo de Transferência entre Cadeias (CCTP) da Circle para USDC é a maior implementação. Quando um usuário transfere USDC da Ethereum para a Avalanche através do CCTP, o USDC da Ethereum é queimado e o USDC nativo é criado na Avalanche. Não há tokens embrulhados, não há fragmentação de liquidez e não há sintéticos não lastreados.

A limitação é que o mecanismo de queima e cunhagem exige que o emissor do token implemente e opere infraestrutura em cada cadeia suportada. Não é um mecanismo de uso geral. Tokens ERC-20 arbitrários não podem usar queima e cunhagem, a menos que seus desenvolvedores construam a infraestrutura de cunhagem entre cadeias. O CCTP atualmente suporta mais de uma dúzia de cadeias, mas cada integração requer o envolvimento direto da Circle.

Pontes de pool de liquidez: velocidade através do capital
Um terceiro modelo evita tanto a embalagem quanto a queima, utilizando pools de liquidez pré-financiados em cada cadeia.

O mecanismo:

1. Depósito. O usuário deposita tokens em um pool na cadeia de origem.
2. Retirada. O usuário (ou um relayer agindo em seu nome) retira tokens equivalentes de um pool na cadeia de destino.
3. Reequilíbrio. O protocolo reequilibra periodicamente os pools entre cadeias para manter liquidez adequada.

Stargate (construído na LayerZero) e o Across Protocol usam variações desse modelo. A vantagem é a velocidade: como os tokens já existem na cadeia de destino, não há atraso na cunhagem. O usuário recebe tokens reais e nativos imediatamente.

O trade-off é a eficiência de capital. A liquidez deve ser pré-posicionada em cada cadeia suportada, e esse capital gera retorno apenas quando as pontes são ativamente utilizadas. Durante períodos de baixo volume, os provedores de liquidez ganham pouco enquanto seu capital permanece ocioso. Os requisitos de capital agregados em todas as cadeias suportadas podem atingir centenas de milhões de dólares, criando uma barreira de entrada e um risco de concentração se um único provedor de liquidez dominar.

O hack da ponte Ronin: $624 milhões de chaves comprometidas
Em 23 de março de 2022, atacantes drenaram $624 milhões em ETH e USDC da ponte Ronin, que conectava Ethereum à sidechain Ronin usada pelo jogo Axie Infinity.

A ponte Ronin usava um esquema de validação multisig. Nove nós validadores verificavam as transações da ponte, e qualquer cinco poderiam autorizar uma retirada. A suposição de segurança era que comprometer cinco dos nove validadores independentes seria impraticável.

A suposição estava errada. A Sky Mavis, a empresa por trás do Axie Infinity, controlava quatro dos nove nós validadores. Um quinto validador havia concedido à Sky Mavis permissão temporária para assinar em seu nome durante um período de alto volume de transações e nunca revogou a permissão.

Os atacantes (mais tarde atribuídos ao Lazarus Group da Coreia do Norte pelo FBI) comprometeram os sistemas da Sky Mavis e obtiveram as chaves privadas de todos os cinco validadores. Com cinco de nove assinaturas, autorizaram duas retiradas fraudulentas: 173.600 ETH e 25,5 milhões de USDC.

A exploração não foi descoberta por seis dias. Veio à tona apenas quando um usuário tentou retirar 5.000 ETH e descobriu que a ponte não tinha fundos suficientes.

A lição. A segurança multisig é tão forte quanto a independência de seus signatários. Quando uma única organização controla a maioria das chaves, o multisig se torna um único ponto de falha com etapas adicionais.

O hack do Wormhole: $326 milhões de uma bypass de verificação
Em 2 de fevereiro de 2022, um atacante explorou a ponte Wormhole para cunhar 120.000 wETH (wrapped ETH) na Solana sem depositar nenhum ETH na Ethereum. A exploração valia aproximadamente $326 milhões.

A ponte Wormhole dependia de um conjunto de 19 guardiões para verificar mensagens entre cadeias. Os guardiões observavam um depósito na Ethereum, produziam uma atestação assinada (chamada VAA, Verified Action Approval), e o contrato do lado da Solana verificava as assinaturas antes de cunhar.

A vulnerabilidade estava na verificação de assinatura do lado da Solana. O contrato da Wormhole na Solana usava uma instrução de sistema obsoleta (verify_signatures) que não validava corretamente as contas passadas para ela. O atacante criou um conjunto de guardiões falso, submeteu um VAA forjado com assinaturas daquele conjunto falso, e o contrato aceitou como válido.

Na prática, o atacante disse ao contrato Solana "esses guardiões aprovaram esta cunhagem" e o contrato não verificou se os guardiões eram reais.

A Jump Crypto, que apoiou o Wormhole, substituiu os 120.000 ETH roubados de suas próprias reservas. A restauração completa ocorreu em 24 horas, uma resposta sem precedentes que impediu perdas em cascata nos protocolos DeFi da Solana que mantinham wETH.

A lição. O código de verificação da ponte é uma superfície de ataque de alto valor. Um único erro de lógica na validação de assinaturas pode permitir cunhagens não autorizadas ilimitadas.

O hack do Nomad: $190 milhões de uma atualização com falha

Em 1º de agosto de 2022, a ponte Nomad foi drenada de aproximadamente $190 milhões. Ao contrário do Ronin e do Wormhole, o Nomad não foi atacado por um grupo sofisticado. Foi drenado por centenas de imitadores individuais após a exploração inicial se tornar pública.
Você também pode gostar: O hack do Cetus Protocol e a exploração do Sui: A história completa por trás do ataque de $260 milhões

O Nomad usou um modelo de verificação otimista. Mensagens entre cadeias foram enviadas e assumidas como válidas, a menos que contestadas dentro de uma janela de 30 minutos. Uma atualização de contrato de rotina introduziu um bug: o contrato foi inicializado com uma raiz confiável de 0x00, o valor zero bytes32.

Na lógica de verificação do Nomad, cada mensagem era verificada em relação à raiz confiável. Como 0x00 é o valor padrão para armazenamento não inicializado em Solidity, cada mensagem automaticamente passou na verificação. Qualquer usuário poderia enviar qualquer mensagem e o contrato a aceitaria como provada.

Uma vez que o primeiro atacante demonstrou que mensagens arbitrárias eram aceitas, outros copiaram a transação, mudaram o endereço do destinatário e a reproduziram. A ponte foi drenada por uma enxurrada de atacantes oportunistas, incluindo hackers de chapéu branco que mais tarde devolveram aproximadamente $36 milhões em fundos recuperados.

A lição. Bugs de inicialização em contratos de ponte podem ser catastróficos. Um único parâmetro mal configurado transformou o modelo de segurança do Nomad de "verificação otimista com provas de fraude" para "sem verificação alguma."

O hack do Harmony Horizon: $100 milhões de um multisig de dois em cinco

Em junho de 2022, a ponte Harmony Horizon perdeu $100 milhões quando atacantes comprometeram as chaves privadas de dois dos cinco validadores no multisig da ponte. A ponte da Harmony exigia apenas que dois dos cinco signatários aprovassem uma transação, um limite incomumente baixo para uma ponte que detinha $100 milhões.

O ataque reforçou a lição do Ronin: pontes multisig são tão seguras quanto seu conjunto de signatários mais fraco. Quando o limite é baixo em relação ao número de signatários, uma única violação de infraestrutura pode ser suficiente. Pesquisadores de segurança criticaram publicamente o limite de dois em cinco da Harmony antes que o ataque ocorresse.

A lição. A seleção do limite é tão importante quanto a contagem de validadores. Um multisig de cinco em nove oferece segurança significativamente diferente de um multisig de dois em cinco, mesmo que ambos usem o mesmo mecanismo subjacente.

Perdas cumulativas e padrões de ataque

A escala das perdas de ponte é sem precedentes na segurança de contratos inteligentes. Explorações de ponte representam cerca de $3 bilhões dos $17 bilhões em hacks de criptomoedas na última década, tornando as pontes a categoria mais atacada de contratos inteligentes.

Os padrões de ataque se agrupam em três categorias:

Comprometimento de chaves. O atacante obtém chaves suficientes de validadores ou signatários para forjar mensagens de ponte. Ronin e Harmony seguiram esse padrão. A vulnerabilidade não está no código, mas na segurança operacional da infraestrutura de signatários.

Desvio de verificação. O atacante encontra um bug na lógica de verificação que permite que mensagens forjadas passem. Wormhole seguiu esse padrão. A vulnerabilidade é um erro de nível de código na função mais crítica do contrato da ponte.

Erros de inicialização ou atualização. O atacante explora uma má configuração introduzida durante a implantação ou atualização. O Nomad seguiu esse padrão. A vulnerabilidade é processual: a equipe cometeu um erro durante uma operação de rotina.

Cada padrão requer uma defesa diferente. O comprometimento de chaves é mitigado aumentando a diversidade de signatários e usando módulos de segurança de hardware. O desvio de verificação é mitigado por auditorias e verificação formal. Os erros de inicialização são mitigados por procedimentos de atualização que incluem execuções de teste obrigatórias em redes bifurcadas.

Um quarto padrão emergente merece menção: ataques de governança. Um atacante que acumula tokens de governança suficientes para controlar o mecanismo de atualização de uma ponte pode modificar o contrato da ponte para drenar fundos. Este ataque é mais lento e mais visível do que os outros, mas visa pontes cuja governança é concentrada ou cujo bloqueio de tempo nas atualizações é muito curto. As equipes de ponte estão cada vez mais usando bloqueios de tempo de vários dias (48 a 72 horas) nas atualizações de contrato para dar aos usuários tempo para retirar antes que uma mudança maliciosa entre em vigor.

A alternativa baseada em intenção para pontes tradicionais

Uma abordagem mais nova contorna completamente os contratos de ponte usando transferências entre cadeias baseadas em intenção. O Across Protocol e o modo cross-chain do UniswapX permitem que os usuários expressem uma intenção de ponte: "Eu tenho 1.000 USDC na Ethereum e quero 1.000 USDC na Arbitrum." Um solucionador (chamado de relayer) envia imediatamente tokens de seu próprio inventário na cadeia de destino e, em seguida, reclama reembolso mais tarde.

Esse modelo reduz a superfície de confiança. O usuário nunca deposita tokens em um contrato de ponte que mantém fundos agrupados. O solucionador assume o risco de reembolso, e o contrato de liquidação garante que o usuário recebeu a saída prometida. Não há um grande pool de ativos bloqueados para um atacante visar.

A troca é a dependência do solucionador: se nenhum solucionador estiver disposto a preencher a intenção a um preço aceitável, a transferência não é executada. Para rotas de alto tráfego (Ethereum para Arbitrum, Ethereum para Base), a competição entre solucionadores é forte. Para rotas de baixo volume, os solucionadores podem não estar ativos.

Pontes de cliente leve e verificação de conhecimento zero

As explorações acima compartilham uma fraqueza comum: elas dependem de validadores externos ou multisigs para atestar que algo aconteceu em outra cadeia. Se esses atestadores forem comprometidos, a ponte falha.

As pontes de cliente leve adotam uma abordagem diferente. Em vez de confiar em um conjunto de validadores, a cadeia de destino executa um cliente leve que verifica diretamente o consenso da cadeia de origem.

Uma ponte de cliente leve para Ethereum, por exemplo, rastrearia o conjunto de validadores da Ethereum e verificaria cabeçalhos de blocos e provas de estado na cadeia. Quando um usuário afirma ter depositado tokens na Ethereum, o contrato da ponte verifica a prova Merkle contra o cabeçalho do bloco Ethereum que já validou.

Essa abordagem minimiza a confiança: a ponte confia no consenso da cadeia de origem, não em um comitê externo. Mas é cara. Verificar o consenso da Ethereum em outra cadeia requer computação significativa, o que se traduz em altos custos de gás.

As provas de conhecimento zero oferecem uma solução para o problema de custo. Em vez de verificar cada assinatura de validador na cadeia, uma prova ZK pode comprimir a verificação em uma única prova sucinta. A cadeia de destino verifica uma prova em vez de centenas de assinaturas.

Projetos como Succinct Labs, Polymer e Lagrange estão construindo pontes verificadas por ZK. Estas ainda estão amadurecendo, mas representam o modelo de segurança mais forte para comunicação entre cadeias: confie na matemática, não no comitê. Implementações iniciais mostram que os custos de verificação estão caindo à medida que os sistemas de prova ZK se tornam mais eficientes, com algumas pontes já operando na mainnet com tempos de prova abaixo de 30 segundos.

O que isso não cobre

Este guia explica a mecânica das pontes e as maiores explorações. Não cobre:

• Estratégias de ponte específicas para tokens ou qual ponte usar para um determinado ativo
• Comparação detalhada de agregadores de ponte (Li.Fi, Socket, Bungee)
• A economia da provisão de liquidez para pools de ponte
• Protocolos de mensagens entre cadeias além de sua função de ponte (LayerZero, Axelar, Chainlink CCIP como camadas de mensagens gerais)

Verificações práticas antes de usar uma ponte

Verifique o mecanismo de verificação. Pontes multisig são o modelo mais fraco. Pontes verificadas por clientes leves e ZK são as mais fortes. Pontes otimistas ficam entre os dois. Saiba em quem você está confiando.

Observe o conjunto de validadores ou guardiões. Para pontes multisig, verifique quantos signatários existem, quem os opera e se são genuinamente independentes. Se a maioria dos signatários pertence à mesma organização ou jurisdição geográfica, a multisig oferece segurança limitada.

Revise o histórico de auditoria. Contratos de ponte são alvos de alto valor. Procure por múltiplas auditorias independentes de empresas respeitáveis. Uma ponte que não foi auditada, ou que foi auditada apenas uma vez, requer cautela extra. Preste atenção ao escopo das auditorias: uma auditoria do contrato do token não cobre a lógica de verificação.

Considere o valor total bloqueado versus o orçamento de segurança. Uma ponte que detém $500 milhões com uma multisig de cinco de nove apresenta um perfil de risco muito diferente de uma ponte que detém $5 milhões. Atacantes visam pontes onde o pagamento potencial justifica o esforço. O atacante racional calcula se o custo de comprometer chaves suficientes é menor do que o valor que pode ser extraído.

Teste com pequenas quantias primeiro. Antes de transferir um valor significativo, envie uma pequena transação de teste. Verifique se o endereço de recebimento, token e valor estão corretos. Transações de ponte são tipicamente irreversíveis.

Prefira pontes nativas para rollups. Para rollups L2 do Ethereum (Arbitrum, Optimism, Base), a ponte canônica herda segurança diretamente do consenso do Ethereum. Pontes de terceiros podem ser mais rápidas, mas introduzem suposições de confiança adicionais. Use pontes canônicas para grandes transferências onde a segurança importa mais do que a velocidade. Leia mais: O que são pontes entre cadeias? Por que continuam sendo hackeadas

O que é uma ponte entre cadeias? {#faq-question-4160687517}

Uma ponte entre cadeias é um sistema que transfere ativos ou dados entre duas blockchains que não podem se comunicar nativamente. A ponte bloqueia, queima ou agrupa tokens em uma cadeia e emite tokens correspondentes em outra, usando um mecanismo de verificação para garantir que a transferência seja legítima.

Por que as pontes foram hackeadas com tanta frequência? {#faq-question-1765570890}

As pontes são alvos de alto valor porque mantêm grandes pools de ativos bloqueados. Elas também introduzem suposições de confiança complexas na fronteira entre dois modelos de segurança diferentes. Uma vulnerabilidade no mecanismo de verificação (chaves comprometidas, verificações de assinatura defeituosas, bugs de inicialização) pode permitir que um atacante drene todo o pool em uma única transação.

Qual é a diferença entre lock-and-mint e burn-and-mint? {#faq-question-0293370535}

Lock-and-mint mantém o token original na cadeia de origem e cria uma versão sintética (embrulhada) na cadeia de destino. Burn-and-mint destrói o original e cria um novo token nativo na cadeia de destino. Burn-and-mint produz tokens nativos em vez de sintéticos, mas requer que o emissor do token controle a criação em ambas as cadeias.

Os tokens embrulhados são seguros? {#faq-question-3820965888}

Tokens embrulhados são tão seguros quanto a ponte que os emitiu. Se a ponte for explorada e os ativos de suporte forem drenados, os tokens embrulhados se tornam sem lastro e perdem seu valor. Usuários que possuem tokens embrulhados suportam o risco de segurança da ponte, não apenas o risco do ativo subjacente.

Quanto tempo leva para fazer a ponte? {#faq-question-8084085272}

Varía de acordo com o mecanismo. As pontes de pool de liquidez e as pontes baseadas em intenção (Across) podem ser concluídas em segundos. As pontes de bloqueio e mint com verificação multisig geralmente levam de 10 a 30 minutos. As pontes otimistas com janelas de prova de fraude podem levar 7 dias para retiradas de rollups otimistas para Ethereum, embora pontes rápidas possam antecipar a liquidez para reduzir isso.

O que é uma ponte de cliente leve? {#faq-question-5264913434}

Uma ponte de cliente leve verifica o consenso da cadeia de origem diretamente na cadeia de destino, em vez de depender de um conjunto de validadores externos. Ela verifica cabeçalhos de bloco e provas de estado, confiando na própria segurança da cadeia de origem. Isso é mais minimizado em termos de confiança do que a verificação multisig ou otimista, mas custa mais gás para operar.

Posso perder dinheiro usando uma ponte? {#faq-question-7660039976}

Sim. Se a ponte for explorada após você ter depositado, mas antes de ter retirado, seus tokens bloqueados podem ser roubados. Se você possui tokens embrulhados e a ponte for hackeada, seus tokens embrulhados podem se tornar sem valor. Além disso, endereços de destino incorretos ou tipos de tokens não suportados podem resultar em perda permanente.

Qual ponte devo usar? {#faq-question-1819675312}

Nenhuma ponte única é a melhor para todas as situações. Para USDC, o CCTP da Circle é a opção mais segura porque utiliza burn-and-mint sem tokens embrulhados. Para transferências gerais de ERC-20, compare os mecanismos de verificação das pontes disponíveis. Prefira pontes com verificação de cliente leve ou ZK, múltiplas auditorias independentes e um histórico de operação segura. Agregadores de pontes como Li.Fi podem ajudar a comparar rotas.

*Aviso: Este artigo é apenas para fins informativos e não constitui aconselhamento financeiro, de investimento ou legal. Criptomoeda envolve risco significativo, e você deve conduzir sua própria pesquisa antes de tomar qualquer decisão. As informações são precisas até agosto de 2026.*