Porque é que as mensagens cross-chain são mais difíceis do que parecem
Mover um token de Ethereum para Solana, ou de uma app-chain Cosmos para um rollup, parece à superfície uma transferência simples. Por baixo, a chain de destino tem de aceitar a palavra de um sistema externo de que um depósito, uma queima ou um voto aconteceu de facto. Essa palavra é uma mensagem, e a forma como é verificada é todo o modelo de segurança do bridge.
A abordagem ingénua é entregar a tarefa a uma carteira multisig. Um grupo de validadores conhecidos assina a mensagem, e a chain de destino aceita-a assim que surge um limiar de assinaturas. Isto é rápido, flexível, e é também o padrão de desenho por detrás da maioria dos maiores exploits de bridges na história das criptomoedas. Quando uma multisig é a raiz de confiança, o bridge é tão seguro quanto o menor número de chaves comprometidas que consegue tolerar.
A abordagem mais profunda é fazer com que a chain de destino verifique diretamente a chain de origem, tal como uma pessoa verifica um passaporte lendo o carimbo do país emissor em vez de confiar na palavra de um terceiro. É isso que um light client faz. Também é caro, lento de lançar, e limitado a chains que conseguem executar a lógica de verificação umas das outras. As três stacks neste artigo situam-se num espetro entre estes dois extremos, e as diferenças importam mais do que as páginas de marketing sugerem.
Riscos que todos os utilizadores cross-chain devem aceitar primeiro
Antes de comparar funcionalidades, o enquadramento honesto é que todas as mensagens cross-chain acarretam riscos que as chains subjacentes não têm. Um token transferido por bridge de Ethereum para outra rede é, em sentido estrito, já não o token de Ethereum. É um IOU wrapped ou mintado que a chain de destino só pode honrar se o modelo de segurança do bridge se mantiver. Os bridges têm sido a maior fonte individual de perdas em cripto por categoria durante três anos consecutivos.
O registo histórico é sério. O bridge Ronin perdeu cerca de 625 milhões de dólares em 2022 depois de cinco de nove chaves de validadores terem sido comprometidas. O bridge Wormhole perdeu cerca de 320 milhões de dólares em 2022 quando um atacante contornou a verificação de assinaturas em Solana. O bridge Harmony Horizon perdeu cerca de 100 milhões de dólares em 2022. O bridge Nomad perdeu perto de 190 milhões de dólares no início de 2023. No total, os bridges cross-chain representaram mais de dois mil milhões de dólares em perdas documentadas, e esse número subestima o cenário porque alguns incidentes são absorvidos discretamente.
Para os utilizadores, os riscos práticos dividem-se em alguns grupos. O risco de smart contract na chain de destino pode permitir que um atacante minte ativos sem colateral. O comprometimento de validadores no lado da origem pode permitir que um ladrão aprove um depósito falso. Problemas de replay ou de finality podem permitir que uma mensagem seja aceite antes de a chain de origem estar verdadeiramente finalizada. A captura da governação pode alterar as regras depois do facto. Nada disto é teórico. Tudo isto já aconteceu, e é por isso que uma comparação de modelos de confiança é mais útil do que uma lista de funcionalidades.
Cosmos IBC e o modelo de confiança de clientes leves
IBC, o protocolo Inter-Blockchain Communication, é o mais próximo que a indústria tem de um padrão cross-chain criptograficamente nativo. Foi especificado pela Interchain Foundation e integrado no Cosmos SDK, e está em funcionamento desde 2021, a transportar ativos reais e mensagens entre app-chains independentes. ATOM, o token nativo do Cosmos Hub, desempenha um papel de coordenação nesse ecossistema, embora muitas cadeias compatíveis com IBC tenham pouca ou nenhuma exposição direta a ATOM.
A ideia definidora por trás do IBC é que a cadeia de destino executa um cliente leve da cadeia de origem, e a cadeia de origem executa um cliente leve da cadeia de destino. Um cliente leve é um pequeno trecho de código que verifica cabeçalhos de blocos de outra cadeia usando apenas as regras de consenso dessa cadeia. Quando a cadeia A quer enviar um pacote para a cadeia B, compromete o pacote na sua própria árvore de Merkle, depois a cadeia B verifica esse compromisso ao verificar o cabeçalho que a cadeia A enviou, assinado pelo conjunto de validadores de A. Não há multisig externa, não há oráculo e não há relayer de terceiros com poder para forjar uma mensagem. A segurança da bridge é a segurança das duas cadeias envolvidas.
Este modelo tem consequências reais. Uma app-chain Cosmos e outra app-chain Cosmos que executem consenso ao estilo Tendermint podem ligar-se com algumas linhas de configuração e herdar garantias muito fortes. Ligar-se a uma cadeia com um algoritmo de consenso diferente, como Ethereum, exige escrever um cliente leve personalizado em Solidity e um relayer que consiga pagar gas em ambos os lados. Esse trabalho já foi feito para Ethereum, e as ligações resultantes ao estilo ICS-27 Neutron são utilizáveis, mas é um esforço maior do que nas outras stacks deste artigo.
O alcance limitado é a contrapartida. O IBC não protege magicamente rollups e alt-L1s arbitrárias. Cada ligação é feita à medida, e cada cadeia ligada passa a fazer parte da superfície de confiança. Isto é uma vantagem do ponto de vista da segurança, porque mantém o modelo de confiança local, e uma limitação do ponto de vista do ecossistema, porque não escala tão facilmente como um barramento de mensagens permissionado.
Segurança partilhada e a perspetiva das app-chains
A tese das app-chains por trás de Cosmos é que as aplicações sérias merecem a sua própria blockchain, com o seu próprio conjunto de validadores e o seu próprio token de taxas. O IBC é o tecido conjuntivo que torna essa tese viável, porque permite que muitas cadeias soberanas interoperem sem abdicar da soberania. A segurança replicada, e a sua sucessora, a segurança interchain, permitem que app-chains mais pequenas aluguem o conjunto de validadores do Cosmos Hub, o que melhora a sua segurança mantendo o IBC como camada cross-chain. O resultado é um modelo em que os pressupostos de confiança para uma mensagem cross-chain são explícitos, locais e auditáveis, mas o custo é a fragmentação por muitas cadeias com níveis variados de qualidade dos validadores.
LayerZero e a stack DVN configurável
LayerZero segue um caminho de desenho diferente. Em vez de executar clientes leves completos em cada cadeia, executa um Ultra Light Node, que é um endpoint minimalista que armazena cabeçalhos de blocos apenas quando necessário e, de resto, depende de um relayer off-chain e de uma stack separada de Decentralized Verifier Networks, chamadas DVNs, para atestar uma mensagem. A cadeia de destino aceita uma mensagem quando as DVNs configuradas concordam que a transação da cadeia de origem é válida.
Esta é uma arquitetura de confiança minimizada no sentido em que nenhuma parte isolada controla a entrega de mensagens, mas é também configurável. A aplicação que implementa um endpoint LayerZero pode escolher quais DVNs verificam as suas mensagens. A configuração predefinida usa um conjunto específico, mas um programador pode substituí-lo por uma stack DVN diferente para alterar o perfil de segurança de uma bridge específica. Algumas equipas lançaram com uma única DVN, o que na prática se aproxima de uma multisig, enquanto outras usam várias DVNs de operadores independentes.
Os críticos de LayerZero têm argumentado que esta flexibilidade é, por si só, um risco. Se uma aplicação for implementada com DVNs fracas para poupar custos ou reduzir latência, a segurança dessa bridge é fraca por construção. A equipa da LayerZero respondeu ao expandir o mercado de DVNs e ao promover configurações predefinidas que usam verificadores independentes, e o redesenho V2 do protocolo aposta mais numa composição explícita de DVNs. Ainda assim, a responsabilidade de escolher a stack de verificadores acaba por recair sobre a equipa da aplicação, o que significa que um utilizador que transaciona através de uma bridge LayerZero tem de confiar tanto no protocolo como nas escolhas que essa equipa fez.
O alcance de LayerZero é amplo. Está ativo na maioria das principais cadeias EVM, em Solana e em várias redes não EVM, e tem sido usado por grandes aplicações, incluindo Stargate, um router de liquidez cross-chain, e vários emitentes de stablecoins. Esse alcance é uma vantagem real, mas vem com um modelo mental mais complexo: a segurança de uma bridge específica depende das DVNs selecionadas, do contrato da aplicação que impõe a verificação e da versão do endpoint on-chain em uso.
Como as DVNs alteram a matemática da confiança
A forma mais simples de pensar numa stack DVN é como um esquema de assinatura modular. Cada DVN pode ser um sistema de zk-proof, um verificador baseado em restaking, um serviço centralizado de atestação ou uma multisig gerida por um operador conhecido. Empilhar DVNs independentes com diferentes raízes de confiança é uma defesa razoável, porque um atacante teria de comprometer mais do que um verificador de uma só vez. Empilhar DVNs correlacionadas que partilham infraestrutura ou governação está mais próximo de ter um único ponto de falha disfarçado de muitos. As equipas de aplicações que lançam com DVNs baratas e correlacionadas obtêm o marketing da descentralização e o perfil de risco de uma multisig.
Wormhole e a multisig dos guardiões
Wormhole, originalmente desenvolvido pela Certus One e agora administrado pela Wormhole Foundation, é a terceira grande stack. Liga Ethereum, Solana, BNB Chain, Aptos, Sui e uma longa cauda de outras redes, e historicamente tem sido um dos desenhos de bridge com maior TVL da indústria. O seu desenho é também o mais simples de descrever, e o mais controverso do ponto de vista da segurança.
As mensagens em Wormhole são atestadas por um conjunto permissionado de 19 guardiões, cada um dos quais executa um nó que observa a cadeia de origem e assina os eventos observados. Quando 13 de 19 guardiões assinam a mesma mensagem, esta é aceite na cadeia de destino. Os guardiões são operadores bem conhecidos de várias áreas da indústria, e o conjunto é controlado por governação, o que significa que novos guardiões podem ser adicionados ou removidos pela Wormhole DAO.
O modelo de confiança é uma multisig com um limiar elevado. Se 7 de 19 guardiões conspirarem, ou se as chaves de 7 guardiões forem comprometidas, a bridge fica totalmente comprometida. Isso é um ponto de centralização significativo, e o exploit de 2022 tornou as consequências concretas. Um atacante encontrou uma forma de forjar uma verificação de assinatura no lado Solana de Wormhole, permitindo-lhe cunhar 120.000 ETH wrapped que não estavam garantidos por depósitos em Ethereum. A perda foi de cerca de 320 milhões de dólares na altura, e foi coberta pela Jump Crypto, que tinha sido operadora de guardião e interveio para recapitalizar a bridge.
Desde então, Wormhole adicionou uma firewall de guardiões, reforçou a sua lógica de verificação on-chain e promoveu revisões de segurança adicionais. Nada disso altera o pressuposto de confiança subjacente, que é o de que uma multisig permissionada com um limiar de 13 de 19 é a raiz da segurança cross-chain. Para os utilizadores, a questão prática é se o conjunto de guardiões é suficientemente descentralizado, se os incentivos dos guardiões estão alinhados com uma operação honesta e se a aplicação na cadeia de destino impõe corretamente o percurso de verificação.
Porque a classificação por TVL é enganadora
O TVL de Wormhole tem sido frequentemente usado como indicador da sua segurança, segundo a lógica implícita de que mais dinheiro a confiar numa bridge significa que a bridge é mais fiável. O registo histórico aponta no sentido oposto. As bridges com maior TVL são os alvos mais atraentes, e a posição de Wormhole perto do topo dessa lista é a razão pela qual os seus exploits foram tão grandes. Um utilizador que olha para o total de depósitos não está a ver o modelo de segurança, apenas o prémio disponível para um atacante.
Como IBC, LayerZero e Wormhole se comparam nas dimensões que importam
O modelo de confiança é a dimensão principal, e nesse eixo o IBC é o mais seguro por desenho, porque cada cadeia verifica a outra através do consenso. LayerZero vem em segundo, porque a stack DVN pode ser configurada para ser criptograficamente robusta, mas apenas se a aplicação escolher verificadores que realmente o sejam. Wormhole fica em terceiro, porque a raiz de confiança é uma multisig de guardiões permissionada que já foi comprometida uma vez e que só melhora ao ritmo a que o conjunto de guardiões é descentralizado e rodado.
Alcance e conectividade favorecem Wormhole e LayerZero. Ambos são disponibilizados de origem em dezenas de cadeias, e um programador pode implementar uma aplicação cross-chain em qualquer um deles sem escrever um cliente leve personalizado. Em contraste, o IBC exige uma configuração por ligação, e uma ligação a uma cadeia com consenso pouco familiar é um projeto de engenharia sério. Para uma aplicação que precisa de chegar rapidamente a todas as grandes redes, isso é um custo real.
A experiência de desenvolvimento é hoje aproximadamente equivalente entre LayerZero e Wormhole, com cada um a oferecer um endpoint relativamente simples e caminhos de implementação bem estabelecidos. As ferramentas de IBC melhoraram muito, com bibliotecas como ibc-go e relayers Hermes, mas a pegada on-chain no lado Ethereum é mais pesada e as ferramentas EVM são menos maduras do que as alternativas.
Latência e custo são difíceis de generalizar. As ligações IBC entre cadeias Tendermint são rápidas e baratas porque o relayer apenas submete cabeçalhos existentes. A latência de LayerZero depende da configuração das DVNs e da frequência com que o Ultra Light Node precisa de atualizar o estado. A latência de Wormhole depende da agregação de assinaturas dos guardiões. Para transferências de dimensão retalhista, os três são competitivos; para arbitragem cross-chain de alta frequência, as diferenças de finalidade e gas podem importar.
Governação e caminhos de atualização são uma superfície de risco subestimada. As atualizações de IBC acontecem ao nível do protocolo e exigem coordenação entre cadeias ligadas. LayerZero tem sido iterado ativamente, com a V2 a remodelar o modelo de confiança no sentido de uma composição de DVNs mais explícita. A governação de Wormhole fica com a Wormhole Foundation e o conjunto de guardiões, com o incidente de 2022 a levar a um roteiro de segurança mais visível. Nenhum destes caminhos de governação é totalmente trustless, e um utilizador deve saber quem pode mudar as regras.
Implicações práticas para developers e utilizadores de DeFi
Para developers, a conclusão honesta é que a escolha da stack cross-chain é a escolha de uma raiz de confiança, e essa decisão deve ser tomada antes de ser escrita uma única linha de lógica de negócio. Uma aplicação que precise das garantias mais fortes possíveis e que aceite viver dentro de um ambiente ao estilo Cosmos terá dificuldade em encontrar melhor do que IBC. Uma aplicação que precise de amplo alcance e esteja disposta a gerir cuidadosamente a composição de DVN encontrará flexibilidade em LayerZero. Uma aplicação que dê prioridade ao tempo de lançamento no mercado e esteja confortável com um conjunto de guardiões permissionado encontrará em Wormhole uma solução rápida de lançar, com a noção de que o modelo de confiança é aquele que a página de marketing tende a omitir.
Para utilizadores de DeFi, a lista de verificação prática é curta. Descobre que bridge um token usa para se mover entre as chains que te interessam. Lê como essa bridge verifica mensagens. Se a resposta for uma multisig, pergunta quantos signatários são necessários, quem são e como são governados. Se a resposta for um light client, pergunta se a chain de destino executa realmente esse cliente e com que frequência é atualizado. Se a resposta for uma stack de DVN, pergunta quais DVNs estão na stack e se são independentes. Um ativo wrapped ou bridged é tão seguro quanto a parte mais fraca dessa resposta, e o token bridged raramente tem o mesmo perfil de risco que o ativo subjacente na sua chain de origem.
Também vale a pena lembrar que o risco cross-chain não é estático. O conjunto de guardiões de uma bridge hoje pode não ser o conjunto de guardiões amanhã. A composição de DVN de uma aplicação LayerZero hoje pode ser reconfigurada amanhã. Os light clients de uma ligação IBC hoje dependem de conjuntos de validadores que podem mudar através da governação. As premissas de confiança são coisas vivas, e uma comparação honesta é aquela que o diz claramente.
Como acompanhar o risco cross-chain de forma inteligente
A infraestrutura cross-chain evolui rapidamente, tal como as notícias sobre a sua segurança. Acompanhar manualmente auditorias de bridges, rotações de guardiões, alterações de DVN e divulgações de exploits é uma batalha perdida. Zippfeed destaca manchetes cross-chain com pontuação de sentimento, bullish, neutral ou bearish, e uma classificação de importância, para que possas ver que eventos de bridge realmente mexeram com os mercados e quais foram apenas ruído. Junta isso ao hábito de perguntar, sempre, em que conjunto de validadores estás a confiar para a mensagem, e estarás à frente da maioria dos utilizadores de retalho que ainda tratam bridges como infraestrutura rotineira.
Crypto Rank News
