--- title: "クロスチェーン・リレイヤーの可用性リスク" description: "クロスチェーン・リレイヤーの可用性リスクとは、認証済みのクロスチェーン・メッセージが期限内に配送または実行されないリスクであり、原因分析では送信元のファイナリティ、証明の可用性、配送、宛先での実行、資産会計を分ける必要があります。" image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # クロスチェーン・リレイヤーの可用性リスク > 教育目的の参考情報であり、投資助言ではありません。クロスチェーンの遅延により資産が滞留し、手数料が消費されることがあり、証明、期限、コントラクトまたは復旧に関する前提が崩れれば恒久的な損失につながる可能性があります。 ## 直接の答え クロスチェーン・リレイヤーの可用性リスクとは、有効で認証済みのメッセージが期限内に宛先へ提出されない、または宛先で実行されないリスクです。リレイヤーは通常、メッセージと証明またはメタデータを運びますが、送信元イベントをファイナライズしたり、ペイロードを認可したりする主体ではありません。送信元のコンセンサス、証明またはアテステーションの生成、宛先での検証、受信コントラクトの実行は別々の依存関係です。 配送遅延は当初、可用性の問題であり、資産が盗まれた証拠ではありません。ただし、商品規則によっては資金調達コスト、期限逸失、チケットの失効、流動性の利用不能、恒久的損失につながります。反対に、送信元のレシートとフロントエンドの `Pending` 表示だけでは、リレイヤーが原因とは断定できません。送信元が未確定、証明が未生成、宛先が一時停止中、ガス資金が不足、または受信コントラクトがリバートしている可能性があります。 パーミッションレスな配送が可能かどうかはプロトコルごとに異なります。Hyperlane と Wormhole には第三者が認証済みメッセージを配送できる経路がありますが、実行者、宛先呼出者、復旧関数を制限するデプロイもあります。提出が公開されていても、リレイヤーが認証済みペイロードを変更できるわけではありません。また、リレイヤーの許可リストは宛先での検証やリプレイ保護の代わりにはなりません。 ## 仕組み 有用なライフサイクル分析では、`source submitted`、`source finalized`、`proof pending`、`ready`、`destination submitted`、`failed/retryable`、`executed`、`expired/cancelled` を区別します。これらは分析用のラベルであり、各プロトコルのオンチェーン・フィールドは異なります。OP Stack の出金、CCTP のバーン・アンド・ミント・メッセージ、Wormhole VAA、Hyperlane メッセージでは、証明、時間、手数料、再試行の規則が異なります。 まず、送信元の操作が価値をロック、バーン、またはディスパッチしたか、その操作が必要なファイナリティに達したかを確認します。次に、想定するルート、バリデータ署名、Guardian VAA、またはアテステーションが利用可能で最新かを確認します。その後で初めて、リレイヤーがメッセージを検知し、手数料方針を受け入れ、正しいメタデータを構築し、正確な宛先コントラクトへ提出したかを調べます。 宛先での実行には独立した障害要因があります。チェーンやシーケンサーの停止、古い RPC、コントラクトの一時停止、受信コントラクトのバージョン違い、ガス不足、順序付き nonce の詰まり、期限切れ、アプリケーションのリバートなどです。トランザクション・ハッシュは提出時の参照情報にすぎません。完了の確認には、成功したレシート、プロトコルの処理済み状態、受信側のイベントまたは状態変更、正しいトークンの識別、および必要な宛先ファイナリティ後の想定残高効果が必要です。 手動リレーは万能の救済手段ではありません。デプロイ済みプロトコルに利用可能な入口があり、元のメッセージと正確な証明を取得でき、呼出者に権限があり、メッセージが未消費かつ期限内で、宛先のガスと送付価値を負担できる場合に限り可能です。公式の宛先呼出しを事前にシミュレーションしてください。原因不明の最初のメッセージを直すために、新たな送信元ロックやバーンを作成してはいけません。 再試行とリプレイは異なります。文書化された再試行は、宛先での効果が失敗した後に同じ正規メッセージを再提出するものです。正しい消費済み状態または nonce 状態は、成功する効果を最大一回に制限します。リプレイ保護によって安全性が保たれていても、複数のリレイヤーが競合すればガスを浪費します。ローカル・タスクの取消しでは、すでにブロードキャストまたは取り込まれた宛先トランザクションを取り消せません。 次の手順を使用します。 1. プロトコル、レーン、デプロイ済みバージョン、送信元と宛先のドメインおよびコントラクト、送信元トランザクションとログ、メッセージ ID または nonce、資産操作、生の数量、受信者、期限を固定します。 2. 送信元のレシートとイベントを確認し、そのチェーンとプロトコルが求める承認またはファイナリティ規則を適用します。画面を信頼するのではなく、ブロック識別子と再編成状態を調べます。 3. プロトコル所定の証明、VAA、アテステーション、チェックポイント、またはルートを取得し、対応する送信元状態、バージョン、署名者集合、可用性、無効化または失効状態を検証します。 4. 宛先チェーンの稼働状況、メッセンジャーと受信コントラクトのバージョン、一時停止、nonce または処理済み状態、前提メッセージ、期限、必要なネイティブ・ガス資産を確認します。 5. 配送がパーミッションレス、許可リスト方式、呼出者制限付きのいずれかを確認します。手動経路が利用可能なら、元のペイロード、証明、公式宛先呼出しを正確に再構築してシミュレーションします。 6. ガス上限、価格、為替上乗せ、手数料上限、返金、見積り期限を更新します。同じメッセージを提出または再試行し、重複提出や置換競合を管理し、宛先レシートを保存します。 7. 送信元のエスクローまたはバーン、移動中負債、宛先でのミント、アンロックまたは呼出し、プロトコル手数料とガス代、返金、最終状態を照合します。シードフレーズや秘密鍵を渡さず、文書化された窓口にのみエスカレーションします。 ## 例 - **段階別に遅延を帰属させる。** 送信元のファイナリティに `12 minutes`、証明またはアテステーション生成に `8 minutes`、リレイヤーのキューに `35 minutes`、宛先での取り込みに `5 minutes` かかります。エンドツーエンド時間は `12 + 8 + 35 + 5 = 60 minutes` です。配送の可用性に属するのは `35-minute` のキューだけであり、最初の `20 minutes` と最後の `5 minutes` の担当は別です。 - **宛先ガスの見積りが不足する。** ガス上限を `300,000` とします。`25 gwei` なら見積額は `300,000 * 25 * 10^-9 = 0.0075 ETH` です。実行時に `60 gwei` が必要なら、所要額は `0.018 ETH`、不足額は `0.018 - 0.0075 = 0.0105 ETH` です。送信元でガス代を上乗せしても、宛先実行の資金になるとは限りません。 - **重複したリレイヤーは元本ではなくガスを消費する。** 三者が同じ `100,000 USDC` メッセージを提出します。成功者は `180,000 gas * 30 gwei = 0.0054 ETH` を使い、失敗した二件はそれぞれ `70,000 gas * 30 gwei = 0.0021 ETH` を使ってリバートします。リレーの総ガス費用は `0.0054 + 0.0021 + 0.0021 = 0.0096 ETH` ですが、正しいリプレイ状態なら効果は一回の `100,000 USDC` であり、`300,000 USDC` ではありません。 - **移動中負債を追跡する。** ロック・アンド・ミント経路で `25 ETH` をロックしたものの、宛先呼出しが失敗した場合、エスクローは `+25 ETH`、ラップ資産の供給量は `+0 ETH`、移動中負債は `25 ETH` です。同じメッセージの再試行に成功すると、エスクローは `25 ETH` のまま、ラップ資産の供給量は `25 ETH` に増え、移動中負債は `0 ETH` になります。新たに送信元へ `25 ETH` を預けると、代わりに `50 ETH` のエスクローと二つの債務が生じます。 ## リスク - 送信元トランザクションが保留中またはリバート済みなのに、画面では送信済みと表示される。 - 十分なファイナリティに達する前の送信元イベントに基づいて処理する。 - 送信元の再編成によりイベントが削除または変更される。 - 証明、アテステーション、チェックポイント、署名データを取得できない。 - 古い、誤った、または無効化されたルートや署名者集合を使う。 - 許可リスト方式のリレイヤー鍵またはサービスが利用不能になる。 - パーミッションレス配送を迅速な配送の保証と誤解する。 - 呼出者制限付き入口を公開された手動経路と誤解する。 - 宛先チェーン、シーケンサー、RPC、インデクサーが停止または古い状態になる。 - 宛先メッセンジャーまたは受信コントラクトが一時停止する。 - 受信コントラクトの更新またはアドレス不一致で呼出しがリバートする。 - 宛先のガス上限が低すぎる。 - ガス見積り、為替レート、手数料上限、返金前提が古くなる。 - ウォレットに正しい宛先ネイティブ・ガス資産がない。 - メッセージ、チケット、証明、実行の期限が切れる。 - 順序付き nonce の欠番が後続メッセージを止める。 - 再試行または消費済み状態のロジックが重複を許すか、復旧を妨げる。 - 重複提出、取消し、置換の競合でガスを浪費する。 - 偽のサポート経路が悪意あるコントラクト、証明、calldata を提示する。 - 送信元のロックまたはバーン、移動中請求権、宛先効果、手数料、返金の照合を誤る。 ## よくある誤解 - **リレイヤーがメッセージを認証する。** 配送は証拠を運ぶ役割であり、送信元、送信者、ペイロード、リプレイに関する規則は宛先の検証器とアプリケーションが執行します。 - **リレイヤーの停止は、資産がすでに失われたか自動返金されることを意味する。** 最初の結果は遅延です。期限、復旧、支払能力、返金の結果は商品ごとに異なります。 - **パーミッションレス・リレーなら誰でもペイロードを変更でき、即時実行も保証される。** 認証は改変を防ぎますが、証明、ガス、チェーン、受信側の可用性が実行時期を左右します。 - **再試行は必ず二重ミントを起こす。** 正しい再試行は一つのメッセージを再利用し、成功効果を一回だけ許します。新しい送信元送付は別の債務を作ります。 - **宛先トランザクション・ハッシュや画面の完了表示が受領を証明する。** レシートの成功、処理済み状態、受信側イベント、残高、トークン識別、必要なファイナリティを確認します。 ## 関連トピック - [クロスチェーン・ブリッジ](/ja/crypto/cross-chain-bridge/) - [クロスチェーン・メッセージのリプレイ保護](/ja/crypto/bridge-message-replay-protection/) - [カノニカル・ブリッジ](/ja/crypto/canonical-bridge/) ## 出典 - [Relayer](https://docs.hyperlane.xyz/docs/protocol/agents/relayer) - Hyperlane Documentation（参照日：2026-08-13） - [Mailbox](https://docs.hyperlane.xyz/docs/protocol/core/mailbox) - Hyperlane Documentation（参照日：2026-08-13） - [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs（参照日：2026-08-13） - [Executor Framework](https://docs.wormhole.com/protocol/infrastructure/relayers/executor-framework/) - Wormhole Docs（参照日：2026-08-13） - [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification（参照日：2026-08-13） - [Cross Domain Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification（参照日：2026-08-13） - [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers（参照日：2026-08-13） - [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org（参照日：2026-08-13） Source: https://wiki.fcontext.com/ja/crypto/bridge-relayer-liveness-risk/index.mdx