O que uma bridge de cripto faz na verdade, e porque tem de guardar o seu dinheiro
Uma bridge de cripto é uma infraestrutura que lhe permite mover um token de uma blockchain para outra. Se detém ETH na mainnet da Ethereum mas quer usá-la na Solana para negociar um token que lá existe, não tem de vender a ETH, levantar para um banco e voltar a comprar do outro lado. Em vez disso, envia a sua ETH para uma bridge e, na outra extremidade, recebe uma versão "wrapped" que representa o seu depósito na nova cadeia.
Para que isto funcione sem um intermediário de confiança, as bridges utilizam quase sempre alguma forma de modelo lock-mint ou burn-mint. A sua ETH original é bloqueada num contrato inteligente na cadeia de origem (ou queimada, o que é funcionalmente igual — a oferta é destruída), e uma quantidade equivalente de ETH "wrapped" (muitas vezes chamada WETH, ou para variantes entre cadeias como a da Wormhole, uma ETH wrapped pela Wormhole) é cunhada na cadeia de destino. Para voltar, queima o token wrapped e o contrato liberta (ou recria) o original na cadeia de origem.
Este design é elegante, mas tem uma consequência estrutural que quem não é de cripto常常 não percebe: em qualquer momento, a bridge está no topo de todos os tokens que os utilizadores já depositaram. Uma bridge que processou mil milhões de dólares em volume pode ter 300 milhões de dólares em custódia no pico. Essa custódia vive num contrato inteligente — e esse único contrato é toda a superfície de ataque. Roube as chaves, comprometa os validadores ou encontre um bug, e leva tudo. Compare com uma DEX (exchange descentralizada) normal como a Uniswap, onde a liquidez está espalhada por milhares de pools independentes e um atacante que esvazia uma pool não compromete as outras. As bridges concentram risco como quase nada em cripto.
Porque é que as bridges continuam a ser hackeadas: as três fragilidades estruturais
Quando se lê sobre uma exploração de bridge — e já houve muitas — as análises pós-incidente descrevem geralmente um bug específico ou uma chave específica comprometida. Mas por baixo de cada uma delas está o mesmo trio de fragilidades estruturais. São elas que tornam as bridges alvos excecionalmente atrativos.
As bridges custodiam um valor enorme num único contrato. O modelo lock-mint significa que o contrato da bridge na cadeia de origem detém os ativos reais, e os tokens wrapped na cadeia de destino são reclamações contra esse pool. Se cunhar na cadeia B sem um bloqueio real na cadeia A, criou tokens wrapped sem respaldo que vão colapsar de preço no momento em que os utilizadores tentarem resgatar. Portanto, todo o modelo de segurança da bridge colapsa sobre esse único contrato, mais a autoridade de cunhagem do outro lado. Uma DEX de mil milhões de dólares é, em termos de atacante, mil honeypots de um milhão. Uma bridge de mil milhões de dólares é um honeypot de mil milhões.
Os contratos das bridges são difíceis de atualizar quando já guardam dinheiro real. Pode pensar: "Basta corrigir o bug." Em teoria, sim. Na prática, os contratos das bridges são intencionalmente não atualizáveis, porque toda a ideia de uma bridge de confiança minimizada é que nenhuma entidade pode mudar as regras depois de ter depositado. Se o responsável pela implementação detivesse uma chave de atualização, poderia dar o golpe nos depositantes numa única transação. Por isso, os contratos são imutáveis — e contratos imutáveis não podem ser corrigidos quando se descobre uma vulnerabilidade. O bug que lançou em 2021 é o bug que é explorado em 2024, porque não há uma entidade central com autoridade para o corrigir sem quebrar a confiança dos utilizadores.
O conjunto de validadores que guarda a bridge é mais pequeno e mais fraco do que o das cadeias que liga. Este é o ponto mais subestimado. A mainnet da Ethereum é protegida por centenas de milhares de validadores. A Solana tem milhares. Uma bridge típica pode ser guardada por um multisig 5 de 9 (uma carteira que exige cinco de nove signatários pré-aprovados para aprovar qualquer ação), ou um pequeno conjunto de validadores que se pode enumerar on-chain. Os atacantes estudam estes conjuntos como ladrões de banco estudam os turnos dos guardas. Se cinco dessas nove chaves forem detidas pela mesma equipa, ou se as chaves estiverem guardadas num servidor hot algures, ou se os membros do multisig nem sequer se conhecerem, a bridge centralizou efetivamente o seu modelo de segurança num punhado de humanos — e os humanos, como a Ronin demonstrou, podem ser alvos de phishing.
Como o modelo de bloqueio-emissão é atacado na prática
Depois de perceberes o modelo de bloqueio-emissão, os padrões de ataque começam a parecer variações sobre o mesmo tema. O atacante não precisa de quebrar a cadeia subjacente. Precisa de quebrar uma de três coisas: o contrato na cadeia de origem que guarda os depósitos, o contrato na cadeia de destino que emite os tokens embrulhados, ou a infraestrutura off-chain que assina mensagens entre cadeias.
Falhas de smart contract na lógica de bloqueio ou emissão. O caso clássico é o Wormhole em fevereiro de 2022. O Wormhole era uma bridge popular entre Ethereum e Solana que permitia aos utilizadores depositar ETH em Ethereum e receber ETH embrulhado em Solana. O atacante encontrou uma falha no código do lado Solana do Wormhole: uma função que a bridge usava para verificar se um depósito realmente tinha acontecido em Ethereum estava a usar uma conta de "conjunto de assinaturas" desatualizada, que o atacante conseguiu substituir por uma falsa. Com uma assinatura falsa em vigor, o atacante convenceu o contrato Solana a emitir 120.000 ETH embrulhados — cerca de 320 milhões de dólares na altura — sem nunca bloquear qualquer ETH real em Ethereum. Quando a poeira assentou, os utilizadores que detinham o token embrulhado em Solana descobriram que o seu "ETH" não tinha qualquer respaldo, e a equipa do Wormhole teve de injetar capital do seu tesouro para ressarcir os depositantes. A falha estava no código, não nas chaves, mas o efeito estrutural foi idêntico.
Compromisso do conjunto de validadores. Se um atacante conseguir reunir chaves ou posições de signatários suficientes que aprovam mensagens entre cadeias, não precisa de qualquer falha. Limita-se a assinar ele próprio uma mensagem fraudulenta, e a bridge libera os fundos obedientemente. O hack da bridge Ronin em março de 2022 é o exemplo canónico. A Ronin era uma sidechain de Ethereum construída para o jogo play-to-earn Axie Infinity, e a sua bridge estava protegida por uma multisig 5-de-9. Cinco desses nove signatários eram operados pela mesma equipa (Sky Mavis, a desenvolvedora do Axie). Os atacantes comprometeram quatro signatários da Sky Mavis e um quinto parceiro, e saíram com cerca de 625 milhões de dólares em USDC e ETH. Não quebraram nenhuma primitiva criptográfica — simplesmente tinham acesso a signatários legítimos suficientes.
Condições de corrida de queima-emissão e falhas de replay. Num modelo de queima-emissão, onde os tokens são destruídos numa cadeia e reemitidos noutra, um atacante pode, por vezes, enganar a bridge para processar a mesma queima duas vezes, ou processar uma queima sem realmente esperar pela confirmação entre cadeias. O hack da bridge Nomad em agosto de 2022 foi uma versão disto: uma atualização de contrato rotineira marcou acidentalmente todas as mensagens como válidas, permitindo que qualquer pessoa chamasse a bridge e levantasse fundos como se tivesse depositado. Cerca de 190 milhões de dólares foram drenados por copycats oportunistas antes de a bridge ser encerrada.
Hacks de bridges famosos, e o que cada um ensina
Ler os post-mortems de hacks de bridges famosos é uma das formas mais rápidas de interiorizar o modelo de ameaça. Cada um demonstra uma fragilidade diferente no mesmo desenho geral.
Wormhole, fevereiro de 2022 — ~320 milhões de dólares. Causa: uma falha de verificação de assinaturas do lado Solana que permitiu ao atacante emitir ETH embrulhado sem respaldo. Lição: mesmo código bem auditado pode ter falhas de lógica na forma como interpreta mensagens entre cadeias. O facto de a bridge ter funcionado perfeitamente durante anos não significava que fosse segura.
Ronin, março de 2022 — ~625 milhões de dólares. Causa: compromisso de cinco das nove chaves da multisig via engenharia social e infraestrutura de um parceiro comprometida. Lição: descentralização de validadores no papel não é o mesmo que descentralização de validadores na prática. A Sky Mavis controlava a maioria dos signatários "apenas por conveniência" e foi essa concentração que foi explorada.
Harmony Horizon, junho de 2022 — ~100 milhões de dólares. Causa: compromisso de uma multisig 2-de-5 que protegia a bridge, via chaves de hot wallet comprometidas. Lição: multisigs com limiares muito baixos e armazenamento de chaves em hot wallets mal se distinguem de um único signatário.
Nomad, agosto de 2022 — ~190 milhões de dólares. Causa: uma atualização de contrato que permitiu acidentalmente levantamentos arbitrários. Lição: contratos de bridge concebidos para serem atualizáveis também podem ser atualizados para um estado vulnerável. A imutabilidade tem dois gumes.
Somando apenas estes quatro incidentes, obténs mais de 1,2 mil milhões de dólares em perdas, num único ano, de uma única categoria de protocolo. Para comparar, todas as outras categorias de hacks cripto combinadas — DEXs, protocolos de empréstimo, wallets, indivíduos — não destroem capital a esse ritmo em relação ao TVL (total value locked, o valor dos ativos depositados num protocolo).
Compromisso do conjunto de validadores vs. falha de smart contract: qual é mais comum?
As falhas de smart contracts recebem mais atenção mediática porque se leem como puzzles. Uma verificação de zero esquecida, uma Merkle root desatualizada, uma proteção contra reentrância que não dispara — são estas as coisas que os auditores destacam, e são nas quais os programadores trabalham para corrigir. O compromisso de validadores é mais confuso. Envolve pessoas, processos internos, infraestrutura off-chain, e por vezes atacantes ao nível de estados-nação. Mas se contares as perdas em dólares, o compromisso de validadores tem sido historicamente a categoria maior, e por larga margem.
Os roubos da Ronin, Harmony, e vários outros mais pequenos foram essencialmente explorações do tipo "quem controla os signatários controla a bridge". Os atacantes não precisaram de encontrar um caminho de código engenhoso; precisaram de uma chave. Isto significa que defender contra eles exige um conjunto de ferramentas diferente do que defender contra falhas de smart contracts: módulos de segurança de hardware (dispositivos de hardware especializados concebidos para manter chaves privadas offline e resistentes a adulteração) em vez de hot wallets, signatários geograficamente distribuídos, criptografia de limiar (onde uma chave privada é dividida em muitas partes, de forma a que nenhum dispositivo ou pessoa possua alguma vez a chave completa) em vez de multisigs estáticas, e monitorização contínua da atividade dos signatários. Nenhuma destas medidas é puramente on-chain, e é por isso que muitas bridges preocupadas com segurança têm migrado para redes de oráculos descentralizadas (serviços que trazem dados do mundo real ou entre cadeias para on-chain usando muitos nós independentes, como a rede alimentada por LINK da Chainlink) e pools de validadores dedicados para espalhar a confiança de forma mais ampla.
Protocolos de mensagens entre cadeias como o LayerZero e o CCIP (Cross-Chain Interoperability Protocol) da Chainlink são uma tentativa de tornar isto menos doloroso. Em vez de cada bridge montar o seu próprio conjunto de validadores, subcontratam a verificação de mensagens a uma rede maior e mais testada em batalha — no caso do CCIP, a rede de oráculos da Chainlink, que foi concebida para exigir o compromisso de muitos operadores de nós independentes para forjar uma mensagem. O trade-off é que trocaste uma pequena assunção de confiança específica da bridge por uma assunção de confiança maior à escala da rede, e deves perceber quais são os modos de falha dessa rede antes de nela confiar.
Segurança partilhada e CCIP como direção alternativa
A leitura honesta sobre o problema das bridges é que nenhum desenho elimina a assunção de confiança — apenas a move. Uma bridge que usa um conjunto pequeno de validadores confia nesses validadores. Uma bridge que usa uma rede de oráculos confia na rede de oráculos. Uma bridge que usa light clients (programas numa cadeia que verificam de forma independente os cabeçalhos de bloco de outra cadeia, eliminando a necessidade de relayers externos) confia que a criptografia e a implementação são sólidas. Uma bridge que usa um bloqueio baseado em hash (o utilizador bloqueia fundos num hashlock numa cadeia e revela um segredo para os reclamar na outra, a base dos protocolos de atomic swap) confia que existe liquidez no lado recetor.
A segurança partilhada é a tentativa mais recente de contornar este problema. A ideia é que, em vez de cada bridge manter o seu próprio conjunto de validadores bespoke, os validadores de uma rede grande e descentralizada — ou das próprias cadeias subjacentes — são reutilizados para verificação entre cadeias. O CCIP da Chainlink é o exemplo mais proeminente em produção hoje: em vez de executar um conjunto paralelo de signatários, a bridge apoia-se na infraestrutura de oráculos existente da Chainlink, mais uma Risk Management Network separada como segunda camada de defesa. O argumento económico é que atacar o CCIP exigiria comprometer simultaneamente a rede de oráculos e a rede de risco, o que é mais dispendioso do que atacar a multisig de uma única bridge.
Isto é uma melhoria real, mas não é uma panaceia. O CCIP herda as assunções de confiança da rede de oráculos da Chainlink. Se essa rede for comprometida, o CCIP fica comprometido. Se surgir um novo modelo de segurança partilhada e 80% das bridges o adotarem, esse modelo torna-se um ponto único de falha para todo o ecossistema entre cadeias. Há uma razão pela qual utilizadores experientes de DeFi ainda dividem transferências grandes por várias rotas e não confiam a nenhuma bridge isolada valores que mudam a vida.
Como avaliar uma bridge antes de a utilizar
Não existe uma bridge "segura". Quem lhe disser o contrário está a tentar vender-lhe algo. Mas há bridges que são mais ou menos arriscadas, e há algumas perguntas que alteram materialmente o risco que assume. Trate isto como uma lista de verificação, não como uma garantia.
Como é distribuída a custódia? Observe a administração on-chain e o conjunto de signatários. Uma multisig 2-de-5 é significativamente mais arriscada do que uma configuração 12-de-20. Verifique se os signatários são entidades independentes ou ramos da mesma equipa. Verifique como as chaves são armazenadas — hot wallets num servidor na cloud são um sinal de alerta; hardware wallets distribuídas por várias localizações geográficas são melhores.
Os contratos são atualizáveis, e por quem? A imutabilidade tem duas faces. Um contrato imutável não pode ser corrigido, o que significa que um bug permanece para sempre. Um contrato atualizável pode ser corrigido, o que significa que um titular de chave malicioso ou comprometido também pode alterar as regras. Leia a documentação para perceber exatamente que poderes de atualização existem e quem os detém.
Foi auditado, e por quem? Uma auditoria não é uma garantia. Uma única auditoria de uma empresa de nível intermédio não é o mesmo que várias auditorias de empresas de topo, além de um programa público de recompensas por bugs. Procure os relatórios de auditoria, veja o que foi encontrado e como a equipa respondeu às conclusões.
Há quanto tempo está em produção e qual o volume processado? Uma bridge que movimentou 20 mil milhões de dólares ao longo de três anos e nunca foi explorada tem algum historial empírico. Uma bridge lançada na semana passada não tem historial nenhum, independentemente de quão bem seja promovida.
Qual é o pior cenário em caso de falha? Leia as análises pós-incidente de ocorrências anteriores e reflita: se a bridge for atacada amanhã, como é que os utilizadores são ressarcidos? Existe um fundo de seguro? O protocolo tem uma tesouraria suficientemente grande para cobrir as perdas? Se a resposta for "nada", deve tratar o seu depósito como 100% em risco a partir do momento em que é feito.
Como acompanhar exploits de bridges de forma inteligente
Os exploits de bridges acontecem rapidamente — quando uma análise pós-incidente é publicada num blog, o próximo incidente já está a germinar. Acompanhar quais as bridges que estão a ser auditadas, quais estão a ser lançadas, quais tiveram incidentes de segurança recentes e como o espaço cross-chain está a evoluir é um trabalho a tempo inteiro se o fizer manualmente. A Zippfeed destaca notícias sobre bridges e interoperabilidade com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa identificar sinais relevantes sem ter de ler todas as threads. Assim, quando uma nova bridge "auditada" é lançada ou um nome conhecido aparece num aviso de segurança, vê-o no contexto certo — não no pânico da enxurrada de tweets pós-ataque.
