Пятичасовой сбой Pyth Network оставил DeFi без данных

У авиадиспетчеров есть поговорка: когда радар выходит из строя, самолёты не сажают — их держат в зоне ожидания. DeFi такой роскоши лишён. Когда оракул отключается, самолёты продолжают лететь: ликвидации срабатывают, кредитные рынки оценивают залог по последнему числу, застрявшему в кэше. В четверг радар Pyth Network не работал более пяти часов — и небо стало очень оживлённым.

Что произошло

Pyth Network сообщил о серьёзном сбое в четверг, затронувшем как основные Price Feeds, так и Sponsored Feeds, — как сообщила Coinpedia. Инцидент продолжался более пяти часов. Сбой затронул два инфраструктурных уровня, знакомых большинству DeFi-разработчиков: Pythnet и Hermes. Именно они передают ценовые данные Pyth в реальном времени протоколам на нескольких блокчейнах.

В итоге Pyth заявил, что установил первопричину, а валидаторы координируют перезапуск с целью восстановить Core Feeds и Sponsored Feeds к 12:30 UTC. Страница статуса status.pyth.network обновлялась в реальном времени — это минимум, которого стоит ожидать от провайдера оракулов во время сбоя. После полного восстановления сервиса ожидается публикация подробного отчёта об инциденте.

Одновременно отказали два компонента. Price Feeds — основной слой данных оракула, который протоколы используют для ценообразования активов в реальном времени, и Sponsored Feeds — вспомогательная инфраструктура для отдельных интеграций. Всё, что было к ним подключено: исполнение сделок, расчёт залогов, триггеры ликвидаций — работало без надёжного ценового ориентира на протяжении всего окна сбоя.

И это произошло не в изоляции. Polymarket, крупнейший в мире рынок прогнозов, в тот же день подвергся активному эксплойту: из его контракта UMA CTF Adapter на Polygon было выведено более $660 000. Два несвязанных инцидента — один неудачный день для всей отрасли.

Техническая анатомия сбоя

Чтобы понять, почему пятичасовой простой — это серьёзно, нужно разобраться, что такое Pythnet. Pythnet — это специализированный appchain, который агрегирует ценовые данные от бирж и маркет-мейкеров, обрабатывает их через логику агрегации Pyth и формирует подписанные обновления цен. Hermes — офчейн-веб-сервис, позволяющий потребителям получать эти подписанные обновления и публиковать их в нужной целевой сети: будь то Solana, EVM-роллап или что-то более экзотическое. Если один из компонентов останавливается, вся модель pull-оракула останавливается вместе с ним.

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

Любой, кто писал адаптер для оракула, знает скучную часть: параметр maxAge. Установите слишком жёсткое ограничение — и протокол остановится, как только фиды замедлятся. Установите слишком мягкое — и вы будете принимать цены из совершенно другого рыночного режима. При пятичасовом сбое на волатильном активе ни один из вариантов не является комфортным. Интеграции на стороне Solana особенно сильно зависят от Pyth, учитывая происхождение этого оракула в данной сети (документация Solana объясняет, как on-chain аккаунты кэшируют данные оракула).

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

Кто пострадал

В наибольшей опасности оказались команды, чьи автоматизированные системы воспринимают оракул как утилиту — вроде электричества, — а не как зависимость с собственным SLA. В первую очередь это площадки для торговли бессрочными контрактами, которые рассчитывают позиции и запускают ликвидации по ценам Pyth. Если протокол приостановил новые ликвидации во время сбоя — хорошо. Если же они продолжали срабатывать по устаревшим ценам, пусть и ненадолго, жалобы пользователей поступят на следующей неделе.

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

Третий уровень — структурированные продукты, опционные хранилища и всё, что занимается автоматической ребалансировкой. Такие системы, как правило, работают на keeper-скриптах, которые не умеют корректно отступить при отсутствии цен. Они либо падают с ошибкой — что приемлемо, — либо тихо накапливают перекос, и вот тут-то всё и рушится.

Отдельно стоит Polymarket, у которого был свой неудачный день по совершенно иным причинам: более $660 000 было потеряно из-за эксплойта UMA CTF Adapter на Polygon. Два события технически не связаны между собой. Однако сбой оракула и эксплойт рынка прогнозов, попавшие в один новостной цикл, подчёркивают то, что отрасль продолжает игнорировать: инфраструктура DeFi хрупка так, как маркетинговые презентации не признают.

Руководство для разработчиков DeFi

Три вещи, которые нужно сделать на этой неделе, если вы пишете код, работающий с ценовым оракулом.

Первое — проверьте staleness-проверки. Откройте адаптерный контракт, найдите параметр maxAge или его эквивалент и задайтесь вопросом: имело ли это значение смысл на спокойном рынке и имеет ли оно смысл теперь, когда базовый оракул может уснуть на пять часов. Задокументируйте ответ. Если режим отказа вашего протокола при сбое оракула — «продолжать работу по последней известной цене», это архитектурное решение, а не умолчание, и оно должно быть одобрено тем, кто несёт за него ответственность.

Второе — создайте резервный путь. Мульти-оракульные схемы непопулярны, потому что операционно неудобны, однако стоимость интеграции вторичного фида и разумного правила согласования значительно ниже стоимости одного каскада плохих ликвидаций. Chainlink, Redstone, API3 — какой бы ни был второй источник, напишите адаптер сейчас, пока ничего не горит.

Третье — относитесь к странице статуса оракула как к производственной зависимости. Подпишите Slack или PagerDuty на status.pyth.network и аналогичные ресурсы. Если ваш протокол способен приостановить принятие новых рисков в течение нескольких минут после деградации оракула — вы уже выиграли. Большинство команд узнают о проблемах из Twitter, а это слишком поздно. Разработчики, ориентированные на стандарты, могут также обратиться к документации Ethereum — там описаны паттерны circuit breaker и pausable-контрактов, которые делают такую плавную деградацию возможной.

Возвращаясь к метафоре диспетчерской: контролёров не наказывают за меньшее число посадок во время сбоя — их наказывают за то, что они притворяются, будто видят, когда не видят. Серьёзными выйдут из этой ситуации те протоколы, которые приостановили работу, опубликовали чёткое уведомление о статусе и возобновили её осознанно. А те, кто тихо проглотил пять часов ценовой неразберихи в надежде, что никто не проверит цифры, — за ними стоит понаблюдать.

Ключевые выводы

• Уровни Pythnet и Hermes компании Pyth Network не работали более пяти часов, выведя из строя как Core Price Feeds, так и Sponsored Feeds.
• Валидаторам пришлось координировать перезапуск; целевое время восстановления — 12:30 UTC, полный отчёт об инциденте ещё не опубликован.
• Polymarket потерял более $660 000 в результате отдельного эксплойта UMA CTF Adapter на Polygon в тот же день, что подчёркивает узость запасов прочности в DeFi.
• Pull-оракулы отказывают иначе, чем push-оракулы, а параметр maxAge — это граница между безопасной паузой и опасным устареванием данных.
• Защищённая позиция для команд протоколов — мультиоракульный fallback плюс автоматическая пауза, привязанная к страницам статуса провайдеров, а не мониторинг Twitter.