ИИ становится «злодеем»: страхование DeFi нуждается в стресс-тесте

Автор: 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%? Отнюдь нет. Этот агент изначально создан специально для поиска уязвимостей.

Обнаружение сбоя отвечает на вопрос «как именно он может произойти и до какой степени». Оценка вероятности отвечает на вопрос «как часто эти условия будут возникать в течение периода страхования». Смешивание этих понятий создает ложную точность.

Концептуально ожидаемая выплата равна сумме произведений размера выплаты по каждому сценарию на вероятность его наступления. Эти вероятности требуют подтверждения фактами, а допущения должны быть четко записаны. Если достоверной оценки нет, используйте диапазоны, консервативные верхние границы и стресс-ограничения, а не придумывайте цифры до десятой части.

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

Опубликованный Capital Framework от Firelight уже учитывает концентрацию и откат стоимости обеспечения. Симуляция должна одновременно подвергать стрессу обе стороны: скачок убытков с одной стороны и синхронное обесценение поддерживающих активов, усложняющее их продажу, с другой. Если в момент крупной катастрофы капитал тоже уменьшается, страховой пул нельзя рассчитывать исходя исключительно из средних убытков.

Кто проводит стресс-тестирование самого стресс-тестера?

Симулятор может обладать внутренней логической согласованностью, но прийти к абсолютно неверным выводам. Запуск миллиона прогонов с нереалистичными параметрами ликвидаторов — это просто многократное повторение одной и той же ошибки. Дополнительные прогоны уменьшают ошибку выборки, но не сокращают автоматически ошибку самого моделирования.

Доверенная лаборатория выполняет четыре действия: анализирует известные инциденты, проверяет выводы на данных вне выборки, сопоставляет модели, собранные разными командами независимо друг от друга, и корректирует допущения относительно поведения участников. Снимки состояния, случайные зерна и логи запусков должны сохраняться для возможности воспроизведения ключевых находок. Постоянно возникает вопрос: нашёл ИИ слабость протокола или баг собственного симулятора?

Ни один тест не способен доказать полное выявление всех путей катастроф. Именно из-за наличия неизвестных зависимостей и ранее не встречавшегося поведения необходимы буфер капитала, исключения из покрытия и сдержанность в андеррайтинге.

Границы контрактов также требуют четкого определения. Новые данные могут влиять на будущее ценообразование и емкость, но не должны превращать существующее покрытие в движущуюся мишень. В опубликованном фреймворке Firelight непрерывный мониторинг рисков и фиксированная ставка в течение периода покрытия обрабатываются отдельно. Непрерывное обучение и соблюдение обязательств совместимы; однако изменять обязательства после наступления опасности недопустимо.

Заключение: обучение до возникновения убытков

Большая ценность кроется во встроенном андеррайтинге в процесс разработки. Любые серьезные изменения в системе запускают соответствующие тесты; результаты тестирования влияют на решения о новом покрытии; реальные инциденты помогают улучшать следующую версию модели. Чем качественнее инженерная работа, тем больше это отражается на цене покрытия и его доступности.

Исторические выплаты — это исправление ошибок постфактум. Симуляция же позволяет Firelight заранее понять, как именно данная система может дать сбой.

Задача ИИ — расширить область поиска, доказательств — ограничить его выводы, а капитала — выполнить обязательства. Цель не в том, чтобы предсказать каждую катастрофу, а в том, чтобы, осознав, с чем предстоит столкнуться, направить капитал на покрытие тех потерь, которые неизбежны.