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

Introdução

Blockchains não conversam entre si. Ethereum não consegue ler o estado da Solana. Arbitrum não consegue 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 finalidade. Esse isolamento é uma característica do design de segurança, mas cria um problema prático: usuários mantêm ativos em uma cadeia e querem usá-los em outra.

Pontes existem para resolver isso. Uma ponte é um sistema que permite a um usuário depositar ativos na cadeia A e receber 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 ocorreu. 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 hacks em pontes observou, falhas de segurança em pontes consistentemente decorrem da lacuna entre as premissas de confiança que uma ponte alega e as premissas de confiança que ela realmente impõe.

Este guia cobre como as principais arquiteturas de pontes 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 de ponte

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

1. Bloqueio. 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. Verificação. Um conjunto de validadores, relayers ou um oráculo observa o depósito na cadeia de origem e atesta sua validade na cadeia de destino.
3. Mintagem. Um contrato inteligente na cadeia de destino cria uma versão sintética do token bloqueado. O usuário recebe "ETH embrulhado" ou "USDC em ponte" que representa uma reivindicação sobre o original bloqueado.

Para voltar, o processo é revertido: o usuário queima o token sintético na cadeia de destino, 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 sem lastro. Isso é exatamente o que aconteceu nos maiores exploits de pontes.

O problema aritmético. Pontes lock-and-mint devem manter uma proporção de 1:1 entre originais bloqueados e sintéticos criados. Se 10.000 ETH estão bloqueados na Ethereum, exatamente 10.000 ETH em ponte devem existir na cadeia de destino. Qualquer discrepância significa que alguns tokens em ponte não têm lastro. Quando exploits criam sintéticos sem lastro, os últimos usuários a resgatar encontram o cofre vazio. Isso cria uma dinâmica de corrida bancária: assim 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 ao destruir o original e criar um novo.

1. Queima. O token é permanentemente destruído na cadeia de origem.
2. Verificação. O evento de queima é verificado na cadeia de destino.
3. Mintagem. Novos tokens são criados nativamente na cadeia de destino.

Este modelo funciona apenas para tokens cujos emissores controlam a mintagem em múltiplas cadeias. O Cross-Chain Transfer Protocol (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 USDC nativo é criado na Avalanche. Não há tokens embrulhados, nenhuma fragmentação de liquidez e nenhum sintético sem lastro.

A limitação é que burn-and-mint exige que o emissor do token implante e opere infraestrutura em cada cadeia suportada. Não é um mecanismo de propósito geral. Tokens ERC-20 arbitrários não podem usar burn-and-mint a menos que seus desenvolvedores construam a infraestrutura de mintagem 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 de capital

Um terceiro modelo evita tanto o embrulho quanto a queima usando 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. Saque. O usuário (ou um relayer agindo em seu nome) retira tokens equivalentes de um pool na cadeia de destino.
3. Rebalanceamento. O protocolo rebalanceia periodicamente os pools entre as cadeias para manter liquidez adequada.

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

A desvantagem é a eficiência de capital. A liquidez deve ser pré-posicionada em todas as cadeias suportadas, e esse capital só gera retorno quando as pontes são usadas ativamente. Durante períodos de baixo volume, os provedores de liquidez ganham pouco enquanto seu capital fica ocioso. Os requisitos agregados de capital em todas as cadeias suportadas podem chegar a 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: US$ 624 milhões de chaves comprometidas

Em 23 de março de 2022, invasores drenaram US$ 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 transações da ponte, e qualquer cinco poderiam autorizar um saque. A suposição de segurança era que comprometer cinco dos nove validadores independentes seria impraticável.

A suposição estava errada. 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 invasores (posteriormente atribuídos ao Grupo Lazarus da Coreia do Norte pelo FBI) comprometeram os sistemas da Sky Mavis e obtiveram as chaves privadas de todos os cinco validadores. Com cinco das nove assinaturas, eles autorizaram dois saques fraudulentos: 173.600 ETH e 25,5 milhões de USDC.

A exploração não foi descoberta por seis dias. Ela veio à tona apenas quando um usuário tentou sacar 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 é um ponto único de falha com etapas extras.

O hack da Wormhole: US$ 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 (ETH embrulhado) na Solana sem depositar nenhum ETH na Ethereum. A exploração valia aproximadamente US$ 326 milhões.

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

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

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

Jump Crypto, que apoiava a Wormhole, repôs os 120.000 ETH roubados de suas próprias reservas. A restauração completa aconteceu em 24 horas, uma resposta sem precedentes que evitou perdas em cascata nos protocolos DeFi da Solana que detinham wETH.

A lição. O código de verificação de ponte é uma superfície de ataque de alto valor. Um único erro de lógica em como as assinaturas são validadas pode permitir cunhagem não autorizada ilimitada.

O hack da Nomad: US$ 190 milhões de uma atualização defeituosa

Em 1º de agosto de 2022, a ponte Nomad foi drenada de aproximadamente US$ 190 milhões. Ao contrário de Ronin e Wormhole, a Nomad não foi atacada por um grupo sofisticado. Foi drenada por centenas de imitadores individuais depois que o exploit inicial se tornou público.

A Nomad usava um modelo de verificação otimista. Mensagens entre cadeias eram submetidas e consideradas válidas, a menos que fossem desafiadas dentro de uma janela de 30 minutos. Uma atualização rotineira de contrato introduziu um bug: o contrato foi inicializado com uma raiz confiável de 0x00, o valor zero de bytes32.

Na lógica de verificação da Nomad, cada mensagem era verificada contra a raiz confiável. Como 0x00 é o valor padrão para armazenamento não inicializado em Solidity, toda mensagem passava automaticamente na verificação. Qualquer usuário podia enviar qualquer mensagem e o contrato a aceitava como comprovada.

Assim 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 repetiram. A ponte foi drenada por um enxame de atacantes oportunistas, incluindo hackers de chapéu branco que posteriormente devolveram aproximadamente US$ 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 da Nomad de "verificação otimista com provas de fraude" para "nenhuma verificação".

O hack da Harmony Horizon: US$ 100 milhões de uma multisig de dois de cinco

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

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

A lição. A seleção do limite importa tanto quanto o número de validadores. Uma multisig de cinco de nove oferece segurança significativamente diferente de uma multisig de dois de cinco, mesmo que ambas usem o mesmo mecanismo subjacente.

Perdas cumulativas e padrões de ataque

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

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.

Bypass 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 no nível do código na função mais crítica do contrato da ponte.

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

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 bypass de verificação é mitigado por auditoria e verificação formal. 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. Esse ataque é mais lento e mais visível que os outros, mas visa pontes cuja governança é concentrada ou cujo bloqueio de tempo em atualizações é muito curto. Equipes de pontes cada vez mais usam bloqueios de tempo de vários dias (48 a 72 horas) em 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 às pontes tradicionais

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

Esse modelo reduz a superfície de confiança. O usuário nunca deposita tokens em um contrato de ponte que detém fundos agrupados. O solver 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 mirar.

A troca é a dependência do solver: se nenhum solver 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 solvers é forte. Para rotas de baixo volume, os solvers 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.

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 bloco e provas de estado on-chain. Quando um usuário afirma ter depositado tokens na Ethereum, o contrato da ponte verifica a prova de Merkle contra o cabeçalho de bloco da Ethereum que já validou.

Essa abordagem é minimizada em 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.

Provas de conhecimento zero oferecem uma solução para o problema de custo. Em vez de verificar cada assinatura de validador on-chain, 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. Elas ainda estão amadurecendo, mas representam o modelo de segurança mais forte para comunicação cross-chain: confie na matemática, não no comitê. Implementações iniciais mostram custos de verificação caindo à medida que os sistemas de prova ZK se tornam mais eficientes, com algumas pontes já operando em mainnet com tempos de prova abaixo de 30 segundos.

O que isto não cobre

Este guia explica a mecânica das pontes e as maiores explorações. Ele 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 pontes (Li.Fi, Socket, Bungee)
• A economia do fornecimento de liquidez para pools de pontes
• Protocolos de mensagens cross-chain 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 de cliente leve e verificadas por ZK são as mais fortes. Pontes otimistas ficam no meio. Saiba no que você está confiando.

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

Revise o histórico de auditoria. Contratos de ponte são alvos de alto valor. Procure múltiplas auditorias independentes de empresas respeitáveis. Uma ponte que não foi auditada, ou foi auditada apenas uma vez, merece cautela extra. Preste atenção ao escopo das auditorias: uma auditoria do contrato de 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 US$ 500 milhões com um multisig de cinco de nove apresenta um perfil de risco muito diferente de uma ponte que detém US$ 5 milhões. Atacantes miram pontes onde o pagamento potencial justifica o esforço. O atacante racional calcula se o custo de comprometer chaves suficientes é menor 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 quantia estão corretos. Transações de ponte são tipicamente irreversíveis.

Prefira pontes nativas para rollups. Para rollups L2 da Ethereum (Arbitrum, Optimism, Base), a ponte canônica herda a segurança diretamente do consenso da Ethereum. Pontes de terceiros podem ser mais rápidas, mas introduzem suposições de confiança adicionais. Use pontes canônicas para transferências grandes onde a segurança importa mais do que a velocidade.