相互運用の信頼モデル

クロスチェーン相互運用の安全性は「どのような前提のもとで誰を信頼するか」という信頼モデルによって決定される。ブリッジやメッセージング層が「安全か危険か」という二項評価ではなく、「どの条件が破れると安全が失われるか」というモデルで理解することが、プロトコル設計者・開発者・ユーザー全員にとって不可欠だ。情報カットオフ ~2025-08、confidence: medium 固定（2026-06 時点での外部再検証は未実施）。

信頼モデルの基本軸：Trust-Minimized vs Trusted

相互運用の信頼モデルは「どこに信頼を置くか」で大きく 2 極に分かれる。

Trust-Minimized（信頼最小化）: 暗号学的な検証（ライトクライアント・ZK 証明）によってメッセージの正当性を検証する。外部の仲介者を必要とせず、「ソースとデスティネーション両チェーンのコンセンサスが誠実であれば安全」という前提だけを置く。

Trusted（外部信頼）: 外部のバリデータ・マルチシグ署名者・ガーディアン・オラクルが正しく動作することを前提とする。「信頼できる N 者のうち M 者が正直であれば安全（M-of-N）」という仮定を置く。

この 2 軸の間には実装難易度・対応チェーン数・速度・コストのトレードオフが存在し、現在のプロトコルはその中間点に位置する。

ライトクライアント検証（Natively Verified）

ライトクライアント検証は最も信頼最小化された設計である。デスティネーションチェーン上でソースチェーンのライトクライアントを実行し、ブロックヘッダーのコンセンサス状態とトランザクションの Merkle 証明によって、「このトランザクションが確実にソースチェーンに含まれている」ことをオンチェーンで検証する。

安全性前提: ソースチェーンのコンセンサスが安全（51% 攻撃を受けていない）かつデスティネーション側のライトクライアント実装が正確であること。外部仲介者への信頼不要。

IBC の実装: Cosmos IBC は各チェーンが相手チェーンの完全なバリデータセットと Merkle 証明を管理し、検証する。BFT コンセンサスの即時ファイナリティと組み合わせることで、数秒以内のクロスチェーン確認を実現している（tech-240 参照）。

課題: Ethereum のような巨大チェーンのライトクライアントをオンチェーンで実行するコストが膨大になる。Ethereum の Altair ライトクライアント仕様はオンチェーン検証には過大なガス消費を必要とし、現実的ではなかった。

ZK ライトクライアント — コスト問題の解決

ZK ライトクライアントはゼロ知識証明を使ってライトクライアント検証の計算コストを劇的に削減する。

設計原理：

1. オフチェーンで ZK 証明生成者がソースチェーンのコンセンサス状態を ZKP で証明する
2. デスティネーション側はこの ZKP を検証するだけ（数万ガスで完了）

これにより「オンチェーンでライトクライアントを走らせる」という計算コストの壁が解消される。

代表実装:

• Succinct Labs（SP1 Helios）: SP1 zkVM を使って Ethereum の Altair ライトクライアント仕様の ZKP を生成。スマートコントラクト側は ZKP の検証のみ。
• Polyhedra（zkBridge）: SNARK を用いて Ethereum ←→ BNB Chain 等の ZK ライトクライアントを実装。LayerZero DVN としても提供。
• ZKM / Murky: 汎用 ZK VM でさまざまなチェーンのライトクライアントを実装する研究・開発が進行中。

ZK ライトクライアントは Trust-Minimized アーキテクチャを広範なチェーンペアに拡張できる可能性を持つが、ZKP 生成のレイテンシ（数十秒〜数分）とコストが依然として課題である。

楽観的検証（Optimistically Verified）

**楽観的検証（Optimistic Verification）**は「メッセージが正しいと仮定して処理を進め、不正が発覚した場合のみ異議申立（Fraud Proof）で正す」設計である。L2 の Optimistic Rollup（tech-192）と同じ原理をクロスチェーン文脈に適用する。

動作:

1. リレイヤーがソースチェーンのメッセージをデスティネーションに届ける
2. チャレンジ期間（例：30 分〜数時間）の間、「異議申立者（Watcher/Guard）」が不正を監視
3. チャレンジ期間内に不正申立がなければメッセージが確定する
4. 不正が証明された場合、リレイヤーはスラッシング（罰金）を受ける

Optimism Messaging（Native Bridge）: Optimistic Rollup の L1 ↔ L2 の公式ブリッジは楽観的検証モデルを採用しており、L1→L2 は数分、L2→L1 は 7 日のチャレンジ期間を設ける。

Across Protocol の UMA オラクル統合: Across は楽観的オラクル（UMA）をソルバーの補填正当性の検証に使用し、チャレンジ窓口を 2 時間程度に設定する。より短いチャレンジ期間を ZK 証明の組み合わせで短縮する設計も検討されている。

欠点: 最終性が遅い（チャレンジ期間）。ウォッチャーが常に監視している必要がある（ライブネス前提）。

外部バリデータ検証（Externally Verified）

外部バリデータ検証は信頼済みの外部バリデータ組（オラクル・マルチシグ・PoS バリデータ）がメッセージを認証する設計だ。現在最も広く実装されているモデルである。

安全性前提: M-of-N のバリデータが正直であること（例：Wormhole の 13/19、Axelar の 2/3）。この前提が破れると（秘密鍵侵害・共謀）、任意の偽メッセージが注入可能になる。

経済的担保（Economic Security）: バリデータがトークンをステークしており、不正行為でスラッシングされる。ネットワーク全体の経済的安全性は「スラッシングによる損失 > 不正で得られる利益」の条件で成立する。ただし bridge 上にロックされた資産総額がネットワーク全体のステーク額を超えるとセキュリティが破綻し得る（過担保問題）。

Uniswap Bridge Assessment の評価軸

Uniswap DAO は 2023 年、Uniswap v3 のクロスチェーン展開先を選定するためにブリッジ・メッセージング層を評価する Bridge Assessment フレームワークを公開した。

評価軸：

Uniswap の評価結果では Wormhole・LayerZero・deBridge が総合上位となったが、Trust Minimization の観点では IBC の光クライアント方式が最高評価とされた。

実際の設計選択

プロトコルが相互運用性の信頼モデルを選ぶ際の判断軸：

現在は単一モデルに頼らず、ZK 証明で外部バリデータを強化する「ハイブリッドモデル」が主流になりつつある。LayerZero V2 DVN に ZK プロバイダーを追加するパターンがその典型例だ。