Dans les applications multi-chaînes, les ponts inter-chaînes reposent souvent sur des modèles de sécurité fixes et immuables, ce qui complique pour les développeurs l'application de forces de vérification différentes aux messages de gouvernance de grande valeur par rapport aux mises à jour de données de faible valeur. L'architecture modulaire d'Hyperlane (HYPER) permet à chaque message de spécifier son propre ISM, et les déployeurs de Warp Route peuvent configurer une pile de sécurité dédiée pour chaque route d'actif, adaptant ainsi le modèle de sécurité au scénario métier spécifique. Le flux de messages inter-chaînes d'Hyperlane couvre le chemin reproductible de l'envoi à la livraison, servant de point de départ pour comprendre quand l'ISM intervient au cours de la phase de processus.
Hyperlane vs. LayerZero vs. Wormhole différencie l'approche modulaire d'Hyperlane de LayerZero et Wormhole selon trois axes architecturaux — Mailbox/ISM, Endpoint/DVN et Guardian/VAA. Cela permet de clarifier où se situe la vérification ISM personnalisable dans le spectre des protocoles d'interopérabilité.
Qu'est-ce que l'ISM ?
Un Interchain Security Module (ISM) est un module de smart contract déployé sur la chaîne de destination. Il vérifie si un message inter-chaînes destiné à être livré existe réellement sur la chaîne source. Avant que la Mailbox n'appelle la fonction handle du contrat destinataire, elle transmet le message et les métadonnées soumises par le relayer à la fonction verify de l'ISM. Si la vérification réussit, la livraison a lieu ; si elle échoue ou si l'appel est annulé, le message n'est pas traité.
La relation entre l'ISM, la Mailbox et le relayer peut se résumer ainsi : la Mailbox de la chaîne source écrit le message via dispatch et émet un événement. Le relayer écoute cet événement, puis appelle la fonction process de la Mailbox sur la chaîne de destination, en soumettant le message et les métadonnées. La Mailbox appelle ensuite l'ISM pour effectuer la vérification. Si le contrat destinataire implémente l'interface ISpecifiesInterchainSecurityModule, il peut spécifier un ISM au niveau de l'application ; si aucun n'est spécifié ou que l'adresse zéro est donnée, la Mailbox utilise l'ISM par défaut.
| Composant |
Chaîne |
Fonction principale |
Responsabilité |
| Mailbox (Source) |
Chaîne source |
dispatch |
Coder le message, écrire dans l'arbre de Merkle, déclencher les hooks |
| Relayer |
Hors chaîne |
— |
Écouter les événements, soumettre l'appel process sur la chaîne de destination |
| ISM |
Chaîne de destination |
verify |
Vérifier la source et l'intégrité du message |
| Mailbox (Destination) |
Chaîne de destination |
process |
Appeler l'ISM pour la vérification et déclencher recipient.handle |
| Contrat destinataire |
Chaîne de destination |
handle |
Exécuter la logique métier inter-chaînes |
Le tableau ci-dessus illustre la position de l'ISM dans la chaîne de livraison des messages inter-chaînes : l'ISM se situe entre la Mailbox de la chaîne de destination et le contrat destinataire, servant de point de contrôle de sécurité qui détermine si le message peut finalement être exécuté.
Types d'ISM par défaut et personnalisés
Hyperlane prend en charge trois modes d'utilisation de l'ISM : Configurer (utiliser des ISM préconstruits), Composer (combiner plusieurs ISM) et Personnaliser (écrire un nouvel ISM). L'ISM par défaut fait référence à l'ISM Multisig préconfiguré sur le contrat Mailbox, qui assure la sécurité économique via l'ensemble de validateurs d'Hyperlane. Le staking de HYPER et stHYPER explique les mécanismes de staking et de slashing derrière l'ensemble de validateurs. Si une application ne spécifie pas d'ISM personnalisé, ce module par défaut est utilisé.
Les types d'ISM préconstruits incluent l'ISM Multisig, l'ISM de Routage, l'ISM d'Agrégation, l'ISM à Débit Limité et l'ISM Pausable, entre autres. L'ISM Multisig utilise un modèle de signature M-of-N de validateurs et est le choix par défaut pour la plupart des déploiements. L'ISM de Routage dirige les messages vers différents ISM en fonction du domaine de la chaîne source, idéal pour les scénarios où les exigences de sécurité varient selon les chaînes sources. L'ISM d'Agrégation exige que m sous-ISM sur n réussissent la vérification, permettant d'empiler plusieurs conditions de sécurité.
L'ISM à Débit Limité est conçu pour les scénarios Warp Route, limitant le montant total de jetons pouvant être transférés vers la chaîne de destination dans une fenêtre de temps unitaire. Le contrat RateLimitedIsm accepte des paramètres tels que maxCapacity et vérifie, lors de la phase verify, si le montant cumulé transféré dépasse le plafond de la fenêtre. Si c'est le cas, la vérification échoue et le message n'est pas livré. Ce mécanisme peut être associé au RateLimitedHook de la chaîne source pour obtenir un contrôle bidirectionnel du débit.
L'ISM Pausable permet au propriétaire de la route de suspendre la vérification des messages en cas d'anomalie, arrêtant complètement les transferts inter-chaînes. L'ISM d'Agrégation peut imbriquer l'ISM à Débit Limité avec l'ISM Pausable : l'ISM à Débit Limité limite l'ampleur des pertes dans une fenêtre d'attaque, tandis que l'ISM Pausable permet au propriétaire de fermer complètement la route après confirmation d'un événement, formant ainsi une stratégie de défense en profondeur.
| Type d'ISM |
Logique de vérification |
Scénario typique |
| ISM Multisig |
Signatures M-of-N de validateurs |
Sécurité par défaut, ensemble de validateurs communautaire |
| ISM de Routage |
Routage vers différents ISM par domaine source |
Plusieurs chaînes sources, sécurité différenciée |
| ISM d'Agrégation |
m sous-ISM sur n doivent réussir |
Empilement de plusieurs modèles de sécurité |
| ISM à Débit Limité |
Plafond sur les jetons entrants par fenêtre |
Contrôle de débit Warp Route |
| ISM Pausable |
Le propriétaire peut suspendre la vérification |
Réponse aux incidents, arrêt d'urgence |
Le tableau ci-dessus compare la logique de vérification et les cas d'usage typiques de cinq types d'ISM courants. L'ISM d'Agrégation peut combiner n'importe quels ISM en une pile de sécurité — par exemple, exiger qu'un ISM Multisig et un ISM Wormhole réussissent tous deux, ou empiler un ISM à Débit Limité avec un ISM Pausable sur les messages de grande valeur.
Figure 1. Types de modules de sécurité ISM Hyperlane : relations de combinaison entre ISM Multisig par défaut, ISM Multisig personnalisé, Agrégation, Débit Limité et Pausable.
Fonctionnement de Warp Route
Hyperlane Warp Route (HWR) est une route d'actif inter-chaînes modulaire construite sur la Mailbox. Chaque Warp Route déploie des contrats d'entrée/sortie sur toutes les chaînes participantes et coordonne le verrouillage, le minting, le brûlage et la libération des jetons via des messages inter-chaînes. Contrairement aux ponts traditionnels avec des modèles de sécurité fixes, les déployeurs de HWR peuvent spécifier l'ISM utilisé pour vérifier les messages de transfert inter-chaînes, permettant ainsi de configurer indépendamment la sécurité de chaque route.
Les types courants de HWR incluent : Native Token HWR (transfert inter-chaînes direct de jetons de gaz natifs comme ETH), ERC20 adossé à des garanties (verrouillage de collatéral ERC-20 sur la chaîne source et minting de jetons synthétiques sur la chaîne de destination), ERC20 synthétique (minting d'une version synthétique représentant le jeton d'origine sur la chaîne de destination) et Warp Route 2.0 (support de collatéral multi-chaînes et rééquilibrage via Rebalancer). Avant d'utiliser une Warp Route, les utilisateurs doivent comprendre sa configuration ISM et ses hypothèses de confiance.
Flux direct typique : L'utilisateur dépose des jetons dans la Warp Route de la chaîne source. Le contrat verrouille le collatéral et appelle Mailbox.dispatch pour envoyer un message inter-chaînes. Le relayer soumet le message à la chaîne de destination via Mailbox.process. Après vérification par l'ISM, la Warp Route de la chaîne de destination mint ou libère les jetons correspondants. Flux inverse : L'utilisateur brûle des jetons synthétiques sur la chaîne de destination. Après vérification par l'ISM, la chaîne source libère les jetons de collatéral verrouillés.
HypERC20Collateral et HypERC20 sont des formes courantes de contrats Warp Route sur les chaînes EVM. Le premier verrouille l'ERC-20 sur la chaîne de collatéral et envoie un message, tandis que le second reçoit le message vérifié sur la chaîne synthétique et mint un jeton synthétique avec un mapping 1:1. Nexus Bridge est une interface inter-chaînes orientée utilisateur, mais en interne, elle suit toujours le chemin de vérification Warp Route et ISM.
Figure 2. Flux Warp Route Hyperlane : la chaîne source verrouille le collatéral, la Mailbox envoie le message, la chaîne de destination vérifie via l'ISM puis mint les jetons synthétiques ; le chemin inverse implique le brûlage et la libération.
Combinaison d'ISM et de Hooks
Les Hooks sont des modules de logique post-traitement exécutés après le dispatch de la Mailbox de la chaîne source. Ils complètent l'ISM sur la chaîne de destination : les Hooks contrôlent le comportement côté envoi du message, tandis que l'ISM contrôle la vérification côté réception. La fonction dispatch de la Mailbox appelle la fonction postDispatch du Hook après avoir écrit le message. Le Hook peut collecter les frais de gaz inter-chaînes, écrire dans l'arbre de Merkle, appliquer des limites de débit, effectuer des vérifications de pause, etc.
Les types de Hook standard incluent MERKLE_TREE, INTERCHAIN_GAS_PAYMASTER, PAUSABLE et RATE_LIMITED. Le RateLimitedHook est déployé sur la chaîne source et associé au RateLimitedIsm de la chaîne de destination. Lors de la phase dispatch, il vérifie si le montant sortant côté source dépasse le plafond de la fenêtre, réalisant un contrôle bidirectionnel du débit. Le Pausable Hook permet au propriétaire de suspendre l'envoi de messages sur la chaîne source, ce qui, combiné à l'ISM Pausable, peut arrêter les routes aux deux extrémités simultanément.
Les Hooks et l'ISM suivent un appariement « Hook de chaîne source + ISM de chaîne de destination » : le Hook exécute des contraintes sortantes dans postDispatch, tandis que l'ISM effectue la vérification entrante dans verify. Les combinaisons personnalisées peuvent suivre les modèles OpStackHook et OpStackIsm.
Lors du déploiement d'une Warp Route, l'adresse interchainSecurityModule et l'adresse du Hook peuvent être spécifiées dans la configuration. Le SDK TypeScript et la CLI prennent en charge des énumérations comme IsmType.RATE_LIMITED, permettant aux déployeurs d'écrire directement les paramètres RateLimitedIsm (par exemple, maxCapacity, owner, recipient) dans la configuration de la Warp Route. Lors de l'imbrication d'un ISM à Débit Limité dans un ISM d'Agrégation, la version du relayer doit être agents-v2.2.0 ou supérieure.
Risques liés à la personnalisation des ISM et des Warp Routes
Lors de la personnalisation d'un ISM, le contrat destinataire doit implémenter l'interface InterchainSecurityModule, qui inclut les fonctions verify et moduleType. verify est la logique de vérification centrale ; le retour de false ou l'annulation empêchera la livraison du message. moduleType informe le relayer du format de métadonnées à attacher. Si l'ISM est mal configuré — par exemple, avec trop peu de validateurs, un seuil bas, ou l'absence de couverture de toutes les chaînes sources — la force de sécurité inter-chaînes peut être affaiblie.
Lors de la combinaison de sous-modules dans un ISM d'Agrégation, le seuil m-of-n et les adresses de déploiement de chaque sous-ISM doivent être clairement définis. Le maxCapacity d'un ISM à Débit Limité doit être ≥ 86400 et un multiple de 86400. Le propriétaire peut ajuster le taux de recharge via setRefillRate. L'autorité de mise en pause dans un ISM Pausable est concentrée chez le propriétaire ; une mauvaise gestion de la clé du propriétaire pourrait entraîner l'arrêt malveillant de la route ou l'incapacité de réagir aux événements en temps utile.
Lors de la personnalisation des Warp Routes, notez que la configuration ISM de chaque route est indépendante. Les utilisateurs doivent vérifier les adresses de contrats on-chain et les types d'ISM avant utilisation. Les mappings de jetons sur les chaînes de collatéral et synthétiques doivent rester 1:1. Si le Rebalancer est un service géré, il existe une dépendance opérationnelle. Des contrats Warp Route frauduleux pourraient entraîner une perte d'actifs ; les utilisateurs doivent vérifier via Explorer et les adresses de déploiement connues.
La sécurité de l'ISM Multisig par défaut est garantie par les stakeurs de HYPER et l'ensemble de validateurs. Pour les ISM personnalisés, les développeurs doivent évaluer indépendamment la qualité des validateurs, les seuils de signature et la couverture du slashing.
Résumé
L'ISM est le module de sécurité d'Hyperlane qui vérifie les messages inter-chaînes sur la chaîne de destination. Warp Route est une route d'actif modulaire basée sur la Mailbox. L'ISM Multisig par défaut assure la sécurité économique via l'ensemble de validateurs d'Hyperlane. Les développeurs peuvent utiliser Configurer, Composer ou Personnaliser pour déployer des ISM tels que Multisig, Routage, Agrégation, Débit Limité et Pausable, et les associer à des Hooks de chaîne source pour le contrôle bidirectionnel du débit et la suspension. Les déployeurs de Warp Route spécifient un ISM indépendant pour chaque route ; les utilisateurs doivent comprendre la configuration de sécurité et les hypothèses de confiance de la route avant de l'utiliser.
FAQ
Quelle est la différence entre ISM et ISM par défaut ?
ISM est un terme général désignant les modules de vérification de messages inter-chaînes. L'ISM par défaut fait référence à l'ISM Multisig préconfiguré sur le contrat Mailbox, qui est utilisé automatiquement lorsqu'une application ne spécifie pas d'ISM personnalisé. Une application peut remplacer la configuration par défaut en spécifiant un ISM indépendant via l'interface ISpecifiesInterchainSecurityModule.
Comment l'ISM à Débit Limité limite-t-il les montants de transfert inter-chaînes ?
L'ISM à Débit Limité vérifie, lors de la phase verify sur la chaîne de destination, si le montant cumulé de jetons entrants dans une fenêtre de temps unitaire dépasse le plafond maxCapacity. Si c'est le cas, la vérification échoue et le message n'est pas livré. Le RateLimitedHook de la chaîne source peut imposer la même contrainte sur les montants sortants lors de la phase dispatch, permettant un contrôle bidirectionnel. maxCapacity doit être ≥ 86400 et un multiple de 86400.
Comment l'ISM d'Agrégation combine-t-il plusieurs modules de sécurité ?
L'ISM d'Agrégation exige que m sous-ISM parmi ses n sous-ISM configurés réussissent la vérification pour que le message soit livré. Par exemple, il peut exiger qu'un ISM Multisig et un ISM à Débit Limité réussissent tous deux, ou imbriquer un ISM Pausable avec un ISM à Débit Limité pour obtenir une limitation de débit plus une suspension d'urgence. Les sous-ISM peuvent être n'importe quelle adresse de contrat ISM déployée.
Quelle est la relation entre Warp Route et Nexus Bridge ?
Warp Route (HWR) est un contrat de routage d'actif inter-chaînes on-chain responsable du verrouillage, du minting, du brûlage et de la libération des jetons, et peut spécifier un ISM indépendant. Nexus Bridge est une interface utilisateur construite sur Warp Route, facilitant les opérations de jetons inter-chaînes pour les utilisateurs finaux. En interne, elle suit toujours le chemin de passage des messages de la Mailbox et de vérification ISM.
Risques courants lors de la personnalisation de l'ISM d'une Warp Route
Un ensemble de validateurs trop petit ou avec un seuil bas peut affaiblir la sécurité d'un ISM Multisig. Une configuration incorrecte des sous-modules dans un ISM d'Agrégation peut rendre certaines conditions de sécurité inefficaces. Des paramètres maxCapacity inappropriés dans un ISM à Débit Limité peuvent restreindre excessivement les transferts normaux. La fuite de la clé du propriétaire d'un ISM Pausable pourrait entraîner une suspension malveillante de la route. Avant utilisation, les utilisateurs doivent vérifier les adresses et paramètres des contrats ISM on-chain, et faire la distinction entre la sécurité économique des validateurs par défaut et les hypothèses de confiance des ISM personnalisés.
Sur quelles chaînes les Hooks et l'ISM s'exécutent-ils ?
Les Hooks exécutent postDispatch après le dispatch de la Mailbox de la chaîne source, contrôlant la logique sortante telle que le paiement du gaz, l'écriture dans l'arbre de Merkle, la limitation du débit et la mise en pause. L'ISM exécute verify lors de la phase process de la Mailbox de la chaîne de destination, contrôlant la vérification entrante. RateLimitedHook et RateLimitedIsm résident respectivement sur la chaîne source et la chaîne de destination, appariés pour réaliser un contrôle bidirectionnel du débit.
