"""
Final Output
Hyperlane Cross-Chain Message Passing (General Message Passing, GMP) est un processus standardisé, exécutable de manière répétée entre toutes les chaînes compatibles : l'application appelle la fonction dispatch sur la Mailbox de la chaîne d'origine pour envoyer un message, un relayer hors chaîne soumet le message accompagné de métadonnées de vérification à la chaîne de destination, et après validation par l'Interchain Security Module (ISM), la Mailbox appelle la fonction handle du contrat destinataire pour finaliser la remise. Hyperlane (HYPER) décrit l'architecture globale de la couche d'interopérabilité Hyperlane au travers de trois composants : Mailbox, ISM et Warp Route.
Dans les applications multi-chaînes, les développeurs doivent maîtriser le parcours complet, du dispatch à la remise, pour configurer correctement les modules de sécurité, estimer les frais et diagnostiquer les messages non remis. ISM et Warp Route présente la répartition des rôles entre les types d'ISM (notamment Multisig et Aggregation) et Warp Route, afin d'aider les développeurs à choisir le niveau de vérification adapté lors de la phase de traitement.
Chaque message cross-chain possède un messageId unique à l'échelle mondiale, et la Mailbox tient un registre des messages déjà remis pour éviter les attaques par rejeu. Hyperlane vs LayerZero vs Wormhole compare les différences structurelles entre les trois protocoles en matière de chemins de vérification des messages et de droits de déploiement. L'expéditeur prépaye les frais de remise sur la chaîne de destination via l'Interchain Gas Payment (IGP) sur la chaîne d'origine ; le relayer règle les frais de gaz sur la chaîne de destination pour exécuter l'appel de traitement. L'Explorer permet de suivre l'intégralité du cycle de vie d'un message, du dispatch à la remise.
Quelles sont les étapes du passage de messages cross-chain Hyperlane ?
Le flux de messages cross-chain Hyperlane se décompose en six phases consécutives : dispatch (envoi sur la chaîne d'origine), écriture dans l'arbre de Merkle, signature par le validateur (si l'ISM l'exige), indexation et collecte des métadonnées par le relayer, traitement (soumission sur la chaîne de destination), puis vérification ISM et exécution du handle (remise sur la chaîne de destination). Ce flux n'est lié ni à une application spécifique ni à un événement unique ; tout contrat intégré à la Mailbox peut le déclencher de manière répétée.
| Étape |
Chaîne |
Action principale |
Participants clés |
| Dispatch |
Chaîne d'origine |
Encodage du message, écriture dans l'arbre de Merkle, émission d'événements |
Contrat expéditeur, Mailbox |
| Attestation (Signature) |
Origine (hors chaîne) |
Signature du checkpoint sur la racine de Merkle |
Validateur (scénario Multisig ISM) |
| Relais |
Hors chaîne → Chaîne de destination |
Indexation des événements, collecte des métadonnées, soumission du traitement |
Relayer |
| Vérification |
Chaîne de destination |
Vérification de l'origine et de l'intégrité du message |
ISM |
| Remise |
Chaîne de destination |
Appel du handle du destinataire pour exécuter la logique métier |
Mailbox, Destinataire |
Le tableau ci-dessus présente la répartition complète des étapes du GMP Hyperlane, de la chaîne d'origine à la chaîne de destination. Le dispatch et la remise s'effectuent sur les contrats Mailbox des chaînes concernées. Les relayers et les validateurs assurent les fonctions de transmission hors chaîne et d'attestation de sécurité, tandis que l'ISM agit comme passerelle de vérification des messages sur la chaîne de destination.
Figure 1. Vue d'ensemble du flux de messages cross-chain Hyperlane : chemin complet depuis le dispatch sur la chaîne d'origine, en passant par le relayer/validateur, jusqu'à la vérification ISM et la remise handle sur la chaîne de destination.
La phase de dispatch sur la chaîne d'origine est initiée par le contrat expéditeur qui appelle Mailbox.dispatch(). La Mailbox reçoit trois paramètres principaux : l'ID de domaine de la chaîne de destination (destinationDomain), l'adresse du destinataire (recipientAddress, encodée en bytes32) et le corps du message (messageBody). La Mailbox ajoute un en-tête de message standard au corps, comprenant les champs version, nonce, origin, sender, destination et recipient, garantissant l'unicité et l'intégrité du message.
Une fois le dispatch exécuté, la Mailbox insère le message complet comme une feuille dans un arbre de Merkle incrémental (géré par le contrat MerkleTreeHook) et émet les événements Dispatch et DispatchId. Le messageId est le hachage keccak256 du message (en-tête inclus), renvoyé par l'appel dispatch et traçable dans l'Explorer. Le nonce est un compteur croissant de manière monotone sur la Mailbox de la chaîne d'origine. Même si le corps du message est identique, des nonces différents produisent des messageIds distincts.
L'expéditeur peut interroger les frais cross-chain via quoteDispatch(), qui couvre le coût du dispatch sur la chaîne d'origine et le gaz inter-chaîne prépayé pour la remise sur la chaîne de destination. Un crochet post-dispatch (Post-Dispatch Hook) peut prépayer le gaz de la chaîne de destination au relayer via l'InterchainGasPaymaster (IGP) après le dispatch. Une fois le dispatch terminé, le message passe en état d'attente de relais. Le messageId est généré à partir du hachage du message complet, et la Mailbox de la chaîne de destination empêche les remises en double via la table de correspondance delivered(messageId).
Le Relayer et le Validateur remplissent des fonctions distinctes mais complémentaires dans le protocole Hyperlane. Le Validateur est responsable de l'attestation de sécurité : lorsque la Mailbox de la chaîne d'origine dispatche un nouveau message, le MerkleTreeHook émet un événement InsertedIntoTree. Le Validateur lit la racine de Merkle courante, signe le checkpoint et publie la signature dans un stockage public (par exemple, AWS S3 ou Google Cloud Storage). Le Relayer gère la couche de transport : il écoute les événements de la Mailbox de la chaîne d'origine, collecte les métadonnées requises par l'ISM (signatures de validateurs, preuve de Merkle, etc.) et appelle Mailbox.process() sur la chaîne de destination pour soumettre le message.
Le Validateur n'est nécessaire que dans les scénarios Multisig ISM ou Economic Security Module. Si le destinataire configure un Optimistic ISM, un ISM à preuve de connaissance nulle, ou tout autre module ne nécessitant pas de signatures de validateurs, le relayer n'a qu'à collecter les métadonnées spécifiques à cet ISM. Hyperlane n'impose pas d'ensemble de validateurs attitrés ; le destinataire peut lui-même configurer les adresses des validateurs et le seuil de signature dans le Multisig ISM.
Le Relayer se compose d'un Indexeur et d'un Soumetteur. L'Indexeur interroge les événements de la chaîne d'origine via RPC et les enregistre dans une base de données locale. Le Soumetteur vérifie que le gaz a été prépayé, récupère les métadonnées, simule puis diffuse l'appel de traitement. En cas d'échec de la remise, le relayer réessaie automatiquement avec une stratégie de backoff exponentiel. Les signatures des validateurs sont publiques ; n'importe qui peut les utiliser et appeler le traitement. L'expéditeur choisit le destinataire prépayé via l'IGP, et l'opérateur du relayer doit rééquilibrer les revenus vers le compte de la chaîne de destination.
La phase de remise sur la chaîne de destination est déclenchée par le relayer appelant Mailbox.process(metadata, message). La Mailbox vérifie d'abord si le messageId a déjà été remis ; s'il figure dans la table delivered, le rejeu est rejeté. Ensuite, la Mailbox interroge l'ISM spécifié par le contrat destinataire (via recipientIsm() ou une configuration applicative personnalisée) et transmet le message et les metadata à la fonction ISM.verify().
Après validation par l'ISM, la Mailbox appelle la fonction handle(origin, sender, body) du contrat destinataire, en lui transmettant le corps du message et les informations d'origine pour exécution de la logique métier. Le contrat destinataire doit implémenter la fonction handle de l'interface IMessageRecipient, qui exécute des opérations telles que le vote de gouvernance cross-chain, le minting/la libération d'actifs ou les mises à jour d'état. Une fois la remise réussie, la Mailbox marque le messageId comme remis et émet les événements Process et ProcessId.
Pour les applications d'actifs cross-chain comme Warp Route, la fonction handle déclenche la logique de verrouillage, minting, brûlage ou libération de tokens. Pour les applications de gouvernance cross-chain, elle enregistre les poids de vote ou exécute les propositions. Les frais de gaz de la phase de remise sont payés par le relayer sur la chaîne de destination, tandis que l'expéditeur a déjà prépayé les frais correspondants sur la chaîne d'origine via l'IGP.
Figure 2. Séquence de remise sur la chaîne de destination : le traitement par la Mailbox déclenche la vérification ISM ; après vérification, le handle du destinataire est appelé, et le rejeu est empêché via la table de correspondance messageId.
L'ISM (Interchain Security Module) est un contrat intelligent sur la chaîne de destination chargé de vérifier l'authenticité des messages cross-chain. Avant la remise, la Mailbox transmet le message et les metadata soumis par le relayer à ISM.verify(). La logique de vérification varie selon le type d'ISM. L'ISM par défaut est le Multisig ISM, qui exige qu'un nombre configuré de validateurs signent la racine de Merkle de la chaîne d'origine, atteignant un seuil. Les applications peuvent également déployer des ISM personnalisés ou utiliser l'ISM d'agrégation pour combiner plusieurs chemins de vérification.
Pour vérifier la configuration ISM, interrogez l'adresse ISM du contrat destinataire, vérifiez le seuil de validateurs et les paramètres de type ISM, et consultez dans l'Explorer l'état de vérification et les métadonnées pour un message spécifique.
| Type d'ISM |
Méthode de vérification |
Cas d'usage |
| Multisig ISM |
Les validateurs signent la racine de Merkle jusqu'à atteindre le seuil |
Modèle de sécurité par défaut, messages généraux |
| Aggregation ISM |
Plusieurs ISM doivent tous valider |
Empilement de sécurité multicouche |
| Rate Limited ISM |
Limite le volume de messages/transferts par unité de temps |
Actifs de grande valeur en cross-chain |
| Routing ISM |
Spécifie différents ISM par chaîne d'origine |
Stratégies de sécurité différenciées multi-chaînes |
| Custom ISM |
L'application définit sa propre logique de vérification |
Besoins métier spécifiques |
Dans le cadre du Multisig ISM, le relayer récupère les signatures de checkpoint dans le stockage public des validateurs et les soumet avec la preuve de Merkle. L'Economic Security Module offre une sécurité économique via EigenLayer AVS ; une fraude du validateur peut entraîner une pénalité (slashing). Si la vérification réussit, l'ISM renvoie true et la Mailbox exécute handle ; en cas d'échec, la transaction de traitement est annulée et le relayer réessaie selon une stratégie de backoff.
Quels sont les risques et les limites du passage de messages cross-chain ?
Le passage de messages cross-chain Hyperlane comporte des risques structurels au niveau mécanique, qu'il convient d'appréhender depuis les couches de message, de transport et économique. Les risques liés à la couche de message incluent : une configuration incorrecte des ISM personnalisés peut affaiblir la force de vérification ; des vulnérabilités dans la logique de la fonction handle du destinataire peuvent entraîner des mises à jour d'état erronées. Les risques liés à la couche de transport incluent : des retards ou des interruptions du relayer peuvent laisser des messages non remis pendant une période prolongée (IGP prépayé mais relayer n'ayant pas encore soumis) ; les fluctuations du prix du gaz sur la chaîne de destination peuvent affecter la volonté du relayer de soumettre ; l'indisponibilité du validateur dans le Multisig ISM avec un seuil élevé peut entraver la vivacité.
Les risques liés à la couche économique incluent la fraude du validateur pouvant déclencher une pénalité HYPER, et une configuration incorrecte des frais IGP pouvant conduire à des frais de remise insuffisants. La remise des messages n'est pas instantanée ; elle nécessite d'attendre la finalité de la chaîne d'origine et la soumission par le relayer. La fiabilité dépend du prépaiement IGP et de la qualité opérationnelle du relayer.
| Source de risque |
Manifestation typique |
Stratégie d'atténuation |
| Configuration ISM |
Seuil de vérification trop bas ou validateurs non fiables |
Auditer les paramètres ISM, utiliser Aggregation ISM |
| Retard du relayer |
Message bloqué en attente |
Suivre via l'Explorer, garantir des frais IGP suffisants, prévoir un relayer de secours |
| Indisponibilité du validateur |
Seuil de signature Multisig non atteint |
Validateurs redondants, surveiller la publication des checkpoints |
| Vulnérabilité de contrat |
Exploitation de la logique handle ou ISM |
Audit, Rate Limited ISM, Pausable ISM |
| Attaque par rejeu |
Même messageId remis plusieurs fois |
La table delivered de Mailbox rejette automatiquement |
Avant toute opération, vérifiez les adresses on-chain des contrats Mailbox, ISM et destinataire, et distinguez les configurations par défaut du protocole des configurations personnalisées de l'application. Pour les scénarios comme le cross-chain d'actifs Warp Route, prêtez également attention au contrat de routage et aux relations de correspondance des tokens.
Résumé
Les messages cross-chain Hyperlane suivent un flux reproductible : dispatch → attestation → relais → vérification → remise. Mailbox.dispatch() sur la chaîne d'origine encode le message et l'inscrit dans l'arbre de Merkle ; les validateurs signent le checkpoint (dans les scénarios Multisig ISM) ; le relayer collecte les métadonnées et appelle process sur la chaîne de destination ; après vérification ISM, la Mailbox appelle handle pour finaliser la remise. Le messageId est unique à l'échelle mondiale et les messages remis ne peuvent pas être rejoués. L'IGP prépaye le gaz de la chaîne de destination, et l'Explorer assure un suivi complet du cycle de vie.
FAQ
Quel est le flux de base des messages cross-chain Hyperlane ?
L'expéditeur sur la chaîne d'origine appelle Mailbox.dispatch() pour envoyer le message. La Mailbox l'inscrit dans l'arbre de Merkle et émet des événements. Le relayer écoute ces événements, collecte les métadonnées requises par l'ISM et appelle Mailbox.process() sur la chaîne de destination. Après vérification ISM, la Mailbox appelle la fonction handle du destinataire pour finaliser la remise.
Sur quelles chaînes se produisent le dispatch et la remise ?
Le dispatch a lieu sur le contrat Mailbox de la chaîne d'origine, déclenché par le contrat expéditeur. La remise a lieu sur le contrat Mailbox de la chaîne de destination, déclenchée par le relayer appelant process, et après vérification ISM, le handle du destinataire est appelé.
Quelle est la différence entre le relayer et le validateur ?
Le Validateur signe le checkpoint de la racine de Merkle de la chaîne d'origine, fournissant une attestation pour les modules de sécurité comme Multisig ISM. Le Relayer gère la couche de transport hors chaîne, en indexant les événements de la chaîne d'origine, en collectant les métadonnées et en soumettant l'appel de traitement sur la chaîne de destination. Leurs fonctions sont complémentaires : le relayer est indispensable pour toutes les remises de messages, tandis que le validateur n'est requis que pour des types d'ISM spécifiques.
Comment puis-je suivre l'état d'un message cross-chain ?
Chaque message possède un messageId unique (le hachage keccak256 renvoyé lors du dispatch). L'Explorer Hyperlane permet d'interroger l'état complet du cycle de vie du message, du dispatch à la remise, y compris l'heure d'envoi sur la chaîne d'origine, les enregistrements de soumission du relayer, les résultats de la vérification ISM et la confirmation de remise sur la chaîne de destination.
Qu'est-ce qui pourrait empêcher la remise d'un message ?
Les causes fréquentes incluent : des frais IGP prépayés insuffisants, le relayer n'a pas encore soumis ou est en phase de nouvelle tentative, les signatures des validateurs n'ont pas atteint le seuil Multisig, les frais de gaz de la chaîne de destination sont trop élevés pour inciter le relayer, ou un échec de la vérification ISM. Vous pouvez utiliser l'Explorer pour consulter la raison spécifique de l'attente et les tentatives de reprise pour un message donné.
Un message cross-chain peut-il être remis deux fois ?
Non. La Mailbox maintient une table delivered(messageId). Une fois qu'un messageId a été remis, il est rejeté lors du traitement sur la chaîne de destination, empêchant ainsi les attaques par rejeu. Le champ nonce garantit également que même si le corps du message est identique, des dispatches différents produisent des messageIds différents.
