ブロックチェーン・ブリッジ

ブロックチェーン・ブリッジは「あるチェーンの資産を別のチェーンで使えるようにする」仕組みの総称である。技術的には、ソースチェーンで資産をロック（または焼却）し、デスティネーションチェーンで等価トークンを発行（またはアンロック）するプロセスを自動化する。ブリッジは Web3 のユーザー体験に不可欠であると同時に、2025 年時点で Web3 全体のエクスプロイト損失の約 40% を占めるとされる最大の攻撃面でもある。情報カットオフ ~2025-08、confidence: medium 固定（2026-06 時点での外部再検証は未実施）。

ブリッジの 3 類型

ロック&ミント型（Lock & Mint）

最も基本的な設計。ソースチェーンのカストディアン・コントラクト（またはマルチシグ）が資産をロックし、デスティネーション側でラップドトークン（例：wBTC・wETH）を発行する。

• 利点: 単純で実装しやすい。任意のトークンに対応できる。
• 欠点: カストディアン・コントラクトが「ハニーポット」になる。攻撃者がカストディアンを侵害するとロックされた全資産を奪える。Ronin Bridge ハック（$625M）・Wormhole ハック（$325M）はこの構造を悪用した事例である。

ラップドトークンはネイティブ資産と 1:1 でペッグされているが、ペッグを保証するのはブリッジのスマートコントラクトとガーディアン（またはマルチシグ）の信頼性のみであり、本質的に中央集権的な信頼仮定を持つ。

流動性ネットワーク型（Liquidity Network / Atomic Swap）

ロック&ミントの代わりに、両チェーンの流動性プールを使って資産を「スワップ」する設計。代表例は Hop Protocol・Across Protocol・Connext である。

• 設計: リクエスト・プロバイダー（LP）がデスティネーション側で即座に資金を立て替え、後でソースチェーンから補填される。ユーザーはデスティネーション側で即座に資産を受け取れる（高速）。
• 利点: ラップドトークンを生成しない（ネイティブ資産の移動）。カストディアンへの資産集中リスクを分散できる。
• 欠点: 流動性が不足すると大口の移動は困難。LP にとってリスクがある（最終性詐欺・短期的な資金ロック）。

Across Protocol は楽観的オラクル（UMA の Optimistic Oracle）を使って LP の補填を検証する設計で、効率性とセキュリティのバランスを重視している。

ネイティブ検証型（Natively Verified / Light Client）

最も信頼最小化された設計。デスティネーションチェーン上でソースチェーンのライトクライアントを動かし、Merkle 証明でロックを検証してからミントする。IBC はこの方式の代表例である。

• 利点: 中間者不要。ソースとデスティネーション両方のコンセンサスが正直であれば安全。
• 欠点: ZK 技術がない場合、Ethereum のような巨大チェーンのライトクライアントをオンチェーンで動かすコストが膨大。ZK Light Client（例：Succinct Labs の SP1 を用いた Ethereum ライトクライアント）はこのコスト問題を解決しつつある。

Bridge セキュリティ：Web3 最大の攻撃面

ブリッジは「大量の資産がロックされた単一コントラクト」という構造上、攻撃者にとって最も魅力的なターゲットである。

累計被害規模（2025 年時点の推計）: Bridge hack の累計損失は約 $2.8B に上り、これは Web3 の全エクスプロイト損失の約 40% に相当するとされる（DefiLlama・Chainalysis レポートに基づく推計。情報カットオフ ~2025-08 の時点での外部検証は未実施）。

主要ハック事例：

2022 年は特に「ブリッジの年」と呼ばれ、同年だけで $1B 超の被害が出た。

攻撃パターンの分類

スマートコントラクトバグ: コントラクトのロジック・署名検証・初期化に脆弱性があるケース（Wormhole・Nomad）。形式検証・複数監査・バグバウンティが緩和手段。

秘密鍵侵害: バリデータ・マルチシグ署名者の鍵が盗まれるケース（Ronin・Harmony）。HSM・MPC Threshold Signing・鍵分散保管が緩和手段。

オラクル操作: 価格オラクルを操作してブリッジの担保評価を歪めるケース（間接的）。TWAP・複数オラクルの採用が緩和手段。

ガバナンス攻撃: ガバナンストークンを操作してブリッジの設定を変更するケース。タイムロックと緊急停止機構が緩和手段。

セキュリティ設計のベストプラクティス

安全なブリッジ設計に向けた主要原則：

1. 信頼最小化: 可能な限りライトクライアント・ZK 証明でオンチェーン検証を行う
2. 最小権限: マルチシグの閾値を高く（例：9/13 以上）、署名者を地理・組織・鍵管理手法で多様化
3. レート・リミット: 大口移動を自動的に遅延させる緊急ブレーカー
4. プログラマブル一時停止: 異常検知時に即座に停止できるガーディアン機構
5. 正式検証（Formal Verification）: 状態遷移の数学的証明（Certora・K-framework 等）

Uniswap の Bridge Assessment（2023）は主要ブリッジをセキュリティ軸で評価し、ライトクライアント検証を最高評価とした。この評価軸の詳細は tech-244 を参照。