Моніторинг DeFi: де протокол втрачає кошти за секунди
Контроль над пулом втрачається не поступово, а в межах однієї транзакції: виводиться ліквідність, зміщується ціна оракула, і до закриття блоку відкатувати вже нічого.
Спостережуваність із затримкою в хвилини означає не «дізнаємося трохи пізніше», а гарантовано пропущене вікно реакції.
Більшість аномалій транзакцій окремо виглядають нешкідливо: незвична послідовність викликів, адреса-отримувач, що вперше з'явився в контракті, розмір операції, удвічі більший за історичний максимум для цього гаманця.
Поодинці це шум, разом — профіль підготовлюваного експлойту смарт-контракту, який правила за одним порогом не відловлюють.
Експлойт смарт-контракту рідко означає помилку в коді.
Частіше дозволена функція викликається в неправильному порядку й на заздалегідь підготовленому стані пулу — звідси клас відмови: втрата ліквідності за один блок, без відкату й без часу на реакцію, бо транзакція незворотна за визначенням.
Тому виявлення в реальному часі будується не на списках підозрілих адрес, а на відхиленні від поведінкового профілю: базової лінії обсягів, типових ланцюжків викликів і швидкості зміни резервів.
Сигнал зобов'язаний з'явитися раніше за підтвердження блоку — інакше моніторинг DeFi фіксує не атаку, а її наслідки.
Що дає безперервний контроль транзакцій і ліквідності
Безперервний контроль транзакцій — це не вивантаження логів за розкладом, а потокова обробка кожного виклику до контрактів пулу. Інженер бачить, хто ініціював операцію, як змінилися резерви й курс оракула, чи вписується поведінка адреси в профіль звичайного користувача. Відхилення від профілю фіксується в момент операції, а не наступного дня у звіті.
Швидкість реакції визначається точкою виявлення. Якщо аномалію шукати за підсумками блоку, ліквідність уже виведена; якщо в момент появи транзакції — між сигналом і втручанням минають секунди.
На цьому інтервалі працюють автоматичні політики: призупинення конкретної функції, ліміт на виведення, ескалація інженеру.
Так закривається цілий клас відмов, який не ловиться статичними перевірками: серія дрібних свопів, що викачує пул, або одноразова маніпуляція ціною оракула. Приклад — пули Uniswap, де коректна на вигляд транзакція витягує резерв за один виклик. Правило на таку поведінку спрацьовує раніше, ніж людина встигає відкрити панель моніторингу.
Для захисту ліквідності важлива не лише реакція, а й спостережуваність протоколу: частка перехоплених аномалій, час від сигналу до паузи, поведінка пулу під різкими рухами. Ці метрики видно безперервно, тому рішення про зупинку ухвалюється за даними, а не за інтуїцією.
Режими моніторингу DeFi: порівняння та обмеження
Режими моніторингу DeFi розрізняються не інструментами, а логікою ухвалення рішення: що вважати відхиленням і коли піднімати тривогу. Порогові правила спрацьовують на заданих межах — різкий відтік ліквідності, сплеск транзакцій до контракту, зсув співвідношення резервів.
Моделі аномалій будують профіль звичайної активності пулу й позначають те, що з нього вибивається, навіть якщо формально жоден поріг не пройдено.
Гібридна схема тримає обидва контури: правила дають миттєву реакцію та зрозумілу причину спрацювання, модель закриває сценарії, під які правило заздалегідь не написали.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Порогові правила | Передбачуваний пул, потрібна реакція за секунди й однозначний розбір інциденту | Не бачить повільних багатокрокових атак, поріг доводиться переглядати при зростанні обсягу |
| Моделі аномалій | Молоді пули, де статистика ще не стабілізувалася | Багато хибних спрацювань на старті, потрібна розмітка підтверджених інцидентів |
| Гібридна схема | Протокол із реальними активами та черговою зміною | Складніше в супроводі: контури потрібно узгоджувати за пріоритетами та порогами |
Що визначає вибір
Ключова метрика — відношення підтверджених спрацювань до хибних. Зміна, яка розбирає десятки порожніх тривог за ніч, перестає реагувати на реальну, тому режим добирають під профіль протоколу, а не за принципом «що складніше, то краще».
Як ми розгортаємо виявлення експлойтів: етапи робіт
Роботи йдуть від інвентаризації до передачі черговій зміні, і майже весь час іде не на код, а на уточнення того, які події вважаються аномалією для конкретного протоколу.
На вході потрібні адреси контрактів, доступ до вузла або провайдера подій і тестове середовище, де гіпотези відтворюються безпечно. Нижче — етапи впровадження моніторингу DeFi-протоколу.
- Збираємо інвентар: адреси контрактів і проксі, список пулів, ролі адміністраторів. Без цього правила спрацьовують не там, де реально рухаються кошти.
- Аудит контрактів та їхнього оточення — читаємо привілейовані функції, зовнішні виклики, залежність від оракулів. Шукаємо шляхи, де один виклик змінює стан протоколу цілком.
- Карта ризиків: розставляємо класи подій за пріоритетом — виведення ліквідності, різка зміна параметрів, аномальні серії операцій. Пріоритет вирішує, що чергує в реальному часі, а що йде в добове зведення.
- Налаштування правил — пороги, вікна агрегації, прив'язка до адрес і ролей. Тут важливіше придушення шуму: правило, що спрацьовує сотні разів на добу, знецінює чергування.
- Перевірка на історичних даних: проганяємо правила по минулих подіях мережі та звіряємо з відомими інцидентами. Рахуємо частку пропусків і хибних спрацювань, підкручуємо пороги.
- Передача черговій зміні: конфігурації, схеми потоків, інструкція «що робити при спрацюванні» — аж до зупинки функцій і виведення коштів.
- Супровід: переглядаємо правила при оновленні контрактів, зміні оточення та появі нових пулів.
Що передаємо на руки: правила, схеми та регламенти
Моніторинг перестає бути чорною скринькою лише тоді, коли разом із працюючим сервісом ви отримуєте артефакти, за якими його можна експлуатувати й розвивати без нас. Що саме фіксується в налаштуваннях і документації на момент здачі:
- Набір правил виявлення — логіка, за якою подія вважається аномалією: виведення коштів із пулу, різке розходження з оракулом, виклик адміністративних функцій контракту. З порогами, переліком ігнорованих ситуацій і порядком доналаштування без правки коду.
- Схема потоків даних — шлях від вузла мережі та індексатора до оповіщення: де дані нормалізуються, де зберігаються, які точки відмови є і як кожна деградація виглядає на дашборді.
- Матриця доступу — ролі в системі, кому доступні ключі та адміністративні дії, як відкликається доступ при зміні співробітника і хто має право зупинити контракт.
- Регламент реагування — рівні серйозності, цільовий час реакції на кожен, порядок ескалації та правило одного голосу при рішенні про паузу.
- Документація системи — розгортання з нуля, додавання нового правила, відкат невдалого оновлення, список перевірок після збою.
- Регламент чергування — графік, кому йде нічний сигнал, передача зміни, журнал інцидентів і розбір хибних спрацювань.
- Передача рішення — репозиторії та інфраструктура на ваших акаунтах, навчання команди, період спільного чергування та критерії приймання.
Такий пакет дозволяє вести систему своїми силами, а нас підключати точково — на нові типи атак і перегляд правил.
Кейс: нічна атака на пул і зупинка виведення коштів
До впровадження моніторингу пул контролювався пороговими оповіщеннями за розміром транзакції та ручним оглядом раз на добу.
Нічна атака на пул Aave йшла серією невеликих викликів: кожна транзакція окремо виглядала звичайною, пороги мовчали, і до ранку частина ліквідності вже пішла, а розбір ішов за логами постфактум.
Система, яку налаштували наші інженери, будує профіль типової поведінки контрактів і стежить за відхиленнями в структурі викликів: незнайома адреса, сплеск частоти звернень до пулу, зростання частки виведень у короткому вікні, розходження зі звичним співвідношенням застави й позики.
Сигнал формується за сукупністю ознак, а не за одним порогом, тому спрацювання прийшло на другій хвилині серії — до спустошення пулу.
Обробка спрацювання теж автоматизована: сценарій ставить виведення по пулу на паузу, піднімає чергового інженера та збирає хронологію викликів для розбору. Атаку зупинили вночі, без ручного підтвердження кожного кроку.
Метрики до та після
| Метрика | До | Після |
|---|---|---|
| Час виявлення | ранковий огляд, години | секунди від початку серії |
| Обробка спрацювання | ручне підтвердження після розбору | пауза виведень по пулу автоматично |
| Матеріали щодо інциденту | вивантаження логів вручну | готова хронологія викликів і умов спрацювання |
Чим потоковий контроль відрізняється від разового аудиту?
Разовий аудит — знімок контракту на конкретний момент: перевіряльник розбирає логіку, права доступу, арифметику та зовнішні виклики, звіт фіксує знайдені класи вразливостей.
Сила підходу в глибині — на зрізі видно те, що не ловиться спостереженням, наприклад помилку в економічній моделі. Слабкість у прив'язці до часу: після оновлення через проксі або зміни ролей адміністратора звіт описує вже не той контракт, що працює в мережі.
Потоковий контроль влаштований інакше: він не читає код, а стежить за поведінкою — подіями, зміною балансів пулів, часток застав, сплесками виведень, позиками з розпродажем в одній транзакції.
Forta і схожі мережі спостереження показують, як із потоку подій будуються правила з порогами відхилення від базової лінії. Спрацювання займає секунди — цього достатньо, щоб призупинити контракт до завершення атаки.
Порівняння підходів: аудит відповідає на питання «чи є помилка в логіці», потоковий контроль — «чи не відбувається нетипове прямо зараз». Перший дає глибину на одному зрізі, другий — покриття за часом і за кількістю адрес під спостереженням.
Залишковий ризик зберігається в обох випадках. Аудит не покриває маніпуляції з ціною та реакцію протоколу на обвал ринку, спостереження — повільне виведення коштів через легітимні функції.
Тому підходи поєднують: перевірка перед запуском, повторні перевірки після кожного оновлення та постійний потоковий контроль. Тоді вікно між появою вразливості та реакцією вимірюється хвилинами.
Часті технічні сумніви перед запуском контролю
Живий контроль над протоколом викликає в інженерних команд передбачуваний набір питань: чи не отримаєте ви доступ до наших коштів, чи не потонете ми в сигналах, що робити з тим, що вже розгорнуто в мережі. Нижче — короткі відповіді на ті, що запитують найчастіше.
Чи потрібен вам доступ до приватних ключів і адреси казни?
Ні. Спостереження йде за публічними даними: стан контрактів, події, черга непідтверджених транзакцій. Підпис і виведення коштів залишаються у вашої команди — ми бачимо лише те, що й так відкрито в мережі.
Як ви гасите хибні спрацювання?
Правило спрацьовує не на одиночній події, а на зв'язці ознак: аномальне виведення, зміна власника, різке зростання запозичень у короткому вікні. Поріг калібруємо на вашій історії, тому потік сигналів стискається до одиниць на добу, а не сотень.
Що робити з контрактами, які вже розгорнуті й незмінні?
Контроль будується поверх зовнішнього спостереження і не потребує правок у розгорнутому коді. Для нових версій, де оновлення доступне, додатково додаємо перевірки на етапі збірки та розгортання.
Яким буде навантаження на наші вузли?
У межах звичайного читання мережі: запити стану та подій із кількох незалежних джерел. Свій вузол тримати не обов'язково, але за потреби підключаємо й його — з резервним каналом доступу.
Як оновлюються правила, якщо протокол змінюється?
Зміни в контрактах і токеноміці відстежуються, після чого правила правляться й проганяються на історичних даних перед включенням у робочий контур. Оновлення займає дні, а не тижні.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка спиралася на факти, а не на припущення, до першої розмови достатньо додати те, що вже є: адреси контрактів і мереж, схему руху коштів між пулами, ролі та права адміністраторів, експорт логів і поточні правила оповіщень.
Якщо частина даних закрита — розберемо й це: часто вузьке місце не в самих правилах виявлення, а в тому, що сигнал приходить пізніше, ніж транзакція потрапляє в блок.
В обговоренні задачі знімаємо головні розвилки:
- які виклики та події покриваємо правилами виявлення, а які свідомо залишаємо поза контролем;
- де проходить межа між аномалією та хибним спрацюванням при поточних порогах;
- як пов'язати сигнал із дією — паузою контракту, виведенням ліквідності або викликом чергового;
- які дані потрібні для розбору інциденту: архів історії транзакцій, стан пулів на момент спрацювання;
- хто на стороні замовника ухвалює рішення і якими каналами йде оповіщення;
- як перевіряємо систему до старту проєкту: сценарії на тестовій копії мережі з імітацією атаки.
Далі повертаємося з планом робіт: склад робіт за етапами, оцінка строків із запасом на інтеграцію, точки, де потрібна участь вашої команди, і порядок виведення правил у робоче середовище.
Опишіть задачу й надішліть доступні матеріали — повернемося з оцінкою та планом, а старт проєкту почнемо з узгодженого складу та пріоритетів.
