マルチシグブリッジは「複数人での確認」がすでにあるように聞こえますが、なぜそれでも頻繁に問題が起きるのですか？
マルチシグの安全性は2つのことに依存する：署名者の数の閾値が十分に高いかどうか、そしてその署名者が本当に独立しているか（異なる組織、異なる地理的位置、異なる秘密鍵の管理方法）である。署名者の数が少なく（例えばほんの数人）、かつ互いの関連性が高い場合（同じ会社内の複数のアカウントなど）、実際に耐えられる攻撃面は「マルチシグ」という言葉から表面的に想像されるよりもはるかに小さい——攻撃者はそのうちの数個の秘密鍵を手に入れるだけでよく、システム全体の暗号学的基盤を実際に破る必要はない。
近年、侵害事件を経験した後に公にバリデーターの閾値を引き上げたブリッジもあり、こうした事後の調整は「マルチシグの閾値設定が低すぎる」という問題に対する業界の継続的な是正をある程度反映しているが、同時にこのリスクが過去に確かに広く過小評価されていたことも示している。
信頼最小化ブリッジの方が安全であるなら、なぜマルチシグブリッジが依然として市場の大部分を占めているのですか？
主な理由は、暗号学的検証方式（ライトクライアント、ZK証明）がエンジニアリング実装上明らかに複雑で開発サイクルが長く、しかもすべてのチェーンの組み合わせに既製のネイティブ検証ソリューションが用意されているわけではない点にある——送信元チェーンと目的地チェーンの技術アーキテクチャが大きく異なる場合、目的地チェーン上に送信元チェーンの状態を検証できるライトクライアントや証明システムを実装すること自体が、かなりのエンジニアリング上の課題となる。対照的に、マルチシグ方式は構築が速くコストも低いため、リスクがすでに広く認識されているにもかかわらず、マルチシグブリッジが市場のTVL（総ロック価値）フローの大部分を依然として占めている。
これはまた、業界全体が現在移行の過程にあり、すでに移行を完了しているわけではないことも反映している——信頼最小化設計を採用したネイティブロールアップブリッジやCCTPのような方式は近年確かに急速に成長しているが、マルチシグ方式を本当に退場させるには、暗号学的検証方式のエンジニアリング上のハードルがさらに下がり続ける必要がある。
楽観的検証モデル（Acrossなど）はチャレンジ期間中に誰かが監視していることに依存していますが、このメカニズムは実際にどれほど信頼できるのですか？
楽観的検証モデルの信頼性は、監視者（watcher）という役割の経済的インセンティブがどれだけうまく設計されているかに依存する——理想的には、監視ネットワークには十分な数の、互いに独立した参加者が継続的に稼働しているべきで、1人の誠実な監視者が無効なメッセージを発見して異議申し立てに成功しさえすれば、そのメッセージの有効化を阻止できる。これは「1人でも誠実であれば十分」という比較的緩やかな安全性の前提であり、マルチシグ方式の「署名者の過半数が誠実でなければならない」という閾値よりも達成しやすい。
しかしこのメカニズムは、チャレンジ期間の長さの設計が妥当かどうかにも大きく依存している——期間が短すぎれば監視者が対応しきれない可能性があり、長すぎればユーザー体験を犠牲にする（資金の確定にそれだけ長く待たされる）ことになる。Acrossが累計50億ドル以上を処理し、2026年中頃時点で重大なハッキング事件が発生していないという事実は、この仕組みが実務上うまく機能していることをある程度反映しているが、これはメカニズム自体に理論上の脆弱な部分がないことを意味するわけではなく、単に現在の監視ネットワークの規模とチャレンジ期間の設計が、本物の攻撃によってその限界までまだ試されていないだけである可能性もある。
技術についてまったく理解していない場合、単に資産を安全に別のチェーンへ移動させたいだけなら、簡略化した判断方法はありますか？
比較的成熟しており、運用実績が長く、重大な事故が発生していないいくつかのルートを優先的に検討できる：公式のネイティブロールアップブリッジ（サードパーティのブリッジサービスではなく、特定のレイヤー2が公式に提供するブリッジ機能を直接使用する）、CircleのCCTP（USDCのクロスチェーン送金に適しており、メカニズムがネイティブ資産の焼却／鋳造であるためラップ資産のリスクを伴わない）、あるいは公に透明な運用実績と累計処理額を持つ有名なブリッジサービスなどだ。金額が小さい場合や迅速な着金が急務な場合は、サードパーティのアグリゲーターサービス（複数のブリッジルートの手数料と着金時間を同時に比較できる）も実用的な選択肢だが、金額が大きい送金の場合は、多少の速度や手数料を犠牲にしてでも、ネイティブ検証や暗号学的証明メカニズムがもたらす安全性を優先することを勧める。
もう一つの簡単なチェック習慣として、送金前に数分かけてそのブリッジの名前に「hack」や「exploit」を加えて検索し、過去に重大な事故が発生したことがあるか、そして事故後にアーキテクチャが公に調整されたかを確認するとよい——これは難解な技術ホワイトペーパーを読み解くよりもはるかに実用的である。
クロスチェーンブリッジは暗号資産分野で損失が最も集中している攻撃対象の一つである——2022年以降、ブリッジ関連のハッキング事件の累計損失は28億ドルを超え、同期間のDeFi総損失の約7割を占めている。しかしこれらの重大事故の原因を詳しく分析すると、基盤となるブロックチェーンの暗号技術が破られたケースはほとんどないことがわかる。本当の破綻点はほぼ常に同じ場所にある——ブリッジのアーキテクチャの中で、「送信元チェーン上でこの取引が実際に発生したこと」を確認する役割を担う部分だ。
2022年のRonin Bridge事件では6億2,500万ドル、Harmonyでは約1億ドル、Orbit Bridgeでは約8,100万ドルの損失が発生した——これらは暗号資産史上最大級のブリッジ事故の一部であり、共通点は、攻撃者が暗号技術面での突破口を得たのではなく、マルチシグ（multisig）メカニズムが設定した閾値を満たすのに十分な数の署名者の秘密鍵を入手し、「この取引は合法である」という確認メッセージを直接偽造したことにある。同じパターンは2022年2月のWormhole事件（損失約3億2,000万ドル）でも見られ、攻撃者はマルチシグ検証を偽造し、Solana上で何もないところから同等額のETHを鋳造した。
これらの事故はすべて同じ構造的問題を指し示している：マルチシグブリッジの安全性は、その小さな署名者グループが誠実かどうか、秘密鍵が適切に管理されているかどうかに完全に依存している。署名者の数が不十分であったり、地理的・組織的に十分に分散していなかったり、秘密鍵の管理に不備があったりすれば、そのブリッジの資産準備金全体が極めて高いリスクにさらされる——これは接続された2つのチェーンそれぞれの暗号技術的な安全性とはまったく関係がない。
マルチシグ方式とは対照的に、別のブリッジ設計は信頼最小化（trust-minimized）の検証ロジックを採用している：一群の署名者の証言に頼るのではなく、目的地チェーンが送信元チェーンの状態を直接暗号学的に検証する——具体的な実装としてはライトクライアント、有効性ZK証明、あるいは目的地チェーンが独自にバリデーター集合を維持し、その集合を用いて送信元チェーンのブロックヘッダーと取引証明を直接検証する方式などがある。この設計は「少数の人々が言うことを信じる」ことを「自ら数学的証明を検証する」ことに置き換えており、理論上はマルチシグ方式の中で最も脆弱な部分を取り除いている。
典型的な例としては、各チェーン独自のネイティブロールアップブリッジ、Circleのクロスチェーン転送プロトコルCCTP（送信元チェーンでネイティブUSDCを焼却し、目的地チェーンでネイティブUSDCを鋳造する方式で、ラップ資産を必要とせず流動性プールのリスクもない。2025年3月にローンチしたCCTP V2は現在13以上のチェーンとSolanaをカバーしている）、そして楽観的検証ロジックを採用したブリッジ（例えばAcrossは楽観的オラクルUMAを通じて動作し、チャレンジ期間中に誰も異議を唱えなければメッセージは有効とみなされる。累計処理額は50億ドルを超え、2026年中頃時点で重大なハッキング事件は発生していない）などが挙げられる。
注目すべきは、信頼最小化を謳う設計であっても、完全にトラストレスであることはほとんどない点だ。楽観的検証モデルを例に取ると、その安全性の前提は「チャレンジ期間中に少なくとも1人の誠実な監視者がオンラインでいて、無効なメッセージに異議を唱える意思がある」というものである——もしすべての監視者が同時にオフラインになれば、偽造されたメッセージは誰にも異議を唱えられることなく自動的に通過してしまう。ライトクライアント検証モデルを例に取ると、その安全性は最終的には送信元チェーン自体のコンセンサスメカニズムの安全性に依存している——もし送信元チェーンのコンセンサスメカニズムが大規模に攻撃されれば、ライトクライアントも攻撃を受けた後のチェーンが偽物であることを何もないところから見抜くことはできない。これはつまり、あるブリッジの安全性を評価する際には、「信頼最小化」や「分散化」といったラベルだけを見るのではなく、具体的に「この設計が実際に何を、どんな条件が成り立つことを信頼することを求めているのか」を問う必要があるということだ。
もしあなたが頻繁に異なるチェーン間で資産を移動させる必要があるなら、ブリッジを選ぶ際にいくつかの具体的な点を時間をかけて確認する価値がある：そのブリッジが資産を実際に制御するメカニズムは何か（少数の署名者によるマルチシグか、暗号学的検証か）、署名者やバリデーターの数と独立性がどの程度公開されているか、そのブリッジが過去に重大な事故を経験したことがあるか、そして事故発生後にアーキテクチャが公に調整されたか（例えば一部のブリッジは侵害事件の後、公にバリデーターの閾値を引き上げている）。大口の送金では、どのルートの手数料が最も安いか、着金が最も速いかを単純に比較するのではなく、ネイティブ検証や暗号学的証明メカニズムを採用したブリッジルートを優先的に検討すべきである——手数料や速度の差は通常数パーセントの違いにすぎないが、ブリッジのメカニズム設計における安全性の格差は、資産がすべてゼロになるかどうかの差になりうる。