マルチチェーンアプリケーションでは、クロスチェーンブリッジは多くの場合、固定された不変のセキュリティモデルに依存しているため、開発者が価値の高いガバナンスメッセージと低価値のデータ更新に異なる検証強度を適用するのは困難です。Hyperlane (HYPER)のモジュラーアーキテクチャでは、各メッセージが独自のISMを指定でき、Warp Routeのデプロイヤーはアセットルートごとに専用のセキュリティスタックを構成できます。これにより、セキュリティモデルを特定のビジネスシナリオに適合させることが可能です。Hyperlaneのクロスチェーンメッセージフローは、ディスパッチからデリバリーまでの反復可能な経路を説明しており、プロセス段階でISMがいつ介入するかを理解するための基礎となります。
Hyperlane vs. LayerZero vs. Wormholeでは、HyperlaneのモジュラーアプローチをLayerZeroおよびWormholeと、Mailbox/ISM、Endpoint/DVN、Guardian/VAAの3つのアーキテクチャパスで比較します。これにより、相互運用性プロトコルのスペクトルの中で、カスタマイズ可能なISM検証がどの位置にあるかが明確になります。
Interchain Security Module(ISM)は、宛先チェーンにデプロイされるスマートコントラクトモジュールです。配信対象のクロスチェーンメッセージがソースチェーンに実際に存在するかを検証します。Mailboxは受信者コントラクトのhandle関数を呼び出す前に、メッセージとリレイヤーが送信したメタデータをISMのverify関数に渡します。検証が成功すれば配信が進み、失敗するか呼び出しがリバートされた場合はメッセージは処理されません。
ISM、Mailbox、リレイヤーの関係は次のように要約できます。ソースチェーンのMailboxはdispatchでメッセージを書き込み、イベントを発行します。リレイヤーはそのイベントをリッスンし、宛先チェーンのMailboxのprocess関数を呼び出してメッセージとメタデータを送信します。続いてMailboxはISMを呼び出して検証を完了します。受信者コントラクトがISpecifiesInterchainSecurityModuleインターフェースを実装している場合、アプリケーションレベルのISMを指定できます。指定がない場合やゼロアドレスが指定された場合、MailboxはデフォルトのISMを使用します。
| コンポーネント | チェーン | コア関数 | 責任 |
|---|---|---|---|
| Mailbox(ソース) | ソースチェーン | dispatch |
メッセージのエンコード、Merkleツリーへの書き込み、フックのトリガー |
| リレイヤー | オフチェーン | — | イベントのリッスン、宛先チェーンでのprocess呼び出しの送信 |
| ISM | 宛先チェーン | verify |
メッセージのソースと完全性の検証 |
| Mailbox(宛先) | 宛先チェーン | process |
ISMを呼び出して検証を実行、recipient.handleをトリガー |
| 受信者コントラクト | 宛先チェーン | handle |
クロスチェーンのビジネスロジックを実行 |
上の表は、クロスチェーンメッセージ配信チェーンにおけるISMの位置を示しています。ISMは宛先チェーンのMailboxと受信者コントラクトの間に位置し、メッセージが最終的に実行可能かどうかを判断するセキュリティチェックポイントとして機能します。
Hyperlaneは3つのISM使用モードをサポートしています。Configure(既存のISMを使用)、Compose(複数のISMを組み合わせる)、Customize(新しいISMを作成する)です。デフォルトISMはMailboxコントラクトにあらかじめ構成されているMultisig ISMであり、Hyperlaneのバリデーターセットを通じて経済的セキュリティを提供します。HYPERとstHYPERのステーキングでは、バリデーターセットの背後にあるステーキングとスラッシングの仕組みを説明しています。アプリケーションがカスタムISMを指定しない場合、このデフォルトモジュールが使用されます。
事前構築されたISMタイプには、Multisig ISM、Routing ISM、Aggregation ISM、Rate Limited ISM、Pausable ISMなどがあります。Multisig ISMはM-of-Nのバリデーター署名モデルを使用し、ほとんどのデプロイメントでデフォルトとして選択されます。Routing ISMはソースチェーンドメインに基づいてメッセージを異なるISMにルーティングするため、ソースチェーンごとにセキュリティ要件が異なるシナリオに適しています。Aggregation ISMはn個のサブISMのうちm個が検証を通過することを要求し、複数のセキュリティ条件を積み重ねることができます。
Rate Limited ISMはWarp Routeのシナリオ向けに設計されており、単位時間ウィンドウ内に宛先チェーンに転送できるトークンの総量を制限します。RateLimitedIsmコントラクトはmaxCapacityなどのパラメータを受け取り、verifyフェーズで累積転送量がウィンドウ上限を超えているかをチェックします。超えている場合は検証が失敗し、メッセージは配信されません。このメカニズムはソースチェーンのRateLimitedHookと組み合わせることで、双方向のスループット制御を実現します。
Pausable ISMを使用すると、ルート所有者は異常を検出した際にメッセージ検証を一時停止し、クロスチェーン転送を完全に停止できます。Aggregation ISMはRate Limited ISMとPausable ISMをネストできます。Rate Limited ISMが攻撃ウィンドウ内の損失規模を制限し、Pausable ISMが所有者にイベント確認後のルート完全停止を可能にすることで、多層防御戦略を形成します。
| ISMタイプ | 検証ロジック | 典型的なシナリオ |
|---|---|---|
| Multisig ISM | M-of-Nのバリデーター署名 | デフォルトセキュリティ、コミュニティバリデーターセット |
| Routing ISM | ソースドメイン別に異なるISMにルーティング | 複数ソースチェーン、差別化されたセキュリティ |
| Aggregation ISM | n個中のm個のサブISMが合格 | 複数セキュリティモデルの積み重ね |
| Rate Limited ISM | ウィンドウあたりの入金トークン上限 | Warp Routeのスループット制御 |
| Pausable ISM | 所有者による検証の一時停止 | インシデント対応、緊急停止 |
上の表は、5つの一般的なISMタイプの検証ロジックと典型的なユースケースを比較しています。Aggregation ISMは任意のISMをセキュリティスタックに組み合わせることができます。例えば、Multisig ISMとWormhole ISMの両方を必須としたり、高価値メッセージに対してRate Limited ISMとPausable ISMを積み重ねたりすることが可能です。
図1. Hyperlane ISMセキュリティモジュールのタイプ:Default Multisig、Custom Multisig、Aggregation、Rate Limited、Pausableの組み合わせ関係。
Hyperlane Warp Route(HWR)は、Mailbox上に構築されたモジュラー型クロスチェーンアセットルートです。各Warp Routeは参加するすべてのチェーンにエントリ/イグジットコントラクトをデプロイし、クロスチェーンメッセージを介してトークンのロック、ミント、バーン、リリースを調整します。固定セキュリティモデルの従来型ブリッジとは異なり、HWRデプロイヤーはクロスチェーン転送メッセージの検証に使用するISMを指定できるため、ルートごとにセキュリティ構成を独立して設定できます。
一般的なHWRタイプには、Native Token HWR(ETHなどのネイティブガストークンの直接クロスチェーン転送)、Collateral-Backed ERC20(ソースチェーンでERC-20担保をロックし、宛先チェーンで合成トークンをミント)、Synthetic ERC20(元のトークンを表す合成バージョンを宛先チェーンでミント)、Warp Route 2.0(マルチチェーン担保とRebalancerによるリバランスをサポート)があります。Warp Routeを使用する前に、ユーザーはそのISM構成と信頼前提を理解する必要があります。
典型的な順方向フロー:ユーザーはソースチェーンのWarp Routeにトークンを預け入れます。コントラクトは担保をロックし、Mailbox.dispatchを呼び出してクロスチェーンメッセージを送信します。リレイヤーはMailbox.processを介して宛先チェーンにメッセージを送信します。ISM検証後、宛先チェーンのWarp Routeは対応するトークンをミントまたはリリースします。逆方向フロー:ユーザーは宛先チェーンで合成トークンをバーンします。ISM検証後、ソースチェーンはロックされた担保トークンをリリースします。
HypERC20CollateralとHypERC20は、EVMチェーンにおける一般的なWarp Routeコントラクト形式です。前者は担保チェーンでERC-20をロックしてメッセージを送信し、後者は合成チェーンで検証されたメッセージを受信して1:1マッピングの合成トークンをミントします。Nexus Bridgeはユーザー向けのクロスチェーンインターフェースですが、内部では依然としてWarp RouteとISM検証の経路に従います。
図2. Hyperlane Warp Routeのフロー:ソースチェーンが担保をロックし、Mailboxがメッセージを送信、宛先チェーンでISMが検証して合成トークンをミント。逆方向パスではバーンとリリースが行われます。
フックは、ソースチェーンMailboxのdispatch後に実行される後処理ロジックモジュールです。これらは宛先チェーンのISMを補完します。フックはメッセージ送信側の動作を制御し、ISMはメッセージ受信側の検証を制御します。Mailboxのdispatch関数はメッセージを書き込んだ後、フックのpostDispatch関数を呼び出します。フックはクロスチェーンガス料金の徴収、Merkleツリーへの書き込み、レート制限の適用、一時停止チェックなどを行います。
標準的なフックタイプには、MERKLE_TREE、INTERCHAIN_GAS_PAYMASTER、PAUSABLE、RATE_LIMITEDがあります。RateLimitedHookはソースチェーンにデプロイされ、宛先チェーンのRateLimitedIsmとペアになります。dispatchフェーズでは、ソース側の出金量がウィンドウ上限を超えていないかをチェックし、双方向のスループット制御を実現します。Pausable Hookは所有者がソースチェーンでのメッセージ送信を一時停止できるようにし、Pausable ISMと組み合わせることで、両端のルートを同時にシャットダウンできます。
フックとISMは「ソースチェーンフック+宛先チェーンISM」のペアリングに従います。フックはpostDispatchで送信制約を実行し、ISMはverifyで受信検証を実行します。カスタムの組み合わせはOpStackHookとOpStackIsmのパターンに従うことができます。
Warp Routeをデプロイする際、設定でinterchainSecurityModuleアドレスとフックアドレスを指定できます。TypeScript SDKとCLIはIsmType.RATE_LIMITEDなどの列挙型をサポートしており、デプロイヤーはRateLimitedIsmパラメータ(例:maxCapacity、owner、recipient)をWarp Routeの設定に直接記述できます。Rate Limited ISMをAggregation ISM内にネストする場合、リレイヤーバージョンはagents-v2.2.0以上である必要があります。
ISMをカスタマイズする場合、受信者コントラクトはverify関数とmoduleType関数を含むInterchainSecurityModuleインターフェースを実装する必要があります。verifyはコアの検証ロジックであり、falseを返すかリバートするとメッセージの配信が阻止されます。moduleTypeはリレイヤーにどのメタデータ形式を添付すべきかを通知します。ISMの設定が誤っている場合(例:バリデーター数が少なすぎる、閾値が低い、すべてのソースチェーンをカバーしていないなど)、クロスチェーンセキュリティの強度が低下する可能性があります。
Aggregation ISMでサブモジュールを組み合わせる場合、m-of-nの閾値と各サブISMのデプロイアドレスを明確に定義する必要があります。Rate Limited ISMのmaxCapacityは86,400以上かつ86,400の倍数である必要があります。所有者はsetRefillRateを介して補充レートを調整できます。Pausable ISMの一時停止権限は所有者に集中しており、所有者キーの管理が不適切だと、悪意のあるルート停止やイベントへのタイムリーな対応の失敗につながる可能性があります。
Warp Routeをカスタマイズする場合、各ルートのISM構成は独立していることに注意してください。ユーザーは使用前にオンチェーンのコントラクトアドレスとISMタイプを確認する必要があります。担保チェーンと合成チェーンのトークンマッピングは1:1を維持する必要があります。Rebalancerが管理対象サービスの場合、運用上の依存関係があります。偽のWarp Routeコントラクトは資産の損失につながる可能性があるため、ユーザーはExplorerや既知のデプロイアドレスを使用して確認する必要があります。
デフォルトのMultisig ISMのセキュリティは、HYPERステーカーとバリデーターセットによって支えられています。カスタムISMの場合、開発者はバリデーターの品質、署名閾値、スラッシング範囲を独自に評価する必要があります。
ISMは宛先チェーンでクロスチェーンメッセージを検証するHyperlaneのセキュリティモジュールです。Warp RouteはMailboxを基盤とするモジュラー型アセットルートです。デフォルトのMultisig ISMはHyperlaneのバリデーターセットを通じて経済的セキュリティを提供します。開発者はConfigure、Compose、Customizeを使用して、Multisig、Routing、Aggregation、Rate Limited、PausableなどのISMをデプロイし、ソースチェーンのフックと組み合わせて双方向のレート制限と一時停止制御を実現できます。Warp Routeのデプロイヤーはルートごとに独立したISMを指定します。ユーザーは使用前にルートのセキュリティ構成と信頼前提を理解する必要があります。
ISMはクロスチェーンメッセージ検証モジュールの総称です。デフォルトISMはMailboxコントラクトにあらかじめ構成されたMultisig ISMであり、アプリケーションがカスタムISMを指定しない場合に自動的に使用されます。アプリケーションはISpecifiesInterchainSecurityModuleインターフェースを介して独立したISMを指定することで、デフォルト構成を上書きできます。
Rate Limited ISMは、宛先チェーンのverifyフェーズで、単位時間ウィンドウ内の累積入金トークン量がmaxCapacityの上限を超えているかをチェックします。超えている場合、検証は失敗し、メッセージは配信されません。ソースチェーンのRateLimitedHookはdispatchフェーズで出金量に同じ制約を課すことができ、双方向制御を実現します。maxCapacityは86,400以上かつ86,400の倍数である必要があります。
Aggregation ISMは、設定されたn個のサブISMのうちm個が検証を通過することを要求し、メッセージを配信します。例えば、Multisig ISMとRate Limited ISMの両方を必須としたり、Pausable ISMとRate Limited ISMをネストしてレート制限と緊急一時停止を実現したりできます。サブISMは任意のデプロイ済みISMコントラクトアドレスです。
Warp Route(HWR)はオンチェーンのクロスチェーンアセットルーティングコントラクトであり、トークンのロック、ミント、バーン、リリースを担当し、独立したISMを指定できます。Nexus BridgeはWarp Route上に構築されたユーザーインターフェースであり、エンドユーザーがクロスチェーントークン操作をより簡単に行えるようにします。内部では依然としてMailboxのメッセージパッシングとISM検証の経路に従います。
バリデーターセットが小さすぎるか閾値が低いと、Multisig ISMのセキュリティが弱まります。Aggregation ISMでのサブモジュールの設定ミスにより、一部のセキュリティ条件が無効になる可能性があります。Rate Limited ISMのmaxCapacity設定が不適切だと、通常の転送を過度に制限する可能性があります。Pausable ISMの所有者キーが漏洩すると、悪意のあるルート停止が発生する可能性があります。使用前に、ユーザーはオンチェーンのISMコントラクトアドレスとパラメータを確認し、デフォルトバリデーターの経済的セキュリティとカスタムISMの信頼前提を区別する必要があります。
フックはソースチェーンMailboxのdispatch後にpostDispatchを実行し、ガス支払い、Merkleツリー書き込み、レート制限、一時停止などの送信ロジックを制御します。ISMは宛先チェーンMailboxのprocessフェーズでverifyを実行し、受信検証を制御します。RateLimitedHookとRateLimitedIsmはそれぞれソースチェーンと宛先チェーンに存在し、ペアになって双方向のスループット制御を実現します。





