【ITニュース解説】Cross-Chain Bridge Risk Assessment: Aave V3

Aave V3は、仮想通貨の世界で非常に重要な「分散型金融（DeFi）」と呼ばれる分野で、資金を貸し借りするための仕組みを提供するプロトコルだ。その中で最も多くの資金を扱っており、様々なブロックチェーン（イーサリアムやそのL2と呼ばれる高速・安価な派生チェーン）にまたがって約175億ドルもの資産が預けられている。Aave V3の中心的な仕組みは、これまで何度も専門家による監査を受け、高い安全性を維持してきた。しかし、今回のリスク評価レポートは、異なるブロックチェーン間で資産を移動させるための「クロスチェーンブリッジ」という部分に潜む新たな危険性について詳しく分析したものだ。システムエンジニアを目指す人にとって、このような複雑なシステムがどのように機能し、どのような脆弱性を抱える可能性があるかを理解することは非常に重要だ。

クロスチェーンブリッジとは、異なるブロックチェーンの間で安全に資産や情報をやり取りするための技術的な架け橋である。たとえば、イーサリアムにある仮想通貨を、より取引手数料の安いL2チェーンに送りたい場合などにこのブリッジを利用する。Aave V3のような大規模なプロトコルにとって、このブリッジはユーザーが様々なチェーンでサービスを利用できるようにするための不可欠な要素だが、同時にシステムの複雑性を増し、これまでになかった新たな攻撃の入り口を生み出す可能性がある。この評価では、ブリッジの設計、コード、関連する外部システム、そして運用プロセスまで、多角的に検証した。

この評価で特に懸念されたのは、以下に挙げる七つの攻撃の可能性だ。

一つ目は、「メッセージ認証とリプレイ攻撃」と呼ばれるものだ。これは、ブリッジシステムがメッセージを処理する際に使う「ノンス」という一意の番号の扱いに問題があることで発生する。ノンスは、同じメッセージが複数回使われることを防ぐためのもので、一度使われたら再利用されないようにするのが基本だ。しかし、一部のL2チェーン向けのブリッジアダプターでは、このノンスの管理が不十分なため、攻撃者は一度有効な「資産を預ける」というメッセージをコピーし、その内容（例えば、送金先のウォレットアドレス）を少し変えて、別のL2チェーンで再度実行することが可能になる。これにより、実際には裏付けとなる資産がないのに、Aaveのトークン（aTokens）が二重に発行されてしまう危険性がある。これは、プロトコルの健全性を損ない、正直なユーザーが損失を被る可能性につながる。この問題を解決するためには、ユーザーごとに、かつ送金先のチェーンごとに一意のノンスを生成し、それを厳格に管理する仕組みを導入する必要がある。

二つ目は、「流動性プロバイダー（LP）管理コントラクトにおける集中型のアップグレード経路」に関する問題だ。LP管理コントラクトとは、ユーザーがブリッジを通じて資産を移動させる際に一時的に資金を預かるスマートコントラクトのことだ。これらのコントラクトには50億ドル以上もの多額の資産が保管されている。しかし、Polygonチェーンのブリッジでは、このコントラクトのアップグレード権限が一つのウォレットアドレス（単一のオーナー）に集中していることが判明した。アップグレードには一応48時間の待機期間があるものの、その待機期間すらも同じオーナーがコントロールできてしまう。もしこのオーナーのウォレットが盗まれたり、内部の人間が悪意を持ったりした場合、悪質なプログラムに書き換えられて、簡単に預けられた資産がすべて盗まれてしまうリスクがある。このリスクを排除するためには、複数の承認者が必要な「マルチシグ（複数署名）」という仕組みと、さらにその承認にも遅延を設ける「タイムロック」を組み合わせた、より安全なアップグレードプロセスを導入することが不可欠だ。

三つ目は、「リレーヤー/オラクルに対するサービス拒否（DoS）攻撃」だ。クロスチェーンブリッジの動作には、「リレーヤー」と呼ばれるオフチェーン（ブロックチェーン外）のシステムが重要な役割を果たす。これは、あるチェーンから別のチェーンへメッセージを中継する役目を担うものだ。しかし、このリレーヤーネットワークは、不正な要求に対する制限や認証機能が不足している。そのため、攻撃者は大量の無意味なメッセージを送りつけることで、リレーヤーのシステムに過剰な負荷をかけ、正常なメッセージの処理を妨害できる可能性がある。結果として、ユーザーの資産移動が遅延し、他のチェーンで担保として預けている資産が強制的に清算されてしまうなど、広範囲な影響を及ぼす可能性がある。この問題には、APIキーによる認証や、特定のIPアドレスからの要求数の制限を設けることで、不正なアクセスや負荷を軽減する対策が必要となる。

四つ目は、「グローバルな供給上限の迂回」という問題だ。Aave V3では、各L2チェーンごとに「これ以上の資産は供給できない」という上限（供給キャップ）が設けられている。しかし、プロトコル全体としての供給上限は、オンチェーン（ブロックチェーン上）で厳密に集計・管理されておらず、オフチェーンでの「目安」に過ぎない。このため、攻撃者は、例えばイーサリアムで許容範囲内の5億ドルを預け、さらにOptimismでも許容範囲内の5億ドルを預けることで、プロトコル全体の意図された上限（例えば8億ドル）を実質的に超えてしまうことが可能だ。これは、市場の急激な変動に対するプロトコルの脆弱性を高めることになる。この課題を解決するには、複数のチェーンにまたがる資産の合計をオンチェーンで常に監視し、全体の上限を厳格に適用するような「グローバルキャップマネージャー」の導入が求められる。

五つ目は、「オンチェーンでの流動性証明の不足」だ。ブリッジが資産をあるチェーンから別のチェーンへ移動させる際、移動元となるチェーンのLPコントラクトに十分な流動性（資産）があることを、事前にブロックチェーン上で完全に検証する仕組みが不足している。現状では、資産移動の指示を受けた後にLPコントラクトの残高を確認する形になっているため、攻撃者は、この確認と実際の資産移動の間に、別の取引を通じてLPコントラクトから資産を一時的に引き出すことが可能になる。これにより、実際には裏付けとなる資産がないまま、目的地となるチェーンでAaveトークンが発行されてしまう「流動性枯渇」攻撃のリスクがある。この脆弱性への対策としては、Aaveトークンを発行する前に、移動元のLPコントラクトに十分な資産がロックされていることを、ブロックチェーン上で誰もが検証できる形で保証する「エスクロー契約」のような仕組みを導入する必要がある。

六つ目は、「ガバナンスアップグレードにおける競合状態」だ。ブリッジのアップグレードに関するガバナンス（意思決定）プロセスに問題がある。現状のシステムでは、アップグレードの提案がなされるとすぐに記録され、24時間の待機期間後には、一定以上の投票権を持つアドレスがその提案を実行できる。しかし、「コミット・リビール」のような、提案者がまず提案のハッシュ値だけを公開し、投票期間後に初めて具体的な内容を明かす、といった安全な仕組みが導入されていない。これにより、投票権を多く持つ悪意のある参加者が、善良なアップグレード提案を察知し、それを実行される前に自身の悪意ある提案にすり替えて実行してしまう「フロントランニング」という攻撃が可能になる。これを防ぐためには、提案の実行までのプロセスに、より多くの時間と複数の段階を踏むような改善が必要だ。

七つ目は、「クロスチェーンリエントランシー」と呼ばれる攻撃だ。これは、ブリッジのL2チェーン側の入り口となるスマートコントラクトで、内部の状態を更新する前に外部のトークンコントラクトを呼び出していることに起因する。一部のトークン（例えばERC-777）は、送金処理中に特定の「フック」と呼ばれる関数を自動的に呼び出す機能を持っている。この特性を悪用すると、攻撃者は外部呼び出し中に再度ブリッジコントラクトを呼び出し、まだ状態が更新されていないことを利用して、同じ送金メッセージで二重にAaveトークンを受け取ることができる。これは、一つ目のリプレイ攻撃と似ているが、特定の機能を持つトークンに限定される問題である。この脆弱性に対処するには、外部のコントラクトを呼び出す前に、必ず内部の状態（例えば、メッセージが処理済みであるというフラグ）を更新するようにコードの実行順序を変更し、「非リエントラント」修飾子を使うなどして、再入を防止する標準的なセキュリティ対策を適用する必要がある。

全体として、これらの脆弱性は単独では簡単には悪用できないものも多いが、複数の攻撃手法を組み合わせることで、億ドル規模の資産が失われる可能性があると評価された。例えば、二重発行攻撃、LPコントラクトの乗っ取り、そして供給上限の迂回などを複合的に仕掛けることで、甚大な被害が生じる可能性がある。評価では、このブリッジレイヤーがプロトコル全体の資産に対して中〜高程度の危険をもたらすと結論付けられた。

このレポートでは、これらのリスクを軽減するための具体的な推奨事項も提示されている。例えば、前述の統一されたノンススキームの導入、LPコントラクトをマルチシグとタイムロックで保護すること、オンチェーンで流動性を証明する仕組み、そしてグローバルな供給上限を厳格に実施するなどの対策だ。これらの対策を講じることで、ブリッジの攻撃対象領域を大幅に縮小し、Aave V3が多額の資産を扱うプロトコルとしてのセキュリティレベルを、ブリッジ部分においても確保することが可能となる。

最終的なリスクスコアは10点中8点と非常に高く評価されており、Aave V3の運営チームは、このブリッジをプロトコルの中心部分と同様に、独立した高価値なコンポーネントとして扱い、専門の監査リソースを割り当て、厳格なアップグレードプロセスを実施し、継続的な監視体制を維持することが強く推奨されている。これらの対策が適切に実施されれば、ブリッジはAaveのマルチチェーン戦略を安全に支え、プロトコルの安全性と信頼性という評判を維持できるだろう。システムエンジニアを目指す上では、このようなシステム設計におけるセキュリティの多層性や、攻撃ベクトルの特定とそれに対する具体的な対策の考案能力が求められることを理解しておくことが重要だ。