AIが「悪役」に、DeFi保険にはストレステストが必要

DeFi金庫の衝突テスト：FirelightはAIを使って「次の事故」を探す予定です。

執筆：@jrdothoughts
編訳：AididiaoJP、Foresight News

DeFi保険の盲点：爆発していないから安全とは限らない

まずはブラックユーモアのセールストークを聞いてみましょう。「私たちの新しい飛行機は絶対に安全で、今まで墜落したことがありません。」
「どのくらい飛びましたか？」
「……おそらく2回です。」
飛行機をDeFi金庫に置き換えると、話はとてもよく似ています：6ヶ月間は出金がスムーズで、攻撃を受けず、利益も悪くない。これは確かに証拠です。しかし、この6ヶ月の間に、ネットワークの混雑時に担保が脱鎖したり、流動性提供者（LP）が一斉に撤退したり、オラクルが更新されなかったりしたことはありませんでしたか？おそらくありません。
クリーンな歴史は、システムが何を耐えたかを示すだけです。保険が問うべきは：次に何が起こる可能性があるのかです。
これがFirelightが見た機会です：損失の発生方法に基づいて価格を設定し、損失が発生したかどうかだけを見ないことです。歴史はアンカーを提供し、シミュレーションは代替シナリオを探求し、AIは弱点を見つけ、資本は保証を提供します。

歴史はスナップショット、システムは変わる

歴史的な損失データは、特定の条件下で動作する機械のスナップショットです。機械が変われば、スナップショットも再評価が必要です。
金庫が新しい担保タイプを追加し、オラクルを変更し、レバレッジを引き上げた場合、名前やロゴは変わらなくても、リスクは大きく異なります。中の借り手、清算者、LPも、表にある静的な数字ではありません。彼らはインセンティブに反応し、問題が発生した場合には同じドアから出ようとします。
これは、通常の火曜日の通勤状況に基づいて描かれた交通地図のようなものです。普段は正確に見えますが、主要な橋が封鎖されると役に立たなくなります。地図自体は間違っていませんが、交通状況が変わったのです。
したがって、Firelightにとって本当の問題は「このプロトコルはハッキングされたことがあるか？」ではなく、次のようなことです：どの権限が存在するのか？どの依存関係が本当に重要なのか？全員が一斉に外に出ようとしたとき、どの清算経路がまだ機能するのか？Firelightが公開したフレームワークは、技術的な脆弱性と経済的な脆弱性を分けており、安全スコアを一つにまとめるのではありません。
保険はシステムの現在の構造と依存関係に対して行われるものであり、今まで使われてきたブランド名に対してではありません。

大災害保険はすでにシナリオを書いている

伝統的な保険会社は不確実性のモデリングを放棄していません。大災害保険者は常に一つのことを行っています：災害がどのように発生するか、どの資産が露出するか、構造がどれほど脆弱か、そして契約が最終的にどれだけの賠償を支払うかをシミュレーションしています。過去に発生したハリケーンは、未来に起こりうるすべてのハリケーンを代表するものではありません。
DeFiも独自の大災害モデルが必要です。ただし、災害はハリケーンからオラクルの故障に変わり、被災対象は建物から貸出ポジションに変わり、脆弱性は建物の品質から担保バッファと清算設計に変わり、最後に保障条項に基づいて賠償を計算します。
大災害モデルが問うのは：ハリケーンが都市を襲った場合はどうなるか？DeFiモデルが問うのは：一度の故障が依存グラフに沿って拡散した場合はどうなるか？
Firelightはリスクを分解し、歴史を校正し、モンテカルロシミュレーション、言語モデル、強化学習を組み合わせて、金融衝突テストラボに接続することを公開しています。これは提案された方向性であり、すべての要素がすでに稼働しているわけではありません。
もう一つ説明が必要なのは、Firelightは自社の製品をプロトコル型保障として定義しており、従来の保険契約ではないということです。文中で保険と類比を用いるのは、保険の規律を比較するためであり、製品の法的な性質には関与しません。

金融衝突テストラボの構築方法

第一歩は、初期状態を固定し、再現可能であることを確認することです。契約のバージョン、残高、担保ポジション、オラクル設定、清算ルール、市場流動性をすべてロックします。そうでなければ、2回のシミュレーション結果が一致しないのは、単に出発点が異なるからであり、同じシステムを測定しているわけではありません。
第二歩は、実行と仮定を分けることです。ブロックチェーンのフォークは実際の契約ロジックを実行できますが、明日の流動性、オフチェーン価格、人間の行動を無から生み出すことはできません。これらは明示的にモデル化する必要があります。フォークやエージェント駆動のテストは、DeFi研究の中で先例があります。
第三歩は、シミュレーション環境にさまざまな参加者を配置することです。借り手、清算者、預金者、LPはそれぞれ資金制限とインセンティブを持っています。しかし、誰かに主役の光を当てることはできません：清算者は完璧な結末を得るために損失取引を行うことはできません。役割はすべて大規模な言語モデルを使用する必要はなく、シンプルで透明なルールの方が時にはより良く、より早く、再現しやすいです。技術的な失敗は、依然としてファジーテスト、コードレビュー、障害注入に依存する必要があり、これらの手法と経済シミュレーションは並行して行われるものであり、互いに代替するものではありません。
第四歩は、破壊を行うことです。価格の急落、オラクルの更新遅延、流動性の減少、実行の中断などを試します。単に幅を変えるだけでなく、順序も変えます。LPが価格の衝撃前に流動性を撤回するのと、衝撃後に撤回するのでは、結果が完全に異なる可能性があります。
シミュレーションの最終結果は、一般的な安全スコアではなく、損失の連鎖を示すべきです：どのポジションが最初に失敗し、どれだけ回収され、ギャップがどのように拡大するか。この連鎖があれば、保障上限と資本要件を決定することができるか、単に「保障しない」と言うことができます。

AIを「悪役の席」に座らせるが、物理法則を変えてはいけない

AIの最も直感的な使い方は、コードや文書を読むことです。言語モデルは依存関係を整理し、アップグレードを説明し、失敗シナリオを提案できます。しかし、信頼できるストーリーがあるからといって、脆弱性を見つけたことにはなりません。証拠が必要です。
さらに興味深いのは、AIにさまざまな可能なシナリオを積極的に探させることです。モンテカルロシミュレーションは設定された分布からサンプリングを行いますが、これは確かに役立ちます。しかし、実際に悪い組み合わせは非常に稀であり、ランダムサンプリングは大部分の時間、普通の状況を繰り返し発見するだけです。
適応型ストレステストは逆に、エージェントがシミュレーター内で擾乱要因を選択し、信頼できる失敗経路を積極的に探します。自動運転テストでは、すでに強化学習を用いてこの考え方が示されています。エージェントは天候を変えることができますが、物理法則を書き換えることはできません。
Firelightの提案された設定では、エージェントは現実の境界内でオラクルの遅延、流動性の撤回、清算者の到着率を調整できます。破壊的な経路を見つけると報酬が与えられ、チートをすると罰せられます。無限の資本と神の権限を持つ悪役は、有用な保険モデルではありません。
次にAIは失敗の軌跡をクラスタリングし、不確実性を最も減少させる次の実験を選びます。数百の異なる災害が、同じ清算ボトルネックを共有している可能性があります。これが行動価値を持つのです。
速度も重要です。低コストの近似手法で大量のシナリオをフィルタリングし、高価な実行テストを複数の独立したテスト環境で重要なシナリオを再生します。しかし、近道は検証が必要です。誤ったシミュレーターを加速させることは、より早く自信を持って間違えるだけです。
AIは対抗テストのドライバーの役割を果たし、安全な審判ではありません。AIは何を調べるべきかを指摘し、実行エンジン、ドメイン専門家、証拠がその発見が正当であるかどうかを決定します。

損失の軌跡から保障条項へ

想像上の貸出金庫を考えてみましょう：担保価格が下落し、LPが次々と撤退し、オラクルの更新が遅れました。清算者は進入しましたが、スリッページが回収価値を飲み込み、最終的に借り手の債務は担保が実際に売れる価格を超えました。
さらにいくつかの対照を作成します：価格を下げるだけ；価格が下がると同時に流動性を引き抜く；いくつかの要因を同時に発生させる。これにより、真の弱点が価格にあるのか、市場の深さにあるのか、または両者の相互作用にあるのかを見極めることができます。
仮に一回の例示運用で200万ドルの適格損失が発生し、自己負担額が50万ドル、保障上限が100万ドルだとします。自己負担層が50万ドルを吸収し、保障が100万ドルを支払うと仮定すると、残りの50万ドルは限度額外に残ります。
これらは架空の例示条項であり、Firelightの見積もりではなく、実際のシミュレーション結果でもありません。適格性、回収、除外責任、重複保障は、まだ明確にする必要があります。
重要なのは：経済的損失があっても、賠償を受けられるとは限らないということです。シミュレーションが保険決定に影響を与える場合にのみ、本当に有用です------例えば、保障上限を引き下げたり、より厳しいリスク管理を要求したり、資本を多く残したり、または単に保険を拒否したりすることです。災害アニメーションがどれだけ美しくても、それは財務的決定ではありません。

失敗経路を見つけることは、確率を算出することではない

仮に対抗的なエージェントが30%のテストでシステムを突破したとします。これはシステムに30%の失敗確率があることを示すのでしょうか？そうではありません。このエージェントはもともと脆弱性を見つけるために設計されたものです。
失敗を発見することは、「どのように悪化する可能性があるか、どの程度悪化するか」を答えることです。確率を推定することは、「これらの条件が保障期間内に発生する頻度はどのくらいか」を答えることです。両者を混同することは、虚偽の精度を生み出すことになります。
概念的には、期待賠償は各シナリオの賠償額に、そのシナリオが発生する確率を掛けて合計したものです。これらの確率は証拠に基づく必要があり、仮定も明確に記載する必要があります。信頼できる推定がない場合は、範囲、保守的な上限、ストレス制約を使用し、正確な小数点数字を作成してはいけません。
期待賠償は全ての保険料に等しいわけではありません。資本は尾部リスク、運営コスト、不確実性をカバーする必要があり、尾部リスクは往々にして非常に厄介です。ポートフォリオレベルで見ると、共有依存関係により、複数の契約が同時に賠償を引き起こす可能性があります。
Firelightが公開した資本フレームワークは、集中度と担保の撤回を考慮しています。シミュレーションは同時に両端を圧力テストする必要があります：一方は賠償の急増、もう一方は支援資産の同時減価、さらには売却が難しくなることです。大災害が発生した際に資本も減少する場合、保障プールは平均損失に基づいて推定されるべきではありません。

誰が「ストレステスター」をストレステストするのか？

シミュレーターは論理的に一貫していても、結論が完全に間違っていることがあります。非現実的な清算者の設定で100万回実行することは、同じ間違いを100万回繰り返すことに過ぎません。何度も実行することでサンプリング誤差を減少させることはできますが、モデル自体の誤差は自動的に小さくなるわけではありません。
信頼できる実験室は4つのことを行います：既知のイベントを振り返り、サンプル外データで検証し、異なるチームが独立して構築したモデルを比較し、参加者の行動に関する仮定を調整します。スナップショット、ランダムシード、実行記録はすべてアーカイブされ、重要な発見が再現可能である必要があります。また、繰り返し尋ねる必要があります：AIが見つけたのはプロトコルの弱点なのか、それともシミュレーター自身のバグなのか？
どのテストも、すべての災害経路を見つけたことを証明することはできません。未知の依存関係や未見の行動が存在するため、資本バッファ、除外責任、保険の抑制が必要です。
契約の境界も明確にする必要があります。新しい証拠は将来の価格設定や容量に影響を与える可能性がありますが、既存の保障を移動する標的にしてはいけません。Firelightが公開したフレームワークは、継続的なリスク監視と保障期間中の固定料金を分けて処理しています。継続的な学習と約束の維持は共存可能ですが、危険が発生した後に約束を改訂することはできません。

結論：損失が発生する前に学ぶ

より大きな価値は、保険を開発プロセスに組み込むことです。システムに重大な変化があれば、それに応じたテストがトリガーされます；テスト結果は新しい保険決定に影響を与えます；実際のイベントは次のモデルの改善に役立ちます。エンジニアリングがうまくいくほど、最終的には保険価格と入手可能性に反映されます。
歴史的な賠償は事後の補習です。シミュレーションはFirelightに、システムがどのように故障する可能性があるかを事前に明らかにします。
AIは検索範囲を広げ、証拠はその結論を制約し、資本は約束を果たします。目標は、すべての災害を予測することではなく、直面する可能性のあるものを明確に見た後に資本を投入し、避けられない損失を支えることです。