Como o Hyperlane Cross-Chain Messaging funciona? O processo completo, do envio à entrega.

A passagem de mensagens cross-chain do Hyperlane (General Message Passing, GMP) é um processo padronizado executado repetidamente entre blockchains compatíveis: o aplicativo chama a função dispatch no Mailbox da blockchain de origem para enviar uma mensagem, um relayer off-chain submete a mensagem com metadados de verificação à blockchain de destino e, após verificação pelo Interchain Security Module (ISM), o Mailbox chama a função handle no contrato destinatário para concluir a entrega. Hyperlane (HYPER) descreve a estrutura geral da camada de interoperabilidade do Hyperlane por meio de três componentes: Mailbox, ISM e Warp Route.

Em aplicativos multichain, os desenvolvedores precisam entender o caminho completo do envio à entrega para configurar módulos de segurança, estimar taxas e solucionar mensagens não entregues. ISM e Warp Route explica a divisão de trabalho entre os tipos de ISM (como Multisig e Aggregation) e Warp Route, ajudando os desenvolvedores a escolher a força de verificação adequada durante a fase do processo.

Cada mensagem cross-chain tem um messageId globalmente único, e o Mailbox mantém um mapeamento de mensagens entregues para impedir ataques de replay. Hyperlane vs LayerZero vs Wormhole compara as diferenças estruturais entre os três protocolos em termos de caminhos de verificação de mensagens e permissões de implantação. O remetente paga antecipadamente a taxa de entrega na blockchain de destino pela blockchain de origem via Interchain Gas Payment (IGP); o relayer paga o gas na blockchain de destino para concluir a chamada de processo. O Explorer rastreia o ciclo de vida completo da mensagem, do envio ao processamento.

Quais são as etapas da passagem de mensagens cross-chain do Hyperlane?

O fluxo de mensagens cross-chain do Hyperlane se resume em seis etapas consecutivas: dispatch (envio na blockchain de origem), gravação na árvore de Merkle, assinatura do validador (se exigido pelo ISM), indexação do relayer e coleta de metadados, process (submissão na blockchain de destino) e verificação do ISM com handle (entrega na blockchain de destino). Esse fluxo não depende de um aplicativo específico nem de um evento único; qualquer contrato integrado ao Mailbox pode acioná-lo repetidamente.

A tabela acima mostra a divisão completa das etapas do GMP do Hyperlane, da blockchain de origem à blockchain de destino. O dispatch e a entrega ocorrem nos contratos Mailbox das respectivas blockchains. Relayers e validadores executam funções de transmissão off-chain e atestação de segurança, enquanto o ISM atua como gateway de verificação de mensagens na blockchain de destino.

Figura 1. Visão geral do fluxo de mensagens cross-chain do Hyperlane: Caminho completo do dispatch na blockchain de origem, passando pelo relayer/validador, até a verificação do ISM e entrega handle na blockchain de destino.

Como uma mensagem é enviada durante a fase de dispatch na blockchain de origem?

A fase de dispatch na blockchain de origem é acionada pelo contrato remetente chamando Mailbox.dispatch(). O Mailbox recebe três parâmetros principais: ID do domínio da blockchain de destino (destinationDomain), endereço do destinatário (recipientAddress, codificado como bytes32) e o corpo da mensagem (messageBody). O Mailbox adiciona um cabeçalho de mensagem padrão ao corpo, que inclui campos como version, nonce, origin, sender, destination e recipient, garantindo que a mensagem seja exclusivamente identificável e à prova de adulteração.

Após a execução do dispatch, o Mailbox insere a mensagem completa como uma folha em uma árvore de Merkle incremental (mantida pelo contrato MerkleTreeHook) e emite os eventos Dispatch e DispatchId. O messageId é o hash keccak256 da mensagem (incluindo o cabeçalho), retornado pela chamada de dispatch e rastreável no Explorer. O nonce é um contador monotonicamente crescente no Mailbox da blockchain de origem. Mesmo que o corpo da mensagem seja idêntico, nonces diferentes produzem messageIds diferentes.

O remetente pode consultar a taxa cross-chain por meio de quoteDispatch(), que cobre o custo do dispatch na blockchain de origem e o gas interchain pré-pago para a entrega na blockchain de destino. Um Post-Dispatch Hook pode pagar antecipadamente o gas da blockchain de destino ao relayer por meio do InterchainGasPaymaster (IGP) após o dispatch. Após a conclusão do dispatch, a mensagem entra em estado de relay pendente. O messageId é gerado a partir do hash da mensagem completa, e o Mailbox da blockchain de destino evita entregas duplicadas por meio do mapeamento delivered(messageId).

Como o relayer e o validador colaboram para entregar mensagens?

O Relayer e o Validador executam funções distintas, porém complementares, no protocolo Hyperlane. O Validador é responsável pela atestação de segurança: quando o Mailbox da blockchain de origem envia uma nova mensagem, o MerkleTreeHook emite um evento InsertedIntoTree. O Validador lê a raiz de Merkle atual, assina o checkpoint e publica a assinatura em um armazenamento público (por exemplo, AWS S3 ou Google Cloud Storage). O Relayer lida com a camada de transporte: ele escuta eventos do Mailbox da blockchain de origem, coleta os metadados exigidos pelo ISM (por exemplo, assinaturas de validadores, prova de Merkle) e chama Mailbox.process() na blockchain de destino para submeter a mensagem.

O Validador é necessário apenas em cenários de ISM Multisig ou Módulo de Segurança Econômica. Se o destinatário configurar um ISM Otimista, um ISM de prova de conhecimento zero ou outro módulo que não exija assinaturas de validadores, o relayer precisará coletar apenas os metadados exigidos por esse ISM. O Hyperlane não exige um conjunto de validadores consagrados; o destinatário pode configurar os endereços dos validadores e o limite de assinaturas no ISM Multisig por conta própria.

O Relayer consiste internamente em um Indexador e um Submissor. O Indexador consulta eventos da blockchain de origem por meio de RPC e os grava em um banco de dados local. O Submissor confirma que o gas foi pago antecipadamente, recupera metadados, simula e transmite a chamada de processo. Se a entrega falhar, o relayer faz novas tentativas automaticamente usando uma estratégia de backoff exponencial. As assinaturas dos validadores são publicamente acessíveis; qualquer pessoa pode carregar as assinaturas e chamar o processo. O remetente da mensagem seleciona o destinatário pré-pago por meio do IGP, e o operador do relayer deve reequilibrar a receita para a conta da blockchain de destino.

Como a entrega é concluída durante a fase de entrega na blockchain de destino?

A fase de entrega na blockchain de destino é acionada pelo relayer chamando Mailbox.process(metadata, message). O Mailbox primeiro verifica se o messageId já foi entregue; se existir no mapeamento delivered, o replay é rejeitado. Em seguida, o Mailbox consulta o ISM especificado pelo contrato destinatário (por meio de recipientIsm() ou configuração personalizada do aplicativo) e passa a message e os metadata para a função ISM.verify().

Após a verificação do ISM ser aprovada, o Mailbox chama a função handle(origin, sender, body) do contrato destinatário, passando o corpo da mensagem e as informações de origem para a lógica da camada de aplicativo. O contrato destinatário deve implementar a função handle da interface IMessageRecipient, que executa operações de negócios, como votação de governança cross-chain, cunhagem/liberação de ativos ou atualizações de estado. Após a entrega bem-sucedida, o Mailbox marca o messageId como entregue e emite os eventos Process e ProcessId.

Para aplicativos cross-chain de ativos, como Warp Route, a função handle aciona a lógica de travamento, cunhagem, queima ou liberação de tokens. Para aplicativos de governança cross-chain, a função handle registra pesos de votação ou executa propostas. O gas para a fase de entrega é pago pelo relayer na blockchain de destino, enquanto o remetente já pagou a taxa correspondente antecipadamente na blockchain de origem por meio do IGP.

Figura 2. Sequência de entrega na blockchain de destino: O processo do Mailbox aciona a verificação do ISM; após a verificação, o handle do destinatário é chamado e o replay é evitado por meio do mapeamento messageId.

Como o ISM da blockchain de destino verifica mensagens cross-chain?

O ISM (Interchain Security Module) é um contrato inteligente na blockchain de destino responsável por verificar a autenticidade das mensagens cross-chain. Antes da entrega, o Mailbox passa a message e os metadata enviados pelo relayer para ISM.verify(). A lógica de verificação varia de acordo com o tipo de ISM. O ISM padrão é o ISM Multisig, que exige que um número configurado de validadores assine a raiz de Merkle da blockchain de origem, atingindo um limite. Os aplicativos também podem implantar ISMs personalizados ou usar o ISM Aggregation para combinar vários caminhos de verificação.

Para verificar a configuração do ISM, consulte o endereço do ISM do contrato destinatário, verifique o limite de validadores e os parâmetros do tipo de ISM e confirme o status de verificação e os metadados de uma mensagem específica no Explorer.

No ISM Multisig, o relayer recupera as assinaturas de checkpoint do armazenamento público do validador e as envia junto com a prova de Merkle. O Módulo de Segurança Econômica fornece segurança econômica por meio do EigenLayer AVS; fraudes de validadores podem acionar o slashing. Se a verificação for aprovada, o ISM retorna true e o Mailbox executa handle; se a verificação falhar, a transação de processo é revertida e o relayer tentará novamente de acordo com uma estratégia de backoff.

Quais são os riscos e limitações da passagem de mensagens cross-chain?

A passagem de mensagens cross-chain do Hyperlane envolve riscos estruturais no nível do mecanismo, que precisam ser entendidos a partir da camada de mensagens, da camada de transporte e da camada econômica. Os riscos da camada de mensagens incluem: configuração inadequada de ISMs personalizados pode enfraquecer a força da verificação; vulnerabilidades na lógica da função handle do destinatário podem levar a atualizações incorretas de estado. Os riscos da camada de transporte incluem: atrasos ou paradas do relayer podem deixar mensagens não entregues por muito tempo (IGP pré-pago, mas o relayer ainda não enviou); flutuações no preço do gas na blockchain de destino podem afetar a disposição do relayer em enviar; inatividade do validador no ISM Multisig com um limite alto pode dificultar a vitalidade.

Os riscos da camada econômica incluem fraudes de validadores que podem acionar o slashing do HYPER, e configuração incorreta de taxas do IGP pode levar a taxas de entrega insuficientes. A entrega de mensagens não é instantânea; é necessário aguardar a finalização da blockchain de origem e o envio do relayer. A confiabilidade depende do pré-pagamento do IGP e da qualidade operacional do relayer.

Antes de operar, verifique os endereços on-chain dos contratos Mailbox, ISM e destinatário, e distinga entre as configurações padrão do protocolo e as configurações personalizadas do aplicativo. Para cenários como cross-chain de ativos Warp Route, preste também atenção ao contrato de roteamento e aos relacionamentos de mapeamento de tokens.

Resumo

As mensagens cross-chain do Hyperlane seguem um fluxo repetível: dispatch → atestação → relay → verificar → entregar. O Mailbox.dispatch() da blockchain de origem codifica a mensagem e a grava na árvore de Merkle; os validadores assinam o checkpoint (em cenários de ISM Multisig); o relayer coleta metadados e chama process na blockchain de destino; após a verificação do ISM, o Mailbox chama handle para concluir a entrega. O messageId é globalmente único e as mensagens entregues não podem ser repetidas. O IGP paga antecipadamente o gas da blockchain de destino, e o Explorer fornece rastreamento do ciclo de vida completo.

Perguntas Frequentes

Qual é o fluxo básico das mensagens cross-chain do Hyperlane?

O remetente na blockchain de origem chama Mailbox.dispatch() para enviar a mensagem. O Mailbox a grava na árvore de Merkle e emite eventos. O relayer escuta os eventos, coleta os metadados exigidos pelo ISM e chama Mailbox.process() na blockchain de destino. Após a verificação do ISM, o Mailbox chama a função handle do destinatário para concluir a entrega.

Em quais blockchains ocorrem o dispatch e a entrega?

O dispatch ocorre no contrato Mailbox da blockchain de origem, acionado pelo contrato remetente. A entrega ocorre no contrato Mailbox da blockchain de destino, acionada pelo relayer chamando process, e após a verificação do ISM, o handle do destinatário é chamado.

Qual é a diferença entre o relayer e o validador?

O Validador assina o checkpoint da raiz de Merkle da blockchain de origem, fornecendo atestação para módulos de segurança como o ISM Multisig. O Relayer lida com a camada de transporte off-chain, indexando eventos da blockchain de origem, coletando metadados e submetendo a chamada de processo na blockchain de destino. Suas funções são complementares: o relayer é essencial para todas as entregas de mensagens, enquanto o validador é necessário apenas para tipos específicos de ISM.

Como posso rastrear o status de uma mensagem cross-chain?

Cada mensagem tem um messageId exclusivo (o hash keccak256 retornado no dispatch). O Explorer do Hyperlane permite consultar o status do ciclo de vida completo da mensagem, do dispatch ao process, incluindo o horário de envio na blockchain de origem, registros de submissão do relayer, resultados da verificação do ISM e confirmação de entrega na blockchain de destino.

O que pode fazer com que uma mensagem não seja entregue?

Os motivos comuns incluem: taxas IGP pré-pagas insuficientes, o relayer ainda não submeteu ou está repetindo a tentativa, as assinaturas do validador não atingiram o limite Multisig, as taxas de gas da blockchain de destino estão muito altas, causando atrasos no relayer, ou falha na verificação do ISM. Você pode usar o Explorer para visualizar o motivo específico da pendência e os registros de repetição de uma mensagem específica.

Uma mensagem cross-chain pode ser entregue duas vezes?

Não. O Mailbox mantém um mapeamento delivered(messageId). Depois que um messageId é entregue, ele é rejeitado durante o processo na blockchain de destino, evitando ataques de replay. O campo nonce também garante que, mesmo que o corpo da mensagem seja o mesmo, dispatches diferentes produzam messageIds diferentes.