Hyperlane 跨鏈訊息是如何運作的？從發送到送達的完整流程

Hyperlane 跨鏈訊息傳遞 (General Message Passing, GMP) 是一套可在所有支援的鏈之間重複執行的標準化流程：應用程式呼叫源鏈 Mailbox 的 dispatch 函式以傳送訊息，鏈下 relayer 將訊息與驗證元資料提交至目標鏈，經 Interchain Security Module (ISM) 驗證通過後，Mailbox 呼叫接收方合約的 handle 函式完成 delivery。Hyperlane (HYPER) 透過 Mailbox、ISM 及 Warp Route 這三大元件，說明 Hyperlane 互操作層的整體架構。

在多鏈應用中，開發者必須掌握訊息從發出到交付的完整流程，才能正確設定安全模組、估算費用並排解未交付的訊息。ISM 與 Warp Route 詳述 Multisig、Aggregation 等 ISM 類型與 Warp Route 的職責劃分，有助於在 process 階段選擇合適的驗證強度。

每筆跨鏈訊息都擁有全域唯一的 messageId，Mailbox 會維護已交付訊息的映射關係，藉此防止重放攻擊。Hyperlane vs LayerZero vs Wormhole 比較了三種協定在訊息驗證路徑與部署權限上的結構差異。訊息發送方在源鏈透過 Interchain Gas Payment (IGP) 預付目標鏈的 delivery 費用，relayer 則在目標鏈支付 gas 完成 process 呼叫；Explorer 可追蹤訊息從 dispatch 到 process 的完整鏈路狀態。

Hyperlane 跨鏈訊息傳遞包含哪些階段？

Hyperlane 的跨鏈訊息流程可分為 6 個連續階段：dispatch（源鏈發送）、Merkle 樹寫入、validator 簽名（若 ISM 需要）、relayer 索引與元資料收集、process（目標鏈提交）、ISM 驗證與 handle（目標鏈交付）。此流程不依附於特定應用或一次性事件，任何整合 Mailbox 的合約都能重複觸發。

上表呈現 Hyperlane GMP 從源鏈到目標鏈的完整階段劃分。dispatch 與 delivery 分別在兩條鏈的 Mailbox 合約上完成，relayer 與 validator 負責鏈下傳輸及安全 attestation，而 ISM 則在目標鏈扮演訊息驗證閘道。

圖 1. Hyperlane 跨鏈訊息流程總覽：從源鏈 dispatch 經 relayer/validator 到目標鏈 ISM 驗證與 handle delivery 的完整路徑。

源鏈 dispatch 階段如何發送訊息？

源鏈 dispatch 階段由發送方合約呼叫 Mailbox.dispatch() 觸發。Mailbox 接收 3 個核心參數：目標鏈 domain ID (destinationDomain)、接收方地址（recipientAddress，以 bytes32 編碼）與訊息本體 (messageBody)。Mailbox 會在訊息本體前方附加標準訊息頭，內容包含 version、nonce、origin、sender、destination、recipient 等欄位，確保訊息可唯一識別且無法篡改。

dispatch 執行後，Mailbox 將完整訊息作為 leaf 插入增量 Merkle 樹（由 MerkleTreeHook 合約維護），並觸發 Dispatch 與 DispatchId 事件。messageId 是訊息（含頭部）的 keccak256 雜湊值，由 dispatch 呼叫回傳，可在 Explorer 中追蹤。nonce 是源鏈 Mailbox 的單調遞增計數器，即使訊息本體相同，nonce 不同也會產生不同的 messageId。

發送方可以透過 quoteDispatch() 查詢跨鏈費用，這些費用涵蓋源鏈 dispatch 成本與目標鏈 delivery 的 interchain gas 預付。Post-Dispatch Hook 可在 dispatch 後透過 InterchainGasPaymaster (IGP) 向 relayer 預付目標鏈的 gas。dispatch 完成後，訊息便進入待 relay 狀態。messageId 由完整訊息的雜湊值生成，目標鏈 Mailbox 透過 delivered(messageId) 映射防止重複交付。

Relayer 與 Validator 如何協作傳遞訊息？

Relayer 與 Validator 在 Hyperlane 協定中各自承擔不同但互補的職責。Validator 負責安全 attestation：當源鏈 Mailbox dispatch 新訊息時，MerkleTreeHook 會觸發 InsertedIntoTree 事件，Validator 讀取當前的 Merkle root 並對 checkpoint 簽名，再將簽名發布至公開儲存空間（例如 AWS S3 或 Google Cloud Storage）。Relayer 負責傳輸層：監聽源鏈 Mailbox 的事件，收集 ISM 所需的 metadata（如 validator 簽名、Merkle proof），然後在目標鏈呼叫 Mailbox.process() 提交訊息。

Validator 只在 Multisig ISM 或 Economic Security Module 的情境下才屬必要；若接收方採用 Optimistic ISM、零知識證明 ISM 或其他不需 validator 簽名的模組，則 relayer 只需收集該 ISM 所要求的 metadata。Hyperlane 不強制規定 enshrined validator set，接收方可自行設定 Multisig ISM 中的 validator 地址與簽名門檻。

Relayer 內部包含 Indexer 與 Submitter：Indexer 透過 RPC 查詢源鏈事件並寫入本地資料庫；Submitter 則確認 gas 已預付、取得 metadata、模擬並廣播 process 呼叫。delivery 失敗時，relayer 會按指數退避策略自動重試。Validator 簽名對外公開，任何人都可攜帶簽名呼叫 process；訊息發送方透過 IGP 選擇預付對象，relayer 營運者需將收入再平衡至目標鏈帳戶。

目標鏈 delivery 階段如何完成交付？

目標鏈 delivery 階段由 relayer 呼叫 Mailbox.process(metadata, message) 觸發。Mailbox 首先檢查 messageId 是否已交付，若已存在於 delivered 映射中則拒絕重放。接著 Mailbox 查詢接收方合約指定的 ISM（透過 recipientIsm() 或應用自訂設定），並將 message 與 metadata 傳遞給 ISM.verify() 函式。

ISM 驗證通過後，Mailbox 呼叫接收方合約的 handle(origin, sender, body) 函式，將訊息本體與來源資訊傳遞給應用層邏輯。接收方合約必須實作 IMessageRecipient 介面的 handle 函式，並在函式內執行跨鏈治理投票、資產鑄造/釋放、狀態更新等業務操作。delivery 成功後，Mailbox 將 messageId 標記為已交付，並觸發 Process 與 ProcessId 事件。

對於 Warp Route 這類資產跨鏈應用，handle 函式內會觸發鎖定、鑄造、銷毀或釋放代幣的邏輯；而對於跨鏈治理應用，handle 函式內則記錄投票權重或執行提案。delivery 階段的 gas 由 relayer 在目標鏈支付，發送方已在源鏈透過 IGP 預付相關費用。

圖 2. 目標鏈 delivery 序列：Mailbox process 觸發 ISM verify，驗證通過後呼叫 recipient handle，並透過 messageId 映射防止重放。

目標鏈 ISM 如何驗證跨鏈訊息？

ISM (Interchain Security Module) 是目標鏈上負責驗證跨鏈訊息真實性的智慧合約。Mailbox 在 delivery 之前，會將 message 與 relayer 提交的 metadata 傳遞給 ISM.verify()；驗證邏輯因 ISM 類型而異。預設 ISM 為 Multisig ISM，要求設定數量的 validator 對源鏈 Merkle root 的簽名達到門檻；應用也可部署自訂 ISM 或使用 Aggregation ISM 組合多種驗證路徑。

驗證 ISM 設定時，可查詢接收方合約的 ISM 地址、檢查 validator 門檻與 ISM 類型參數，並在 Explorer 中確認特定訊息的驗證狀態與 metadata。

在 Multisig ISM 下，relayer 從 validator 的公開儲存空間取得 checkpoint 簽名，連同 Merkle proof 一併提交。Economic Security Module 則透過 EigenLayer AVS 提供經濟安全保障，validator 若發生欺詐行為可能觸發 slashing。驗證通過後 ISM 回傳 true，Mailbox 才會執行 handle；驗證失敗則 process 交易會 revert，relayer 將按退避策略重試。

跨鏈訊息傳遞有哪些風險與限制？

Hyperlane 跨鏈訊息傳遞存在機制層面的結構性風險，需從訊息層、傳輸層與經濟層分別探討。訊息層風險包括：自訂 ISM 設定不當可能削弱驗證強度；接收方 handle 函式的邏輯漏洞可能導致錯誤的狀態更新。傳輸層風險包括：relayer 延遲或停止 relay 可能使訊息長時間未交付（IGP 已預付但 relayer 未提交）；目標鏈 gas 價格波動可能影響 relayer 的提交意願；validator 停機在 Multisig ISM 門檻較高時可能阻礙 liveness。

經濟層風險則包括 validator 欺詐可能觸發 HYPER slashing，IGP 費率設定錯誤可能導致 delivery 費用不足。訊息 delivery 並非即時，需要等待源鏈 finality 與 relayer 提交，可靠性取決於 IGP 預付與 relayer 的營運品質。

操作前應核對鏈上 Mailbox、ISM 與接收方合約地址，區分協定預設設定與應用自訂設定。Warp Route 等資產跨鏈場景還需額外注意路由合約與代幣映射關係。

總結

Hyperlane 跨鏈訊息遵循 dispatch → attestation → relay → verify → deliver 的可重複流程。源鏈 Mailbox.dispatch() 編碼訊息並寫入 Merkle 樹；validator 對 checkpoint 簽名（在 Multisig ISM 情境下）；relayer 收集 metadata 並在目標鏈呼叫 process；ISM 驗證通過後，Mailbox 呼叫 handle 完成 delivery。messageId 全域唯一，已交付訊息不可重放。IGP 預付目標鏈 gas，Explorer 提供全鏈路追蹤。

FAQ

Hyperlane 跨鏈訊息的基本流程是什麼？

源鏈發送方呼叫 Mailbox.dispatch() 發送訊息，Mailbox 寫入 Merkle 樹並觸發事件。Relayer 監聽事件、收集 ISM 所需的 metadata，在目標鏈呼叫 Mailbox.process()。ISM 驗證通過後，Mailbox 呼叫接收方 handle 函式完成 delivery。

dispatch 與 delivery 分別在哪條鏈發生？

dispatch 發生在源鏈 (Origin Chain) 的 Mailbox 合約上，由發送方合約觸發。delivery 則發生在目標鏈 (Destination Chain) 的 Mailbox 合約上，由 relayer 呼叫 process 觸發，最終透過 ISM 驗證後呼叫接收方 handle。

Relayer 與 Validator 有什麼區別？

Validator 對源鏈 Merkle root checkpoint 簽名，為 Multisig ISM 等安全模組提供 attestation。Relayer 負責鏈下傳輸層，索引源鏈事件、收集 metadata 並在目標鏈提交 process 呼叫。兩者職能互補，relayer 在所有訊息 delivery 中皆屬必要，validator 則僅在特定 ISM 類型下才需要。

如何追蹤跨鏈訊息狀態？

每條訊息擁有唯一的 messageId（dispatch 時回傳的 keccak256 雜湊值）。Hyperlane Explorer 可查詢訊息從 dispatch 到 process 的完整鏈路狀態，包括源鏈發送時間、relayer 提交記錄、ISM 驗證結果與目標鏈 delivery 確認。

訊息未交付可能是什麼原因？

常見原因包括：IGP 預付費用不足、relayer 尚未提交或仍在 retry 中、validator 簽名未達 Multisig 門檻、目標鏈 gas 費用過高導致 relayer 延遲提交、ISM 驗證失敗。可透過 Explorer 查看特定訊息的 pending 原因與 retry 記錄。

跨鏈訊息會被重複交付嗎？

不會。Mailbox 維護 delivered(messageId) 映射，已交付的 messageId 在目標鏈 process 時將被拒絕，從而防止重放攻擊。nonce 欄位也確保即使訊息本體相同，不同的 dispatch 仍會產生不同的 messageId。