Como funciona a troca de mensagens entre cadeias da Hyperlane? O processo completo, do envio à entrega.

A Passagem de Mensagens entre Cadeias (General Message Passing, GMP) do Hyperlane é um processo padronizado executável de forma repetida entre quaisquer cadeias suportadas: a aplicação invoca a função dispatch na Mailbox da cadeia de origem para enviar uma mensagem; um relayer off-chain submete a mensagem juntamente com metadados de verificação para a cadeia de destino; após verificação pelo Interchain Security Module (ISM), a Mailbox chama a função handle no contrato recetor para concluir a entrega. O Hyperlane (HYPER) descreve a arquitetura geral da camada de interoperabilidade do Hyperlane através de três componentes: Mailbox, ISM e Warp Route.

Em aplicações multi-cadeia, os programadores precisam de compreender o percurso completo, desde o envio da mensagem até à entrega, para configurarem corretamente os módulos de segurança, estimarem taxas e resolverem problemas de mensagens não entregues. O ISM e Warp Route explica a divisão de tarefas entre os tipos de ISM (como Multisig e Aggregation) e a Warp Route, auxiliando os programadores a selecionar a força de verificação adequada durante a fase do processo.

Cada mensagem entre cadeias possui um messageId globalmente único, e a Mailbox mantém um mapeamento das mensagens já entregues para prevenir ataques de repetição. Hyperlane vs LayerZero vs Wormhole compara as diferenças estruturais entre os três protocolos ao nível dos percursos de verificação de mensagens e permissões de implantação. O remetente da mensagem paga adiantadamente a taxa de entrega na cadeia de destino através do Interchain Gas Payment (IGP) na cadeia de origem; o relayer paga o gas na cadeia de destino para concluir a chamada de process. O Explorer permite rastrear o ciclo de vida completo de uma mensagem, desde o dispatch até ao process.

Quais são as Etapas da Passagem de Mensagens entre Cadeias do Hyperlane?

O fluxo de mensagens entre cadeias do Hyperlane pode ser resumido em seis etapas consecutivas: dispatch (envio na cadeia de origem), escrita na Merkle tree, assinatura do validador (se exigido pelo ISM), indexação do relayer e recolha de metadados, process (submissão na cadeia de destino) e verificação ISM com handle (entrega na cadeia de destino). Este fluxo não depende de uma aplicação específica nem de um evento isolado; qualquer contrato que integre a Mailbox pode desencadeá-lo repetidamente.

A tabela acima apresenta a decomposição completa das etapas do GMP do Hyperlane, desde a cadeia de origem até à cadeia de destino. O dispatch e a entrega ocorrem nos contratos Mailbox das respetivas cadeias. Os relayers e validadores desempenham funções de transmissão off-chain e atestação de segurança, enquanto o ISM atua como portal de verificação de mensagens na cadeia de destino.

Figura 1. Visão geral do fluxo de mensagens entre cadeias do Hyperlane: percurso completo desde o dispatch na cadeia de origem, passando pelo relayer/validador, até à verificação ISM e entrega com handle na cadeia de destino.

Como é Enviada uma Mensagem Durante a Fase de Dispatch na Cadeia de Origem?

A fase de dispatch na cadeia de origem é iniciada pelo contrato remetente ao invocar Mailbox.dispatch(). A Mailbox recebe três parâmetros principais: o ID do domínio da cadeia de destino (destinationDomain), o endereço do recetor (recipientAddress, codificado como bytes32) e o corpo da mensagem (messageBody). A Mailbox antepõe um cabeçalho padrão ao corpo, que inclui campos como version, nonce, origin, sender, destination e recipient, garantindo que a mensagem seja exclusivamente identificável e resistente a adulterações.

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

O remetente pode consultar a taxa entre cadeias através de quoteDispatch(), que cobre o custo do dispatch na cadeia de origem e o gas inter-cadeias pré-pago para a entrega na cadeia de destino. Um Post-Dispatch Hook pode pagar adiantadamente o gas da cadeia de destino ao relayer através do InterchainGasPaymaster (IGP) após o dispatch. Uma vez concluído o dispatch, a mensagem entra no estado de espera de relay. O messageId é gerado a partir do hash da mensagem completa, e a Mailbox da cadeia de destino impede entregas duplicadas através do mapeamento delivered(messageId).

Como Colaboram o Relayer e o Validador para Entregar Mensagens?

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

O Validador só é necessário em cenários de Multisig ISM ou Economic Security Module. Se o recetor configurar um Optimistic ISM, um ISM de prova de conhecimento zero ou outro módulo que não exija assinaturas de validadores, o relayer apenas precisa de recolher os metadados exigidos por esse ISM. O Hyperlane não impõe um conjunto de validadores obrigatório; o recetor pode configurar os endereços dos validadores e o limite de assinaturas no Multisig ISM por sua conta.

O Relayer é composto internamente por um Indexer e um Submitter. O Indexer consulta eventos da cadeia de origem via RPC e regista-os numa base de dados local. O Submitter confirma que o gas foi pré-pago, obtém metadados, simula e transmite a chamada process. Se a entrega falhar, o relayer tenta novamente com uma estratégia de backoff exponencial. As assinaturas dos validadores são publicamente acessíveis; qualquer pessoa pode transportar as assinaturas e invocar process. O remetente da mensagem seleciona o recetor pré-pago através do IGP, e o operador do relayer deve reequilibrar as receitas para a conta da cadeia de destino.

Como é Concluída a Entrega Durante a Fase de Entrega na Cadeia de Destino?

A fase de entrega na cadeia de destino é iniciada pelo relayer ao invocar Mailbox.process(metadata, message). A Mailbox verifica primeiro se o messageId já foi entregue; se existir no mapeamento delivered, a repetição é rejeitada. De seguida, a Mailbox consulta o ISM especificado pelo contrato recetor (através de recipientIsm() ou configuração personalizada da aplicação) e passa a message e os metadados para a função ISM.verify().

Após a verificação do ISM ser aprovada, a Mailbox invoca a função handle(origin, sender, body) do contrato recetor, passando o corpo da mensagem e as informações de origem para a lógica da camada de aplicação. O contrato recetor deve implementar a função handle da interface IMessageRecipient, que executa operações de negócio, como votação de governança entre cadeias, cunhagem/libertação de ativos ou atualizações de estado. Assim que a entrega é bem-sucedida, a Mailbox marca o messageId como entregue e emite os eventos Process e ProcessId.

Para aplicações de ativos entre cadeias como a Warp Route, a função handle desencadeia lógica de bloqueio, cunhagem, queima ou libertação de Tokens. Para aplicações de governança entre cadeias, a função handle regista pesos de votação ou executa propostas. O gas da fase de entrega é pago pelo relayer na cadeia de destino, enquanto o remetente já pagou adiantadamente a taxa correspondente na cadeia de origem através do IGP.

Figura 2. Sequência de entrega na cadeia de destino: Mailbox process desencadeia ISM verify; após verificação, recipient handle é invocado e a repetição é impedida através do mapeamento messageId.

Como Verifica o ISM na Cadeia de Destino as Mensagens entre Cadeias?

O ISM (Interchain Security Module) é um Contrato inteligente na cadeia de destino responsável por verificar a autenticidade das mensagens entre cadeias. Antes da entrega, a Mailbox passa a message e os metadados submetidos pelo relayer para ISM.verify(). A lógica de verificação varia conforme o tipo de ISM. O ISM predefinido é o Multisig ISM, que exige que um número configurado de validadores assine a raiz Merkle da cadeia de origem, atingindo um limite. As aplicações também podem implementar ISMs personalizados ou usar o Aggregation ISM para combinar vários percursos de verificação.

Para verificar a configuração do ISM, pode consultar o endereço ISM do contrato recetor, verificar o limite de validadores e os parâmetros do tipo ISM, e confirmar o estado de verificação e metadados para uma mensagem específica no Explorer.

No Multisig ISM, o relayer obtém assinaturas de checkpoint do armazenamento público do validador e submete-as juntamente com a prova Merkle. O Economic Security Module proporciona segurança económica através do EigenLayer AVS; a fraude do validador pode desencadear slashing. Se a verificação for aprovada, o ISM devolve true e a Mailbox executa handle; se a verificação falhar, a transação process reverte 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 entre Cadeias?

A passagem de mensagens entre cadeias do Hyperlane envolve riscos estruturais ao nível do mecanismo, que precisam de ser compreendidos 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 de verificação; vulnerabilidades na lógica da função handle do recetor podem levar a atualizações de estado incorretas. Os riscos da camada de transporte incluem: atrasos ou paragens do relayer podem deixar mensagens não entregues por muito tempo (IGP pré-pago mas relayer ainda não submeteu); flutuações no preço do gas na cadeia de destino podem afetar a disposição do relayer em submeter; inatividade do validador no Multisig ISM com um limite elevado pode dificultar a vivacidade.

Os riscos da camada económica incluem fraude do validador que pode desencadear slashing de HYPER, e configuração incorreta das taxas IGP pode levar a taxas de entrega insuficientes. A entrega de mensagens não é instantânea; é necessário aguardar pela finalidade da cadeia de origem e pela submissão do relayer. A fiabilidade depende do pré-pagamento IGP e da qualidade operacional do relayer.

Antes de operar, verifique os endereços on-chain dos contratos Mailbox, ISM e recetor, e distinga entre configurações predefinidas do protocolo e configurações personalizadas da aplicação. Para cenários como Warp Route de ativos entre cadeias, preste também atenção ao contrato de roteamento e às relações de mapeamento de Tokens.

Resumo

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

Perguntas Frequentes

Qual é o fluxo básico das mensagens entre cadeias do Hyperlane?

O remetente na cadeia de origem invoca Mailbox.dispatch() para enviar a mensagem. A Mailbox escreve-a na Merkle tree e emite eventos. O relayer escuta os eventos, recolhe os metadados exigidos pelo ISM e invoca Mailbox.process() na cadeia de destino. Após verificação ISM, a Mailbox invoca a função handle do recetor para concluir a entrega.

Em que cadeias ocorrem o dispatch e a entrega?

O dispatch ocorre no contrato Mailbox da cadeia de origem, iniciado pelo contrato remetente. A entrega ocorre no contrato Mailbox da cadeia de destino, iniciada pelo relayer ao invocar process, e após verificação ISM, o handle do recetor é invocado.

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

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

Como posso rastrear o estado de uma mensagem entre cadeias?

Cada mensagem tem um messageId único (o hash keccak256 devolvido no dispatch). O Hyperlane Explorer permite consultar o estado do ciclo de vida completo da mensagem, desde o dispatch até ao process, incluindo o tempo de envio na cadeia de origem, registos de submissão do relayer, resultados de verificação ISM e confirmação de entrega na cadeia de destino.

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

As razões comuns incluem: taxas IGP pré-pagas insuficientes, o relayer ainda não submeteu ou está a tentar novamente, as assinaturas dos validadores não atingiram o limite Multisig, as taxas de gas na cadeia de destino são demasiado altas causando atrasos do relayer, ou falha na verificação ISM. Pode usar o Explorer para ver a razão específica de pendência e os registos de repetição para uma determinada mensagem.

Uma mensagem entre cadeias pode ser entregue duas vezes?

Não. A Mailbox mantém um mapeamento delivered(messageId). Assim que um messageId foi entregue, será rejeitado durante o process na cadeia de destino, impedindo ataques de repetição. O campo nonce também garante que, mesmo que o corpo da mensagem seja o mesmo, diferentes dispatches produzem diferentes messageIds.