クロスチェーンブリッジ脆弱性とリスク管理|Kelp DAO $292Mハック事件で考えるブリッジセキュリティ

コラム

2026/04/22

コラム

2026/04/22

クロスチェーンブリッジ脆弱性とリスク管理|Kelp DAO $292Mハック事件で考えるブリッジセキュリティ

2026年4月18日に発生したKelp DAO $292Mハック事件は、LayerZeroブリッジ層の検証脆弱性を悪用してリステーキングトークン rsETHが不正発行され、AaveやDeFi全体のTVLが$6B超流出する波及を生んだ。クロスチェーンブリッジの構造的脆弱性と、マルチチェーン時代のセキュリティ設計を専門家視点で解説する。

1. Kelp DAO事件の概要

2026年4月18日深夜(公開発表は4月19日)、流動性リステーキングプロトコルKelp DAOが攻撃を受け、約2億9,200万ドル(約430億円)相当の資産が危機にさらされた。攻撃者はLayerZeroのクロスチェーンメッセージを偽造し、約116,500 rsETH(流通供給の約18%)を不正にミントした。

Kelp DAOはイーサリアムのリステーキング(EigenLayer)エコシステムにおける主要プロトコルの一つであり、rsETH(リステーキングトークン)は複数のDeFiプロトコルにまたがって広く利用されていた。今回の攻撃の連鎖的影響は深刻だった。

  • 攻撃者は不正にミントしたrsETHのうち約89,567 rsETHをAaveに偽担保として預け、ETH等を約$190M借り入れ
  • Aaveの想定不良債権は$124M〜$230M規模
  • 事件発覚後、DeFi全体のTVLが約$6B以上引き出される連鎖パニックに発展

本インシデントは、クロスチェーンブリッジが抱える構造的な脆弱性を改めて浮き彫りにした。単一プロトコルの欠陥が、互いに連結された複数のDeFiプロトコルにドミノ倒しのように波及するリスクは、マルチチェーン時代の現在においても依然として深刻な課題であり続けている。

2. LayerZeroメッセージング層の脆弱性

LayerZeroの基本的な仕組み(V1 → V2)

LayerZeroは、異なるブロックチェーン間でメッセージを送受信するための汎用メッセージングプロトコルだ。「オムニチェーン」インフラストラクチャとして、Ethereum、BNB Chain、Avalanche、Polygon、Arbitrumなど160を超えるブロックチェーンを接続している。

LayerZero V1のアーキテクチャは、エンドポイント(Endpoint)、Oracle、Relayerの3コンポーネントで構成されていたが、現行のV2では設計が刷新され、DVN(Decentralized Verifier Network)+ Executorという、より柔軟で分散性の高いモデルに移行している。アプリケーション開発者は複数のDVNを組み合わせて検証ポリシーをカスタマイズできる。

今回悪用された脆弱性 — 1-of-1検証者問題

Kelp DAOの事件では、Kelp側のLayerZero設定が1-of-1署名者構成(単一のDVNのみで検証)になっていたことが直接的な引き金となった。これにより攻撃者は単一の偽装メッセージで、本来は正規ユーザーのみが実行できるはずのrsETHのミント操作を不正に呼び出すことができた。

注目すべきは、事後にKelp DAOとLayerZeroの間で責任の所在をめぐる公的な議論が発生していることだ。Kelpは「LayerZeroのデフォルト設定が原因」と主張し、LayerZeroは「Kelpが推奨設定(複数DVN構成)を選択しなかった」と反論している。これは「ブリッジ層と上位アプリケーションの責任分界点」という業界共通の課題を示す。

メッセージング層脆弱性のインパクト

LayerZeroのような汎用メッセージングプロトコルの構成ミスや脆弱性は、それを利用するすべてのアプリケーションに波及する可能性を持つ。LayerZeroを基盤として構築されたdAppは世界中に数百以上存在しており、今回のKelp DAO事件はその一例に過ぎない。メッセージング層という基盤的インフラの設定不備は、個々のスマートコントラクトの脆弱性よりも広範な影響を持ち得る点で、特に危険度が高い。

3. クロスチェーンブリッジが狙われる構造的理由

資金集中という構造的問題

クロスチェーンブリッジが攻撃者にとって魅力的なターゲットである最大の理由は、「大量の資金が一箇所に集中する」という構造的特性にある。攻撃者の観点から見れば、ブリッジコントラクトは「巨大な金庫」であり、その金庫を開けるための鍵(脆弱性)を見つけることができれば、一度の攻撃で数百億円規模の利益を得ることができる。

過去のブリッジ攻撃事例を振り返ると、この傾向は明白だ。

事件 時期 被害額 主な原因
Ronin Bridge2022年3月約$625M9バリデータ中5つの秘密鍵漏洩
Wormhole2022年2月約$326M署名検証の脆弱性
Nomad2022年8月約$190M初期化バグの集団的悪用
Kelp DAO2026年4月約$292MLayerZero 1-of-1検証者構成

スマートコントラクトの複雑性

クロスチェーンブリッジのスマートコントラクトは、単一チェーン上のDeFiプロトコルと比較して著しく複雑だ。複数のチェーンにまたがるロジック、異なるコンセンサスメカニズムへの適応、非同期処理の管理など、考慮すべき要素が桁違いに多い。コードの複雑性が高まるほど、バグや脆弱性が潜在する可能性も高まる。

マルチシグ・オラクル・バリデータへの依存

クロスチェーン通信の信頼性を担保するために、多くのブリッジは外部の検証者やオラクルに依存している。これらの外部コンポーネントは、それ自体が新たな攻撃対象面を生む。バリデータの秘密鍵が漏洩した場合、あるいはバリデータ集合の過半数が攻撃者によって制御された場合、ブリッジ全体のセキュリティが崩壊する。Ronin Bridge攻撃(2022年)はその典型例だ。

経済的インセンティブのアンバランス

セキュリティ研究者がブリッジの脆弱性を発見し、バグバウンティを通じて報告した場合、受け取れる報奨金は通常数万〜数百万ドル程度だ。一方、同じ脆弱性を悪用した場合、数億ドル規模の不正利益を得られる可能性がある。この極端な経済的インセンティブの非対称性が、悪意ある行為者を引き寄せ続ける根本的な原因の一つとなっている。

4. 連鎖パニック — rsETH価格崩壊とAaveの緊急対応

rsETH価格の急落

攻撃が発覚した2026年4月18-19日、rsETHの市場価格は急落した。不正にミントされた大量のrsETHがDEX上で売却されたことに加え、インシデント発覚に伴うパニック売りが重なり、rsETHはETHとのペッグを大きく失った。

Aaveの緊急ガバナンス対応

Aaveは世界最大級のDeFi貸付プロトコルであり、rsETHを担保として受け入れていた。事件発覚直後、Aaveガバナンスは以下の緊急措置を実行した。

  • V3デプロイ全てでrsETH/wrsETHの預入リザーブを凍結
  • rsETHのLTV(担保比率)を0に設定
  • Core/Prime/Arbitrum/Base/Mantle/LineaのWETHリザーブも一時凍結
  • WETHの金利モデルを調整し、追加引き出しを抑制

これらの緊急対応により、想定不良債権を$124M〜$230Mに抑え込んだが、DeFi全体のTVLは$6B超が引き出される事態となった。

コンタージョン(伝染)リスクの顕現

今回のインシデントが示す最も重要な教訓の一つは、DeFiエコシステムにおけるコンポーザビリティ(組み合わせ可能性)がリスクの伝播路にもなり得るという点だ。DeFiのコンポーザビリティは「マネーレゴ」とも呼ばれ、革新的な金融サービスを実現できる点が魅力だが、一つのプロトコルが機能不全に陥ったとき、依存していたすべてのプロトコルが連鎖的に影響を受けるリスクは、コンポーザビリティの必然的な裏面でもある。

5. ブリッジセキュリティの現状と業界標準

セキュリティ監査の現状と限界

DeFiプロトコルのセキュリティ監査は業界標準として定着しつつあり、CertiK、Trail of Bits、OpenZeppelin、Peckshieldなど複数の著名な監査会社が存在する。しかし、監査が実施されていることが安全性を保証するわけではない。アップグレード後の差分が監査されていない、監査範囲が限定的、依存先プロトコルの設定検証が不十分など、複数の盲点が存在する。複数の独立した監査機関による監査(マルチ監査)、継続的な監査契約(Continuous Audit)、形式的検証の活用が求められている。

バグバウンティプログラムの役割

Immunefi、Cantina、HackerOneなどのプラットフォームを通じたバグバウンティは、ホワイトハットによるリスク発見を促進する重要な仕組みだ。Uniswapはv4で総額$15.5Mのバグバウンティプログラム(最大$1M/件、Cantina上で運営)を設定。AaveもImmunefi上で最大$1Mのバウンティを提供している。ただし、ロックされた資産規模に対するバウンティの相対比率は依然として小さく、改善の余地がある。

保険プロトコルとリスクヘッジ

Nexus Mutual、InsurAce、Risk HarborなどDeFiリスクに特化した保険プロトコルが台頭している。ユーザーはこれらを通じて、スマートコントラクトのリスクや特定プロトコルのリスクに対して保険を購入できる。ただし、供給量は需要に対して常に十分とは言えず、大規模インシデント時には保険プロトコル自体のソルベンシーが問われる場合もある。

業界全体の取り組み — セキュリティ標準の策定

Ethereum Foundationや主要プロトコルの開発チームが連携し、クロスチェーンブリッジのセキュリティ標準策定に向けた動きが進んでいる。ERC-5164(Cross-Chain Execution Standard)はメッセージング層の標準化を通じてセキュリティの底上げを図ることを目的としており、PoolTogetherでリファレンス実装が動いている。CosmosエコシステムではIBC(Inter-Blockchain Communication Protocol)がプロトコルレベルでの標準化を進めており、115以上のチェーンで稼働している。

6. 開発者・利用者が取るべき対策

開発者向け — セキュアなブリッジ設計の原則

(1)最小権限の原則とタイムロック: ブリッジコントラクトの管理者権限を複数の独立したマルチシグで管理し、重大変更には48時間〜7日間のタイムロックを設ける。

(2)検証モデルの多様化と冗長化: LayerZero V2のDVNを使う場合、複数のDVNを組み合わせ「N-of-M」の閾値を超えた場合のみ取引を承認する。Kelp DAOの教訓は、デフォルト設定を盲信せず、自プロトコルのリスク特性に合わせた検証ポリシーを設計することの重要性だ。

(3)引き出し制限(Rate Limiting): 一定時間内に引き出せる資産額に上限を設けるレートリミッティング、大量資産が短時間で動いた場合の自動一時停止(Circuit Breaker)を実装する。

(4)形式的検証とファジング: Certora Prover、Hevm、Echidnaなどのツールを組み合わせ、手動監査では発見できない脆弱性を特定する。

(5)依存関係の継続的なモニタリング: 自プロトコルが依存する外部プロトコル(今回はLayerZero)のセキュリティ状況を継続的に監視し、依存先で異変が起きた場合に自動的に一時停止する機能を実装する。

利用者向け — リスク管理の実践

分散化の徹底担保としての利用リスクの認識(rsETHのようなデリバティブトークンを担保にする際は十分なバッファを確保)、インシデント発生時の情報収集体制(DeFiLlama、Rekt.news、各プロトコルの公式X/Discordをフォロー)が基本だ。

7. マルチチェーン時代のセキュリティ設計思想

ゼロトラストの原則をクロスチェーンへ

Kelp DAO事件が改めて示したのは、クロスチェーンブリッジにおいては「信頼できるものは何もない」というゼロトラストの原則を徹底することの重要性だ。LayerZeroのような汎用メッセージングプロトコルを利用する場合も、そのプロトコルの安全性を盲目的に信頼するのではなく、アプリケーション層で追加的な検証ロジック・複数DVN構成・タイムロックなどを実装する必要がある。

zkBridgeなど次世代ブリッジ

zkBridge(ゼロ知識証明を用いたブリッジ)は、チェーン間のメッセージ検証を数学的に保証する可能性を持ち、外部の信頼できる第三者(オラクルやリレイヤー)への依存を最小化できる点で注目される。Polyhedra Networkなどが既に本番実装を出しているが、新技術自体も新たな脆弱性を持つ可能性があることを忘れてはならない。

筆者の見解としては、Kelp DAO事件は「ブリッジ自体の技術的脆弱性」というより「アプリケーション側の設定ミス(1-of-1検証者)」が引き金になっており、この点が重要だ。クロスチェーン時代のセキュリティは、プロトコル単体の堅牢性に加えて、「どの設定を選ぶか・誰がレビューするか」という運用面の判断品質が決定的に重要になる。XTELAでもクロスチェーン対応のスマートコントラクト実装支援において、依存先プロトコルの設定レビューを必須プロセスに組み込むことを推奨している。

まとめ

Kelp DAO事件は、クロスチェーンブリッジのセキュリティが「単一プロトコルの問題」ではなく、「プロトコル間の依存関係と設定品質の問題」であることを改めて突きつけた。LayerZero V2のDVNやzkBridgeなど次世代技術が登場する一方で、利用するアプリケーション側が適切な検証ポリシーを選択しなければ、技術の進化はセキュリティに直結しない。マルチチェーン時代のセキュリティは、技術と運用、両輪での成熟が問われている。

本記事はXTELA JAPAN株式会社が作成しました。クロスチェーン対応スマートコントラクトの実装やセキュリティ監査に関するご相談は、無料技術相談はこちらからお問い合わせください。

どんなフェーズからでも、お持ちのアイデアや企画をもとにご提案可能です。
まずはお気軽にご相談下さい!