Como Pontes de Cripto Movem Bilhões E Por Que Hackers Continuam a Quebrá‑las

Pontes cross-chain já perderam mais dinheiro em 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.

Ainda assim, as pontes são mais importantes hoje do que nunca.

TAC, Celo e dezenas de outros projetos dependem delas para conectar ecossistemas de blockchain separados que, de outro modo, 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.

Resumo rápido

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

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.

Há quatro designs principais de ponte (lock-and-mint, burn-and-mint, pools de liquidez e verificação por 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.

Designs mais novos, com mínima confiança, usando provas de conhecimento zero estão reduzindo a superfície de ataque, mas nenhuma ponte é isenta de risco hoje.

O Que Uma Ponte de Blockchain Realmente Faz

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

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

Cada cadeia 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 movimento cross-chain.

Na prática, os ativos não “se movem” literalmente de uma cadeia para outra. O que acontece é um processo em duas etapas: um ativo é bloqueado (ou queimado) na cadeia de origem e uma representação correspondente é emitida (ou liberada) na cadeia 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 questão de segurança é sempre: quem controla o bloqueio 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.

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

Os Quatro Principais Designs de Ponte

Nem todas as pontes funcionam da mesma maneira. Há quatro padrões arquitetônicos dominantes em produção hoje, e cada um faz um conjunto diferente de trade-offs entre segurança, velocidade, eficiência de capital e descentralização.

Lock-and-Mint é o design mais comum. Um usuário envia tokens para um contrato inteligente na cadeia de origem, onde eles ficam bloqueados. O conjunto de validadores da ponte observa esse depósito e instrui a cadeia de destino a cunhar uma versão “embrulhada” daquele token. Wrapped Bitcoin (WBTC) no Ethereum funciona assim. O mesmo vale para a maior parte do ETH em pontes 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 bloqueio na cadeia de origem é liberado.

Burn-and-Mint é usado quando o emissor de um token controla diretamente a oferta em várias cadeias. Em vez de embrulhar, o token é queimado na cadeia de origem (reduzindo a oferta total ali) e cunhado do zero na cadeia de destino. O Cross-Chain Transfer Protocol (CCTP) da Circle para o USD Coin (USDC) funciona assim. Como a própria Circle autoriza a cunhagem, não há um pool de tokens bloqueados para um invasor roubar, mas você passa a confiar totalmente na Circle.

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

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

Por Que as Pontes Concentram Tantos Riscos

A superfície de ataque de uma ponte é fundamentalmente diferente da superfície de ataque de um único blockchain. Uma cadeia 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 comprometer uma grande fração desse conjunto de validadores simultaneamente, um ataque quase impossivelmente caro.

Um conjunto de validadores de ponte costuma ser muito menor. A ponte Ronin, que atendia o jogo Axie Infinity em sua própria sidechain, era protegida por apenas nove nós validadores. Um invasor precisava controlar cinco deles para autorizar saques. O Lazarus Group, organização de hackers patrocinada 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 saques fraudulentos. As cadeias Ethereum e Ronin subjacentes nunca foram tocadas.

O hack da Ronin não quebrou um blockchain. Ele quebrou um comitê de validadores nove-de-nove 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 cadeias que conectam; é um sistema separado, muitas vezes menor e menos testado em batalha. Quanto mais valor uma ponte detém, 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 em mecanismo, mas semelhante em resultado. Um invasor encontrou um bug no contrato inteligente da Wormhole na Solana que lhe permitiu 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 ocorrera, e cunhou US$ 320 milhões em ETH embrulhado na Solana. Nenhum validador foi comprometido. A vulnerabilidade estava na própria lógica do contrato. A Jump Crypto, apoiadora da Wormhole, repôs os fundos em 24 horas, evitando um colapso de mercado, mas sem desfazer a falha subjacente.

Como Validadores e Oráculos se Encaixam

A maioria das pontes que não são sistemas de light client puros depende de alguma forma 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 desempenham a mesma função: observar uma cadeia e relatar o estado a outra.

A questão de confiança é sempre: o que é preciso 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 feed de preço ou os dados de bloco que o oráculo reporta”. Em um modelo de validadores 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 compartilhado de validadores de ponte. Isso desloca o risco de “uma ponte falha, tudo falha” para “cada aplicação assume seu próprio risco”, o que é uma melhoria significativa em termos de isolamento, mas coloca mais responsabilidade sobre os desenvolvedores para configurar a segurança corretamente.

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

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

Como Provas ZK Estão Mudando a Segurança de 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 tenha que refazer todo o cálculo por conta própria.

Aplicado a pontes, isso significa que uma cadeia de destino pode verificar um evento em uma cadeia 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 de cadeia completa (como a agregação de assinaturas BLS do Proof of Stake do 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 conecta o ecossistema de desenvolvimento EVM do Ethereum à 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 aproximadamente 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 contrapartida dos bridges ZK hoje é a latência. Gerar uma prova para um bloco finalizado do Ethereum pode levar minutos. Para aplicações que exigem finalidade rápida, bridges otimistas com janelas de prova de fraude ainda são frequentemente preferidas, aceitando um atraso maior para retiradas (tipicamente 7 dias nos principais rollups otimistas) em troca de simplicidade.

Also Read: Chainlink’s Wallet Record Turns LINK’s $9 Rebound Into The Main Test

Bridges Nativos Versus Bridges de Terceiros

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

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

A contrapartida é que bridges nativos só vão em uma direção: de L1 para L2 e de volta. Eles não conseguem levar ativos do Ethereum para a Solana, nem mover ativos diretamente entre dois L2 distintos. Para movimentações entre ecossistemas — Ethereum para Solana, ou 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 nativos para movimentação de L1 para L2 quando a prioridade for segurança, e use bridges de terceiros auditados, com histórico comprovado, para movimentação entre ecossistemas quando você aceitar o risco adicional. Verificar se um bridge foi auditado 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: Russian Hackers Found A Signal Weak Spot In Recovery Keys

Quem Realmente Precisa Usar um Bridge

Bridges não são necessários 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 toca em um bridge.

Você precisa de um 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 do Ethereum, mas você quer usar um protocolo DeFi na Arbitrum, você usa o bridge nativo da Arbitrum. Se você quer usar uma aplicação nativa da Solana com USDC que começou no Ethereum, você usa um bridge de terceiros.

Desenvolvedores que constroem aplicações cross-chain são os usuários mais intensivos de bridges. Qualquer protocolo que queira agregar liquidez através de múltiplas cadeias, ou qualquer jogo que queira permitir que jogadores usem ativos em diferentes redes, precisa ter infraestrutura de bridging incorporada ao produto. É por isso que projetos como LayerZero, Axelar, Wormhole e Hyperlane se posicionam como “protocolos de mensagens omni-chain” e não apenas como 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 nativos canônicos ao se mover entre L1 e um grande L2. Para bridges de terceiros, limite a exposição ao que você está disposto a perder, verifique o histórico de auditorias e prefira bridges que operam sem incidentes há pelo menos um ano com TVL significativo. A abordagem “bridge devagar, bridge pequeno” não é timidez, ela reflete o perfil de risco real da tecnologia como existe hoje.

Also Read: Claude Fable 5 May Return As Washington Softens Anthropic Standoff

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 onde ativos e aplicações nunca interagem.

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

Os hacks não são evidência de que bridges sejam inerentemente quebrados.

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 passaram a custodiar.

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 nativos de rollups que herdam diretamente a segurança da L1.