ISMとWarp Routeとは何でしょうか?Hyperlaneのセキュリティモジュールをカスタマイズするには、どうすればよいですか?

最終更新 2026-07-03 01:46:42
読了時間: 5m
Interchain Security Module(ISM)と Hyperlane Warp Route(HWR)は、Hyperlane の相互運用性プロトコルにおいて、それぞれ独立して設定可能な主要モジュールです。ISMはクロスチェーンメッセージが確かに送信元チェーンから発信されていることを宛先チェーン上で検証します。Warp RouteはMailboxベースのメッセージパッシングにより、チェーン間でトークンのロック、ミント、バーン、リリースを行います。Hyperlane(HYPER)は、Mailbox、ISM、Warp Route、そしてHYPERの経済的セキュリティという4つの側面から、その総合的なフレームワークを構築しています。

マルチチェーンアプリケーションでは、クロスチェーンブリッジは多くの場合、固定された不変のセキュリティモデルに依存しているため、開発者が価値の高いガバナンスメッセージと低価値のデータ更新に異なる検証強度を適用するのは困難です。Hyperlane (HYPER)のモジュラーアーキテクチャでは、各メッセージが独自のISMを指定でき、Warp Routeのデプロイヤーはアセットルートごとに専用のセキュリティスタックを構成できます。これにより、セキュリティモデルを特定のビジネスシナリオに適合させることが可能です。Hyperlaneのクロスチェーンメッセージフローは、ディスパッチからデリバリーまでの反復可能な経路を説明しており、プロセス段階でISMがいつ介入するかを理解するための基礎となります。

Hyperlane vs. LayerZero vs. Wormholeでは、HyperlaneのモジュラーアプローチをLayerZeroおよびWormholeと、Mailbox/ISM、Endpoint/DVN、Guardian/VAAの3つのアーキテクチャパスで比較します。これにより、相互運用性プロトコルのスペクトルの中で、カスタマイズ可能なISM検証がどの位置にあるかが明確になります。

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と受信者コントラクトの間に位置し、メッセージが最終的に実行可能かどうかを判断するセキュリティチェックポイントとして機能します。

デフォルトISMとカスタムISMのタイプ

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を積み重ねたりすることが可能です。

Hyperlane ISMセキュリティモジュール:Default Multisig、Aggregation、Rate Limited、Pausable ISM 図1. Hyperlane ISMセキュリティモジュールのタイプ:Default Multisig、Custom Multisig、Aggregation、Rate Limited、Pausableの組み合わせ関係。

Warp Routeの仕組み

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検証後、ソースチェーンはロックされた担保トークンをリリースします。

HypERC20CollateralHypERC20は、EVMチェーンにおける一般的なWarp Routeコントラクト形式です。前者は担保チェーンでERC-20をロックしてメッセージを送信し、後者は合成チェーンで検証されたメッセージを受信して1:1マッピングの合成トークンをミントします。Nexus Bridgeはユーザー向けのクロスチェーンインターフェースですが、内部では依然としてWarp RouteとISM検証の経路に従います。

Hyperlane Warp Routeのフロー:担保ロックからISM検証、合成ミント、逆方向バーンパスまで 図2. Hyperlane Warp Routeのフロー:ソースチェーンが担保をロックし、Mailboxがメッセージを送信、宛先チェーンでISMが検証して合成トークンをミント。逆方向パスではバーンとリリースが行われます。

ISMとフックの組み合わせ

フックは、ソースチェーンMailboxのdispatch後に実行される後処理ロジックモジュールです。これらは宛先チェーンのISMを補完します。フックはメッセージ送信側の動作を制御し、ISMはメッセージ受信側の検証を制御します。Mailboxのdispatch関数はメッセージを書き込んだ後、フックのpostDispatch関数を呼び出します。フックはクロスチェーンガス料金の徴収、Merkleツリーへの書き込み、レート制限の適用、一時停止チェックなどを行います。

標準的なフックタイプには、MERKLE_TREEINTERCHAIN_GAS_PAYMASTERPAUSABLERATE_LIMITEDがあります。RateLimitedHookはソースチェーンにデプロイされ、宛先チェーンのRateLimitedIsmとペアになります。dispatchフェーズでは、ソース側の出金量がウィンドウ上限を超えていないかをチェックし、双方向のスループット制御を実現します。Pausable Hookは所有者がソースチェーンでのメッセージ送信を一時停止できるようにし、Pausable ISMと組み合わせることで、両端のルートを同時にシャットダウンできます。

フックとISMは「ソースチェーンフック+宛先チェーンISM」のペアリングに従います。フックはpostDispatchで送信制約を実行し、ISMはverifyで受信検証を実行します。カスタムの組み合わせはOpStackHookOpStackIsmのパターンに従うことができます。

Warp Routeをデプロイする際、設定でinterchainSecurityModuleアドレスとフックアドレスを指定できます。TypeScript SDKとCLIはIsmType.RATE_LIMITEDなどの列挙型をサポートしており、デプロイヤーはRateLimitedIsmパラメータ(例:maxCapacityownerrecipient)をWarp Routeの設定に直接記述できます。Rate Limited ISMをAggregation ISM内にネストする場合、リレイヤーバージョンはagents-v2.2.0以上である必要があります。

ISMとWarp Routeをカスタマイズする際のリスク

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を指定します。ユーザーは使用前にルートのセキュリティ構成と信頼前提を理解する必要があります。

FAQ

ISMとデフォルトISMの違いは何ですか?

ISMはクロスチェーンメッセージ検証モジュールの総称です。デフォルトISMはMailboxコントラクトにあらかじめ構成されたMultisig ISMであり、アプリケーションがカスタムISMを指定しない場合に自動的に使用されます。アプリケーションはISpecifiesInterchainSecurityModuleインターフェースを介して独立したISMを指定することで、デフォルト構成を上書きできます。

Rate Limited ISMはどのようにクロスチェーン転送量を制限しますか?

Rate Limited ISMは、宛先チェーンのverifyフェーズで、単位時間ウィンドウ内の累積入金トークン量がmaxCapacityの上限を超えているかをチェックします。超えている場合、検証は失敗し、メッセージは配信されません。ソースチェーンのRateLimitedHookdispatchフェーズで出金量に同じ制約を課すことができ、双方向制御を実現します。maxCapacityは86,400以上かつ86,400の倍数である必要があります。

Aggregation ISMはどのように複数のセキュリティモジュールを組み合わせますか?

Aggregation ISMは、設定されたn個のサブISMのうちm個が検証を通過することを要求し、メッセージを配信します。例えば、Multisig ISMとRate Limited ISMの両方を必須としたり、Pausable ISMとRate Limited ISMをネストしてレート制限と緊急一時停止を実現したりできます。サブISMは任意のデプロイ済みISMコントラクトアドレスです。

Warp RouteとNexus Bridgeの関係は?

Warp Route(HWR)はオンチェーンのクロスチェーンアセットルーティングコントラクトであり、トークンのロック、ミント、バーン、リリースを担当し、独立したISMを指定できます。Nexus BridgeはWarp Route上に構築されたユーザーインターフェースであり、エンドユーザーがクロスチェーントークン操作をより簡単に行えるようにします。内部では依然としてMailboxのメッセージパッシングとISM検証の経路に従います。

Warp RouteのISMをカスタマイズする際の一般的なリスク

バリデーターセットが小さすぎるか閾値が低いと、Multisig ISMのセキュリティが弱まります。Aggregation ISMでのサブモジュールの設定ミスにより、一部のセキュリティ条件が無効になる可能性があります。Rate Limited ISMのmaxCapacity設定が不適切だと、通常の転送を過度に制限する可能性があります。Pausable ISMの所有者キーが漏洩すると、悪意のあるルート停止が発生する可能性があります。使用前に、ユーザーはオンチェーンのISMコントラクトアドレスとパラメータを確認し、デフォルトバリデーターの経済的セキュリティとカスタムISMの信頼前提を区別する必要があります。

フックとISMはどのチェーンで実行されますか?

フックはソースチェーンMailboxのdispatch後にpostDispatchを実行し、ガス支払い、Merkleツリー書き込み、レート制限、一時停止などの送信ロジックを制御します。ISMは宛先チェーンMailboxのprocessフェーズでverifyを実行し、受信検証を制御します。RateLimitedHookRateLimitedIsmはそれぞれソースチェーンと宛先チェーンに存在し、ペアになって双方向のスループット制御を実現します。

著者: Jayne
免責事項
* 本情報はGateが提供または保証する金融アドバイス、その他のいかなる種類の推奨を意図したものではなく、構成するものではありません。
* 本記事はGateを参照することなく複製/送信/複写することを禁じます。違反した場合は著作権法の侵害となり法的措置の対象となります。

関連記事

ONDOトークン経済モデル:プラットフォームの成長とユーザーエンゲージメントをどのように推進するのか
初級編

ONDOトークン経済モデル:プラットフォームの成長とユーザーエンゲージメントをどのように推進するのか

ONDOは、Ondo Financeエコシステムの中核を担うガバナンストークンかつ価値捕捉トークンです。主な目的は、トークンインセンティブの仕組みを活用し、従来型金融資産(RWA)とDeFiエコシステムをシームレスに統合することで、オンチェーン資産運用や収益プロダクトの大規模な成長を促進することにあります。
2026-03-27 13:52:46
Pendle対Notional:DeFi固定倍率収益プロトコルの比較分析
中級

Pendle対Notional:DeFi固定倍率収益プロトコルの比較分析

PendleとNotionalは、DeFi固定収益分野を代表する2つの主要プロトコルです。それぞれ独自の仕組みで収益を創出しています。Pendleは、PTとYTのイールド分離モデルにより、固定収益や利回り取引機能を提供します。一方、Notionalは、固定金利のレンディングマーケットプレイスを通じて、ユーザーが借入金利をロックできるようにしています。比較すると、Pendleは収益資産管理や金利取引に最適であり、Notionalは固定金利レンディングに特化しています。両者は、プロダクト構造、流動性設計、ターゲットユーザー層において独自のアプローチを持ち、DeFi固定収益市場の発展を牽引しています。
2026-04-21 07:34:07
PendleにおけるPTとYTとは何か?収益分割メカニズムを詳しく解説
中級

PendleにおけるPTとYTとは何か?収益分割メカニズムを詳しく解説

PTとYTは、Pendleプロトコルにおいて不可欠な2種類の利回りトークンです。PT(Principal Token)は利回り資産の元本を表し、通常は割引価格で取引され、満期日に額面で償還されます。YT(Yield Token)は資産の将来利回りを受け取る権利を示し、予想収益を狙って取引することができます。Pendleは利回り資産をPTとYTに分割することで、DeFi領域に利回り取引のマーケットプレイスを構築しました。これにより、ユーザーは固定利回りの確保、利回り変動への投機、および利回りリスクの管理が可能となります。
2026-04-21 07:18:16
Render、io.net、Akash:DePINハッシュレートネットワークの比較分析
初級編

Render、io.net、Akash:DePINハッシュレートネットワークの比較分析

Render、io.net、Akashは、単なる均質な市場で競争しているのではなく、DePINハッシュパワー分野における三つの異なるアプローチを体現しています。それぞれが独自の技術路線を進んでおり、GPUレンダリング、AIハッシュパワーのオーケストレーション、分散型クラウドコンピューティングという特徴があります。Renderは、高品質なGPUレンダリングタスクの提供に注力し、結果検証や強固なクリエイターエコシステムの構築を重視しています。io.netはAIモデルのトレーニングと推論に特化し、大規模なGPUオーケストレーションとコスト最適化を主な強みとしています。Akashは多用途な分散型クラウドマーケットプレイスを確立し、競争入札メカニズムにより低コストのコンピューティングリソースを提供しています。
2026-03-27 13:18:37
AI分野におけるRenderの申請理由:分散型ハッシュレートが人工知能の発展を支える仕組み
初級編

AI分野におけるRenderの申請理由:分散型ハッシュレートが人工知能の発展を支える仕組み

AIハッシュパワーに特化したプラットフォームとは異なり、RenderはGPUネットワーク、タスク検証システム、RENDERトークンインセンティブモデルを組み合わせている点が際立っています。この構成により、Renderは特定のAIシナリオ、特にグラフィックス計算を必要とするAIアプリケーションにおいて、優れた適応性と柔軟性を提供します。
2026-03-27 13:13:31
Plasma(XPL)トークノミクス分析:供給、分配、価値捕捉
初級編

Plasma(XPL)トークノミクス分析:供給、分配、価値捕捉

Plasma(XPL)は、ステーブルコイン決済に特化したブロックチェーンインフラです。ネイティブトークンのXPLは、ガス料金の支払い、バリデータへのインセンティブ、ガバナンスへの参加、価値の捕捉といった、ネットワーク内で重要な機能を果たします。XPLのトークノミクスは高頻度決済に最適化されており、インフレ型の分配と手数料バーンの仕組みを組み合わせることで、ネットワークの拡大と資産の希少性の間に持続的なバランスを実現しています。
2026-03-24 11:58:52