Porque é que as pontes cripto são o ponto mais vulnerável do ecossistema Web3 (e como está a mudar)

As pontes cripto (do inglês "bridges") permitem a transferência de ativos e dados entre diferentes redes blockchain que, por si só, não conseguem "comunicar" entre si.

Sem elas, não existiriam transferências de ETH para Solana, BTC wrapped na Ethereum, nem a liquidez que flui entre dezenas de soluções Layer 2.

Mas é precisamente este papel de intermediário que tornou as pontes num dos alvos mais frequentes de ataques no espaço cripto. O motivo não é acaso, mas sim a própria arquitetura sobre a qual são construídas.

Porque é que as pontes são estruturalmente vulneráveis

No essencial, cada ponte faz uma única coisa: bloqueia (ou queima) o ativo na cadeia de origem e emite uma versão equivalente, "wrapped", na cadeia de destino.

Isto significa que, algures, tem de existir um contrato, o chamado vault, onde se encontra depositado todo o valor bloqueado. Este contrato representa um ponto de risco único e concentrado: enquanto as consequências de um ataque a uma plataforma DeFi individual costumam limitar-se aos seus próprios utilizadores, as consequências de um ataque a uma ponte podem afetar todos os que alguma vez tenham transferido fundos através dela.

O segundo problema é o modelo de confiança. A maioria das pontes continua, ainda hoje, a depender de um conjunto de validadores ou de signatários multisig que confirmam que uma transação na cadeia de origem realmente ocorreu antes de autorizarem a libertação de fundos na cadeia de destino.

Este modelo é rápido e económico de implementar, mas resume-se a confiar num número limitado de pessoas e nas suas chaves privadas, e são precisamente estas chaves o ponto de compromisso mais frequente, seja através de roubo, engenharia social ou ataques de phishing dirigidos a signatários específicos.

Por fim, uma ponte tem de conciliar a cadeia de origem e a de destino: dois sistemas que, muitas vezes, apresentam uma lógica de consenso, uma velocidade de finalidade das transações e uma forma de registo do estado completamente diferentes.

Por exemplo, a Bitcoin regista os fundos através do modelo UTXO ("moedas" individuais que são gastas), enquanto a Ethereum ou a Solana utilizam um modelo de contas (o estado é atualizado dentro de uma conta, à semelhança de um extrato bancário).

Quando uma ponte tem de traduzir um evento de um sistema para outro, a equipa de desenvolvimento tem de modelar manualmente essa diferença no código do contrato, e é precisamente nessa tradução, na lógica que verifica se uma assinatura ou uma prova é realmente válida, que surgem com mais frequência erros subtis, difíceis de detetar mesmo durante auditorias minuciosas.

A dimensão do problema

A história confirma isto com números.

Tomemos como exemplo a ponte Ronin, que em 2022 dava suporte ao jogo Axie Infinity: esta ponte exigia as assinaturas de cinco em nove validadores para aprovar transações.

Imaginem isto como um cofre que só abre se cinco de nove guardas rodarem a chave em simultâneo.

Os atacantes ligados ao grupo norte-coreano Lazarus não violaram a criptografia; em vez disso, enganaram os funcionários da empresa que controlava quatro das nove chaves através de uma falsa proposta de emprego.

Obtiveram a quinta chave porque uma organização DAO (uma comunidade descentralizada que vota nas decisões) tinha, anteriormente, concedido à ponte uma autorização temporária para usar a sua assinatura - autorização essa que nunca chegou a ser revogada.

Assim, em vez de invadirem o sistema, simplesmente reuniram "guardas" suficientes - e pagaram a si próprios 173.600 ETH e 25,5 milhões de USDC.

Nesse mesmo ano, ocorreram mais dois ataques semelhantes.

A ponte Wormhole perdeu 320 milhões de dólares depois de conseguir falsificar a assinatura de um dos seus validadores "guardian"; o contrato não detetou a falsificação e autorizou o pagamento.

A ponte Nomad perdeu quase 200 milhões de dólares de uma forma ainda mais peculiar: a primeira pessoa que descobriu uma falha que permitia levantar fundos sem uma prova válida explorou-a, e assim que a notícia se espalhou, centenas de outros utilizadores repetiram a mesma transação, deixando a ponte sem uma parte significativa dos seus fundos em poucas horas.

Somando tudo isto, o panorama torna-se claro. Segundo a empresa de análise Chainalysis, só no período de 2021-2023 foram roubados mais de 2,5 mil milhões de dólares de pontes, enquanto estimativas mais alargadas situam as perdas totais das pontes desde 2021 até hoje em mais de 2,8 mil milhões de dólares.

O aspeto mais interessante em todos estes números é o padrão que se repete: quase todas as grandes perdas ocorreram em pontes que dependem de um número limitado de pessoas ou validadores para confirmar se uma transação é válida (as chamadas pontes de menor confiança).

As pontes que, em vez de pessoas, utilizam verificação criptográfica e matemática - sobre a qual falaremos mais adiante - mantiveram-se, até agora, praticamente intocadas. Por outras palavras, o risco aumenta em todos os pontos em que a segurança de uma ponte depende do comportamento de indivíduos, em vez de uma verificação criptográfica.

Como a situação está a mudar

A indústria retirou uma lição clara destes ataques: a solução a longo prazo não é um multisig mais forte, mas sim a eliminação completa do elemento humano do processo de verificação.

Daqui surgem três direções de desenvolvimento que atualmente moldam uma geração mais segura de pontes.

Verificação por light client e zero-knowledge

Em vez de confiar num grupo de validadores, a cadeia de destino verifica ela própria o que aconteceu na cadeia de origem, de forma semelhante a quando alguém revê pessoalmente documentos em vez de confiar na palavra de outra pessoa de que estão corretos.

Numa variante mais avançada, é utilizada uma prova zero-knowledge: um registo matemático que confirma que a transação ocorreu, sem que ninguém tenha de voltar a verificar todo o histórico da cadeia.

A segurança da ponte já não depende, assim, de os validadores serem honestos, mas apenas de a matemática estar correta.

O protocolo IBC da Cosmos utiliza esta abordagem há já vários anos, e um número crescente de pontes Ethereum está a adotar um modelo semelhante, ainda que este tipo de infraestrutura seja mais difícil e demorada de construir.

Pontes nativas e canónicas

Quando uma ponte "envolve" (wrap) um ativo, cria, na realidade, uma nova versão sintética do token, que representa o original bloqueado noutro local.

Por exemplo, o BTC wrapped na Ethereum não é Bitcoin genuína, mas sim uma nota promissória que vale apenas o que o contrato que a emite valer. Cada uma destas versões wrapped constitui um ponto adicional que requer o seu próprio nível de segurança.

Por isso, um número crescente de projetos está a optar por uma abordagem diferente: em vez de envolver o token, este é queimado numa cadeia e é emitido um token idêntico e canónico na outra.

É exatamente isto que o protocolo da Circle para o USDC faz. O resultado é um menor número de "versões" diferentes do mesmo token em circulação, o que simplifica todo o sistema e reduz o número de componentes com que é preciso preocupar-se.

Redes de verificadores distribuídas

Em vez de fazer depender toda a segurança da ponte de um único conjunto fixo de validadores, as arquiteturas mais recentes combinam várias redes independentes que verificam mutuamente o seu trabalho, fazendo com que cada rede adicional aumente a fiabilidade global do sistema.

A isto juntam-se, cada vez com maior frequência, mecanismos de "travagem" adicionais: timelocks que atrasam pagamentos de maior valor para deixar margem de reação, pausas automáticas assim que o sistema deteta algo invulgar, e seguros que compensam os clientes pelas suas perdas caso, ainda assim, ocorra uma falha de segurança.

Orientações práticas

A mensagem é simples: cada ponte é um componente ativo do sistema, e não apenas um canal neutro através do qual os ativos passam.

Cada ponte tem o seu próprio perfil de risco, consoante dependa de pessoas ou de criptografia.

Antes de transferir um valor considerável através de qualquer ponte, vale a pena verificar que modelo de verificação utiliza, há quanto tempo opera sem incidentes e se foi objeto de auditoria independente.

Um futuro mais seguro para a interoperabilidade da Web3 constrói-se precisamente reduzindo o número de pontos onde a confiança tem de ser depositada em pessoas, e cada vez mais nos pontos em que esta é simplesmente substituída pela matemática.