Mensagens Cross-Chain e Liquidez Partilhada: Modelos de Segurança do LayerZero v2, Hyperlane e IBC 3.0
Protocolos de interoperabilidade como LayerZero v2, Hyperlane e IBC 3.0 estão a emergir como infraestrutura crítica para um ecossistema DeFi multi-chain. Cada um adota uma abordagem diferente para mensagens cross-chain e liquidez partilhada, com modelos de segurança distintos:
- LayerZero v2 – um modelo de agregação de provas que utiliza Redes de Verificadores Descentralizados (DVNs)
- Hyperlane – uma estrutura modular que frequentemente utiliza um comité de validadores multisig
- IBC 3.0 – um protocolo de light client com relayers de confiança minimizada no ecossistema Cosmos
Este relatório analisa os mecanismos de segurança de cada protocolo, compara os prós e contras de light clients vs. multisigs vs. agregação de provas, e examina o seu impacto na componibilidade e liquidez DeFi. Também revemos as implementações atuais, modelos de ameaça e níveis de adoção, concluindo com uma perspetiva sobre como estas escolhas de design afetam a viabilidade a longo prazo do DeFi multi-chain.
Mecanismos de Segurança dos Principais Protocolos Cross-Chain
LayerZero v2: Agregação de Provas com Redes de Verificadores Descentralizados (DVNs)
LayerZero v2 é um protocolo de mensagens omnichain que enfatiza uma camada de segurança modular e configurável pela aplicação. A ideia central é permitir que as aplicações protejam as mensagens com uma ou mais Redes de Verificadores Descentralizados (DVNs) independentes, que atestam coletivamente as mensagens cross-chain. No modelo de agregação de provas do LayerZero, cada DVN é essencialmente um conjunto de verificadores que pode validar independentemente uma mensagem (por exemplo, verificando uma prova de bloco ou assinatura). Uma aplicação pode exigir provas agregadas de múltiplos DVNs antes de aceitar uma mensagem, formando uma "pilha de segurança" de limiar.
Por defeito, o LayerZero fornece alguns DVNs prontos a usar – por exemplo, um DVN operado pela LayerZero Labs que usa uma validação multisig 2-de-3, e um DVN gerido pela Google Cloud. Mas, crucialmente, os desenvolvedores podem misturar e combinar DVNs: por exemplo, um pode exigir uma configuração “1 de 3 de 5”, o que significa que um DVN específico deve assinar, mais quaisquer 2 de outros 5. Esta flexibilidade permite combinar diferentes métodos de verificação (light clients, zkProofs, oráculos, etc.) numa única prova agregada. Na prática, o LayerZero v2 generaliza o modelo Ultra Light Node da v1 (que dependia de um Relayer + um Oráculo) para uma agregação multisig X-de-Y-de-N através de DVNs. O contrato LayerZero Endpoint de uma aplicação em cada cadeia só entregará uma mensagem se o quórum de DVN necessário tiver escrito atestados válidos para essa mensagem.
Características de segurança: A abordagem do LayerZero é de confiança minimizada na medida em que pelo menos um DVN no conjunto requerido é honesto (ou uma prova zk é válida, etc.). Ao permitir que as aplicações executem o seu próprio DVN como um signatário obrigatório, o LayerZero até permite que uma aplicação vete qualquer mensagem, a menos que seja aprovada pelo verificador da equipa da aplicação. Isto pode endurecer significativamente a segurança (à custa da centralização), garantindo que nenhuma mensagem cross-chain é executada sem a assinatura da aplicação. Por outro lado, os desenvolvedores podem escolher um quórum de DVN mais descentralizado (por exemplo, 5 de 15 redes independentes) para uma distribuição de confiança mais forte. O LayerZero chama a isto "segurança detida pela aplicação": cada aplicação escolhe o compromisso entre segurança, custo e desempenho ao configurar os seus DVNs. Todos os atestados de DVN são, em última análise, verificados on-chain por contratos LayerZero Endpoint imutáveis, preservando uma camada de transporte sem permissão. A desvantagem é que a segurança é apenas tão forte quanto os DVNs escolhidos – se os DVNs configurados conspirarem ou forem comprometidos, eles poderiam aprovar uma mensagem cross-chain fraudulenta. Assim, o ónus recai sobre cada aplicação para selecionar DVNs robustos ou arriscar uma segurança mais fraca.
Hyperlane: Modelo de Validador Multisig com ISMs Modulares
Hyperlane é uma estrutura de interoperabilidade centrada num Módulo de Segurança Interchain (ISM) on-chain que verifica as mensagens antes de serem entregues na cadeia de destino. Na configuração mais simples (e padrão), o ISM do Hyperlane usa um conjunto de validadores de multi-assinatura: um comité de validadores off-chain assina atestados (frequentemente uma raiz de Merkle de todas as mensagens de saída) da cadeia de origem, e um limiar de assinaturas é necessário no destino. Por outras palavras, o Hyperlane depende de um quórum de validadores com permissão para confirmar que "a mensagem X foi de facto emitida na cadeia A", análogo ao consenso de uma blockchain, mas ao nível da ponte. Por exemplo, o Wormhole usa 19 guardiões com um multisig 13-de-19 – a abordagem do Hyperlane é semelhante em espírito (embora o Hyperlane seja distinto do Wormhole).
Uma característica chave é que o Hyperlane não tem um único conjunto de validadores consagrado ao nível do protocolo. Em vez disso, qualquer pessoa pode executar um validador, e diferentes aplicações podem implementar contratos ISM com diferentes listas de validadores e limiares. O protocolo Hyperlane fornece implementações ISM padrão (com um conjunto de validadores que a equipa iniciou), mas os desenvolvedores são livres para personalizar o conjunto de validadores ou até mesmo o modelo de segurança para a sua aplicação. De facto, o Hyperlane suporta múltiplos tipos de ISMs, incluindo um ISM de Agregação que combina múltiplos métodos de verificação, e um ISM de Roteamento que escolhe um ISM com base nos parâmetros da mensagem. Por exemplo, uma aplicação poderia exigir que tanto um multisig do Hyperlane como uma ponte externa (como Wormhole ou Axelar) assinassem – alcançando um nível de segurança mais elevado através da redundância.
Características de segurança: A segurança base do modelo multisig do Hyperlane provém da honestidade da maioria dos seus validadores. Se o limiar (por exemplo, 5 de 8) de validadores conspirar, eles poderiam assinar uma mensagem fraudulenta, pelo que a suposição de confiança é aproximadamente confiança multisig N-de-M. O Hyperlane está a abordar este risco integrando-se com o restaking do EigenLayer, criando um Módulo de Segurança Económico (ESM) que exige que os validadores coloquem ETH em stake, que pode ser penalizado (slashed) por mau comportamento. Este "Serviço Ativamente Validado (AVS)" significa que se um validador do Hyperlane assinar uma mensagem inválida (uma que não está realmente no histórico da cadeia de origem), qualquer pessoa pode apresentar prova no Ethereum para penalizar o stake desse validador. Isto fortalece significativamente o modelo de segurança ao desincentivar economicamente a fraude – as mensagens cross-chain do Hyperlane tornam-se protegidas pelo peso económico do Ethereum, não apenas pela reputação social dos validadores. No entanto, um compromisso é que depender do Ethereum para o slashing introduz uma dependência da sua liveness e assume que as provas de fraude são viáveis de submeter a tempo. Em termos de liveness, o Hyperlane avisa que se não houver validadores suficientes online para atingir o limiar, a entrega de mensagens pode parar. O protocolo mitiga isto permitindo uma configuração de limiar flexível – por exemplo, usando um conjunto de validadores maior para que o tempo de inatividade ocasional não paralise a rede. No geral, a abordagem multisig modular do Hyperlane fornece flexibilidade e capacidade de atualização (as aplicações escolhem a sua própria segurança ou combinam múltiplas fontes) ao custo de adicionar confiança num conjunto de validadores. Este é um modelo de confiança mais fraco do que um verdadeiro light client, mas com inovações recentes (como colateral em restake e slashing) pode aproximar-se de garantias de segurança semelhantes na prática, mantendo-se mais fácil de implementar em muitas cadeias.
IBC 3.0: Light Clients com Relayers de Confiança Minimizada
O protocolo de Comunicação Inter-Blockchain (IBC), amplamente utilizado no ecossistema Cosmos, adota uma abordagem fundamentalmente diferente: utiliza light clients on-chain para verificar o estado cross-chain, em vez de introduzir um novo conjunto de validadores. No IBC, cada par de cadeias estabelece uma conexão onde a Cadeia B mantém um light client da Cadeia A (e vice-versa). Este light client é essencialmente uma réplica simplificada do consenso da outra cadeia (por exemplo, rastreando assinaturas do conjunto de validadores ou hashes de blocos). Quando a Cadeia A envia uma mensagem (um pacote IBC) para a Cadeia B, um relayer (um ator off-chain) transporta uma prova (prova de Merkle do pacote e do cabeçalho do bloco mais recente) para a Cadeia B. O módulo IBC da Cadeia B usa então o light client on-chain para verificar se a prova é válida sob as regras de consenso da Cadeia A. Se a prova for verificada (ou seja, o pacote foi comprometido num bloco finalizado em A), a mensagem é aceite e entregue ao módulo de destino em B. Em essência, a Cadeia B confia diretamente no consenso da Cadeia A, não num intermediário – é por isso que o IBC é frequentemente chamado de interoperabilidade de confiança minimizada.
IBC 3.0 refere-se à mais recente evolução deste protocolo (por volta de 2025), que introduz melhorias de desempenho e funcionalidades: retransmissão paralela para menor latência, tipos de canais personalizados para casos de uso especializados, e Consultas Interchain para ler o estado remoto. Notavelmente, nenhuma destas alterações muda o modelo de segurança central do light client – elas melhoram a velocidade e a funcionalidade. Por exemplo, retransmissão paralela significa que múltiplos relayers podem transportar pacotes simultaneamente para evitar estrangulamentos, melhorando a liveness sem sacrificar a segurança. As Consultas Interchain (ICQ) permitem que um contrato na Cadeia A peça dados à Cadeia B (com uma prova), que é então verificada pelo light client de B em A. Isto estende as capacidades do IBC para além das transferências de tokens para um acesso a dados cross-chain mais geral, ainda sustentado por provas de light client verificadas.
Características de segurança: A garantia de segurança do IBC é tão forte quanto a integridade da cadeia de origem. Se a Cadeia A tiver uma maioria honesta (ou o limiar de consenso configurado) e o light client de A na Cadeia B estiver atualizado, então qualquer pacote aceite deve ter vindo de um bloco válido em A. Não há necessidade de confiar em quaisquer validadores de ponte ou oráculos – as únicas suposições de confiança são o consenso nativo das duas cadeias e alguns parâmetros como o período de confiança do light client (após o qual os cabeçalhos antigos expiram). Os relayers no IBC não precisam ser confiáveis; eles não podem forjar cabeçalhos ou pacotes válidos porque estes falhariam na verificação. Na pior das hipóteses, um relayer malicioso ou offline pode censurar ou atrasar mensagens, mas qualquer pessoa pode executar um relayer, pelo que a liveness é eventualmente alcançada se existir pelo menos um relayer honesto. Este é um modelo de segurança muito forte: efetivamente descentralizado e sem permissão por defeito, espelhando as propriedades das próprias cadeias. Os compromissos vêm no custo e na complexidade – executar um light client (especialmente de uma cadeia de alto rendimento) noutra cadeia pode ser intensivo em recursos (armazenar alterações no conjunto de validadores, verificar assinaturas, etc.). Para cadeias do Cosmos SDK que usam Tendermint/BFT, este custo é gerível e o IBC é muito eficiente; mas integrar cadeias heterogéneas (como Ethereum ou Solana) requer implementações de cliente complexas ou nova criptografia. De facto, a ligação de cadeias não-Cosmos via IBC tem sido mais lenta — projetos como Polymer e Composable estão a trabalhar em light clients ou provas zk para estender o IBC ao Ethereum e outros. As melhorias do IBC 3.0 (por exemplo, light clients otimizados, suporte para diferentes métodos de verificação) visam reduzir estes custos. Em resumo, o modelo de light client do IBC oferece as garantias de confiança mais fortes (sem validadores externos) e uma liveness sólida (dado múltiplos relayers), à custa de uma maior complexidade de implementação e limitações de que todas as cadeias participantes devem suportar o protocolo IBC.
Comparando Light Clients, Multisigs e Agregação de Provas
Cada modelo de segurança – light clients (IBC), multisigs de validadores (Hyperlane) e provas agregadas (LayerZero) – vem com prós e contras distintos. Abaixo, comparamo-los em dimensões chave:
Garantias de Segurança
-
Light Clients (IBC): Oferece a segurança mais elevada ao ancorar a verificação on-chain ao consenso da cadeia de origem. Não há uma nova camada de confiança; se confia que a blockchain de origem (por exemplo, Cosmos Hub ou Ethereum) não produzirá blocos duplos, confia nas mensagens que ela envia. Isto minimiza suposições de confiança adicionais e a superfície de ataque. No entanto, se o conjunto de validadores da cadeia de origem for corrompido (por exemplo, >⅓ no Tendermint ou >½ numa cadeia PoS se tornarem maliciosos), o light client pode ser alimentado com um cabeçalho fraudulento. Na prática, os canais IBC são geralmente estabelecidos entre cadeias economicamente seguras, e os light clients podem ter parâmetros (como período de confiança e requisitos de finalidade de bloco) para mitigar riscos. No geral, a minimização da confiança é a vantagem mais forte do modelo de light client – há prova criptográfica de validade para cada mensagem.
-
Validadores Multisig (Hyperlane e pontes semelhantes): A segurança depende da honestidade de um conjunto de signatários off-chain. Um limiar típico (por exemplo, ⅔ dos validadores) deve aprovar cada mensagem cross-chain ou ponto de verificação de estado. A vantagem é que isto pode ser tornado razoavelmente seguro com validadores suficientes, reputáveis ou economicamente em stake. Por exemplo, os 19 guardiões do Wormhole ou o comité padrão do Hyperlane teriam de conspirar coletivamente para comprometer o sistema. A desvantagem é que isto introduz uma nova suposição de confiança: os utilizadores devem confiar no comité da ponte, além das cadeias. Isto provou ser um ponto de falha em alguns hacks (por exemplo, se chaves privadas são roubadas ou se insiders conspiram). Iniciativas como o colateral de ETH em restake do Hyperlane adicionam segurança económica a este modelo – validadores que assinam dados inválidos podem ser automaticamente penalizados (slashed) no Ethereum. Isto aproxima as pontes multisig da segurança de uma blockchain (ao punir financeiramente a fraude), mas ainda não é tão minimizado em confiança como um light client. Em suma, os multisigs são mais fracos em garantias de confiança: depende-se da maioria de um pequeno grupo, embora o slashing e as auditorias possam reforçar a confiança.
-
Agregação de Provas (LayerZero v2): Isto é, de certa forma, um meio-termo. Se uma aplicação configurar a sua Pilha de Segurança para incluir um DVN de light client ou um DVN de prova zk, então a garantia pode aproximar-se do nível do IBC (matemática e consenso da cadeia) para essas verificações. Se usar um DVN baseado em comité (como o padrão 2-de-3 do LayerZero ou um adaptador Axelar), então herda as suposições de confiança desse multisig. A força do modelo do LayerZero é que se pode combinar múltiplos verificadores independentemente. Por exemplo, exigir tanto que "uma prova zk seja válida" como que "o oráculo da Chainlink diga que o cabeçalho do bloco é X" como que "o nosso próprio validador assine" poderia reduzir drasticamente as possibilidades de ataque (um atacante precisaria quebrar todos de uma vez). Além disso, ao permitir que uma aplicação exija o seu próprio DVN, o LayerZero garante que nenhuma mensagem será executada sem o consentimento da aplicação, se assim configurado. A fraqueza é que se os desenvolvedores escolherem uma configuração de segurança frouxa (por taxas mais baratas ou velocidade), eles podem minar a segurança – por exemplo, usar um único DVN gerido por uma parte desconhecida seria semelhante a confiar num único validador. O próprio LayerZero é não-opinativo e deixa estas escolhas para os desenvolvedores de aplicações, o que significa que a segurança é apenas tão boa quanto os DVNs escolhidos. Em resumo, a agregação de provas pode fornecer segurança muito forte (até mais alta que um único light client, ao exigir múltiplas provas independentes), mas também permite configurações fracas se mal configurada. É flexível: uma aplicação pode aumentar a segurança para transações de alto valor (por exemplo, exigir múltiplos grandes DVNs) e diminuí-la para as de baixo valor.
Liveness e Disponibilidade
-
Light Clients (IBC): A liveness depende dos relayers e do light client se manter atualizado. O lado positivo é que qualquer pessoa pode executar um relayer, pelo que o sistema não depende de um conjunto específico de nós – se um relayer parar, outro pode assumir o trabalho. A retransmissão paralela do IBC 3.0 melhora ainda mais a disponibilidade ao não serializar todos os pacotes através de um único caminho. Na prática, as conexões IBC têm sido muito fiáveis, mas há cenários onde a liveness pode sofrer: por exemplo, se nenhum relayer publicar uma atualização por um longo tempo, um light client pode expirar (por exemplo, se o período de confiança passar sem renovação) e então o canal fecha por segurança. No entanto, tais casos são raros e mitigados por redes de relayers ativas. Outra consideração de liveness: os pacotes IBC estão sujeitos à finalidade da cadeia de origem – por exemplo, esperar 1-2 blocos no Tendermint (alguns segundos) é padrão. No geral, o IBC fornece alta disponibilidade desde que haja pelo menos um relayer ativo, e a latência é tipicamente baixa (segundos) para blocos finalizados. Não há o conceito de um quórum de validadores ficar offline como no multisig; a própria finalidade de consenso da blockchain é o principal fator de latência.
-
Validadores Multisig (Hyperlane): A liveness pode ser uma fraqueza se o conjunto de validadores for pequeno. Por exemplo, se uma ponte tem um multisig 5-de-8 e 4 validadores estão offline ou inacessíveis, as mensagens cross-chain param porque o limiar não pode ser atingido. A documentação do Hyperlane nota que o tempo de inatividade do validador pode parar a entrega de mensagens, dependendo do limiar configurado. É em parte por isso que ter um comité maior ou um limiar mais baixo (com um compromisso de segurança) pode ser escolhido para melhorar o tempo de atividade. O design do Hyperlane permite implementar novos validadores ou trocar de ISM se necessário, mas tais mudanças podem exigir coordenação/governança. A vantagem que as pontes multisig têm é tipicamente a confirmação rápida assim que as assinaturas de limiar são recolhidas – não há necessidade de esperar pela finalidade de bloco de uma cadeia de origem na cadeia de destino, uma vez que o atestado multisig é a finalidade. Na prática, muitas pontes multisig assinam e retransmitem mensagens em segundos. Portanto, a latência pode ser comparável ou até menor que a dos light clients para algumas cadeias. O gargalo é se os validadores são lentos ou geograficamente distribuídos, ou se quaisquer passos manuais estão envolvidos. Em resumo, os modelos multisig podem ser altamente vivos e de baixa latência na maior parte do tempo, mas têm um risco de liveness concentrado no conjunto de validadores – se muitos validadores falharem ou ocorrer uma partição de rede entre eles, a ponte fica efetivamente inativa.
-
Agregação de Provas (LayerZero): A liveness aqui depende da disponibilidade de cada DVN e do relayer. Uma mensagem deve reunir assinaturas/provas dos DVNs necessários e depois ser retransmitida para a cadeia de destino. O aspeto positivo é que os DVNs operam independentemente – se um DVN (de um conjunto) estiver inativo e não for obrigatório (apenas parte de um "M de N"), a mensagem ainda pode prosseguir desde que o limiar seja atingido. O modelo do LayerZero permite explicitamente configurar quóruns para tolerar algumas falhas de DVN. Por exemplo, um conjunto de DVN "2 de 5" pode lidar com 3 DVNs offline sem parar o protocolo. Adicionalmente, como qualquer pessoa pode executar o papel final de Executor/Relayer, não há um único ponto de falha para a entrega de mensagens – se o relayer principal falhar, um utilizador ou outra parte pode chamar o contrato com as provas (isto é análogo ao conceito de relayer sem permissão no IBC). Assim, o LayerZero v2 esforça-se por resistência à censura e liveness ao não vincular o sistema a um único intermediário. No entanto, se DVNs obrigatórios fizerem parte da pilha de segurança (digamos que uma aplicação exige que o seu próprio DVN assine sempre), então esse DVN é uma dependência de liveness: se ficar offline, as mensagens pausarão até que ele volte ou a política de segurança seja alterada. Em geral, a agregação de provas pode ser configurada para ser robusta (com DVNs redundantes e retransmissão por qualquer parte) de modo que é improvável que todos os verificadores estejam inativos ao mesmo tempo. O compromisso é que contactar múltiplos DVNs pode introduzir um pouco mais de latência (por exemplo, esperar por várias assinaturas) em comparação com um único multisig mais rápido. Mas esses DVNs poderiam funcionar em paralelo, e muitos DVNs (como uma rede de oráculos ou um light client) podem responder rapidamente. Portanto, o LayerZero pode alcançar alta liveness e baixa latência, mas o desempenho exato depende de como os DVNs são configurados (alguns podem esperar por algumas confirmações de bloco na cadeia de origem, etc., o que poderia adicionar atraso por segurança).
Custo e Complexidade
-
Light Clients (IBC): Esta abordagem tende a ser complexa de implementar, mas barata de usar uma vez configurada em cadeias compatíveis. A complexidade reside em escrever uma implementação correta de light client para cada tipo de blockchain – essencialmente, está-se a codificar as regras de consenso da Cadeia A num contrato inteligente na Cadeia B. Para cadeias do Cosmos SDK com consenso semelhante, isto foi simples, mas estender o IBC para além do Cosmos exigiu engenharia pesada (por exemplo, construir um light client para a finalidade GRANDPA do Polkadot, ou planos para light clients do Ethereum com provas zk). Estas implementações não são triviais e devem ser altamente seguras. Há também uma sobrecarga de armazenamento on-chain: o light client precisa de armazenar informações recentes do conjunto de validadores ou da raiz de estado da outra cadeia. Isto pode aumentar o tamanho do estado e o custo de verificação da prova na cadeia. Como resultado, executar o IBC diretamente na mainnet do Ethereum (verificando cabeçalhos do Cosmos) seria caro em termos de gás – uma razão pela qual projetos como o Polymer estão a criar um rollup do Ethereum para hospedar estes light clients fora da mainnet. Dentro do ecossistema Cosmos, as transações IBC são muito eficientes (muitas vezes apenas alguns cêntimos de gás) porque a verificação do light client (assinaturas ed25519, provas de Merkle) é bem otimizada ao nível do protocolo. Usar o IBC é relativamente de baixo custo para os utilizadores, e os relayers apenas pagam taxas de transação normais nas cadeias de destino (eles podem ser incentivados com taxas através do middleware ICS-29). Em resumo, o custo do IBC é concentrado na complexidade do desenvolvimento, mas uma vez em funcionamento, fornece um transporte nativo e eficiente em termos de taxas. As muitas cadeias Cosmos conectadas (mais de 100 zonas) partilham uma implementação comum, o que ajuda a gerir a complexidade através da padronização.
-
Pontes Multisig (Hyperlane/Wormhole/etc.): A complexidade de implementação aqui é muitas vezes menor – os contratos de ponte principais precisam principalmente de verificar um conjunto de assinaturas contra chaves públicas armazenadas. Esta lógica é mais simples do que um light client completo. O software do validador off-chain introduz complexidade operacional (servidores que observam eventos da cadeia, mantêm uma árvore de Merkle de mensagens, coordenam a recolha de assinaturas, etc.), mas isto é gerido pelos operadores da ponte e mantido off-chain. Custo on-chain: verificar algumas assinaturas (digamos 2 ou 5 assinaturas ECDSA) não é muito caro, mas é certamente mais gás do que uma única assinatura de limiar ou uma verificação de hash. Algumas pontes usam esquemas de assinatura agregada (por exemplo, BLS) para reduzir o custo on-chain para a verificação de 1 assinatura. Em geral, a verificação multisig no Ethereum ou cadeias semelhantes é moderadamente dispendiosa (cada verificação de assinatura ECDSA custa ~3000 gás). Se uma ponte requer 10 assinaturas, isso são ~30k de gás apenas para verificação, mais qualquer armazenamento de uma nova raiz de Merkle, etc. Isto é geralmente aceitável, dado que as transferências cross-chain são operações de alto valor, mas pode acumular-se. Do ponto de vista do desenvolvedor/utilizador, interagir com uma ponte multisig é simples: deposita-se ou chama-se uma função de envio, e o resto é tratado off-chain pelos validadores/relayers, depois uma prova é submetida. Há uma complexidade mínima para os desenvolvedores de aplicações, pois eles apenas integram a API/contrato da ponte. Uma consideração de complexidade é adicionar novas cadeias – cada validador deve executar um nó ou indexador para cada nova cadeia para observar mensagens, o que pode ser uma dor de cabeça de coordenação (isto foi notado como um gargalo para a expansão em alguns designs multisig). A resposta do Hyperlane são validadores sem permissão (qualquer um pode juntar-se para uma cadeia se o ISM os incluir), mas a aplicação que implementa o ISM ainda tem de configurar essas chaves inicialmente. No geral, os modelos multisig são mais fáceis de iniciar em cadeias heterogéneas (não há necessidade de um light client personalizado por cadeia), tornando-os mais rápidos de chegar ao mercado, mas incorrem em complexidade operacional off-chain e custos moderados de verificação on-chain.
-
Agregação de Provas (LayerZero): A complexidade aqui está na coordenação de muitos métodos de verificação possíveis. O LayerZero fornece uma interface padronizada (os contratos Endpoint & MessageLib) e espera que os DVNs adiram a uma certa API de verificação. Do ponto de vista de uma aplicação, usar o LayerZero é bastante simples (basta chamar
lzSende implementar callbackslzReceive), mas por baixo dos panos, há muita coisa a acontecer. Cada DVN pode ter a sua própria infraestrutura off-chain (alguns DVNs são essencialmente mini-pontes, como uma rede Axelar ou um serviço de oráculo Chainlink). O protocolo em si é complexo porque deve agregar de forma segura tipos de prova díspares – por exemplo, um DVN pode fornecer uma prova de bloco EVM, outro um SNARK, outro uma assinatura, etc., e o contrato tem de verificar cada um por sua vez. A vantagem é que grande parte desta complexidade é abstraída pela estrutura do LayerZero. O custo depende de quantos e que tipo de provas são necessárias: verificar um snark pode ser caro (a verificação de prova zk on-chain pode custar centenas de milhares de gás), enquanto verificar um par de assinaturas é mais barato. O LayerZero permite que a aplicação decida quanto quer pagar pela segurança por mensagem. Há também um conceito de pagar aos DVNs pelo seu trabalho – a carga útil da mensagem inclui uma taxa pelos serviços do DVN. Por exemplo, uma aplicação pode anexar taxas que incentivam os DVNs e Executores a processar a mensagem prontamente. Isto adiciona uma dimensão de custo: uma configuração mais segura (usando muitos DVNs ou provas caras) custará mais em taxas, enquanto um DVN simples 1-de-1 (como um único relayer) pode ser muito barato, mas menos seguro. A capacidade de atualização e a governança também fazem parte da complexidade: como as aplicações podem mudar a sua pilha de segurança, é necessário um processo de governança ou uma chave de administrador para fazer isso – o que por si só é um ponto de confiança/complexidade a gerir. Em resumo, a agregação de provas via LayerZero é altamente flexível, mas complexa por baixo dos panos. O custo por mensagem pode ser otimizado escolhendo DVNs eficientes (por exemplo, usando um ultra-light client otimizado, ou aproveitando as economias de escala de uma rede de oráculos existente). Muitos desenvolvedores acharão a natureza plug-and-play (com padrões fornecidos) apelativa – por exemplo, simplesmente usar o conjunto de DVN padrão por facilidade – mas isso novamente pode levar a suposições de confiança subótimas se não for compreendido.
Capacidade de Atualização e Governança
-
Light Clients (IBC): As conexões e clientes IBC podem ser atualizados através de propostas de governança on-chain nas cadeias participantes (particularmente se o light client precisar de uma correção ou uma atualização para um hardfork na cadeia de origem). A atualização do próprio protocolo IBC (digamos, das funcionalidades do IBC 2.0 para o 3.0) também requer que a governança da cadeia adote novas versões do software. Isto significa que o IBC tem um caminho de atualização deliberado – as mudanças são lentas e requerem consenso, mas isso está alinhado com a sua abordagem de segurança em primeiro lugar. Não há uma única entidade que possa virar um interruptor; a governança de cada cadeia deve aprovar mudanças nos clientes ou parâmetros. O positivo é que isto impede mudanças unilaterais que poderiam introduzir vulnerabilidades. O negativo é menos agilidade – por exemplo, se um bug for encontrado num light client, pode levar a votos de governança coordenados em muitas cadeias para o corrigir (embora existam mecanismos de coordenação de emergência). Do ponto de vista de uma dApp, o IBC não tem realmente uma "governança ao nível da aplicação" – é uma infraestrutura fornecida pela cadeia. As aplicações apenas usam módulos IBC (como transferência de tokens ou contas interchain) e confiam na segurança da cadeia. Portanto, a governança e as atualizações acontecem ao nível da blockchain (governança do Hub e da Zona). Uma nova funcionalidade interessante do IBC são os canais personalizados e o roteamento (por exemplo, hubs como Polymer ou Nexus) que podem permitir a troca de métodos de verificação subjacentes sem interromper as aplicações. Mas, em geral, o IBC é estável e padronizado – a capacidade de atualização é possível, mas infrequente, contribuindo para a sua fiabilidade.
-
Pontes Multisig (Hyperlane/Wormhole): Estes sistemas têm frequentemente um mecanismo de administração ou governança para atualizar contratos, alterar conjuntos de validadores ou modificar parâmetros. Por exemplo, adicionar um novo validador ao conjunto ou rodar chaves pode exigir um multisig do proprietário da ponte ou um voto de uma DAO. O facto de o Hyperlane ser sem permissão significa que qualquer utilizador pode implementar o seu próprio ISM com um conjunto de validadores personalizado, mas se usar o padrão, a equipa do Hyperlane ou a comunidade provavelmente controla as atualizações. A capacidade de atualização é uma faca de dois gumes: por um lado, é fácil de atualizar/melhorar, por outro, pode ser um risco de centralização (se uma chave privilegiada pode atualizar os contratos da ponte, essa chave poderia teoricamente roubar os fundos da ponte). Um protocolo bem governado limitará isto (por exemplo, atualizações com time-lock, ou usar uma governança descentralizada). A filosofia do Hyperlane é a modularidade – então uma aplicação poderia até contornar um componente falho trocando de ISMs, etc. Isto dá aos desenvolvedores o poder de responder a ameaças (por exemplo, se um conjunto de validadores for suspeito de estar comprometido, uma aplicação poderia mudar para um modelo de segurança diferente rapidamente). A sobrecarga de governança é que as aplicações precisam de decidir o seu modelo de segurança e potencialmente gerir chaves para os seus próprios validadores ou prestar atenção às atualizações do protocolo principal do Hyperlane. Em resumo, os sistemas baseados em multisig são mais atualizáveis (os contratos são frequentemente atualizáveis e os comités configuráveis), o que é bom para melhorias rápidas e adição de novas cadeias, mas requer confiança no processo de governança. Muitas explorações de pontes no passado ocorreram através de chaves de atualização comprometidas ou governança falha, pelo que esta área deve ser tratada com cuidado. Do lado positivo, adicionar suporte para uma nova cadeia pode ser tão simples como implementar os contratos e fazer com que os validadores executem nós para ela – nenhuma mudança fundamental no protocolo é necessária.
-
Agregação de Provas (LayerZero): O LayerZero apregoa uma camada de transporte imutável (os contratos de endpoint não são atualizáveis), mas os módulos de verificação (Bibliotecas de Mensagens e adaptadores DVN) são apenas de acréscimo e configuráveis. Na prática, isto significa que o contrato principal do LayerZero em cada cadeia permanece fixo (fornecendo uma interface estável), enquanto novos DVNs ou opções de verificação podem ser adicionados ao longo do tempo sem alterar o núcleo. Os desenvolvedores de aplicações têm controlo sobre a sua Pilha de Segurança: eles podem adicionar ou remover DVNs, alterar a profundidade do bloco de confirmação, etc. Esta é uma forma de capacidade de atualização ao nível da aplicação. Por exemplo, se um DVN particular for descontinuado ou um novo e melhor surgir (como um cliente zk mais rápido), a equipa da aplicação pode integrá-lo na sua configuração – preparando a dApp para o futuro. O benefício é evidente: as aplicações não ficam presas à tecnologia de segurança de ontem; elas podem adaptar-se (com a devida cautela) a novos desenvolvimentos. No entanto, isto levanta questões de governança: quem dentro da aplicação decide mudar o conjunto de DVN? Idealmente, se a aplicação for descentralizada, as mudanças passariam pela governança ou seriam codificadas se quisessem imutabilidade. Se um único administrador pode alterar a pilha de segurança, isso é um ponto de confiança (eles poderiam reduzir os requisitos de segurança numa atualização maliciosa). A própria orientação do LayerZero incentiva a criação de uma governança robusta para tais mudanças ou até mesmo a tornar certos aspetos imutáveis, se necessário. Outro aspeto da governança é a gestão de taxas – pagar aos DVNs e relayers pode ser ajustado, e incentivos desalinhados podem impactar o desempenho (embora, por defeito, as forças de mercado devam ajustar as taxas). Em suma, o modelo do LayerZero é altamente extensível e atualizável em termos de adição de novos métodos de verificação (o que é ótimo para a interoperabilidade a longo prazo), mas o ónus recai sobre cada aplicação para governar essas atualizações de forma responsável. Os contratos base do LayerZero são imutáveis para garantir que a camada de transporte não possa ser alvo de "rug-pull" ou censurada, o que inspira confiança de que o pipeline de mensagens em si permanece intacto através das atualizações.
Para resumir a comparação, a tabela abaixo destaca as principais diferenças:
| Aspeto | IBC (Light Clients) | Hyperlane (Multisig) | LayerZero v2 (Agregação) |
|---|---|---|---|
| Modelo de Confiança | Confiar no consenso da cadeia de origem (sem confiança extra). | Confiar num comité de validadores de ponte (por exemplo, limiar multisig). O slashing pode mitigar o risco. | A confiança depende dos DVNs escolhidos. Pode emular light client ou multisig, ou misturar (confiar em pelo menos um dos verificadores escolhidos). |
| Segurança | A mais alta – prova criptográfica de validade via light client. Ataques requerem comprometer a cadeia de origem ou o light client. | Forte se o comité for de maioria honesta, mas mais fraca que o light client. A colusão do comité ou o comprometimento de chaves é a principal ameaça. | Potencialmente muito alta – pode exigir múltiplas provas independentes (por exemplo, zk + multisig + oráculo). Mas a segurança configurável significa que é apenas tão forte quanto os DVNs mais fracos escolhidos. |
| Liveness | Muito boa desde que pelo menos um relayer esteja ativo. Relayers paralelos e cadeias de finalidade rápida proporcionam entrega quase em tempo real. | Boa em condições normais (assinaturas rápidas). Mas dependente do tempo de atividade do validador. Tempo de inatividade do quórum de limiar = paragem. A expansão para novas cadeias requer suporte do comité. | Muito boa; múltiplos DVNs fornecem redundância, e qualquer utilizador pode retransmitir transações. DVNs obrigatórios podem ser pontos únicos de falha se mal configurados. A latência pode ser ajustada (por exemplo, esperar por confirmações vs. velocidade). |
| Custo | Complexidade inicial para implementar clientes. Verificação on-chain de consenso (assinaturas, provas de Merkle), mas otimizada no Cosmos. Baixo custo por mensagem em ambientes nativos de IBC; potencialmente caro em cadeias não-nativas sem soluções especiais. | Menor complexidade de desenvolvimento para contratos principais. O custo on-chain escala com o número de assinaturas por mensagem. Custo de operações off-chain para validadores (nós em cada cadeia). Possivelmente mais gás que o light client se houver muitas assinaturas, mas muitas vezes gerível. | Complexidade moderada a alta. O custo por mensagem varia: cada prova de DVN (assinatura ou SNARK) adiciona gás de verificação. As aplicações pagam taxas de DVN pelo serviço. Pode otimizar custos escolhendo menos ou provas mais baratas para mensagens de baixo valor. |
| Capacidade de Atualização | O protocolo evolui via governança da cadeia (lento, conservador). As atualizações do light client requerem coordenação, mas a padronização mantém-no estável. Adicionar novas cadeias requer construir/aprovar novos tipos de cliente. | Flexível – conjuntos de validadores e ISMs podem ser alterados via governança ou administrador. Mais fácil de integrar novas cadeias rapidamente. Risco se as chaves de atualização ou a governança forem comprometidas. Tipicamente contratos atualizáveis (necessita de confiança nos administradores). | Altamente modular – novos DVNs/métodos de verificação podem ser adicionados sem alterar o núcleo. As aplicações podem alterar a configuração de segurança conforme necessário. Endpoints principais imutáveis (sem atualizações centrais), mas governança ao nível da aplicação necessária para mudanças de segurança para evitar abuso. |
Impacto na Componibilidade e Liquidez Partilhada em DeFi
As mensagens cross-chain desbloqueiam novos padrões poderosos para a componibilidade – a capacidade de contratos DeFi em diferentes cadeias interagirem – e permitem a liquidez partilhada – agrupar ativos através de cadeias como se estivessem num único mercado. Os modelos de segurança discutidos acima influenciam com que confiança e fluidez os protocolos podem utilizar funcionalidades cross-chain. Abaixo, exploramos como cada abordagem suporta o DeFi multi-chain, com exemplos reais:
-
DeFi Omnichain via LayerZero (Stargate, Radiant, Tapioca): As mensagens genéricas do LayerZero e o padrão Omnichain Fungible Token (OFT) são projetados para quebrar os silos de liquidez. Por exemplo, a Stargate Finance usa o LayerZero para implementar um pool de liquidez unificado para a ponte de ativos nativos – em vez de pools fragmentados em cada cadeia, os contratos da Stargate em todas as cadeias acedem a um pool comum, e as mensagens do LayerZero gerem a lógica de bloqueio/libertação através das cadeias. Isto levou a mais de 800 milhões de dólares de volume mensal nas pontes da Stargate, demonstrando uma liquidez partilhada significativa. Ao confiar na segurança do LayerZero (com a Stargate presumivelmente a usar um conjunto robusto de DVNs), os utilizadores podem transferir ativos com alta confiança na autenticidade da mensagem. A Radiant Capital é outro exemplo – um protocolo de empréstimo cross-chain onde os utilizadores podem depositar numa cadeia e pedir emprestado noutra. Ele aproveita as mensagens do LayerZero para coordenar o estado da conta através das cadeias, criando efetivamente um mercado de empréstimos único em múltiplas redes. Da mesma forma, a Tapioca (um mercado monetário omnichain) usa o LayerZero v2 e até executa o seu próprio DVN como um verificador obrigatório para proteger as suas mensagens. Estes exemplos mostram que, com segurança flexível, o LayerZero pode suportar operações cross-chain complexas como verificações de crédito, movimentos de colateral e liquidações através de cadeias. A componibilidade vem do padrão "OApp" (Omnichain Application) do LayerZero, que permite aos desenvolvedores implementar o mesmo contrato em muitas cadeias e fazê-los coordenar via mensagens. Um utilizador interage com a instância de qualquer cadeia e experiencia a aplicação como um sistema unificado. O modelo de segurança permite um ajuste fino: por exemplo, transferências grandes ou liquidações podem exigir mais assinaturas de DVN (por segurança), enquanto ações pequenas passam por caminhos mais rápidos/baratos. Esta flexibilidade garante que nem a segurança nem a UX precisam de ser de tamanho único. Na prática, o modelo do LayerZero melhorou muito a liquidez partilhada, evidenciado por dezenas de projetos que adotam o OFT para tokens (para que um token possa existir "omnichain" em vez de como ativos embrulhados separados). Por exemplo, stablecoins e tokens de governança podem usar o OFT para manter uma única oferta total em todas as cadeias – evitando a fragmentação de liquidez e problemas de arbitragem que atormentavam os tokens embrulhados anteriores. No geral, ao fornecer uma camada de mensagens fiável e permitir que as aplicações controlem o modelo de confiança, o LayerZero catalisou novos designs de DeFi multi-chain que tratam múltiplas cadeias como um único ecossistema. O compromisso é que os utilizadores e projetos devem entender a suposição de confiança de cada aplicação omnichain (uma vez que podem diferir). Mas padrões como o OFT e DVNs padrão amplamente utilizados ajudam a tornar isto mais uniforme.
-
Contas e Serviços Interchain no IBC (DeFi do Cosmos): No mundo do Cosmos, o IBC permitiu uma rica tapeçaria de funcionalidades cross-chain que vão além das transferências de tokens. Uma funcionalidade emblemática são as Contas Interchain (ICA), que permitem que uma blockchain (ou um utilizador na cadeia A) controle uma conta na cadeia B como se fosse local. Isto é feito através de pacotes IBC que transportam transações. Por exemplo, o Cosmos Hub pode usar uma conta interchain na Osmosis para fazer stake ou trocar tokens em nome de um utilizador – tudo iniciado a partir do Hub. Um caso de uso concreto de DeFi é o protocolo de liquid staking da Stride: a Stride (uma cadeia) recebe tokens como ATOM dos utilizadores e, usando ICA, faz stake remotamente desses ATOM no Cosmos Hub e depois emite stATOM (ATOM em liquid stake) de volta para os utilizadores. Todo o fluxo é sem confiança e automatizado via IBC – o módulo da Stride controla uma conta no Hub que executa transações de delegação e não-delegação, com confirmações e timeouts a garantir a segurança. Isto demonstra componibilidade cross-chain: duas cadeias soberanas a realizar um fluxo de trabalho conjunto (stake aqui, cunhar token ali) de forma fluida. Outro exemplo é a Osmosis (uma cadeia DEX) que usa o IBC para atrair ativos de mais de 95 cadeias conectadas. Utilizadores de qualquer zona podem trocar na Osmosis enviando os seus tokens via IBC. Graças à alta segurança do IBC, a Osmosis e outros tratam com confiança os tokens IBC como genuínos (não necessitando de custodiantes confiáveis). Isto levou a Osmosis a tornar-se uma das maiores DEXes interchain, com um volume diário de transferências IBC que, segundo relatos, excede o de muitos sistemas de ponte. Além disso, com as Consultas Interchain (ICQ) no IBC 3.0, um contrato inteligente numa cadeia pode obter dados (como preços, taxas de juro ou posições) de outra cadeia de forma minimizada em confiança. Isto poderia permitir, por exemplo, um agregador de rendimento interchain que consulta taxas de rendimento em múltiplas zonas e realoca ativos em conformidade, tudo via mensagens IBC. O impacto chave do modelo de light client do IBC na componibilidade é a confiança e a neutralidade: as cadeias permanecem soberanas, mas podem interagir sem medo de um risco de ponte de terceiros. Projetos como Composable Finance e Polymer estão até a estender o IBC para ecossistemas não-Cosmos (Polkadot, Ethereum) para aproveitar estas capacidades. O resultado pode ser um futuro onde qualquer cadeia que adote um padrão de cliente IBC possa ligar-se a uma "internet universal de blockchains". A liquidez partilhada no Cosmos já é significativa – por exemplo, a DEX nativa do Cosmos Hub (Gravity DEX) e outras dependem do IBC para agrupar liquidez de várias zonas. No entanto, uma limitação até agora é que o DeFi do Cosmos é maioritariamente assíncrono: inicia-se numa cadeia, o resultado acontece noutra com um ligeiro atraso (segundos). Isto é bom para coisas como trocas e staking, mas uma componibilidade síncrona mais complexa (como flash loans através de cadeias) permanece fora de alcance devido à latência fundamental. Ainda assim, o espectro de DeFi cross-chain permitido pelo IBC é amplo: yield farming multi-chain (mover fundos para onde o rendimento é mais alto), governança cross-chain (uma cadeia a votar para executar ações noutra via pacotes de governança), e até Segurança Interchain, onde uma cadeia consumidora aproveita o conjunto de validadores de uma cadeia provedora (através de pacotes de validação IBC). Em resumo, os canais seguros do IBC fomentaram uma economia interchain no Cosmos – uma onde os projetos podem especializar-se em cadeias separadas, mas trabalhar fluidamente em conjunto através de mensagens de confiança minimizada. A liquidez partilhada é aparente em coisas como o fluxo de ativos para a Osmosis e o surgimento de stablecoins nativas do Cosmos que se movem livremente entre zonas.
-
Abordagens Híbridas e Outras Multi-Chain (Hyperlane e além): A visão do Hyperlane de conectividade sem permissão levou a conceitos como Warp Routes para a ponte de ativos e dapps interchain que abrangem vários ecossistemas. Por exemplo, uma Warp Route pode permitir que um token ERC-20 no Ethereum seja teleportado para um programa Solana, usando a camada de mensagens do Hyperlane por baixo dos panos. Uma implementação concreta voltada para o utilizador é a ponte Nexus do Hyperlane, que fornece uma UI para transferir ativos entre muitas cadeias através da infraestrutura do Hyperlane. Ao usar um modelo de segurança modular, o Hyperlane pode adaptar a segurança por rota: uma pequena transferência pode passar por um caminho rápido e simples (apenas validadores do Hyperlane a assinar), enquanto uma grande transferência pode exigir um ISM agregado (Hyperlane + Wormhole + Axelar, todos a atestar). Isto garante que o movimento de liquidez de alto valor seja protegido por múltiplas pontes – aumentando a confiança para, digamos, mover 10 milhões de dólares de um ativo cross-chain (seria necessário comprometer múltiplas redes para o roubar) ao custo de maior complexidade/taxas. Em termos de componibilidade, o Hyperlane permite o que eles chamam de "interoperabilidade de contratos" – um contrato inteligente na cadeia A pode chamar uma função na cadeia B como se fosse local, uma vez que as mensagens são entregues. Os desenvolvedores integram o SDK do Hyperlane para despachar estas chamadas cross-chain facilmente. Um exemplo poderia ser um agregador de DEX cross-chain que vive parte no Ethereum e parte na BNB Chain, usando mensagens do Hyperlane para arbitrar entre os dois. Como o Hyperlane suporta cadeias EVM e não-EVM (até trabalho inicial em integração com CosmWasm e MoveVM), ele aspira a conectar "qualquer cadeia, qualquer VM". Este amplo alcance pode aumentar a liquidez partilhada ao ligar ecossistemas que de outra forma não são facilmente conectados. No entanto, a adoção real do Hyperlane em DeFi de grande escala ainda está a crescer. Ainda não tem o volume do Wormhole ou do LayerZero em pontes, mas a sua natureza sem permissão atraiu a experimentação. Por exemplo, alguns projetos usaram o Hyperlane para conectar rapidamente rollups específicos de aplicações ao Ethereum, porque podiam configurar o seu próprio conjunto de validadores e não esperar por soluções complexas de light client. À medida que o restaking (EigenLayer) cresce, o Hyperlane pode ver mais adoção ao oferecer segurança de nível Ethereum a qualquer rollup com latência relativamente baixa. Isto poderia acelerar novas composições multi-chain – por exemplo, um rollup Optimism e um rollup zk Polygon a trocar mensagens através do Hyperlane AVS, cada mensagem apoiada por ETH penalizável (slashed) se for fraudulenta. O impacto na componibilidade é que mesmo ecossistemas sem um padrão partilhado (como Ethereum e um L2 arbitrário) podem obter um contrato de ponte em que ambos os lados confiam (porque é economicamente seguro). Com o tempo, isto pode resultar numa teia de aplicações DeFi interconectadas onde a componibilidade é "ajustada" pelo desenvolvedor (escolhendo quais módulos de segurança usar para quais chamadas).
Em todos estes casos, a interação entre modelo de segurança e componibilidade é evidente. Os projetos só confiarão grandes pools de liquidez a sistemas cross-chain se a segurança for sólida – daí o impulso para designs de confiança minimizada ou economicamente seguros. Ao mesmo tempo, a facilidade de integração (experiência do desenvolvedor) e a flexibilidade influenciam quão criativas as equipas podem ser ao aproveitar múltiplas cadeias. O LayerZero e o Hyperlane focam-se na simplicidade para os desenvolvedores (basta importar um SDK e usar chamadas de envio/receção familiares), enquanto o IBC, sendo de nível mais baixo, requer mais compreensão dos módulos e pode ser tratado pelos desenvolvedores da cadeia em vez dos desenvolvedores de aplicações. No entanto, todos os três estão a caminhar para um futuro onde os utilizadores interagem com dApps multi-chain sem precisarem de saber em que cadeia estão – a aplicação acede de forma fluida à liquidez e funcionalidade de qualquer lugar. Por exemplo, um utilizador de uma aplicação de empréstimo pode depositar na Cadeia A e nem perceber que o empréstimo aconteceu de um pool na Cadeia B – tudo coberto por mensagens cross-chain e validação adequada.
Implementações, Modelos de Ameaça e Adoção na Prática
É importante avaliar como estes protocolos se estão a sair em condições do mundo real – as suas implementações atuais, vetores de ameaça conhecidos e níveis de adoção:
-
LayerZero v2 em Produção: O LayerZero v1 (com o modelo de 2 entidades Oráculo+Relayer) ganhou uma adoção significativa, garantindo mais de 50 mil milhões de dólares em volume de transferências e mais de 134 milhões de mensagens cross-chain até meados de 2024. Está integrado com mais de 60 blockchains, principalmente cadeias EVM, mas também não-EVM como Aptos, e o suporte experimental para Solana está no horizonte. O LayerZero v2 foi lançado no início de 2024, introduzindo DVNs e segurança modular. Já, grandes plataformas como Radiant Capital, SushiXSwap, Stargate, PancakeSwap e outras começaram a migrar ou a construir sobre a v2 para aproveitar a sua flexibilidade. Uma integração notável é a Flare Network (uma Layer1 focada em dados), que adotou o LayerZero v2 para se conectar com 75 cadeias de uma só vez. A Flare foi atraída pela capacidade de personalizar a segurança: por exemplo, usando um único DVN rápido para mensagens de baixo valor e exigindo múltiplos DVNs para as de alto valor. Isto mostra que, em produção, as aplicações estão de facto a usar a abordagem de segurança "misturar e combinar" como um ponto de venda. Segurança e auditorias: Os contratos do LayerZero são imutáveis e foram auditados (a v1 teve múltiplas auditorias, a v2 também). A principal ameaça na v1 era o conluio Oráculo-Relayer – se as duas partes off-chain conspirassem, poderiam forjar uma mensagem. Na v2, essa ameaça é generalizada para o conluio de DVNs. Se todos os DVNs em que uma aplicação confia forem comprometidos por uma única entidade, uma mensagem falsa poderia passar. A resposta do LayerZero é encorajar DVNs específicos da aplicação (para que um atacante tivesse de comprometer também a equipa da aplicação) e a diversidade de verificadores (tornando o conluio mais difícil). Outro problema potencial é a má configuração ou o uso indevido da atualização – se o proprietário de uma aplicação mudar maliciosamente para uma Pilha de Segurança trivial (como um DVN 1-de-1 controlado por si mesmo), ele poderia contornar a segurança para explorar os seus próprios utilizadores. Isto é mais um risco de governança do que um bug do protocolo, e as comunidades precisam de estar vigilantes sobre como a segurança de uma aplicação omnichain é definida (preferencialmente exigindo multi-sig ou aprovação da comunidade para mudanças). Em termos de adoção, o LayerZero tem indiscutivelmente o maior uso entre os protocolos de mensagens em DeFi atualmente: ele alimenta a ponte para Stargate, a integração CCTP da Circle (para transferências de USDC), o swap cross-chain da Sushi, muitas pontes de NFT e inúmeros tokens OFT (projetos que escolhem o LayerZero para tornar o seu token disponível em múltiplas cadeias). Os efeitos de rede são fortes – à medida que mais cadeias integram os endpoints do LayerZero, torna-se mais fácil para novas cadeias se juntarem à rede "omnichain". A própria LayerZero Labs gere um DVN e a comunidade (incluindo fornecedores como Google Cloud, Polyhedra para provas zk, etc.) lançou mais de 15 DVNs até 2024. Nenhuma exploração importante do protocolo principal do LayerZero ocorreu até à data, o que é um sinal positivo (embora alguns hacks ao nível da aplicação ou erros de utilizador tenham acontecido, como com qualquer tecnologia). O design do protocolo de manter a camada de transporte simples (essencialmente apenas armazenando mensagens e exigindo provas) minimiza as vulnerabilidades on-chain, transferindo a maior parte da complexidade para os DVNs off-chain.
-
Hyperlane em Produção: O Hyperlane (anteriormente Abacus) está ativo em numerosas cadeias, incluindo Ethereum, múltiplos L2s (Optimism, Arbitrum, zkSync, etc.), cadeias Cosmos como a Osmosis através de um módulo Cosmos-SDK, e até cadeias MoveVM (é bastante amplo em suporte). No entanto, a sua adoção está atrás de incumbentes como LayerZero e Wormhole em termos de volume. O Hyperlane é frequentemente mencionado no contexto de ser uma solução de "ponte soberana" – ou seja, um projeto pode implementar o Hyperlane para ter a sua própria ponte com segurança personalizada. Por exemplo, algumas equipas de appchains usaram o Hyperlane para conectar a sua cadeia ao Ethereum sem depender de uma ponte partilhada. Um desenvolvimento notável é o Hyperlane Active Validation Service (AVS) lançado em meados de 2024, que é uma das primeiras aplicações de restaking do Ethereum. Tem validadores (muitos sendo operadores de topo do EigenLayer) a fazer restake de ETH para proteger as mensagens do Hyperlane, focando-se inicialmente em mensagens rápidas entre rollups. Atualmente, está a garantir a interoperabilidade entre rollups L2 do Ethereum com bons resultados – essencialmente fornecendo passagem de mensagens quase instantânea (mais rápido do que esperar pelas saídas de 7 dias dos rollups otimistas) com segurança económica ligada ao Ethereum. Em termos de modelo de ameaça, a abordagem multisig original do Hyperlane poderia ser atacada se chaves de validadores suficientes fossem comprometidas (como com qualquer ponte multisig). O Hyperlane teve um incidente de segurança no passado: em agosto de 2022, durante uma testnet inicial ou lançamento, houve uma exploração onde um atacante conseguiu sequestrar a chave de implementação de uma ponte de tokens do Hyperlane numa cadeia e cunhar tokens (perda de cerca de 700 mil dólares). Isto não foi uma falha do multisig em si, mas sim da segurança operacional em torno da implementação – destacou os riscos da capacidade de atualização e da gestão de chaves. A equipa reembolsou as perdas e melhorou os processos. Isto sublinha que as chaves de governança fazem parte do modelo de ameaça – proteger os controlos de administração é tão importante quanto os validadores. Com o AVS, o modelo de ameaça muda para um contexto do EigenLayer: se alguém pudesse causar um falso slashing ou evitar ser penalizado apesar de mau comportamento, isso seria um problema; mas o protocolo do EigenLayer lida com a lógica de slashing no Ethereum, que é robusta, assumindo a submissão correta da prova de fraude. A adoção atual do Hyperlane está a crescer no espaço dos rollups e entre algumas cadeias específicas de aplicações. Pode ainda não lidar com os fluxos multibilionários de alguns concorrentes, mas está a criar um nicho onde os desenvolvedores querem controlo total e extensibilidade fácil. O design modular do ISM significa que podemos ver configurações de segurança criativas: por exemplo, uma DAO poderia exigir não apenas assinaturas do Hyperlane, mas também um time-lock ou uma segunda assinatura de ponte para qualquer mensagem de administração, etc. O ethos sem permissão do Hyperlane (qualquer um pode executar um validador ou implementar numa nova cadeia) pode provar-se poderoso a longo prazo, mas também significa que o ecossistema precisa de amadurecer (por exemplo, mais validadores de terceiros a juntarem-se para descentralizar o conjunto padrão; a partir de 2025 não está claro quão descentralizado é o conjunto de validadores ativo na prática). No geral, a trajetória do Hyperlane é de melhoria da segurança (com restaking) e facilidade de uso, mas precisará de demonstrar resiliência e atrair liquidez significativa para ganhar o mesmo nível de confiança da comunidade que o IBC ou mesmo o LayerZero.
-
IBC 3.0 e Interoperabilidade do Cosmos em Produção: O IBC está ativo desde 2021 e é extremamente testado em batalha dentro do Cosmos. Até 2025, conecta mais de 115 zonas (incluindo Cosmos Hub, Osmosis, Juno, Cronos, Axelar, Kujira, etc.) com milhões de transações por mês e fluxos de tokens multibilionários. Impressionantemente, não teve nenhuma falha de segurança importante ao nível do protocolo. Houve um incidente notável relacionado com o IBC: em outubro de 2022, foi descoberta uma vulnerabilidade crítica no código do IBC (afetando todas as implementações v2.0) que poderia ter permitido a um atacante drenar valor de muitas cadeias conectadas ao IBC. No entanto, foi corrigida secretamente através de atualizações coordenadas antes de ser divulgada publicamente, e nenhuma exploração ocorreu. Isto foi um alerta de que mesmo protocolos formalmente verificados podem ter bugs. Desde então, o IBC passou por mais auditorias e reforço. O modelo de ameaça para o IBC diz respeito principalmente à segurança da cadeia: se uma cadeia conectada for hostil ou sofrer um ataque de 51%, ela poderia tentar alimentar dados inválidos ao light client de uma contraparte. As mitigações incluem o uso da governança para parar ou fechar conexões com cadeias que são inseguras (a governança do Cosmos Hub, por exemplo, pode votar para desligar as atualizações de cliente para uma cadeia específica se for detetada como quebrada). Além disso, os clientes IBC têm frequentemente um período de desvinculação ou alinhamento do período de confiança – por exemplo, um light client Tendermint não aceitará uma atualização do conjunto de validadores mais antiga que o período de desvinculação (para prevenir ataques de longo alcance). Outro problema possível é a censura de relayers – se nenhum relayer entregar pacotes, os fundos podem ficar presos em timeouts; mas como a retransmissão é sem permissão e muitas vezes incentivada, isto é tipicamente transitório. Com as Consultas Interchain e novas funcionalidades do IBC 3.0 a serem lançadas, vemos adoção em coisas como agregadores de DeX Cross-Chain (por exemplo, o Skip Protocol usando ICQ para recolher dados de preços através de cadeias) e governança cross-chain (por exemplo, o Cosmos Hub usando contas interchain para gerir a Neutron, uma cadeia consumidora). A adoção para além do Cosmos também é uma história: projetos como Polymer e Astria (um hub de interoperabilidade para rollups) estão efetivamente a trazer o IBC para os rollups do Ethereum através de um modelo hub/spoke, e as parachains do Polkadot usaram com sucesso o IBC para se conectar com cadeias Cosmos (por exemplo, a ponte Centauri entre Cosmos e Polkadot, construída pela Composable Finance, usa o IBC por baixo dos panos com um light client GRANDPA do lado do Cosmos). Há até uma implementação IBC-Solidity em andamento pela Polymer e DataChain que permitiria que contratos inteligentes do Ethereum verificassem pacotes IBC (usando um light client ou provas de validade). Se estes esforços tiverem sucesso, poderia ampliar drasticamente o uso do IBC para além do Cosmos, trazendo o seu modelo de confiança minimizada para competição direta com as pontes mais centralizadas nessas cadeias. Em termos de liquidez partilhada, a maior limitação do Cosmos era a ausência de uma stablecoin nativa ou de uma DEX com liquidez profunda ao nível do Ethereum – isso está a mudar com o surgimento de stablecoins nativas do Cosmos (como IST, CMST) e a conexão de ativos como USDC (Axelar e a ponte Gravity trouxeram USDC, e agora a Circle está a lançar USDC nativo no Cosmos via Noble). À medida que a liquidez se aprofunda, a combinação de alta segurança e transferências IBC fluidas pode tornar o Cosmos um nexo para o trading DeFi multi-chain – de facto, o relatório da Blockchain Capital notou que o IBC já estava a lidar com mais volume do que o LayerZero ou o Wormhole no início de 2024, embora isso se deva principalmente à força do tráfego Cosmos-para-Cosmos (o que sugere uma economia interchain muito ativa). No futuro, o principal desafio e oportunidade do IBC é expandir-se para cadeias heterogéneas sem sacrificar o seu ethos de segurança.
Em resumo, cada protocolo está a avançar: o LayerZero está a integrar-se rapidamente com muitas cadeias e aplicações, priorizando a flexibilidade e a adoção por parte dos desenvolvedores, e mitigando riscos ao permitir que as aplicações façam parte da sua própria segurança. O Hyperlane está a inovar com restaking e modularidade, visando ser a forma mais fácil de conectar novas cadeias com segurança configurável, embora ainda esteja a construir confiança e uso. O IBC é o padrão de ouro em ausência de confiança dentro do seu domínio, agora a evoluir para ser mais rápido (IBC 3.0) e esperando estender o seu domínio para além do Cosmos, apoiado por um forte historial. Utilizadores e projetos são sábios em considerar a maturidade e os incidentes de segurança de cada um: o IBC tem anos de operação estável (e enorme volume), mas limitado a certos ecossistemas; o LayerZero acumulou rapidamente uso, mas requer a compreensão de configurações de segurança personalizadas; o Hyperlane é mais recente na execução, mas promissor na visão, com passos cuidadosos em direção à segurança económica.
Conclusão e Perspetivas: Arquitetura de Interoperabilidade para o Futuro Multi-Chain
A viabilidade e interoperabilidade a longo prazo do cenário DeFi multi-chain serão provavelmente moldadas pela coexistência e até complementaridade de todos os três modelos de segurança. Cada abordagem tem pontos fortes claros, e em vez de uma solução única, podemos ver uma pilha onde o modelo de light client (IBC) fornece a base de maior garantia para rotas chave (especialmente entre as principais cadeias), enquanto sistemas de agregação de provas (LayerZero) fornecem conectividade universal com confiança personalizável, e modelos multisig (Hyperlane e outros) servem necessidades de nicho ou iniciam novos ecossistemas rapidamente.
Compromisso Segurança vs. Conectividade: Light clients como o IBC oferecem o mais próximo de uma "internet de blockchains" – uma camada de transporte neutra e padronizada, semelhante ao TCP/IP. Eles garantem que a interoperabilidade não introduz novas fraquezas, o que é crítico para a sustentabilidade a longo prazo. No entanto, eles exigem um amplo acordo sobre padrões e engenharia significativa por cadeia, o que abranda a rapidez com que novas conexões podem ser formadas. O LayerZero e o Hyperlane, por outro lado, priorizam a conectividade imediata e a flexibilidade, reconhecendo que nem toda a cadeia implementará o mesmo protocolo. Eles visam conectar "qualquer um a qualquer um", mesmo que isso signifique aceitar um pouco mais de confiança no entretanto. Com o tempo, podemos esperar que a lacuna se estreite: o LayerZero pode incorporar mais DVNs de confiança minimizada (até o próprio IBC poderia ser envolvido num DVN), e o Hyperlane pode usar mecanismos económicos para se aproximar da segurança da verificação nativa. De facto, o projeto Polymer prevê que IBC e LayerZero não precisam de ser concorrentes, mas podem ser sobrepostos – por exemplo, o LayerZero poderia usar um light client IBC como um dos seus DVNs quando disponível. Tal polinização cruzada é provável à medida que o espaço amadurece.
Componibilidade e Liquidez Unificada: Do ponto de vista de um utilizador de DeFi, o objetivo final é que a liquidez se torne agnóstica à cadeia. Já estamos a ver passos: com tokens omnichain (OFTs) não se preocupa em que cadeia a sua versão do token está, e com mercados monetários cross-chain pode pedir emprestado em qualquer cadeia contra colateral noutra. As escolhas arquitetónicas afetam diretamente a confiança do utilizador nestes sistemas. Se ocorrer um hack de ponte (como aconteceu com algumas pontes multisig historicamente), isso fratura a confiança e, portanto, a liquidez – os utilizadores retiram-se para locais mais seguros ou exigem prémios de risco. Assim, os protocolos que demonstram consistentemente segurança sustentarão os maiores pools de liquidez. A segurança interchain do Cosmos e o IBC mostraram um caminho: múltiplos livros de ordens e AMMs através de zonas compõem-se essencialmente num grande mercado porque as transferências são sem confiança e rápidas. O Stargate do LayerZero mostrou outro: um pool de liquidez unificado pode servir as transferências de muitas cadeias, mas exigia que os utilizadores confiassem na suposição de segurança do LayerZero (Oráculo+Relayer ou DVNs). À medida que o LayerZero v2 permite que cada pool defina uma segurança ainda maior (por exemplo, usar múltiplas redes de validadores de renome para verificar cada transferência), está a reduzir a lacuna de confiança. A viabilidade a longo prazo do DeFi multi-chain provavelmente depende de protocolos de interoperabilidade serem invisíveis, mas fiáveis – assim como os utilizadores da internet não pensam no TCP/IP, os utilizadores de cripto não deveriam ter de se preocupar com qual ponte ou sistema de mensagens uma dApp usa. Isso acontecerá quando os modelos de segurança forem robustos o suficiente para que as falhas sejam extremamente raras e quando houver alguma convergência ou componibilidade entre estas redes de interoperabilidade.
Interoperabilidade da Interoperabilidade: É concebível que, em alguns anos, não falaremos de LayerZero vs Hyperlane vs IBC como reinos separados, mas sim como um sistema em camadas. Por exemplo, um rollup do Ethereum poderia ter uma conexão IBC com um hub Cosmos via Polymer, e esse hub Cosmos poderia ter também um endpoint LayerZero, permitindo que as mensagens transitem do rollup para a rede do LayerZero através de um canal IBC seguro. O Hyperlane poderia até funcionar como um fallback ou agregação: uma aplicação poderia exigir tanto uma prova IBC como uma assinatura Hyperlane AVS para a máxima garantia. Este tipo de agregação de segurança através de protocolos poderia abordar até os modelos de ameaça mais avançados (é muito mais difícil subverter simultaneamente um light client IBC e um multisig restaked independente, etc.). Tais combinações, claro, adicionarão complexidade e custo, pelo que seriam reservadas para contextos de alto valor.
Governança e Descentralização: Cada modelo coloca poder diferente nas mãos de diferentes atores – o IBC nas mãos da governança da cadeia, o LayerZero nas mãos dos desenvolvedores de aplicações (e indiretamente, dos operadores de DVN que eles escolhem), e o Hyperlane nas mãos dos validadores da ponte e possivelmente dos restakers. O cenário interoperável a longo prazo precisará de garantir que nenhuma parte ou cartel possa dominar as transações cross-chain. Este é um risco, por exemplo, se um protocolo se tornar ubíquo, mas for controlado por um pequeno conjunto de atores; poderia tornar-se um ponto de estrangulamento (análogo aos provedores de serviços de internet centralizados). A forma de mitigar isso é descentralizando as próprias redes de mensagens (mais relayers, mais DVNs, mais validadores – todos sem permissão para aderir) e tendo caminhos alternativos. Neste ponto, o IBC tem a vantagem de ser um padrão aberto com muitas equipas independentes, e tanto o LayerZero como o Hyperlane estão a mover-se para aumentar a participação de terceiros (por exemplo, qualquer um pode executar um DVN do LayerZero ou um validador do Hyperlane). É provável que a competição e a participação aberta mantenham estes serviços honestos, assim como os mineiros/validadores nas L1s mantêm a camada base descentralizada. O mercado também votará com os pés: se uma solução se provar insegura ou demasiado centralizada, os desenvolvedores podem migrar para outra (especialmente à medida que os padrões de ponte se tornam mais interoperáveis).
Em conclusão, as arquiteturas de segurança do LayerZero v2, Hyperlane e IBC 3.0 contribuem cada uma para tornar a visão do DeFi multi-chain uma realidade, mas com filosofias diferentes. Os light clients priorizam a ausência de confiança e a neutralidade, os multisigs priorizam o pragmatismo e a facilidade de integração, e as abordagens agregadas priorizam a personalização e a adaptabilidade. O cenário DeFi multi-chain do futuro provavelmente usará uma combinação destes: infraestrutura crítica e transferências de alto valor protegidas por métodos de confiança minimizada ou economicamente seguros, e middleware flexível para conectar à longa cauda de novas cadeias e aplicações. Com estes elementos em vigor, os utilizadores desfrutarão de liquidez unificada e componibilidade cross-chain com a mesma confiança e facilidade de usar uma única cadeia. O caminho a seguir é de convergência – não necessariamente dos próprios protocolos, mas dos resultados: um mundo onde a interoperabilidade é segura, fluida e padrão. Alcançar isso exigirá engenharia rigorosa contínua (para evitar explorações), governança colaborativa (para definir padrões como o IBC ou interfaces de contrato universais), e talvez o mais importante, uma abordagem iterativa à segurança que combina o melhor de todos os mundos: matemática, incentivos económicos e design inteligente. O estado final pode realmente cumprir a analogia frequentemente citada: blockchains interconectadas como redes na internet, com protocolos como LayerZero, Hyperlane e IBC a formar a autoestrada omnichain na qual o DeFi irá viajar no futuro previsível.
Fontes:
- LayerZero v2 architecture and DVN security – LayerZero V2 Deep Dive; Flare x LayerZero V2 announcement
- Hyperlane multisig and modular ISM – Hyperlane Docs: Validators; Tiger Research on Hyperlane; Hyperlane restaking (AVS) announcement
- IBC 3.0 light clients and features – IBC Protocol Overview; 3Commas Cosmos 2025 (IBC 3.0)
- Comparison of trust assumptions – Nosleepjohn (Hyperlane) on bridge tradeoffs; IBC vs bridges (Polymer blog)
- DeFi examples (Stargate, ICA, etc.) – Flare blog on LayerZero (Stargate volume); IBC use cases (Stride liquid staking); LayerZero Medium (OFT and OApp standards); Hyperlane use cases
- Adoption and stats – Flare x LayerZero (cross-chain messages, volume); Range.org on IBC volume; Blockchain Capital on IBC vs bridges; LayerZero blog (15+ DVNs); IBC testimonials (Osmosis, etc.).