クロスチェーンブリッジ

なぜ資産は「移動」できないのか

まず誤解を解くところから始めます。あるトークンをチェーンAからチェーンBへ「移す」とき、コインそのものが動くわけではありません。各ブロックチェーンは独立した台帳で、互いの状態を直接は知りません。チェーンBのノードは、チェーンA上で何が起きたかを自力では検証できないのです。両者は別々の合意アルゴリズムで動く閉じた世界であり、A上の残高をB上でそのまま使う手段は原理的に存在しません。

そこでクロスチェーンブリッジは、資産の物理的移動ではなく価値の移転を模倣します。送出側で原資産を動かせない状態に固定し、受入側でそれと1対1で裏付けられた代替表現（ラップトークン）を発行する。ブリッジの設計問題は突き詰めると一点に集約されます——「送出側で起きた事実を、受入側がどうやって信頼できる形で知るか」。このメッセージ検証の方式こそがブリッジのセキュリティを決め、後述する外部・楽観的・zkの分類もここから生まれます。

ロック＆ミント と バーン＆リリース

資産の保存則（勝手に増減しない）を守るための基本パターンが2つあります。

ロック＆ミント（Lock & Mint） は、原資産がまだ存在しない先へ移すときに使います。送出側でトークンをブリッジのコントラクトにロック（預託）し、受入側でそれを裏付けとするラップトークンを新規ミントします。戻すときは逆に、受入側でラップトークンをバーン（焼却）し、送出側でロックを解いて原資産をリリースします。ラップトークンの発行量が、常に送出側でロックされた量と一致することが健全性の条件です。

バーン＆リリース（Burn & Release） は、両側にすでに正規資産があり、供給が共有されている場合に使います。送出側でトークンをバーンし、その事実を根拠に受入側で同量を**リリース（またはミント）**します。ネイティブ発行トークンが複数チェーンに正規展開しているケースがこれにあたります。

[ロック＆ミント：A→B]
  A側: user → BridgeContract に 100 TOKEN をロック（残高凍結）
        └─ Lock イベント発火
  検証機構が「Aで100ロックされた」ことを B へ伝達・保証
  B側: BridgeContract が wTOKEN を 100 ミント → user へ
  （不変条件: B上の wTOKEN総供給 == A上でロック中の TOKEN量）

[戻す：B→A]
  B側: user が wTOKEN 100 をバーン
  検証機構が「Bで100バーンされた」ことを A へ伝達・保証
  A側: ロックを解除し TOKEN 100 を user へリリース

検証方式の3分類 — 誰が「送出側の事実」を保証するか

パターン（ロック／ミント）は資金の帳尻の話にすぎません。真の設計軸は受入側がどうやって送出側のイベントを信頼するかです。ここで信頼の置き所が変わり、セキュリティ特性が根本から変わります。

外部検証（External Verification）

最も普及した方式で、ブリッジが独自に選んだ検証者の集合が送出側のイベントを監視し、「確かに100ロックされた」という署名を出します。受入側コントラクトは、その署名が既定の閾値（例 M-of-N）を満たすかだけを見てミントを許可します。

実装はBFTコンセンサスの耐障害モデルと同型で、悪意ノードが閾値未満なら安全、という前提に立ちます。署名の集約には、単一鍵に集約しないマルチシグや、鍵を分割したまま署名を協調生成する**しきい値署名（MPC/TSS）**が使われます（署名・ウォレット・鍵管理 で扱う M-of-N やTSSがそのまま応用されます）。

楽観的検証（Optimistic Verification）

送出側イベントの主張をいったん正しいと仮定して受理予約し、一定の異議期間を設けます。期間内に「その主張は不正だ」と証拠つきで異議（fraud proof）を出せる監視者が誰もいなければ確定します。信頼の前提は「正直な監視者が最低1人いる」ことに薄まり、外部委員会への信頼より小さくできます。代償は確定までの待機時間で、資産の引き出しに遅延が生じます。レイヤー2とロールアップ のOptimistic Rollupと同じ「疑わしきは事後に罰する」思想で、L2からL1への出金経路も本質的にはこの型のブリッジです。

暗号学的検証（Native / zk Verification）

理想形は、受入側が送出側チェーンの合意そのものを検証することです。受入側に軽量なライトクライアント（送出側のブロックヘッダとファイナリティを追う最小限の検証器）を実装し、「そのブロックは送出側で確定済みで、その中にロック取引が含まれる」ことを検証します。取引の包含はマークル証明、ブロックの正当性は署名やファイナリティ証明で確かめます。

問題は、他チェーンのヘッダ検証や署名検証をオンチェーンで毎回行うとガス代が膨大になること。そこでzk証明を使い、「送出側のヘッダ列は正当で、この取引を含む」という事実を簡潔な妥当性証明に圧縮します。受入側は小さな証明を検証するだけで済み、しかも信頼の前提はゼロ知識証明（SNARK・STARK） が保証する暗号の健全性と送出側の合意の安全性のみ——外部委員会を一切要しません。これがブリッジの信頼最小化における到達点です。

ブリッジのセキュリティと過去の攻撃

ブリッジは構造的に最悪の攻撃対象です。理由は3つ重なります。第一に、多数チェーンの資産が一箇所にロックされるため、破れば得られる報酬が桁外れに大きい。第二に、多くのブリッジが外部委員会に信頼を置き、チェーン本体より弱い環を新設してしまう。第三に、2チェーン分のコントラクトとリレーとブリッジ暗号を正しく実装せねばならず、攻撃面が広くバグが混入しやすい。

歴史的な大型事案の型を一般化すると、ほぼこの表に収まります。検証者鍵の奪取では、外部委員会のうち閾値に達する秘密鍵が（多くはオフチェーンの運用・端末侵害を通じて）奪われ、攻撃者が正規に見える署名で不正な引き出しを承認しました——コントラクトは規則どおり動いており、破られたのはチェーン外の鍵です。署名検証の欠陥では、受入側の検証コードが空・偽の証明を有効と誤認し、裏付けのないミントを許しました。ミント権限の奪取では、ロックを経ずにラップトークンを直接増発され、裏付け比率が崩れて流出しました。

対策の方向は検証方式の選択と直結します。外部検証なら委員会の分散度と鍵管理（TSS化、ハードウェア隔離、閾値の引き上げ）を厚くし、権限にタイムロックや上限を課す。楽観的検証なら監視者の活性（誰かが必ず異議を出せる状態）を制度的に保証する。そして根本策は、可能な限り信頼主体を増やさない zk ／ネイティブ検証へ寄せ、ブリッジの安全性を両チェーンの安全性に一致させることです。

まとめ

• 資産はチェーンをまたいで移動できない。クロスチェーンブリッジは送出側で原資産を**ロック（またはバーン）し、受入側で等価のラップトークンをミント（またはリリース）**して価値移転を模倣する。健全性の条件は「受入側の総供給が送出側のロック量と一致する」こと。
• 設計の核心はパターンではなく検証方式——受入側が送出側の事実をどう信頼するか。外部検証（委員会の閾値署名／TSS）、楽観的検証（異議期間で事後に覆す）、暗号学的検証（ライトクライアント＋zk証明）に大別される。
• 外部検証は最も普及するが、チェーン本体とは別の少数委員会に安全性を委ね、新たな信頼境界を増やす。zk／ネイティブ検証は信頼主体を追加せず、ブリッジの安全性を両チェーンの安全性に一致させる到達点。
• ブリッジは巨額資産をロックする単一の的で、検証者鍵の奪取・署名検証の欠陥・ミント権限の奪取が過去の大規模流出の主因。事故の多くはコントラクト外（鍵運用・権限管理）で起き、リスク評価では「信頼をどこに置くか」を必ず問うべきである。