2026年4月18日、KelpDAOのrsETHクロスチェーンブリッジが約2億9000万ドルの規模で侵害され、今年のDeFiセキュリティインシデントとしては最大のものとなりました。初期の分析では、仮想通貨インフラを標的とした実績のある国家支援の脅威アクターであるLazarus Groupが関与しているとされています[1]。この攻撃はスマートコントラクトの脆弱性を悪用したものではありません。その代わりに、単一の分散型検証ネットワーク(DVN)ノードの基盤となるRPCインフラが汚染され、ソースチェーンでのバーンに対応しないrsETHトークンが不正に発行されました。
この侵害自体については、LayerZero[1]とKelpDAO[2]によって詳細に報じられています。本稿は異なる角度から論じます。攻撃の再現ではなく、侵害後に何が起こったのか、単一障害点となるインフラ依存がどのように5つのチェーンにわたる数十億ドルの流動性を凍結させる連鎖反応を可能にし、その連鎖反応がどのように分散型ガバナンスフレームワークに、公衆の面前で中央集権的な緊急権限を行使させることを余儀なくさせたのかを考察します。
KelpDAOのインシデントは、「分散型」スタックの3つのレイヤーを通過する因果連鎖をたどります。単一障害点となるDVNへの依存が侵害を可能にし、プロトコルがビルディングブロックのように相互に接続できるDeFiのコンポーザビリティ(「DeFiレゴ」とも呼ばれる)は、そのブリッジ侵害をシステム全体にわたる流動性危機に変え、そして危機の規模はガバナンスフレームワークに、その中に埋め込まれた中央集権的な緊急権限を明らかにさせることを余儀なくさせました。
背景:KelpDAO侵害の概要
KelpDAOは、複数のオペレーターにわたるステーキングされたETHポジションを表す流動性リステーキングトークン(LRT)であるrsETHの発行者です。rsETHのクロスチェーン移動を可能にするため、KelpDAOはLayerZeroのメッセージングプロトコルと統合しました。このプロトコルはDVNに依存しており、DVNはクロスチェーンメッセージが宛先チェーンで実行される前に、それらが正当であることを確認する独立した検証者です。
重要な設定上の選択:KelpDAOのrsETH OAppは、LayerZero Labsが運営するDVNを唯一の検証者として、1対1のDVN設定を使用しました。これは、rsETHのクロスチェーンセキュリティ全体が単一の検証エンティティに依存することを意味しました。LayerZeroの統合ドキュメントでは、冗長性を持つマルチDVN設定を明確に推奨しており、LayerZeroはインシデント前にKelpDAOにこのベストプラクティスを伝達したと述べています[1]。KelpDAO側は、1/1設定は「LayerZeroのドキュメントに記載され、新しいOFTデプロイメントのデフォルトとして出荷された設定」であり、「L2拡張中にデフォルトが適切であることが肯定的に確認された」と主張しています[2]。
攻撃者はLayerZero Labs DVNによって使用されている2つのRPCノードを侵害し、バイナリを悪意のあるバージョンに置き換えて、他のすべてのオブザーバー、LayerZero自身の監視インフラストラクチャを含むには正常に見えながら、DVNのIPアドレスにのみ偽造されたチェーン状態データを返しました。未侵害のRPCノードに対する同時DDoS攻撃は、汚染されたノードへのフェイルオーバーを強制しました。結果として、DVNはソースチェーンで発生しなかったクロスチェーンメッセージを確認し、Ethereum側のアダプター(0x85d4...8ef3)から、ソース側でのバーンに対応しない116,500 rsETHを発行しました[1, 3]。発行トランザクションは0x1ae232...db4222です。オンチェーンの証拠は明白です。Ethereum宛先エンドポイントはノンce 308を受け入れましたが、Unichainソースエンドポイントは依然として最大アウトバウンドノンce 307を報告しています[10]。
KelpDAOは異常を検知し、46分以内にすべての関連コントラクトを一時停止しました。この介入により、さらに40,000 rsETH(約9500万ドル)を標的とした後続の試みが阻止されました[2]。しかし、その時点までに攻撃者は次の段階に進んでいました。DeFiレンディングプロトコルを通じて、盗まれたrsETHを借入資産に変換することです。
偽造トークンから借入資産へ
攻撃者は単に盗まれたrsETHを売却したわけではありません。116,500トークンは7つのブランチウォレットに分散され、アグリゲーター経由の直接スワップ、Compound V3供給ポジション、Arbitrumへの再ブリッジング[10]など、複数のチャネルを通じて収益化されました。しかし、最も影響力のあった経路はAaveを通過しました。攻撃者はEthereum CoreとArbitrumの2つのチェーンにわたるAaveレンディング市場に89,567 rsETH(約2億2100万ドル)を預け入れました。AaveのE-Mode、つまり相関資産に対してより高いLTV(借入可能額/担保価値)比率を許可する資本効率機能を使用し、攻撃者は預け入れたrsETHに対して82,620 WETHと821 wstETHを借入ました[3]。
ポジションは最大限にレバレッジされていました。攻撃者の7つのアドレスのヘルスファクターは1.01から1.03の範囲で、清算閾値をわずかに上回っているだけでした[3]。これは、AaveのrsETHに対するE-Mode LTVが93%に設定され、清算閾値が95%であったため、安全バッファーがわずか2パーセントポイントしか残っていなかったため可能でした。
両市場にわたるアドレスごとの内訳:
| 市場 | アドレス | 供給rsETH |
借入WETH |
借入wstETH |
|---|---|---|---|---|
| Ethereum Core | 0x1f4c...adef |
53,000.00 ($134.71M) | 52,440.58 ($126.13M) | |
| Ethereum Core | 0x8d11...2d49 |
400.00 ($1.02M) | 393.92 ($0.95M) | |
| Arbitrum | 0eba7...129b |
12,573.80 ($31.93M) | 12,381.93 ($29.45M) | |
| Arbitrum | 0xcbb2...55cc |
9,299.00 ($23.61M) | 4,307.87 ($10.25M) | 8.13 ($23.82K) |
| Arbitrum | 0x1b74...644c |
8,000.00 ($20.33M) | 7,877.92 ($18.95M) | |
| Arbitrum | 0bb6a...c787 |
770.00 ($1.96M) | 758.25 ($1.80M) | |
| Arbitrum | 0x8d11...2d49 |
1,024.43 ($2.60M) | 28.68 ($0.07M) | 813.11 ($2,382.32K) |
| Arbitrum | 0xe9e2...d181 |
4,500.00 ($11.44M) | 4,431.33 ($10.66M) | |
| 合計 | 89,567.22 rsETH ($227.61M) | 82,620.49 WETH ($198.25M) | 821.24 wstETH ($2.41M) |
出典:Etherscan、Arbiscan、DeBankから集計されたオンチェーンデータ(2026年4月22日16:51 UTC時点)。米ドル価格は各トランザクション時点のトークン価格を反映しています。
Web3の最高のセキュリティ監査人
ローンチ前に設計、コード、ビジネスロジックを検証
連鎖反応:ブリッジ侵害がいかに5つのチェーンにわたるWETHを凍結させたか
下の図は、完全な連鎖反応を要約しています。ステップ1と2(ブリッジ侵害とAave担保預け入れ)は、上記の「背景」セクションで説明されています。このセクションの残りの部分では、ステップ3から5を詳細に分析します。なぜWETHが凍結される必要があったのか、連鎖反応の深刻さを形作ったパラメータ、そして凍結が実際に何をもたらしたのかについてです。
なぜWETHが凍結される必要があったのか
4月19日、AaveのProtocol Guardianは、Aave V3およびV4全体でrsETHとwrsETHのすべての市場を凍結し、rsETH担保に対する新規預け入れと借入を阻止しました[8]。これが予想される最初の対応でした。
予想外の2番目のステップは4月20日に来ました。AaveはEthereum、Arbitrum、Base、Mantle、Linea全体でWETH準備金を凍結しました[3, 8]。
なぜ、侵害されたわけでも、クロスチェーンブリッジとは何の関係もない資産であるWETHを凍結する必要があったのか?それは、攻撃者がソースチェーンの対応する裏付けなしに発行されたrsETHを預け入れていたためです。Aaveのオラクルは、これらのトークンを完全な市場価値で価格設定し続け、それらを正当な担保として、正しくブリッジされたrsETHと区別がつかないように扱っていました。攻撃者はこの情報非対称性を悪用して、システムレベルでは裏付けのない負債を表す担保に対して、実際のWETHを借り入れました。これにより、レンディングプールからWETHが枯渇し、影響を受ける市場全体で利用率が100%に達しました。利用率が100%になると、既存のWETH預入者は引き出しができなくなり、清算人は清算を実行するために必要な裏付け資産を受け取ることができなくなります。プロトコルの不良債権に対する主要な防御策である清算メカニズムは、事実上麻痺していました[3]。
WETHの借入がオープンなままだった場合、他のチェーンの残りのプール流動性は同じメカニズムを通じて枯渇する可能性がありました。rsETHを預け入れ、WETHを借りて、そのまま立ち去るのです。WETHの凍結はオプションではありませんでした。それは損害を封じ込める唯一の方法でした。
連鎖反応を形作った3つのパラメータ
この連鎖反応の深刻さは偶然ではありませんでした。3つのプロトコルパラメータが、直接的な損害と結果的な凍結の範囲の両方を決定しました。
1. LTV:汚染された担保の単位あたり、どれだけの健全な資産を引き出せるか
AaveのrsETHに対するE-Mode LTVは93%でした。これは、汚染されたrsETHの1ドルあたり0.93ドルのWETHを借り入れることができることを意味します。参考までに、Spark Protocolは同時期にrsETH LTVを72%に設定し、Fluidは約75%でした[3]。Aaveのパラメータは市場で最も積極的でした。
これは見落としではなく、意図的な設計上の決定でした。2026年1月、AaveガバナンスはrsETHのE-Mode LTVを92.5%から93%に引き上げ、すでに薄かった安全バッファーを2.5%から2%にさらに圧縮しました[3]。ベース(非E-Mode)LTVは意図的にゼロ近く(0.05%)に設定され、事実上、意味のあるrsETHの借入をすべて高LTVのE-Modeパスに強制しました。
2. プールの深さ:各市場が流動性枯渇に対してどれだけ脆弱か
同じ借入額でも、ターゲットプールの深さによって影響は大きく異なります。
| チェーン | 市場 | WETH準備金(攻撃前) | 攻撃者の借入 | 直接枯渇率 |
|---|---|---|---|---|
| Ethereum | V3 Core | $5.98B | 52,834.50 WETH (~$127M) | ~2.1% |
| Arbitrum | V3 | $331M | 29,785.98 WETH (~$71M) | ~21.5% |
| Mantle | V3 | $109M | N/A | 攻撃活動なし;予防的にWETH凍結 |
| Base | V3 | $204M | N/A | 攻撃活動なし;予防的にWETH凍結 |
| Linea | V3 | $33M | N/A | 攻撃活動なし;予防的にWETH凍結 |
攻撃者はAave V3市場にのみrsETHを預け入れました。Aave V4(Ethereumのみ、2026年3月30日ローンチ)も予防的なrsETH凍結の対象となりました[8]が、この表には反映されていません。WETH準備金データはLlamaRisk[3]から;攻撃者の借入は上記の住所ごとの内訳から導出されました。
攻撃者はEthereum CoreとArbitrumに借入を集中させました。しかし、攻撃者がまったく手を付けていないチェーンに何が起こったのかが重要な観察点です。rsETHがMantle、Base、Lineaで担保として受け入れられていたため、これらのチェーン上のrsETHを担保とする既存のユーザーポジションは、ブリッジの裏付けが侵害された後、潜在的な不良債権リスクを抱えていました。Aaveが5つのチェーンすべてでWETHを予防的に凍結するという決定は、合理的な対応でした。これらの市場を開放しておくと、攻撃者がEthereumとArbitrumで既に実証したのと同じ枯渇メカニズムにさらされることになります[3, 8]。
3. クロスチェーン展開数:凍結がどこまで広がるか
rsETHは23のAave V3市場のうち11市場で担保としてリストされており、7市場が実質的なエクスポージャーを示していました[3]。攻撃者はわずか2つのチェーンで活動していました。しかし、予防的なWETH凍結は少なくとも5つのチェーンに影響を与え、攻撃者がトークンを1つも預け入れなかった市場も含まれていました。LTVはチェーンあたりどれだけ抽出されるかを支配し、プールの深さは各市場がどれだけ逼迫するかを決定します。しかし、凍結が最終的にどこまで広がるかを決定したのは、rsETHが担保として受け入れられたチェーンの数でした。
これらのパラメータは静的ではありません。侵害の9日前、4月9日に、AaveのリスクスチュワードはrsETH供給キャップを引き上げました。Ethereum Coreは480,000から530,000、Mantleは52,000から70,000になりました[3]。これは因果関係を示唆するものではありませんが(攻撃者の準備期間はおそらくこれらの変更よりも前)、定期的なパラメータ調整が将来のインシデントの爆発半径を不注意に広げる可能性があることを強調しています。
凍結の真の影響
結果:2億9000万ドルのブリッジ侵害が、5つのチェーンにわたるWETH流動性の凍結につながり、合計67億ドルを超える準備金を持つ市場に影響を与えました。
直接的な損失は、攻撃者の借入に限定されました。しかし、DeFiレンディングにおいて、凍結は単なる軽微な運用上の不便ではありません。それはユーザーの流動性をロックし、引き出しを阻止し、アクティブなポジションを混乱させ、プロトコルを不良債権から保護する清算メカニズムを損ないます。影響を受けたユーザーの大多数は、rsETH、KelpDAO、またはクロスチェーンブリッジとは一切関わったことがありませんでした。彼らはAaveのWETH預入者および借入者であり、彼らが合理的に単純なレンディング市場だと理解していたものに参加していました。
WETHはDeFiで最も基本的な流動性資産です。それを凍結することは、ほとんどの預入者が聞いたことのない製品を使用している別の金融機関が詐欺にあったために、街で最大の銀行の引き出しを停止することに相当します。
LlamaRiskのインシデントレポート[3]は、チェーンごとのショートフォール予測とともに2つの不良債権シナリオをモデル化し、利用可能な最も詳細なリスク伝播分析を提供しました。しかし、この分析でさえ、潜在的な不良債権に焦点を当てており、凍結自体の運用コスト、つまりロックされた引き出し、混乱したポジション、および影響を受けるすべての市場での清算能力の低下については触れていませんでした。全連鎖反応の影響の包括的な定量化は、未解決の問題です。
攻撃連鎖が複雑であった場合、回復も簡単ではないことが証明されています。コンポーザビリティは、ダメージを可能にするのと同じように、修理を制限します。Aaveは単に「すべてを凍結解除」することはできませんでした。各市場は、ローカルなrsETHエクスポージャー、WETH利用率、および攻撃者の活動に依存する異なるリスクプロファイルで、個別に評価する必要がありました。タイムラインがその物語を語っています:
- 4月19日: Protocol GuardianがAave V3およびV4全体で
rsETHとwrsETHの準備金をすべて凍結[8]。 - 4月20日: Ethereum、Arbitrum、Base、Mantle、Linea全体で
WETHが凍結[3, 8]。 - 4月21日: Ethereum Core V3のみで
WETHが凍結解除され、予防措置としてLTVは0のまま。Ethereum Prime、Arbitrum、Base、Mantle、LineaのWETHは凍結されたまま[8]。
侵害から4日後、影響を受けた6市場のうち5市場が凍結されたままです。回復パスは攻撃パスの複雑さを反映しています。プロトコルごと、チェーンごとに、各ステップでガバナンスの調整とリスク評価が必要になります。
対応:Arbitrumがいかに署名なしで30,766 ETHを移動させたか
Aaveがレンディング連鎖を管理している間、Arbitrumでは並行して対応が進められていました。4月21日、Arbitrum Security Councilは、Arbitrum Oneで攻撃者が保有していた30,766 ETHを凍結する緊急措置を発表しました[6]。資金は、後続のArbitrumガバナンスアクションを通じてのみアクセス可能な、中間的な凍結アドレス(0x...0DA0)に移されました[7]。
ガバナンスアクション
Arbitrum Security Councilは、外部アクターではなく、Arbitrum DAOガバナンス構造の公式コンポーネントです。緊急措置は、Arbitrumガバナンスフォーラム[7]を通じて公に発表され、攻撃者の身元に関する法執行機関からの情報提供を受けて実行され[6]、完全なトランザクション詳細で文書化されました。「Arbitrumコミュニティのセキュリティと整合性へのコミットメント」と「Arbitrumユーザーやアプリケーションへの影響なし」という原則を考慮して、Security Councilは確立された権限の範囲内で行動しました[6]。
これは裏部屋での決定ではありませんでした。これはガバナンスによって承認された緊急措置であり、透明性を持って実行され、誰でも確認できるオンチェーンの証拠があります。
技術的メカニズム
このアクションを注目に値するものにしているのは、ガバナンスの決定ではなく、オンチェーンでの実行方法です。BlockSecのPhalconトレース分析[9]に基づくと、Security Councilはアトミックな3段階アプローチを採用しました:
-
Upgrade Executorは、Ethereumインボックスコントラクト(
DelayedInbox)を一時的にアップグレードし、sendUnsignedTransactionOverrideという新しい関数を追加しました。 -
この関数は、攻撃者のアドレスを偽装したクロスチェーンメッセージを作成するために使用されました。メッセージは、
kind=3でBridge.enqueueDelayedMessageを介して注入されました。これはArbitrumのNitroスタックではL1MessageType_L2Messageにマッピングされます。このメッセージタイプは、L2でのL2MessageKind_UnsignedUserTx実行を許可します。重要なのは、このパスでは署名チェックが不要であることです。送信者パラメータは標準のmsg.senderパスから、L1→L2アドレスエイリアスを通じて変換され、攻撃者のアドレスコンテキストを運ぶ、呼び出し元制御の入力にシフトされました。 -
L2での転送が実行された後、インボックスコントラクトは元の実装に復元されました。
L1トランザクション[4]と結果のL2トランザクション[5]は、Phalcon Explorerで公開されています。L2トランザクションが「攻撃者から0x...0DA0へ」と表示しているのは、標準的なユーザー署名付き転送ではありません。これはチェーンレベルの強制状態遷移であり、所有者の秘密鍵なしで資産を移動させたトランザクションであり、ガバナンスレベルのインフラストラクチャアップグレード権限を通じて実行されました。
ジレンマ
メカニズムは原理的には単純です。アップグレード可能なコントラクトは無制限の機能を提供します。コントラクトがアップグレード可能であれば、その動作は、所有者の署名なしで資産を転送することを含む、あらゆることを行うように変更できます。この機能は、アップグレード可能なコントラクト上に構築されたどのシステムにも固有のものです。30,766 ETHは現在、凍結されたアドレスにあります。その処分を決定できるのは、後続のArbitrumガバナンス投票のみです。アトミックなアップグレード-実行-復元パターンは、インボックスコントラクトに永続的な変更を残さず、他のユーザーやアプリケーションにも影響を与えませんでした[6]。
Arbitrum Security Councilのアクションは、ほとんどの合理的な評価では、正しい判断でした。攻撃者は国家支援の活動家として特定されました。法執行機関が関与しました。ガバナンスプロセスは公開されました。そして7100万ドルの盗まれた資産が回収された、あるいは少なくともさらなるマネーロンダリングから阻止されました。
しかし、これを可能にした機能は、この特定のケースを超えています。アップグレード-実行-復元メカニズムは、原理的には、Arbitrum One上の任意のアドレスが保有するあらゆる資産を移動するために使用できます。Security Councilの権限は、攻撃者アドレスや盗まれた資金に限定されません。それはガバナンス規範によって制約される一般目的の機能であり、コードによって制約されるものではありません。
これがジレンマです。ユーザーは暗黙のメンタルモデルの下でL2と対話します。「私の資産は私の秘密鍵によって制御されており、誰も私の署名なしでそれらを移動させることはできません。」KelpDAOの対応は、このモデルが不完全であることを示しています。Arbitrum、そしてアップグレード可能なブリッジコントラクトとSecurity Councilを持つ任意のL2では、署名チェックを完全に回避するガバナンスレベルのアクションを通じて資産を移動させることができます。
Arbitrumがこの点でユニークなわけではありません。Aaveの市場凍結もガバナンス主導の緊急措置です。KelpDAOインシデント中、複数のプロトコルが同時に中央集権的な緊急権限を行使しました。Aaveは複数のチェーンで市場を凍結し、ArbitrumのSecurity Councilは強制転送を実行し、KelpDAOはコントラクトをグローバルに一時停止しました。事実上、「分散型」エコシステムの危機対応は、中央集権的な権限の調整された行使でした。
問題は、緊急権限が存在すべきかどうかではありません。KelpDAOのケースは、それらが存在するべきであるという説得力のある議論を提示しています。問題は、これらの権限の境界、トリガー条件、および説明責任メカニズムが十分に透明であるかどうかです。L2に資産を預け入れるユーザーは、基本的な質問に答えられるべきです。「どのような状況でSecurity Councilが私の資金を移動させることができ、私にはどのような救済措置がありますか?」
盗まれた資金の現状
独立したオンチェーン追跡(MetaSleuth[11]で完全な視覚化)によると、攻撃者は116,500 rsETHを7つのファーストホップアドレスに分散させ、その大部分をAave(Ethereum CoreおよびArbitrum)に担保として供給してWETHとwstETHを借り入れ、その収益を両チェーンの共有アドレス 0x5d39...7cccに集約しました(Ethereum / Arbitrum)。2026年4月22日05:42 UTC現在、盗まれた資金は4つの異なる状態にあります:
| ステータス | 金額 | 場所 | 詳細 |
|---|---|---|---|
| 凍結 | 30,765.67 ETH | Arbitrumの0x0000...0da0 |
2026年4月21日03:35:08 UTCにArbitrum Security Councilによって強制転送、署名なし、sendUnsignedTransactionOverrideガバナンスアップグレードを通じて実行 |
| ブリッジ傍受 | 3,575.57 rsETH |
ArbitrumのLZMultiCall 0x8e60...286e |
2026年4月18日18:30:31 UTCにクロスチェーン転送試行失敗 |
| アイドル | 25,701.76 ETH | Ethereumの0xd4b8...1530 |
2026年4月21日11:16 UTCに受信、以来未接触 |
| 分散または分散中 | ~50,000 ETH | Ethereumの0xf980...0b85および0x62c7...c64e 、103のユニークなファーストホップアドレスに拡散 |
0xf980...0b85は2026年4月21日08:05から20:21 UTCの間に約25,000 ETHを分散し、その後最終的な8.989 ETHを0x62c7...c64eに直接スイープしました。0x62c7...c64eは20:13 UTCに独自の分散を開始し、2026年4月22日05:41 UTC現在もアクティブでした。 |
収益の約31%は凍結または傍受されており、23%は単一の休眠Ethereumアドレスにアイドル状態で残っており、46%は103のファーストホップアドレスに分散されているか、現在分散中です。Aave担保として提供されたrsETHは預け入れられたままで、借り入れたWETHとwstETHは返済されていません。攻撃者はレンディングポジションを放棄しました。
結論
KelpDAOインシデントは、「分散型」スタックの3つのレイヤーを横断する因果連鎖をたどります。
それは単一障害点への依存から始まりました。KelpDAOの1対1 DVN設定は、クロスチェーン検証を単一エンティティにまで削減し、単一の侵害されたインフラストラクチャコンポーネントを通じて、ブリッジ全体を侵害可能にしました。アーキテクチャは分散化をサポートしていましたが、設定はそうではありませんでした。
次に、コンポーザビリティがブリッジ侵害をシステム全体にわたる流動性危機に変えました。単一の攻撃が、rsETHやKelpDAOに接続していないユーザーが保有する数十億ドルの流動性に影響を与え、5つのチェーンにわたるDeFiの最も基本的な資産であるWETHを凍結させました。連鎖反応の範囲は、測定可能なパラメータによって形作られました。積極的なLTV設定、浅い流動性プール、そして広範なクロスチェーン担保展開です。
危機の規模は、分散型ガバナンスに中央集権的な緊急権限を行使させることを余儀なくさせました。ArbitrumのSecurity Councilは、ガバナンスによって承認されたアトミックなコントラクトアップグレードを通じて、所有者の署名なしで30,766 ETHを移動させました。Aaveは、ガバナンス駆動の緊急措置を通じて、複数のチェーンにわたる市場を凍結しました。対応は効果的で、透明性があり、そしておそらく必要でした。それはまた、「パーミッションレス」には実用的な境界があることを示しました。
単一障害点への依存が侵害を可能にし、コンポーザビリティが損害を増幅させ、損害は常にそこに存在していた中央集権的な権限、すなわちアップグレード可能なコントラクトとガバナンスフレームワークに埋め込まれた権限を明らかにしました。これらの連動するダイナミクスに対処するには、すべての参加者からの行動が必要です。
プロトコル向け:プロトコルの全体的なセキュリティは、その最も弱いリンクによって決定されます。この場合、それはスマートコントラクトではなく、DVNインフラストラクチャでした[10]。効果的なセキュリティには、コードセキュリティ、インフラストラクチャセキュリティ、キー管理、および運用セキュリティを含む、複数の次元にわたる体系的なカバレッジが必要です。包括的な評価とペネトレーションテストは、個々のコンポーネントを孤立してではなく、フルスタックをストレステストする必要があります。オンチェーン監視は、数時間ではなく数分以内の緊急対応を可能にし、資産凍結を調整し、回復を最大化するために、迅速なクロスチェーン資金追跡が不可欠です。特にレンディングプロトコルについては、クロスチェーン合成資産からの担保は、LTV、プール深度、およびクロスチェーン展開数の3つのパラメータについて、「総担保侵害」シナリオに対してストレステストされるべきです。
L2ガバナンスおよびDAO向け:緊急権限は透明で説明責任があるべきです。ほとんどの主要なL2はすでにこれらの機能を持っていますが、それらはしばしばユーザー向け資料に表面化されるのではなく、技術文書に埋もれています。ガバナンスフレームワークは、トリガー条件、範囲制限、時間制約、および事後説明責任要件を成文化すべきです。
ユーザー向け:DeFiコンポーザビリティに固有のシステムリスクを理解してください。このインシデントでは、rsETHに一切触れなかったWETH預入者の流動性が5つのチェーンにわたって凍結されました。個々のポジションリスクは、全体像の一部にすぎません。あなたの資産が相互作用するプロトコル、プール、担保タイプ、およびチェーンはすべて、相互接続されたリスクサーフェスを形成します。
参考文献
[1] LayerZero Core, "KelpDAO Incident Statement": https://x.com/LayerZero_Core/status/2046081551574983137
[2] KelpDAO, "April 18 Incident: Additional Context": https://x.com/KelpDAO/status/2046332070277091807
[3] LlamaRisk, "rsETH Incident Report" (April 20, 2026): https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580
[4] BlockSec Phalcon Explorer, L1 Transaction (Arbitrum Security Council action): https://app.blocksec.com/phalcon/explorer/tx/eth/0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770
[5] BlockSec Phalcon Explorer, L2 Transaction (Arbitrum forced transfer): https://app.blocksec.com/phalcon/explorer/tx/arbitrum/0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b
[6] Arbitrum, "Security Council Emergency Action": https://x.com/arbitrum/status/2046435443680346189
[7] Arbitrum Governance Forum, "Security Council Emergency Action 21/04/2026": https://forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803
[8] Aave, rsETH incident updates (April 19-21, 2026): https://x.com/aave/status/2045593585966252377
[9] BlockSec Phalcon, "Arbitrum Security Council freeze analysis": https://x.com/Phalcon_xyz/status/2046467830498173088
[10] banteg, "Kelp rsETH Unichain → Ethereum Path Investigation": https://gist.github.com/banteg/705d0284513b74ad20f61d90f5b5de62
[11] MetaSleuth, KelpDAO exploit trace: https://metasleuth.io/result/eth/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222?source=600c61cd-f0cd-4dff-8687-14e02f6ccd24



