ШІ як «антигерой»: DeFi-страхування потребує стрес-тестування

Проведення стрес-тестування DeFi-скарбниць: Firelight планує використовувати ШІ для виявлення «наступної катастрофи».

Автор: @jrdothoughts

Переклад: AididiaoJP, Foresight News

Сліпі зони DeFi-страхування: відсутність катастрофи не означає безпеку

Почнемо з чорного гумору в рекламі: «Наш новий літак абсолютно безпечний, він ніколи не розбивався».

«Скільки часу він літає?»

«... приблизно двічі».

Якщо замінити літак на DeFi-скарбницю, історія стає знайомою: шість місяців без проблем з виведенням, без атак, прибуток непоганий. Це, звичайно, є доказом. Але за ці шість місяців, чи стикалася вона з проблемами, такими як втрата застави під час мережевих заторів, коли постачальники ліквідності (LP) поспішали вивести свої кошти, а оракули не оновлювалися? Швидше за все, ні.

Чиста історія може лише свідчити про те, що система витримала. Страхування має запитувати: з чим вона може зіткнутися далі?

Це можливість, яку побачила Firelight: визначати ціни на основі способів виникнення втрат, а не лише на основі того, чи відбувалися втрати раніше. Історія відповідає за закріплення, моделювання відповідає за дослідження альтернативних сценаріїв, ШІ відповідає за виявлення слабких місць, а капітал відповідає за гарантії.

Історія — це моментальний знімок, але система може змінюватися

Дані про історичні втрати — це моментальний знімок роботи машини в певних умовах. Як тільки машина змінюється, знімок потрібно переглядати знову.

Якщо в скарбницю додається новий тип застави, змінюється оракул або підвищується важіль. Ім'я залишається тим самим, логотип не змінюється, але ризик стає зовсім іншим. Позичальники, ліквідатори та LP всередині не є статичними цифрами в таблиці. Вони реагують на стимули, і коли щось трапляється, всі хочуть вийти через одну і ту ж двері.

Це схоже на карту трафіку, намальовану за звичайними умовами поїздок у вівторок. Зазвичай вона виглядає досить точно, але якщо головний міст закритий, вона стає непотрібною. Карта сама по собі не помилкова, просто змінилися умови.

Отже, для Firelight справжнє питання не лише в тому, чи був цей протокол зламаний, а в тому: які права існують? Які залежності дійсно важливі? Коли всі одночасно намагаються вийти, які шляхи ліквідації ще залишаються? Відкритий каркас Firelight вже розділяє технічні вразливості та економічну слабкість, а не зливає їх в один показник безпеки.

Страхування стосується поточної конструкції системи та її залежностей, а не бренду, який вона використовує досі.

Страхування катастроф вже написало сценарій

Традиційні страхові компанії не відмовилися від моделювання невизначеності. Страхувальники катастроф завжди займаються одним: моделюванням того, як відбуваються катастрофи, які активи піддаються ризику, наскільки вразливою є структура, і скільки потрібно виплатити за контрактом. Урагани, які вже пройшли, не можуть представляти всі можливі урагани в майбутньому.

DeFi також потребує власної моделі катастроф. Просто катастрофи змінюються з ураганів на збої оракулів, об'єкти катастрофи змінюються з будівель на позиції позики, а вразливість змінюється з якості будівлі на буфер застави та дизайн ліквідації, а потім виплати розраховуються відповідно до умов покриття.

Модель катастроф запитує: що станеться, якщо ураган пронесеться містом? Модель DeFi запитує: що станеться, якщо збій пошириться за залежностями?

Firelight публічно обговорювала, як розділити ризики, калібрувати історію, використовувати моделювання Монте-Карло, мовні моделі та навчання з підкріпленням, об'єднуючи їх у фінансову лабораторію стрес-тестування. Варто зазначити, що це пропонований напрямок, а не ствердження, що кожен елемент вже реалізований.

Ще один момент, який потрібно зазначити: Firelight визначає свій продукт як протокольне покриття, а не традиційний страховий контракт. У статті використано аналогію зі страхуванням, порівнюючи дисципліну страхування, не торкаючись юридичної природи продукту.

Як побудувати фінансову лабораторію стрес-тестування

Перший крок — зафіксувати початковий стан, щоб забезпечити можливість відтворення. Версії контрактів, баланси, позиції застави, а також налаштування оракулів, правила ліквідації та ліквідність ринку повинні бути зафіксовані. Інакше результати двох симуляцій можуть не збігатися, можливо, лише через різні початкові умови, і ви не тестуєте одну й ту ж систему.

Другий крок — розділити виконання та припущення. Блокчейн може виконувати реальну логіку контракту, але не може створити завтрашню ліквідність, ціни поза ланцюгом і поведінку людей. Це все потрібно явно моделювати. Тестування на основі розгалужень та агентного управління вже має прецеденти в дослідженнях DeFi.

Третій крок — організувати різних учасників у симуляційному середовищі. Позичальники, ліквідатори, вкладники, LP — у кожного є обмеження капіталу та стимули. Але не можна давати комусь головну роль: ліквідатор не може робити збиткові угоди, щоб досягти «ідеального» результату. Ролі також не обов'язково виконувати за допомогою великих мовних моделей; прості та прозорі правила іноді є кращими, швидшими та легшими для відтворення. Технічні невдачі все ще потрібно перевіряти за допомогою розмитого тестування, перевірки коду та введення збоїв; ці методи паралельні економічному моделюванню, а не взаємозамінні.

Четвертий крок — влаштувати руйнування. Цінові стрибки, затримки оновлення оракулів, зменшення ліквідності, переривання виконання — все це потрібно протестувати. Не лише змінювати амплітуду, але й змінювати порядок. Виведення ліквідності LP до цінового шоку та після нього може дати зовсім різні результати.

Останній результат симуляції не повинен бути загальним показником безпеки, а має бути ланцюгом втрат: яка позиція першою зазнала невдачі, скільки було повернуто, як розширився дефіцит. Лише маючи цей ланцюг, можна визначити верхню межу покриття та вимоги до капіталу, або просто дати відповідь «не покривається».

Дайте ШІ роль «антигероя», але не змінюйте фізичні закони

Найочевидніше використання ШІ — це читання коду та документації. Мовні моделі можуть розбирати залежності, пояснювати оновлення, пропонувати сценарії невдач. Але правдоподібна історія не означає, що знайдено вразливість; для цього все ще потрібні докази.

Ще цікавіше — дати ШІ можливість активно шукати різні можливі сценарії. Моделювання Монте-Карло буде вибирати з заданого розподілу, і це, звичайно, корисно; але справжні погані комбінації можуть бути занадто рідкісними, і випадкове вибіркове тестування більшість часу лише повторює звичайні ситуації.

Адаптивне стрес-тестування навпаки: агенти в симуляторі вибирають фактори збурення, активно шукаючи правдоподібні шляхи невдач. У тестуванні автономного водіння вже були продемонстровані ці ідеї за допомогою навчання з підкріпленням. Агенти можуть змінювати погоду, але не можуть переписувати фізичні закони.

У пропонованій налаштуванні Firelight агенти можуть налаштовувати затримки оракулів, виведення ліквідності та частоту прибуття ліквідаторів в межах реальності. Знаходження руйнівних шляхів нагороджується, а шахрайство карається. Антигерой з безмежним капіталом і божественними повноваженнями не є корисною моделлю страхування.

Потім ШІ кластеризує траєкторії невдач, вибираючи наступну партію експериментів, які найкраще зменшать невизначеність. Сотні на вигляд різних катастроф можуть ділити одну й ту ж ліквідаційну вузьку ділянку. Це має практичну цінність.

Швидкість також важлива. Низьковитратні наближені методи спочатку відфільтровують велику кількість сценаріїв, а дорогі тестування виконуються в кількох незалежних тестових середовищах для відтворення важливих сценаріїв. Але скорочення шляхів має бути перевірено. Прискорення помилкових симуляторів лише призведе до того, що вони швидше впадуть у впевнені помилки.

ШІ виконує роль водія в тестуванні на протидію, а не судді з безпеки. Він вказує, що потрібно перевірити, а виконавчий механізм, експерти в галузі та докази визначають, чи витримує це відкриття.

Від траєкторій втрат до умов покриття

Уявіть собі гіпотетичну позикову скарбницю: ціна застави падає, LP поспішно виводять свої кошти, затримка оновлення оракулів. Ліквідатор, хоча й прибуває, але спред поглинає вартість повернення, в результаті чого борг позичальника перевищує реальну ціну, за яку можна продати заставу.

Потім проводимо кілька контрольних груп: лише дозволяємо ціні падати; одночасно з падінням ціни виводимо ліквідність; кілька факторів разом. Лише так можна зрозуміти, чи справжня слабкість полягає в ціні, чи в глибині ринку, або ж у взаємному впливі обох.

Припустимо, що один запуск прикладу призводить до 2 мільйонів доларів допустимих втрат, з франшизою 500 тисяч доларів і верхньою межею покриття 1 мільйон доларів. Франшиза поглинає 500 тисяч, припустимо, покриття виплачує 1 мільйон, залишок у 500 тисяч залишається поза межами ліміту.

Це вигадані приклади умов, не пропозиція Firelight і не реальні результати симуляції. Допустимість, повернення, виключення відповідальності та перекриття покриття все ще потребують уточнення.

Ключовим є те, що наявність економічних втрат не означає, що можна отримати виплату. Симуляція є справді корисною лише тоді, коли вона впливає на рішення про страхування — наприклад, знижуючи верхню межу покриття, вимагаючи більш суворого контролю ризиків, залишаючи більше капіталу або просто відмовляючи в покритті. Навіть найкрасивіша анімація катастрофи не є фінансовим рішенням.

Знайти шляхи невдачі не означає визначити ймовірність

Припустимо, що агресивний агент зламав систему в 30% тестів. Чи означає це, що система має 30% ймовірності невдачі? Ні. Цей агент спеціально створений для виявлення вразливостей.

Виявлення невдачі відповідає на запитання «як може щось піти не так, і до якого ступеня». Оцінка ймовірності відповідає на запитання «як часто ці умови виникають протягом періоду покриття». Змішування обох понять створює ілюзію неправдивої точності.

З концептуальної точки зору, очікувані виплати — це сума виплат у кожному сценарії, помножена на ймовірність виникнення цього сценарію, і все це підсумовується. Ці ймовірності потребують доказів, а припущення мають бути чітко викладені. Якщо немає надійної оцінки, слід використовувати діапазони, консервативні верхні межі та обмеження стресу, а не вигадувати точні до десяткових знаків числа.

Очікувані виплати не дорівнюють усім страховим внескам. Капітал також має покривати ризики «хвоста», операційні витрати та невизначеність, а ризики «хвоста» часто є досить неприємними. На рівні портфеля спільні залежності можуть призвести до одночасного виникнення виплат за кількома контрактами.

Відкритий капітальний каркас Firelight вже враховує концентрацію та відведення застави. Симуляція повинна одночасно тестувати обидва кінці: один кінець — це сплеск виплат, інший — це синхронне знецінення активів, або навіть ускладнення їх продажу. Якщо під час великої катастрофи капітал також зменшується, резерв покриття не може оцінюватися лише за середніми втратами.

Хто протестує «тестери стресу»?

Симулятори можуть бути логічно послідовними, але їхні висновки можуть бути абсолютно неправильними. Запускати мільйон разів з нереалістичними налаштуваннями ліквідаторів — це просто повторення однієї й тієї ж помилки мільйон разів. Більше запусків може зменшити вибіркову похибку, але похибка моделі не зменшиться автоматично.

Надійна лабораторія робить чотири речі: аналізує відомі події, перевіряє дані поза зразком, порівнює моделі, створені різними командами, і коригує припущення щодо поведінки учасників. Моментальні знімки, випадкові насіння та записи виконання мають бути збережені, щоб ключові відкриття можна було відтворити. І потрібно постійно запитувати: чи знайшов ШІ слабкість протоколу, чи це баг самого симулятора?

Жоден тест не може довести, що всі шляхи катастрофи знайдені. Саме через наявність невідомих залежностей і поведінки, яку ніколи не бачили, потрібні капітальні буфери, виключення відповідальності та стриманість у страхуванні.

Кордони контракту також мають бути чітко визначені. Нові докази можуть вплинути на майбутнє ціноутворення та ємність, але не повинні перетворювати існуюче покриття на рухому ціль. Відкритий каркас Firelight розділяє постійний моніторинг ризиків і фіксовані тарифи протягом періоду покриття. Постійне навчання та дотримання зобов'язань можуть співіснувати; але змінювати зобов'язання після виникнення небезпеки — це вже інша справа.

Висновок: навчання до виникнення втрат

Більша цінність полягає в тому, щоб інтегрувати страхування в процес розробки. Коли система зазнає значних змін, це викликає відповідні тести; результати тестування впливають на нові рішення щодо покриття; реальні події допомагають покращити наступну версію моделі. Чим краще виконана робота, тим більше це відображається на цінах покриття та доступності.

Історичні виплати — це навчання після події. Симуляція дозволяє Firelight заздалегідь зрозуміти, як ця система може зазнати збоїв.

ШІ відповідає за розширення області пошуку, докази обмежують його висновки, а капітал відповідає за виконання зобов'язань. Мета не в тому, щоб передбачити кожну катастрофу, а в тому, щоб, зрозумівши, з чим можна зіткнутися, інвестувати капітал, щоб витримати ті втрати, які неминучі.