本文へ移動
Financial Context Wiki

オラクル攻撃

オラクル攻撃は、操作可能、古い、スケール不正、設定不正の外部データを悪用し、プロトコルに危険な値で貸付、発行、償還、決済、清算を行わせます。

更新日

教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。

端的な答え

オラクル攻撃はプロトコルのデータ信頼境界を悪用し、価格、為替レート、指数、純資産価値、ステータス入力によって経済的に危険な処理を引き起こします。攻撃者は流動性の薄い取引場所を操作したり、レポーターや鍵を侵害したり、集約・更新規則を悪用したりします。また、借入資本と、利用側に欠けている鮮度、単位、範囲、フォールバック検査を組み合わせることもあります。オラクル運営者に悪意がなくても、古いフィードや設定不備で同じ損失が生じるため、インシデント分析では攻撃経路と障害形態を分ける必要があります。

重要なのは表示価格が急変したかではありません。コントラクトが実際に使う値へ影響を与える費用とリスクが、貸付、発行、償還、決済、清算から実行可能な形で引き出せる価値を下回るかどうかです。フラッシュ流動性はアトミックな経路に資金を供給できますが、欠陥のある信頼境界を生み出すものでも、悪用に必須のものでもありません。

オラクル値は必ずしも市場で約定可能な価格ではありません。レビューでは値をチェーン、ブロック、フィードまたはプールのアドレス、ベースとクオートの向き、小数桁、タイムスタンプ、集約方法、市場規模、利用関数に結び付けます。有効な署名が証明するのは、ある方式の下で誰がデータを報告したかです。それだけで鮮度、情報源の独立性、市場の厚み、経済的な正しさは証明できません。

仕組み

  1. デプロイを固定します。チェーン、ブロック、利用コントラクトと関数、資産コントラクト、フィード proxy または pool、aggregator、base/quote asset、decimals、administrator、upgrade state を特定します。
  2. exchange、pool、reporter から aggregation、signature、proxy/adapter、fallback、consumer logic までの信頼経路全体を描きます。ラベルの数を独立ソースとみなさず、共有 venue、operator、key、governance を記録します。
  3. オンチェーンの読み取りを正確に再現します。answer、round metadata、timestamp、該当する confidence/status、decimal normalization、quote inversion、sequencer state と grace period、maximum age、deviation bound、zero/negative value の扱いを確認します。
  4. 利用側の exposure ledger を作ります。collateral factor、liquidation threshold、borrow/supply cap、available liquidity、debt、mint/redemption limit、close factor、liquidation bonus、その値により可能になるすべての処理を記録します。
  5. reserve、active liquidity、observation、window と weighting convention、fee、arbitrage、block ordering、flash/owned capital、unwind loss、gas、MEV、競合 liquidator を含め、実行可能な規模で操作をモデル化します。
  6. independent source、TWAP cardinality、cap、circuit breaker、pause authority、timelock、古い・乖離した fallback、reporter/key loss、L2 sequencer outage、正当な price gap、fail-open/fail-closed をテストします。
  7. canonical feed round、proxy/configuration change、source divergence、protocol action、liquidation、bad debt、pause/recovery decision を監視・照合します。流動性、listing、upgrade、市場環境の変化後に分析を繰り返します。

spot AMM の読み取り値は、多くの場合 1 トランザクション内で変更できます。時間加重平均は複数観測にわたる影響を必要とするため費用を上げられますが、安全性は算術平均か tick ベースかという方式、window、observation cardinality、liquidity distribution、block control に依存します。median は一部の outlier を排除できますが、上流 venue の相関や quorum 喪失は安全性または liveness を損ないます。heartbeat/deviation の設定は一部フィードの公開時期を決めますが、consumer には独自の freshness/validity policy が必要です。

計算例

  • 定数積 spot。 fee を無視し、reserve が 1,000,000 ABC と 1,000,000 USDC なら k = 10^12 です。目標 marginal price 9 USDC/ABC には reserve 3,000,000 USDC と 333,333.333333 ABC が必要です。trader は 2,000,000 USDC を入れ、666,666.666667 ABC を受け取ります。最終 marginal price は 3,000,000 / 333,333.333333 = 9、average execution price は 2,000,000 / 666,666.666667 = 3 USDC/ABC です。一方、5,000,000 USDC を入れると reserve は 6,000,000 と 166,666.666667 になり、marginal price は 36 であって 9 ではありません。実際には fee、arbitrage、concentrated liquidity、unwind により ledger が変わります。
  • TWAP の方式。 1 分ごとの等間隔観測 10 個のうち、9 個が 100、1 個が 160 です。説明用 arithmetic TWAP は (9 * 100 + 160) / 10 = 106 で、100 より 6% 高いだけです。最後の spot は 60% 高くなっています。他の 9 観測を 100 のまま arithmetic average を 130 にするには、操作観測値が 400 でなければなりません。Uniswap v3 の tick mean はこの算術例ではなく幾何平均なので、consumer はデプロイ済み方式を再現する必要があります。
  • median と quorum。 正規化済み観測 7 個は [99, 100, 100, 101, 101, 500, 600] で、median は 101 です。極端な 2 報告は結果を正直な値の集団から動かしません。受入れに live report が 5 個必要で、正直な reporter 3 者が offline になると残りは 4 < 5 です。outlier resistance は availability を保証せず、fallback behavior も security model の一部です。
  • stale data と不当な清算。 decimals が 8 のフィードが raw 140,000,000,000、すなわち 1,400 を返しても、age が 17 minutes で consumer maximum 15 minutes を超えるなら拒否すべきです。それでも stale value を 10 ETH、liquidation threshold 75%、debt 12,000 に使うと health factor は 10 * 1,400 * 0.75 / 12,000 = 0.875 です。fresh price 2,000 なら 1.25 です。後の価格訂正は完了済み清算を取り消しません。

リスク

  • chain、asset、feed、proxy、pool、consumer address の誤り。
  • base/quote asset の反転または denomination の不整合。
  • feed、token、内部 fixed-point の decimal normalization の誤り。
  • stale data を受け入れる、または heartbeat/deviation trigger を鮮度保証と誤解する。
  • incomplete round、invalid status、zero、negative、capped、out-of-range answer を受け入れる。
  • 薄い単一 venue の spot price が大きな protocol exposure を左右する。
  • TWAP window が短い、観測が疎、weighting が不正、または向きを逆に読む。
  • observation cardinality、initialization、interpolation、fallback behavior の誤解。
  • concentrated/JIT liquidity により pool value が attack cost を表さない。
  • 複数 feed が同じ exchange、data vendor、operator、key、control plane を共有する。
  • reporter、exchange、API、signer、network、quorum failure により更新または完全性が失われる。
  • L2 sequencer downtime や recovery grace period の欠落・誤設定で stale state が露出する。
  • fallback が stale、circular、correlated、scale 不一致、semantic incompatibility である。
  • flash liquidity と atomic composability により一時的な影響を経済的に利用できる。
  • oracle update ordering、front-running、sandwich、back-running、liquidation MEV が payout を変える。
  • collateral factor、liquidation threshold、cap、bonus、available liquidity が小さな誤差を増幅する。
  • governance、administrator、guardian、multisig、signing key の侵害で trust path が変わる。
  • proxy、aggregator、adapter、upgrade、storage、configuration の誤りで別の値が選ばれる。
  • circuit breaker や fail-closed logic がストレス時の正当な借入、返済、清算を止める。
  • pause、recovery、account reconciliation、bad-debt allocation、cross-protocol containment が失敗する。

よくある誤解

  • 「オラクル攻撃はすべてオラクルネットワークを侵害する。」 多くは薄い source、stale value、wrong unit、unsafe adapter、consumer logic を悪用し、reporting network 自体は設定どおり動作しています。
  • 「複数または分散型のフィードなら正しい価格が保証される。」 independence、source quality、quorum、freshness、unit、aggregation、consumer check が依然必要です。
  • 「TWAP なら操作は不可能になる。」 影響に必要な期間と費用が変わるだけで、弱い window、疎な observation、浅い liquidity、block control は悪用され得ます。
  • 「フラッシュローンを禁止すればオラクルリスクは解決する。」 フラッシュローンは資金調達手段の一つです。自己資本、credit、cross-protocol borrowing、reporter compromise、configuration error は残ります。
  • 「価格が戻れば被害も取り消される。」 canonical な borrow、mint、redemption、settlement、liquidation は、別途権限を与えられた recovery process がなければ残ります。

関連トピック

出典

ナビゲーション

Wiki を検索...