レッスン4 — Wormhole と IBC（マルチチェーンメッセージプロトコル）

問い

CCIP が規制環境下の Tempo merchant 用 bridge なら、Wormhole は 2022 年に Solana DeFi が Ethereum に届くために使った bridge（速・安・19 鍵 multisig、過去ハック済）。IBC は 2019 年以降 Cosmos chain が使い続けている（遅・安全・Cosmos 内）。CCIP が真ん中、両端を画す 2 つを並べると何が見えるか？

原理（最小モデル）

• Wormhole = 19 guardian + 13-of-19 multisig. Solana / Ethereum / Sui / Aptos / Bitcoin（wrapping）含む 30+ chain サポート。唯一の trust 仮定 = 13-of-19。
• 2022 ハック $325M は鍵盗難ではなく署名検証バグ. Solana program のチェック漏れ。Multisig は鍵 + 検証ロジックの 2 経路で破られる。
• IBC = 各 chain が相手の light client を動かす. Relayer（permissionless）が header + state proof 提出 → destination の light client で検証 → 純粋暗号、multisig 介在せず。
• IBC が Cosmos 外で支配しない理由. chain Y で chain X の light client を動かすには Y が X のコンセンサスルールを検証可能必要 → Cosmos = Tendermint 共通で同コード使い回し、Ethereum で Tendermint 検証実装は高価。
• Polymer が IBC↔Ethereum を rollup ハブで橋渡し中.
• Trust スペクトラム再訪. Wormhole = Multisig / CCIP = PoS / OP Standard = Optimistic + Rollup / IBC = Light client / 将来 = ZK light client。

具体例

Wormhole アーキテクチャ:

• 19 個の Guardian ノード、それぞれが validator 運用
• Guardian が source-chain イベント観測
• 各 guardian が attestation 署名: 「chain Y で event X 観測」
• 13-of-19 署名でメッセージ valid
• Destination chain が署名集約検証

2022 ハック事例:

• 攻撃者が Wormhole-bridged ETH を $325M 持ち去り
• 根本原因 = 署名検証バグ（鍵盗難ではない）
• Solana program のチェック漏れ
• 攻撃者は妥当に見える署名を偽造 = 19 guardian がいてもコントラクトにバグあれば無意味

IBC フロー:

flowchart LR
    A["Cosmos Hub<br/>(source)"] -->|1. Packet 送信| AClient["IBC client<br/>on source"]
    AClient -->|2. Commit + sign| Relayer["IBC Relayer<br/>(off-chain)"]
    Relayer -->|3. Headers + proof 中継| BClient["IBC client<br/>on destination"]
    BClient -->|4. Header に対し検証| B["Osmosis<br/>(destination)"]

IBC の特徴:

• 各 chain が相手の light client 動作
• relayer 誰でも（permissionless）
• relayer = source header + state 変更の proof 提出
• proof 検証 = destination chain が暗号的にクロスチェーンアクション実行
• multisig 介在せず

なぜ IBC が Cosmos 外で支配しないか:

• chain Y で chain X の light client → Y が X のコンセンサスルールを検証可能必要
• Cosmos chain は全部 Tendermint → 同 light client コードがそのまま動く
• Ethereum で Tendermint 検証 = 高価 Solidity contract
• Solana で同等 = Anchor program
• クロスエコシステム IBC は理論可能だが実装コスト高で実用例乏しい

Wormhole + IBC + CCIP の使い分け:

Trust スペクトラム再訪:

失敗例（誤解）

「Wormhole は 19 guardian = 分散化されている」— 間違い。f = ⌊(19-1)/3⌋ = 6 Byzantine 耐性だが、実際の故障モードは Byzantine 共謀ではなく運用侵害（鍵盗難）か検証バグ。Guardian を増やしてもコントラクトバグは救えない。

「IBC は Ethereum サポートを追加すれば支配的 bridge」— 間違い。Tendermint 検証を Solidity で実装するコストが高い + 各 chain 用 light client が必要 → chain 追加コストが超線形。bridge トリレンマで「trustless + general」を選ぶと extensibility を諦める = IBC が Cosmos に閉じる理由。

「CCIP が trustless」— 間違い（再掲）。multisig + 第二防衛層。Wormhole（13/19）と CCIP（DON + RMN）は同じ multisig 系列で trust スペクトラム上は近い。IBC は完全別系列（light client = 暗号）。

🛑 予測。 Wormhole は 30+ chain、IBC は Cosmos chain のみ。なぜ IBC は Ethereum サポート追加して支配的にできないか？（答え: ① chain ごと light client 実装コスト高 = Cosmos 全部 Tendermint で同コード使い回しできるが、Ethereum で Tendermint 検証実装は高価 Solidity + Solana で Anchor program 必要、② bridge トリレンマ（trustless + general + extensible 同時不可）で IBC は「trustless + general」を選ぶ → extensibility を諦める = 各ペア light client 実装でしか動かない、③ エコシステム拡張のインセンティブが弱い = Cosmos 内では IBC が必須だが、Ethereum / Solana 側は既存 bridge（CCIP / Wormhole）で十分。Polymer が rollup ハブで橋渡し中だが本番化に時間 + IBC の優位性（trustless）が他の Solana / Ethereum 向け bridge ユーザに刺さりにくい。）

ステップで組み立てる

Step 1: Wormhole と IBC の対比

Wormhole = multisig（19 guardian、13 必要）、30+ chain サポート / IBC = light client、Cosmos 内のみ。両極。

Step 2: 2022 ハックの教訓

Multisig は鍵 + 検証ロジックの 2 経路で破られる。Guardian を増やしてもバグは救えない。

Step 3: IBC が Cosmos に閉じる構造的理由

各 chain で相手の light client → Cosmos は Tendermint 共通で動く → Ethereum / Solana は別実装で高コスト。bridge トリレンマで extensibility 諦め。

Step 4: 6 ユースケースの使い分け

Solana↔Ethereum（CCIP/Wormhole）/ Cosmos 内（IBC）/ EVM↔EVM（CCIP/LZ）/ L2↔L1 同 stack（OP Standard）/ BTC↔EVM（Wormhole）/ 任意 chain（Wormhole）。

Step 5: Trust スペクトラム上の位置

Wormhole（Multisig）< CCIP（PoS）< OP Standard（Optimistic + Rollup）< IBC（Light client）< 将来 ZK light client。

Step 6: Polymer = IBC↔Ethereum 橋渡しの試み

Rollup ハブで Cosmos の IBC を Ethereum エコシステムに接続。本番化中、Tempo 用途では時期尚早。

答え合わせ

• Wormhole 19 guardian の本当のセキュリティ: 理論的 f = 6（19 guardian で 6 Byzantine 許容）だが、実故障モード = 共謀ではなく ① 運用侵害（鍵盗難で 9/5 取得など）、② 検証バグ（コントラクトが署名を実際に検証していない）。Guardian 数は 2 経路（鍵 + コード）どちらの攻撃も救わない。multisig の根本的脆さ。
• IBC が Cosmos に閉じる理由: ① 各 chain ペアで相手の light client 実装必要 → Cosmos 内 Tendermint 共通でコスト 0、Ethereum / Solana で別実装 → 高コスト、② bridge トリレンマで trustless + general を選ぶと extensibility 諦め、③ Cosmos 外のユーザは既存 bridge で十分（CCIP / Wormhole の集客力）→ IBC 拡張のインセンティブ弱。Polymer が rollup ハブで橋渡し中だが本番化に時間。
• 3 プロトコルが「競合ではなく相補的」な理由: 異なる trust 許容度 + 異なるエコシステム。Wormhole = Solana / Bitcoin 向け（multisig 許容ユーザ + 速度優先）、CCIP = 機関投資家 / 規制対象（PoS + RMN + 規制統合）、IBC = Cosmos 内（trustless 必須 + 同コンセンサス前提）。棲み分けが trust スペクトラム + エコシステム 2 軸で決まる。

合格基準

• Wormhole 19/13 multisig と 2022 ハック教訓を即答できる。
• IBC が各 chain で相手 light client を動かす仕組みを言える。
• IBC が Cosmos 外で支配しない理由を構造的に説明できる。
• 6 ユースケースの最適 bridge を判断できる。
• Trust スペクトラム上の 5 プロトコル位置を順に言える。

まとめ（3行）

• Wormhole = 19/13 multisig（30+ chain、最広範、最 trust 仮定弱）/ IBC = 各 chain 相互 light client（Cosmos 内 trustless）= trust スペクトラム両極。
• 2022 Wormhole ハック教訓 = Multisig は鍵 + 検証ロジックの 2 経路で破られる、Guardian 数は救えない、Light client にはこの攻撃面なし。
• 3 プロトコル（Wormhole / CCIP / IBC）は競合ではなく相補的、棲み分けは trust スペクトラム + エコシステム 2 軸で決まる、Polymer が IBC↔EVM 橋渡し中。