Hyperlaneのクロスチェーンメッセージングの仕組み：送信から配信までの完全なプロセス

Hyperlaneクロスチェーンメッセージパッシング（General Message Passing、GMP）は、対応する任意のチェーン間で繰り返し実行可能な標準化プロセスです。アプリケーションが送信元チェーンのMailboxのdispatch関数を呼び出してメッセージを送信し、オフチェーンのリレイヤーがメッセージと検証メタデータを送信先チェーンに提出、Interchain Security Module（ISM）による検証後、Mailboxが受信側コントラクトのhandle関数を呼び出して配信を完了します。Hyperlane (HYPER)は、Mailbox、ISM、Warp Routeという3つのコンポーネントを通じてHyperlane相互運用性レイヤーの全体的なフレームワークを解説しています。

マルチチェーンアプリケーションでは、デベロッパーがメッセージのディスパッチから配信までの完全な経路を理解することが不可欠です。これにより、セキュリティモジュールの適切な設定、手数料の見積もり、未配信メッセージのトラブルシューティングが可能になります。ISM and Warp Routeでは、ISMのタイプ（MultisigやAggregationなど）とWarp Routeの役割分担を解説し、プロセスフェーズ中の適切な検証強度の選択を支援します。

各クロスチェーンメッセージにはグローバルに一意のmessageIdが割り当てられ、Mailboxは配信済みメッセージのマッピングを保持することでリプレイ攻撃を防止します。Hyperlane vs LayerZero vs Wormholeでは、3つのプロトコル間のメッセージ検証経路とデプロイ許可における構造的な違いを比較しています。メッセージ送信者は、Interchain Gas Payment（IGP）を介して送信元チェーンで送信先チェーンの配信手数料を前払いし、リレイヤーが送信先チェーンでガス代を支払ってプロセス呼び出しを完了します。Explorerでは、メッセージのディスパッチからプロセスまでの全ライフサイクルを追跡できます。

Hyperlaneクロスチェーンメッセージパッシングのステージとは

Hyperlaneのクロスチェーンメッセージフローは、次の6つの連続ステージに集約できます。ディスパッチ（送信元チェーンでの送信）、Merkleツリーへの書き込み、バリデーター署名（ISMで必要な場合）、リレイヤーのインデックス作成とメタデータ収集、プロセス（送信先チェーンへの提出）、ISM検証とhandle（送信先チェーンでの配信）です。このフローは特定のアプリケーションや1回限りのイベントに依存せず、Mailboxと統合された任意のコントラクトが繰り返しトリガーできます。

上表は、Hyperlane GMPの送信元チェーンから送信先チェーンまでの完全なステージ構成を示しています。ディスパッチと配信は各チェーンのMailboxコントラクトで発生します。リレイヤーとバリデーターはオフチェーンの送信とセキュリティアテステーション機能を担い、ISMは送信先チェーンでメッセージ検証のゲートウェイとして機能します。

図1. Hyperlaneクロスチェーンメッセージフローの概要：送信元チェーンのディスパッチからリレイヤー/バリデーターを経由し、送信先チェーンのISM検証とhandle配信までの完全な経路。

送信元チェーンのディスパッチフェーズでのメッセージ送信方法

送信元チェーンのディスパッチフェーズは、送信者コントラクトがMailbox.dispatch()を呼び出すことで開始されます。Mailboxは3つのコアパラメーター（送信先チェーンのドメインID destinationDomain、受信者アドレス recipientAddress（bytes32としてエンコード）、メッセージ本文 messageBody）を受け取ります。Mailboxは本文の前に標準メッセージヘッダーを付加します。このヘッダーにはversion、nonce、origin、sender、destination、recipientなどのフィールドが含まれ、メッセージの一意な識別と改ざん防止を保証します。

ディスパッチ実行後、Mailboxは完全なメッセージをリーフとして増分Merkleツリー（MerkleTreeHookコントラクトが管理）に挿入し、DispatchおよびDispatchIdイベントを発行します。messageIdはメッセージ（ヘッダーを含む）のkeccak256ハッシュであり、ディスパッチ呼び出しによって返され、Explorerで追跡可能です。nonceは送信元チェーンのMailbox上の単調増加カウンターで、メッセージ本文が同一でも異なるnonceは異なるmessageIdを生成します。

送信者はquoteDispatch()を介してクロスチェーン手数料を照会できます。この手数料には、送信元チェーンでのディスパッチコストと、送信先チェーンでの配信用に前払いするインター�チェーンガスが含まれます。ディスパッチ後のフック（Post-Dispatch Hook）は、InterchainGasPaymaster（IGP）を通じてリレイヤーに送信先チェーンのガスを前払いできます。ディスパッチが完了すると、メッセージは保留リレー状態になります。messageIdは完全なメッセージのハッシュから生成され、送信先チェーンのMailboxはdelivered(messageId)マッピングで重複配信を防止します。

リレイヤーとバリデーターの連携によるメッセージ配信

リレイヤーとバリデーターは、Hyperlaneプロトコルにおいて異なるが補完的な機能を果たします。バリデーターはセキュリティアテステーションを担当します。送信元チェーンのMailboxが新しいメッセージをディスパッチすると、MerkleTreeHookがInsertedIntoTreeイベントを発行します。バリデーターは現在のMerkleルートを読み取り、チェックポイントに署名し、署名を公開ストレージ（AWS S3やGoogle Cloud Storageなど）に公開します。リレイヤーはトランスポート層を担当し、送信元チェーンのMailboxからのイベントをリッスンし、ISMが必要とするメタデータ（バリデーター署名やMerkleプルーフなど）を収集して、送信先チェーンでMailbox.process()を呼び出します。

バリデーターが必要となるのは、Multisig ISMやEconomic Security Moduleのシナリオのみです。受信者がOptimistic ISMやゼロ知識証明ISMなど、バリデーター署名を必要としないモジュールを設定する場合、リレイヤーはそのISMが必要とするメタデータだけを収集すればよいです。Hyperlaneは固定のバリデーターセットを義務付けておらず、受信者はMultisig ISM内でバリデーターアドレスと署名しきい値を自身で設定できます。

リレイヤーは内部にIndexerとSubmitterを持ちます。IndexerはRPC経由で送信元チェーンのイベントを照会し、ローカルデータベースに書き込みます。Submitterはガスが前払いされていることを確認し、メタデータを取得し、シミュレーションを実行してプロセス呼び出しをブロードキャストします。配信が失敗した場合、リレイヤーは指数バックオフ戦略で自動再試行します。バリデーターの署名は公開されており、誰でも署名を運んでprocessを呼び出せます。メッセージ送信者はIGPを介して前払い受信者を選択し、リレイヤーオペレーターは収益を送信先チェーンアカウントにリバランスする必要があります。

送信先チェーンの配信フェーズでの配信完了

送信先チェーンの配信フェーズは、リレイヤーがMailbox.process(metadata, message)を呼び出すことで開始されます。Mailboxはまず、messageIdが既に配信済みかを確認します。deliveredマッピングに存在する場合はリプレイを拒否します。次にMailboxは、受信者コントラクトが指定するISM（recipientIsm()またはカスタムアプリケーション設定経由）を照会し、messageとmetadataをISM.verify()関数に渡します。

ISM検証が成功すると、Mailboxは受信者コントラクトのhandle(origin, sender, body)関数を呼び出し、メッセージ本文と送信元情報をアプリケーション層ロジックに引き渡します。受信者コントラクトはIMessageRecipientインターフェースのhandle関数を実装する必要があり、この関数がクロスチェーンガバナンス投票や資産のミント/リリース、状態更新などのビジネス操作を実行します。配信が成功すると、MailboxはmessageIdを配信済みとしてマークし、ProcessおよびProcessIdイベントを発行します。

Warp Routeのような資産クロスチェーンアプリケーションでは、handle関数がトークンのロック、ミント、バーン、またはリリースのロジックをトリガーします。クロスチェーンガバナンスアプリケーションでは、handle関数が投票ウェイトを記録したり提案を実行したりします。配信フェーズのガスはリレイヤーが送信先チェーンで支払い、送信者はIGP経由で送信元チェーンにて対応する手数料を前払い済みです。

図2. 送信先チェーン配信シーケンス：MailboxプロセスがISM検証をトリガー。検証後に受信側handleが呼び出され、messageIdマッピングによってリプレイが防止されます。

送信先チェーンのISMによるクロスチェーンメッセージ検証

ISM（Interchain Security Module）は送信先チェーン上のスマートコントラクトで、クロスチェーンメッセージの信頼性を検証します。配信前に、Mailboxはリレイヤーが提出したmessageとmetadataをISM.verify()に渡します。検証ロジックはISMのタイプによって異なります。デフォルトのISMはMultisig ISMで、設定された数のバリデーターが送信元チェーンのMerkleルートに署名してしきい値に達する必要があります。アプリケーションはカスタムISMをデプロイしたり、Aggregation ISMを使用して複数の検証経路を組み合わせることもできます。

ISM設定を確認するには、受信者コントラクトのISMアドレスを照会し、バリデーターのしきい値やISMタイプのパラメーターを確認し、Explorerで特定のメッセージの検証ステータスとメタデータを確認します。

Multisig ISMでは、リレイヤーはバリデーター公開ストレージからチェックポイント署名を取得し、Merkleプルーフとともに提出します。Economic Security ModuleはEigenLayer AVSを通じて経済的セキュリティを提供し、バリデーターの不正行為はスラッシングの対象となります。検証が成功するとISMはtrueを返し、Mailboxがhandleを実行します。検証が失敗するとプロセストランザクションはリバートされ、リレイヤーはバックオフ戦略に従って再試行します。

クロスチェーンメッセージパッシングのリスクと制限

Hyperlaneクロスチェーンメッセージパッシングには、メカニズムレベルでの構造的リスクが伴い、メッセージ層、トランスポート層、経済層の観点から理解する必要があります。メッセージ層のリスク：カスタムISMの不適切な設定により検証強度が低下する可能性、受信者のhandle関数ロジックの脆弱性により誤った状態更新が発生する可能性。トランスポート層のリスク：リレイヤーの遅延や停止によりメッセージが長時間未配信となる可能性（IGPは前払い済みだがリレイヤーが未提出）、送信先チェーンのガス価格変動がリレイヤーの提出意欲に影響する可能性、Multisig ISMで高いしきい値のバリデーターがダウンすると活性が損なわれる可能性。

経済層のリスク：バリデーターの不正行為によるHYPERのスラッシング、IGP手数料設定の誤りによる配信手数料不足。メッセージ配信は即時ではなく、送信元チェーンのファイナリティとリレイヤーの提出を待つ必要があります。信頼性はIGPの前払いとリレイヤーの運用品質に依存します。

運用前には、Mailbox、ISM、受信者コントラクトのオンチェーンアドレスを確認し、プロトコルのデフォルト設定とアプリケーションカスタム設定を区別してください。Warp Routeアセットクロスチェーンのようなシナリオでは、ルーティングコントラクトとトークンマッピング関係にも注意が必要です。

まとめ

Hyperlaneクロスチェーンメッセージは、ディスパッチ→アテステーション→リレー→検証→配信という繰り返し可能なフローに従います。送信元チェーンのMailbox.dispatch()がメッセージをエンコードしてMerkleツリーに書き込み、バリデーター（Multisig ISMシナリオ）がチェックポイントに署名、リレイヤーがメタデータを収集して送信先チェーンでprocessを呼び出し、ISM検証後にMailboxがhandleを呼び出して配信を完了します。messageIdはグローバルに一意で、配信済みメッセージのリプレイは不可能です。IGPが送信先チェーンのガスを前払いし、Explorerで全ライフサイクルを追跡できます。

よくある質問

Hyperlaneクロスチェーンメッセージの基本フローを教えてください。

送信元チェーンの送信者がMailbox.dispatch()を呼び出してメッセージを送信します。MailboxがMerkleツリーに書き込み、イベントを発行します。リレイヤーがイベントをリッスンし、ISMが必要とするメタデータを収集して、送信先チェーンでMailbox.process()を呼び出します。ISM検証後、Mailboxが受信者のhandle関数を呼び出して配信を完了します。

ディスパッチと配信はどのチェーンで発生しますか？

ディスパッチは送信元チェーンのMailboxコントラクトで、送信者コントラクトによってトリガーされます。配信は送信先チェーンのMailboxコントラクトで、リレイヤーがprocessを呼び出すことでトリガーされ、ISM検証後に受信者のhandleが呼び出されます。

リレイヤーとバリデーターの違いは何ですか？

バリデーターは送信元チェーンのMerkleルートチェックポイントに署名し、Multisig ISMなどのセキュリティモジュールにアテステーションを提供します。リレイヤーはオフチェーンのトランスポート層を担当し、送信元チェーンのイベントをインデックスし、メタデータを収集して、送信先チェーンでprocess呼び出しを提出します。両者の機能は補完的で、リレイヤーはすべてのメッセージ配信に必須ですが、バリデーターは特定のISMタイプでのみ必要です。

クロスチェーンメッセージのステータスを追跡する方法は？

各メッセージには一意のmessageId（ディスパッチ時に返されるkeccak256ハッシュ）があります。Hyperlane Explorerを使用すると、ディスパッチからプロセスまでの全ライフサイクルステータス（送信元チェーンの送信時間、リレイヤーの提出記録、ISM検証結果、送信先チェーンの配信確認）を照会できます。

メッセージが配信されない原因は何ですか？

主な原因として、IGPの前払い手数料不足、リレイヤーの未提出または再試行中、バリデーター署名がMultisigしきい値に未達、送信先チェーンのガス手数料高騰によるリレイヤー遅延、ISM検証失敗などがあります。Explorerで特定のメッセージの保留理由と再試行記録を確認してください。

クロスチェーンメッセージは2回配信されますか？

いいえ。Mailboxがdelivered(messageId)マッピングを維持しており、一度配信されたmessageIdは送信先チェーンのプロセスで拒否され、リプレイ攻撃が防止されます。また、nonceフィールドにより、メッセージ本文が同じでも異なるディスパッチが異なるmessageIdを生成することが保証されます。