Como pontes de cripto movem bilhões e por que hackers continuam a quebrá-las

Pontes cross-chain perderam mais dinheiro com exploits do que quase qualquer outra categoria em cripto.

A ponte Ronin perdeu US$ 625 milhões em 2022. A Wormhole perdeu US$ 320 milhões no mesmo ano. A Nomad perdeu US$ 190 milhões poucos meses depois.

Mesmo assim, as pontes são mais importantes agora do que nunca.

TAC, Celo e dezenas de outros projetos dependem delas para conectar ecossistemas de blockchain separados que, de outra forma, não conseguiriam se comunicar.

Entender por que as pontes são ao mesmo tempo indispensáveis e perigosas começa por entender o que elas realmente fazem em nível técnico.

TL;DR

Uma ponte de blockchain é um software que bloqueia ativos em uma rede e emite representações equivalentes em outra, permitindo que o valor circule entre redes isoladas.

As pontes são alvos de alto valor porque mantêm a custódia de ativos bloqueados — às vezes bilhões de dólares — em contratos inteligentes ou carteiras multisig.

Existem quatro principais modelos de ponte (lock-and-mint, burn-and-mint, pools de liquidez e verificação via light client), cada um com diferentes trade-offs de segurança.

A maioria dos grandes hacks explorou comprometimento de chaves de validadores, manipulação de oráculos ou bugs de lógica em contratos inteligentes, não os blockchains em si.

Novos modelos com confiança minimizada usando provas de conhecimento zero estão reduzindo a superfície de ataque, mas nenhuma ponte é totalmente livre de risco hoje.

O que uma ponte de blockchain realmente faz

Dois blockchains são, por padrão, sistemas completamente isolados.

O Bitcoin (BTC) não tem nenhuma consciência do Ethereum (ETH). O Ethereum não consegue ler nativamente uma atualização de estado da Solana (SOL).

Cada rede processa suas próprias transações, mantém seu próprio livro-razão e alcança consenso de forma independente. Não existe memória compartilhada entre elas.

Uma ponte é a camada de software que cria a ilusão de movimentação entre redes.

Na prática, os ativos não “se movem” literalmente de uma rede para outra. O que acontece de fato é um processo em duas etapas: um ativo é bloqueado (ou queimado) na rede de origem e uma representação correspondente é emitida (ou liberada) na rede de destino.

O protocolo da ponte coordena esses dois eventos e garante que estejam vinculados.

Uma ponte não teletransporta seus tokens. Ela os bloqueia de um lado e imprime um IOU do outro — a pergunta de segurança é sempre: quem controla o cadeado e quem autoriza a impressão?

Essa distinção é extremamente importante para a segurança.

O ativo original fica sob custódia em algum lugar. Essa custódia é a superfície de ataque.

Seja um contrato inteligente, uma carteira multisig controlada por um comitê de validadores ou um sistema de provas criptográficas — isso determina quase tudo sobre o quão segura é a ponte.

Veja também: Bitget bloqueou 150M ataques cibernéticos em um ano, revela novo relatório

Os quatro principais modelos de ponte

Nem todas as pontes funcionam da mesma forma. Existem quatro arquiteturas dominantes em produção hoje, e cada uma faz um conjunto diferente de trade-offs entre segurança, velocidade, eficiência de capital e descentralização.

Lock-and-Mint é o modelo mais comum. Um usuário envia tokens para um contrato inteligente na rede de origem, onde eles são bloqueados. O conjunto de validadores da ponte observa esse depósito e instrui a rede de destino a cunhar uma versão “embrulhada” daquele token. O Wrapped Bitcoin (WBTC) no Ethereum funciona assim. O mesmo vale para a maior parte do ETH ponteado nas primeiras redes de Layer 2. O token embrulhado representa uma reivindicação sobre o original bloqueado. Quando o usuário quer voltar, ele queima o token embrulhado e o cadeado na rede de origem é liberado.

Burn-and-Mint é usado quando o emissor de um token controla diretamente a oferta em múltiplas redes. Em vez de embrulhar, o token é queimado na rede de origem (reduzindo a oferta total ali) e cunhado do zero na rede de destino. O Cross-Chain Transfer Protocol (CCTP) da Circle para o USD Coin (USDC) funciona assim. Como é a própria Circle que autoriza a emissão, não existe um pool de tokens bloqueados para um atacante roubar, mas você está confiando totalmente na Circle.

Pontes com pools de liquidez, como as usadas pelo Hop Protocol e Across Protocol, funcionam de modo diferente. Em vez de bloquear ativos e emitir representações, elas dependem de provedores de liquidez que mantêm o token nativo em ambos os lados. Um usuário deposita na rede de origem, e um provedor de liquidez na rede de destino envia imediatamente o token nativo equivalente. Depois, o LP é reembolsado pelo protocolo. Essa abordagem é mais rápida e evita tokens embrulhados, mas depende de liquidez suficiente e introduz risco de contraparte para os LPs.

Verificação via Light Client é o modelo com menos necessidade de confiança e o mais difícil de construir. Aqui, a rede de destino executa uma prova criptográfica do consenso da rede de origem diretamente dentro de um contrato inteligente ou de um circuito ZK. Não é necessário um comitê externo de validadores; a matemática prova que o depósito aconteceu. O IBC (Inter-Blockchain Communication), o padrão de ponte usado entre as redes do Cosmos (ATOM), se aproxima desse modelo. Pontes baseadas em ZK, como o SP1 da Succinct e o zkBridge da Polyhedra, vão além ao usar provas de conhecimento zero para verificar transições de estado de forma barata.

Veja também: HIVE acaba de tomar emprestado US$ 115M a juros zero para apostar contra a mineração de Bitcoin

Por que as pontes concentram tanto risco

A superfície de ataque de uma ponte é fundamentalmente diferente da superfície de ataque de um único blockchain. Uma rede como o Ethereum é protegida por centenas de bilhões de dólares em ETH em stake e centenas de milhares de validadores. Comprometê-la exige atacar uma grande fração desse conjunto de validadores ao mesmo tempo — um ataque quase impossivelmente caro.

O conjunto de validadores de uma ponte costuma ser muito menor. A ponte Ronin, que atendia ao jogo Axie Infinity em sua própria sidechain, era protegida por apenas nove nós validadores. Um atacante precisava controlar cinco deles para autorizar retiradas. O Lazarus Group, o grupo de hackers patrocinado pelo Estado norte-coreano, comprometeu cinco chaves privadas por meio de uma combinação de phishing e uma falsa oferta de emprego. Eles autorizaram US$ 625 milhões em retiradas fraudulentas. Os blockchains subjacentes Ethereum e Ronin nunca foram tocados.

O hack da Ronin não quebrou um blockchain. Ele quebrou um comitê de nove validadores em que cinco chaves eram mantidas de forma insegura. A ponte era o elo mais fraco por design.

Esse é o problema estrutural das pontes validadas externamente. A segurança delas não é herdada das redes que conectam; é um sistema separado, muitas vezes menor e menos testado em batalha. Quanto mais valor uma ponte guarda, mais atraente ela se torna como alvo, mas o modelo de segurança não escala automaticamente com os ativos sob custódia.

O exploit da Wormhole em fevereiro de 2022 foi diferente no mecanismo, mas similar no resultado. Um atacante encontrou um bug no contrato inteligente da Wormhole na Solana que permitia falsificar um evento de “verificação de assinatura do guardião”. Ele convenceu o contrato de que 120.000 ETH haviam sido depositados no Ethereum quando isso não tinha acontecido, e cunhou US$ 320 milhões em ETH embrulhado na Solana. Nenhum validador foi comprometido. A vulnerabilidade estava na lógica do próprio contrato. A Jump Crypto, apoiadora da Wormhole, repôs os fundos em menos de 24 horas, o que evitou um colapso de mercado, mas não desfez a falha estrutural.

Veja também: Usuários da Polymarket perdem US$ 3,1M em ataque ao frontend enquanto investigação da CFTC continua

Como validadores e oráculos se encaixam nisso

A maioria das pontes que não são sistemas puros de light client depende de algum tipo de observador externo para confirmar que um depósito aconteceu e autorizar a cunhagem ou liberação correspondente.

Esses observadores recebem nomes diferentes — validadores, relayers, guardians, attestors —, mas exercem a mesma função: observar uma rede e reportar o estado para outra.

A pergunta de confiança é sempre: o que é necessário para fazer esses observadores mentirem?

Em um modelo multisig, a resposta é “comprometer chaves suficientes”. Em um modelo baseado em oráculos, a resposta pode ser “manipular o preço ou os dados de bloco que o oracle reporta”. Em um modelo de validadores com proof-of-stake, a resposta é “adquirir stake suficiente para controlar uma supermaioria”.

A LayerZero usa um modelo em que cada aplicação configura seu próprio conjunto de oráculos e relayers, criando segurança específica por aplicação em vez de um conjunto de validadores de ponte compartilhado. Isso desloca o risco de “se uma ponte falhar, tudo falha” para “cada aplicação arca com seu próprio risco”, o que é uma melhoria significativa em termos de isolamento, mas coloca mais responsabilidade nos desenvolvedores para configurar a segurança corretamente.

A Axelar usa uma rede de proof-of-stake com validadores próprios para observar eventos cross-chain. Assim, a segurança da ponte fica atrelada ao valor do token da própria Axelar em stake pelos validadores — um modelo semelhante ao de um blockchain de Layer 1, mas voltado para mensagens entre redes.

O desafio fundamental é que você não consegue verificar nativamente o estado de uma rede estrangeira sem rodar o full node daquela rede, o que é caro. Abordagens com light clients e ZK resolvem isso criptograficamente. Todo o resto envolve confiar em um intermediário para reportar honestamente.

Veja também: Ethereum caminha para US$ 1.000 após perder suporte-chave?

Como provas ZK estão mudando a segurança das pontes

Provas de conhecimento zero são a solução de longo prazo mais promissora para o problema de confiança em pontes. Uma prova ZK permite que uma parte prove a outra que uma afirmação é verdadeira, como “esta transação foi incluída em um bloco finalizado no Ethereum”, sem que o verificador precise refazer todo o processamento por conta própria.

Aplicado a pontes, isso significa que a rede de destino pode verificar um evento da rede de origem criptograficamente, sem confiar em nenhum validador externo. A própria prova é a atestação. Um validador comprometido não consegue forjar uma prova ZK válida. Não há chaves privadas para serem roubadas. A segurança deriva da matemática.

O desafio prático é o custo computacional. Gerar provas ZK para consenso completo de cadeia (como a agregação de assinaturas BLS do Proof of Stake da Ethereum sobre milhares de validadores) exige um trabalho computacional substancial, embora esse custo tenha caído dramaticamente à medida que a tecnologia de provas ZK amadureceu. Equipes como Succinct Labs, =nil; Foundation e Polyhedra estão construindo sistemas de prova especificamente otimizados para verificação de estado de blockchain.

A TAC, a Layer 1 em tendência agora no CoinGecko, adota uma abordagem específica para esse problema: ela faz a ponte entre o ecossistema de desenvolvedores EVM da Ethereum e a base de usuários da TON (The Open Network) e do Telegram, usando um modelo híbrido de validadores e provas. Projetos como a TAC ilustram a demanda prática por bridges; o Telegram tem cerca de 950 milhões de usuários ativos mensais, e conectar esse público a aplicações compatíveis com Ethereum exige exatamente o tipo de infraestrutura cross-chain que as bridges fornecem.

A compensação dos bridges ZK hoje é a latência. Gerar uma prova para um bloco finalizado da Ethereum pode levar minutos. Para aplicações que exigem finalização rápida, bridges otimistas com janelas de prova de fraude ainda costumam ser preferidas, aceitando um atraso maior no saque (tipicamente 7 dias nos principais optimistic rollups) em troca de simplicidade.

Also Read: O Registro De Carteiras Da Chainlink Transforma O Rebate De US$ 9 Do LINK No Principal Teste

Bridges Nativos Versus Bridges de Terceiros

Quando você move ativos entre uma Layer 1 e seu rollup de Layer 2, normalmente está usando uma “bridge nativa”, uma bridge construída e mantida pela própria equipe do rollup, profundamente integrada ao modelo de segurança do próprio rollup. A bridge nativa da Arbitrum (ARB), a bridge nativa da Optimism (OP) e a bridge nativa da zkSync se enquadram nessa categoria.

As bridges nativas herdam grande parte das garantias de segurança do próprio rollup. Em um optimistic rollup, uma retirada fraudulenta pode ser contestada durante a janela de 7 dias de prova de fraude. Em um ZK rollup, uma retirada só é finalizada quando uma prova ZK válida do lote de transações é publicada na Ethereum. Essas são garantias significativamente mais fortes do que a maioria das bridges de terceiros.

A contrapartida é que bridges nativas só vão em uma direção: de L1 para L2 e de volta. Elas não conseguem fazer bridge de ativos da Ethereum para Solana, nem mover ativos diretamente entre duas L2 distintas. Para movimentação entre ecossistemas, de Ethereum para Solana ou de Arbitrum para Polygon (POL), os usuários precisam usar bridges de terceiros, que carregam os riscos de validadores e de contratos inteligentes descritos acima.

Isso cria uma taxonomia prática: use bridges nativas para movimentação de L1 para L2 quando a prioridade é segurança, e use bridges de terceiros auditadas e com histórico consolidado para movimentação entre ecossistemas quando você aceita o risco adicional. Verificar se uma bridge foi auditada por uma empresa de segurança respeitável (Trail of Bits, OpenZeppelin, Certik, Spearbit) e revisar qualquer histórico prévio de exploits é a diligência mínima antes de usar qualquer serviço de transferência cross-chain.

Also Read: Hackers Russos Encontraram Um Ponto Fraco Nas Chaves De Recuperação Do Signal

Quem De Fato Precisa Usar Uma Bridge

Bridges não são necessárias para a maioria dos usuários casuais de cripto. Se você mantém Bitcoin (BTC) ou Ethereum (ETH) em uma exchange centralizada e só quer exposição ao movimento de preço, você nunca chega a usar uma bridge.

Você precisa de uma bridge quando quer usar uma aplicação que vive em uma cadeia diferente daquela onde seus ativos estão. Se seu ETH está na mainnet da Ethereum, mas você quer usar um protocolo DeFi na Arbitrum, você faz bridge pela bridge nativa da Arbitrum. Se quiser usar uma aplicação nativa da Solana com USDC que começou na Ethereum, você usa uma bridge de terceiros.

Desenvolvedores que constroem aplicações cross-chain são os usuários mais pesados de bridges. Qualquer protocolo que queira agregar liquidez entre múltiplas cadeias, ou qualquer jogo que queira permitir que jogadores usem ativos em diferentes redes, precisa ter infraestrutura de bridging embutida no produto. É por isso que projetos como LayerZero, Axelar, Wormhole e Hyperlane se posicionam como “protocolos de mensagens omnichain” em vez de apenas bridges: eles são infraestrutura para desenvolvedores, não apenas para usuários finais movendo tokens.

Para usuários comuns, a orientação prática é direta. Use bridges nativas canônicas ao se mover entre L1 e uma grande L2. Para bridges de terceiros, limite a exposição ao que você está disposto a perder, verifique o histórico de auditorias e dê preferência a bridges que operam sem incidentes há pelo menos um ano com TVL relevante. A abordagem “faça bridge devagar, faça bridge com pouco” não é timidez; ela reflete o perfil de risco honesto da tecnologia como existe hoje.

Also Read: Claude Fable 5 Pode Retornar À Medida Que Washington Suaviza O Impasse Com A Anthropic

Considerações Finais

Bridges cross-chain resolvem um problema real e inevitável.

Blockchains são sistemas soberanos. Sem bridges, o cripto seria um conjunto de silos isolados em que ativos e aplicações nunca interagem.

A interoperabilidade que as bridges permitem sustenta a maior parte do DeFi, dos games e do ecossistema multi-chain que projetos como a TAC estão ativamente construindo.

Os hacks não são evidência de que as bridges são inerentemente quebradas.

Eles são evidência de que os primeiros designs de bridges fizeram concessões agressivas de segurança — comitês pequenos de validadores, lógica de contratos inteligentes não auditada, dependências de oráculos — que não eram proporcionais ao valor que acabaram custodiando.

Cada exploit importante empurrou a indústria em direção a designs melhores: conjuntos maiores de validadores, verificação formal, sistemas de prova baseados em ZK e bridges nativas de rollup que herdam diretamente a segurança da L1.