Мониторинг DeFi: где протокол теряет средства за секунды
Контроль над пулом теряется не постепенно, а в пределах одной транзакции: выводится ликвидность, смещается цена оракула, и к закрытию блока откатывать уже нечего. Наблюдаемость с задержкой в минуты означает не «узнаем чуть позже», а гарантированно упущенное окно реакции.
Большинство аномалий транзакций по отдельности выглядят безобидно: необычная последовательность вызовов, адрес-получатель, впервые появившийся в контракте, размер операции, вдвое превышающий исторический максимум для этого кошелька. Поодиночке это шум, вместе — профиль готовящегося эксплойта смарт-контракта, который правила по одному порогу не отлавливают.
Эксплойт смарт-контракта редко означает ошибку в коде. Чаще разрешённая функция вызывается в неверном порядке и на заранее подготовленном состоянии пула — отсюда класс отказа: потеря ликвидности за один блок, без отката и без времени на реакцию, потому что транзакция необратима по определению.
Поэтому обнаружение в реальном времени строится не на списках подозрительных адресов, а на отклонении от поведенческого профиля: базовой линии объёмов, типовых цепочек вызовов и скорости изменения резервов. Сигнал обязан появиться раньше подтверждения блока — иначе мониторинг DeFi фиксирует не атаку, а её последствия.
Что даёт непрерывный контроль транзакций и ликвидности
Непрерывный контроль транзакций — это не выгрузка логов по расписанию, а потоковая обработка каждого вызова к контрактам пула. Инженер видит, кто инициировал операцию, как изменились резервы и курс оракула, укладывается ли поведение адреса в профиль обычного пользователя. Отклонение от профиля фиксируется в момент операции, а не на следующий день в отчёте.
Скорость реакции определяется точкой обнаружения. Если аномалию искать по итогам блока, ликвидность уже выведена; если в момент появления транзакции — между сигналом и вмешательством проходят секунды. На этом интервале работают автоматические политики: приостановка конкретной функции, лимит на вывод, эскалация инженеру.
Так закрывается целый класс отказов, который не ловится статичными проверками: серия мелких свопов, выкачивающая пул, либо разовая манипуляция ценой оракула. Пример — пулы Uniswap, где корректная на вид транзакция вытягивает резерв за один вызов. Правило на такое поведение срабатывает раньше, чем человек успевает открыть панель мониторинга.
Для защиты ликвидности важна не только реакция, но и наблюдаемость протокола: доля перехваченных аномалий, время от сигнала до паузы, поведение пула под резкими движениями. Эти метрики видны непрерывно, поэтому решение об остановке принимается по данным, а не по интуиции.
Режимы мониторинга DeFi: сравнение и ограничения
Режимы мониторинга DeFi различаются не инструментами, а логикой принятия решения: что считать отклонением и когда поднимать тревогу. Пороговые правила срабатывают на заданных границах — резкий отток ликвидности, всплеск транзакций к контракту, сдвиг соотношения резервов. Модели аномалий строят профиль обычной активности пула и отмечают то, что из него выбивается, даже если формально ни один порог не пройден.
Гибридная схема держит оба контура: правила дают мгновенную реакцию и понятную причину срабатывания, модель закрывает сценарии, под которые правило заранее не написали.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Пороговые правила | Предсказуемый пул, нужна реакция за секунды и однозначный разбор инцидента | Не видит медленных многошаговых атак, порог приходится пересматривать при росте объёма |
| Модели аномалий | Молодые пулы, где статистика ещё не устоялась | Много ложных срабатываний на старте, нужна разметка подтверждённых инцидентов |
| Гибридная схема | Протокол с реальными активами и дежурной сменой | Сложнее в сопровождении: контуры нужно согласовывать по приоритетам и порогам |
Что определяет выбор
Ключевая метрика — отношение подтверждённых срабатываний к ложным. Смена, которая разбирает десятки пустых тревог за ночь, перестаёт реагировать на реальную, поэтому режим подбирают под профиль протокола, а не по принципу «чем сложнее, тем лучше».
Как мы разворачиваем обнаружение эксплойтов: этапы работ
Работы идут от инвентаризации до передачи дежурной смене, и почти всё время уходит не на код, а на уточнение того, какие события считаются аномалией для конкретного протокола. На входе нужны адреса контрактов, доступ к узлу или провайдеру событий и тестовая среда, где гипотезы воспроизводятся безопасно. Ниже — этапы внедрения мониторинга DeFi-протокола.
- Собираем инвентарь: адреса контрактов и прокси, список пулов, роли администраторов. Без этого правила срабатывают не там, где реально двигаются средства.
- Аудит контрактов и их окружения — читаем привилегированные функции, внешние вызовы, зависимость от оракулов. Ищем пути, где один вызов меняет состояние протокола целиком.
- Карта рисков: расставляем классы событий по приоритету — вывод ликвидности, резкая смена параметров, аномальные серии операций. Приоритет решает, что дежурит в реальном времени, а что уходит в суточную сводку.
- Настройка правил — пороги, окна агрегации, привязка к адресам и ролям. Здесь важнее подавление шума: правило, срабатывающее сотни раз в сутки, обесценивает дежурство.
- Проверка на исторических данных: прогоняем правила по прошлым событиям сети и сверяем с известными инцидентами. Считаем долю пропусков и ложных срабатываний, подкручиваем пороги.
- Передача дежурной смене: конфигурации, схемы потоков, инструкция «что делать при срабатывании» — вплоть до остановки функций и вывода средств.
- Сопровождение: пересматриваем правила при обновлении контрактов, смене окружения и появлении новых пулов.
Что передаём на руки: правила, схемы и регламенты
Мониторинг перестаёт быть чёрным ящиком только тогда, когда вместе с работающим сервисом вы получаете артефакты, по которым его можно эксплуатировать и развивать без нас. Что именно фиксируется в настройках и документации к моменту сдачи:
- Набор правил обнаружения — логика, по которой событие считается аномалией: вывод средств из пула, резкое расхождение с оракулом, вызов административных функций контракта. С порогами, перечнем игнорируемых ситуаций и порядком донастройки без правки кода.
- Схема потоков данных — путь от узла сети и индексатора до оповещения: где данные нормализуются, где хранятся, какие точки отказа есть и как каждая деградация выглядит на дашборде.
- Матрица доступа — роли в системе, кому доступны ключи и административные действия, как отзывается доступ при смене сотрудника и кто имеет право остановить контракт.
- Регламент реагирования — уровни серьёзности, целевое время реакции на каждый, порядок эскалации и правило одного голоса при решении о паузе.
- Документация системы — развёртывание с нуля, добавление нового правила, откат неудачного обновления, список проверок после сбоя.
- Регламент дежурства — график, кому уходит ночной сигнал, передача смены, журнал инцидентов и разбор ложных срабатываний.
- Передача решения — репозитории и инфраструктура на ваших аккаунтах, обучение команды, период совместного дежурства и критерии приёмки.
Такой пакет позволяет вести систему своими силами, а нас подключать точечно — на новые типы атак и пересмотр правил.
Кейс: ночная атака на пул и остановка вывода средств
До внедрения мониторинга пул контролировался пороговыми оповещениями по размеру транзакции и ручным обзором раз в сутки. Ночная атака на пул Aave шла серией небольших вызовов: каждая транзакция по отдельности выглядела обычной, пороги молчали, и к утру часть ликвидности уже ушла, а разбор шёл по логам постфактум.
Система, которую настроили наши инженеры, строит профиль типового поведения контрактов и следит за отклонениями в структуре вызовов: незнакомый адрес, всплеск частоты обращений к пулу, рост доли выводов в коротком окне, расхождение с привычным соотношением залога и займа. Сигнал формируется по совокупности признаков, а не по одному порогу, поэтому сработка пришла на второй минуте серии — до опустошения пула.
Обработка срабатывания тоже автоматизирована: сценарий ставит выводы по пулу на паузу, поднимает дежурного инженера и собирает хронологию вызовов для разбора. Атаку остановили ночью, без ручного подтверждения каждого шага.
Метрики до и после
| Метрика | До | После |
|---|---|---|
| Время обнаружения | утренний обзор, часы | секунды от начала серии |
| Обработка срабатывания | ручное подтверждение после разбора | пауза выводов по пулу автоматически |
| Материалы по инциденту | выгрузка логов вручную | готовая хронология вызовов и условий срабатывания |
Чем потоковый контроль отличается от разового аудита?
Разовый аудит — снимок контракта на конкретный момент: проверяющий разбирает логику, права доступа, арифметику и внешние вызовы, отчёт фиксирует найденные классы уязвимостей. Сила подхода в глубине — на срезе видно то, что не ловится наблюдением, например ошибку в экономической модели. Слабость в привязке ко времени: после обновления через прокси или смены ролей администратора отчёт описывает уже не тот контракт, что работает в сети.
Потоковый контроль устроен иначе: он не читает код, а следит за поведением — событиями, изменением балансов пулов, долей залогов, всплесками выводов, займами с распродажей в одной транзакции. Forta и похожие сети наблюдения показывают, как из потока событий строятся правила с порогами отклонения от базовой линии. Срабатывание занимает секунды — этого хватает, чтобы приостановить контракт до завершения атаки.
Сравнение подходов: аудит отвечает на вопрос «есть ли ошибка в логике», потоковый контроль — «не происходит ли нетипичное прямо сейчас». Первый даёт глубину на одном срезе, второй — покрытие по времени и по числу адресов под наблюдением.
Остаточный риск сохраняется в обоих случаях. Аудит не покрывает манипуляции с ценой и реакцию протокола на обвал рынка, наблюдение — медленный вывод средств через легитимные функции. Поэтому подходы сочетают: проверка перед запуском, повторные проверки после каждого обновления и постоянный потоковый контроль. Тогда окно между появлением уязвимости и реакцией измеряется минутами.
Частые технические сомнения перед запуском контроля
Живой контроль над протоколом вызывает у инженерных команд предсказуемый набор вопросов: не получите ли вы доступ к нашим средствам, не утонете ли мы в сигналах, что делать с тем, что уже развёрнуто в сети. Ниже — короткие ответы на те, что задают чаще всего.
Нужен ли вам доступ к приватным ключам и адресу казны?
Нет. Наблюдение идёт по публичным данным: состояние контрактов, события, очередь неподтверждённых транзакций. Подпись и вывод средств остаются у вашей команды — мы видим только то, что и так открыто в сети.
Как вы гасите ложные срабатывания?
Правило срабатывает не на одиночном событии, а на связке признаков: аномальный вывод, смена владельца, резкий рост заимствований в коротком окне. Порог калибруем на вашей истории, поэтому поток сигналов сжимается до единиц в сутки, а не сотен.
Что делать с контрактами, которые уже развёрнуты и неизменяемы?
Контроль строится поверх внешнего наблюдения и не требует правок в развёрнутом коде. Для новых версий, где обновление доступно, дополнительно добавляем проверки на этапе сборки и развёртывания.
Какой будет нагрузка на наши узлы?
В пределах обычного чтения сети: запросы состояния и событий из нескольких независимых источников. Свой узел держать не обязательно, но при необходимости подключаем и его — с резервным каналом доступа.
Как обновляются правила, если протокол меняется?
Изменения в контрактах и токеномике отслеживаются, после чего правила правятся и прогоняются на исторических данных перед включением в рабочий контур. Обновление занимает дни, а не недели.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка опиралась на факты, а не на предположения, к первому разговору достаточно приложить то, что уже есть: адреса контрактов и сети, схему движения средств между пулами, роли и права администраторов, экспорт логов и текущие правила оповещений. Если часть данных закрыта — разберём и это: часто узкое место не в самих правилах обнаружения, а в том, что сигнал приходит позже, чем транзакция попадает в блок.
В обсуждении задачи снимаем главные развилки:
- какие вызовы и события покрываем правилами обнаружения, а какие осознанно оставляем вне контроля;
- где проходит граница между аномалией и ложным срабатыванием при текущих порогах;
- как связать сигнал с действием — паузой контракта, выводом ликвидности или вызовом дежурного;
- какие данные нужны для разбора инцидента: архив истории транзакций, состояние пулов на момент срабатывания;
- кто на стороне заказчика принимает решение и по каким каналам идёт оповещение;
- как проверяем систему до старта проекта: сценарии на тестовой копии сети с имитацией атаки.
Дальше возвращаемся с планом работ: состав работ по этапам, оценка сроков с запасом на интеграцию, точки, где нужно участие вашей команды, и порядок вывода правил в рабочую среду. Опишите задачу и пришлите доступные материалы — вернёмся с оценкой и планом, а старт проекта начнём с согласованного состава и приоритетов.
