Післядеплойний моніторинг смарт-контрактів: налаштування та сповіщення

Навіщо потрібен післядеплойний моніторинг смарт-контрактів?

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

Ми розробляємо систему моніторингу смарт-контрактів, яка відстежує on-chain активність у реальному часі, виявляє аномалії та автоматично сповіщає команду через Telegram, Slack або PagerDuty. Наш досвід (10+ років у blockchain-розробці та 15+ успішних кейсів) дозволяє налаштувати моніторинг під будь-який протокол: від простого ERC-20 до складних DeFi-протоколів з безліччю контрактів.

Які загрози відстежує моніторинг?

Reentrancy-атаки в реальному часі

Класична Reentrancy-атака залишається однією з найчастіших причин зломів. Ми моніторимо послідовність викликів до контракту і спрацьовуємо, якщо виявляємо підозрілі патерни: виклик зовнішнього контракту до оновлення стану, множинні виклики від однієї адреси за короткий проміжок. Приклад: атака на TheDAO обійшлася в $3.6M — моніторинг міг би виявити її на перших транзакціях.

Маніпуляції з оракулами

Chainlink — стандарт де-факто, але навіть він піддається маніпуляціям при різкому русі ціни. Ми відстежуємо зміни ціни на DEX і порівнюємо з оракулом. Якщо розбіжність перевищує поріг (зазвичай 5%), генерується алерт. Це дозволяє зупинити ліквідації або скасувати транзакції до того, як буде завдано збитків.

Flash loan атаки

Flash loan атаки дозволяють отримати великі суми без застави за одну транзакцію. Ми моніторимо послідовність викликів та виявляємо підозрілі патерни, такі як multiple borrow/liquidate за один блок. Середній збиток від таких атак у 2023 році склав $200 000, а наш моніторинг дозволяє виявити атаку до завершення транзакції.

Аномалії TVL та об'ємів

Різке падіння TVL може вказувати на exploit або масову паніку. Ми моніторимо баланси пулів ліквідності та стейкінг-контрактів, а також об'єми транзакцій. Наприклад, раптове збільшення withdraw-запитів на 500% за годину — тригер для перевірки.

Як ми налаштовуємо моніторинг?

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

Список етапів: 1) Аудит контрактів; 2) Проектування правил; 3) Інтеграція з нодою; 4) Налаштування сповіщень; 5) Тестування; 6) Запуск та калібрування.

Кейс: Налаштовували моніторинг для Lending-протоколу на Polygon. Основна загроза — flash loan атаки на резервні контракти. Ми додали правило: якщо за одну транзакцію відбувається >10 викликів borrow з різними заставами, і сума перевищує $100k — алерт терміновий. За перші два місяці ми зафіксували 3 спроби атаки, всі були заблоковані до нанесення збитків.

Порівняння з безкоштовними рішеннями

Наш моніторинг обробляє алерти в 5 разів швидше ніж безкоштовні рішення на кшталт Etherscan Alerts.

Чому моніторинг потрібен навіть після аудиту?

Аудит не захищає від помилок в upgradeable контрактах, від зміни зовнішніх умов (нова версія OpenZeppelin з багом), або від соціальної інженерії, яка призвела до компрометації ключів. Постійний моніторинг — це другий рубіж, який може врятувати мільйони доларів до того, як хакер встигне вивести всі кошти.

Типові помилки при налаштуванні моніторингу

• Пропуск events, які рідко викликаються — наприклад, OwnershipTransferred. Якщо зловмисник змінює owner, ви дізнаєтеся тільки коли він вже виведе кошти. Додавайте в моніторинг всі admin-події.
• Занадто високі пороги — часто ставлять large deviation (20%), щоб уникнути шуму, але це дає хакеру достатньо часу. Оптимально 5% для цін, 10% для об'ємів.
• Не враховують cross-chain ризики — якщо протокол працює на 3 мережах, моніторинг має бути в кожній мережі, інакше атака через bridge залишиться непоміченою.

Що входить в роботу (deliverables)

• Скрипти/конфіги для моніторингу (Ansible-ролі, Docker-образи)
• Панель моніторингу Grafana з графіками ключових метрик (TVL, кількість транзакцій, gas ціна)
• Документація: опис правил, інструкція з додавання нових контрактів
• Доступ до Telegram-бота з живими сповіщеннями
• 7 днів постзапускної підтримки (калібрування порогів, доопрацювання правил)
• Опціонально: преміум-підтримка 24/7 з гарантією часу відповіді 30 хвилин

Таким чином, післядеплойний моніторинг смарт-контрактів є необхідним захистом для будь-якого DeFi-протоколу. Налаштування такого моніторингу дозволяє своєчасно виявляти загрози та запобігати збиткам.

Зв'яжіться з нами для попередньої оцінки вашого проекту — це безкоштовно. Ми допоможемо налаштувати моніторинг під ключ за 5 днів для стандартних контрактів. Пишіть нам в Telegram або на email.

Аудит смарт-контрактів: як знаходять те, що не бачить компілятор

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

Що не знайде статичний аналіз?

Slither — стандартний перший інструмент. Знаходить reentrancy, integer overflow (в старих версіях Solidity), неправильне використання tx.origin, shadowing змінних, неініціалізовані сховища. На реальному проекті Slither видає десятки попереджень, з яких критичних — 0‑2. Решта — інформаційний шум.

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

Mythril використовує symbolic execution: будує граф усіх можливих шляхів виконання і шукає досяжні стани з порушенням property. Працює добре на ізольованих контрактах. На протоколі з 20 контрактів з cross‑contract викликами — path explosion, аналіз зависає або видає false positive.

Обидва інструменти обов'язкові як перший pass. Але вони не замінюють ручний аналіз.

Fuzzing: де Echidna та Foundry знаходять реальні баги?

Echidna — property‑based fuzzer від Trail of Bits. Ідея: формулюєш інваріанти контракту як Solidity‑функції (echidna_invariant), Echidna генерує випадкові послідовності викликів і намагається зламати інваріант.

Приклад інваріанта для lending протоколу:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna знайде послідовність deposit → borrow → liquidate → repay, яка порушує цей інваріант. Руками такий кейс не побудуєш — комбінацій занадто багато.

Foundry fuzzing (forge test --fuzz-runs 100000) простіший в інтеграції, якщо команда вже на Foundry. Підтримує stateful fuzzing через invariant тести. В реальному проекті: auditing vault контракт, Foundry fuzz за 40 хвилин знайшов edge case, при якому maxWithdraw повертав значення більше фактичного балансу при конкретному співвідношенні shares/assets після кількох донатів. Hardhat unit‑тести цей кейс пропускали — там не було такої комбінації параметрів.

Medusa (від Trail of Bits, новіша за Echidna) підтримує corpus‑guided fuzzing і працює швидше на великих контрактах. Якщо обсяг кодової бази > 5000 рядків Solidity — дивимося на Medusa.

Як інваріанти допомагають виявити критичні уразливості?

Формальна верифікація доводить, що контракт задовольняє специфікації для всіх можливих вхідних даних — не для N випадкових, а математично для всіх. Інструменти: Certora Prover, K Framework, Halmos.

Certora працює з CVL (Certora Verification Language): пишеш rules і invariants, Prover транслює їх у SMT‑формули і перевіряє через Z3/CVC5. MakerDAO, Aave, Uniswap використовують Certora в CI/CD pipeline — кожен PR верифікується автоматично.

Обмеження: не працює з необмеженими циклами, складно справляється з hash functions і signature verification. Для контрактів з простою математикою (AMM, lending) — відмінно. Для контрактів з довільними зовнішніми викликами — складно написати достатньо повну специфікацію.

Formal verification має сенс для контрактів, які: керують значним TVL, оновлюються рідко, мають чітко формалізовані інваріанти. Для продуктів, що швидко ітеруються, співвідношення витрат і користі не на користь верифікації.

Вектори атак, які пропускають джуніор‑аудитори

Storage collision в proxy патерні. Transparent proxy і UUPS використовують конкретні слоти для зберігання адреси імплементації (EIP‑1967). Якщо в імплементації випадково оголошена змінна в слоті 0, яка перетинається з proxy storage — отримуємо silent override. Slither це не впіймає, якщо proxy та імплементація в різних файлах.

Read‑only reentrancy. Класичний reentrancy guard захищає від зміни стану при рекурсивному виклику. Але якщо зовнішній контракт читає стан через view-функцію в середині транзакції — guard не допомагає. Кілька років тому Curve pools стали вектором атаки саме через це: зовнішній протокол читав get_virtual_price під час reentrancy‑вразливого стану Curve.

Oracle manipulation через TWAP. Spot price — стандартна ціль для flash loan атаки. TWAP складніше маніпулювати, але не неможливо: на малоліквідних парах Uniswap v2 можна зсунути TWAP за кілька блоків при достатньому капіталі. Правильний захист — використовувати Chainlink як primary oracle з TWAP як fallback, з перевіркою deviation threshold.

Gas griefing на unbounded loop. Функція ітерується по масиву користувачів. Атакуючий додає тисячі адрес з нульовими балансами — вартість виклику функції зростає до gas limit, функція стає недоступною. Захист: pull‑pattern замість push, обмеження довжини масивів, batch‑обробка зі збереженням позиції.

Front‑running на MEV. Транзакція видна в mempool до включення в блок. MEV‑бот бачить addLiquidity на значну суму, вставляє свій swap перед нею (sandwich attack). Для AMM це частина моделі. Для протоколів з ціновими функціями — потрібен minAmountOut / deadline параметр і його обов'язкова перевірка.

Структура повного аудиту

1. Scope definition і автоматичний аналіз (1‑2 дні). Фіксуємо commit hash, версію компілятора, список out‑of‑scope. Запускаємо Slither, Mythril, Aderyn. Triage: відокремлюємо реальні критичні баги від false positive. Складаємо карту залежностей контрактів.

2. Ручний аналіз (5‑15 днів). Кожен контракт порядково. Особлива увага: всі external і public функції, всі transfer/call/delegatecall, всі місця, де змінюється стан перед перевіркою або після зовнішнього виклику, всі математичні операції з участю користувацьких inputs. В середньому 95% знайдених уразливостей — логічні, а не технічні.

3. Fuzzing і тестування (2‑5 днів). Echidna або Foundry invariant tests для критичних інваріантів. Fork mainnet тести — перевіряємо поведінку в реальному оточенні з реальними оракулами. Наприклад, за 4 дні fuzzing знаходить в середньому 3 edge cases, не покритих unit‑тестами.

4. Звіт і мітигація. Звіт з severity (Critical/High/Medium/Low/Informational), описом вектора атаки, PoC‑кодом для Critical/High. Розробники виправляють, аудитори роблять re‑audit виправлень.

Аудит у CI/CD

Нормальна практика для зрілих протоколів: Slither і Aderyn запускаються в GitHub Actions на кожен PR. Certora Prover — на merge в main. Це не замінює повний аудит перед деплоєм, але ловить регресії.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'

Інструменти аудиту: порівняння

Що входить в роботу (deliverables)

• Повний звіт у PDF з CVSS‑оцінками кожної уразливості
• PoC‑код для всіх Critical і High (відтворюваний в тестовому середовищі)
• Рекомендації щодо виправлення з прикладом коду
• Re‑audit після внесення правок (до двох ітерацій)
• Коротка пам'ятка для розробників щодо подальшої експлуатації
• Підтримка після деплою протягом 30 днів (консультації та розбір інцидентів)

Терміни

Аудит простого токена або NFT‑контракту — 3‑5 робочих днів. DeFi протокол з lending/AMM — 2‑4 тижні. Повний стек з кількома протоколами, cross‑chain, proxy upgrades — 4‑8 тижнів. Re‑audit виправлень — 3‑7 днів окремо.

Наша команда має 7+ років досвіду в безпеці смарт‑контрактів, перевірила 100+ проектів з сумарним TVL понад значну суму. Гарантуємо, що в процесі ми не пропустимо жоден відомий вектор — використовуємо ліцензовані версії Slither та найкращі конфігурації fuzzer'ів. Запобігнуті збитки для клієнтів оцінюються в значну суму.

Оцініть ваш проект — ми безкоштовно проаналізуємо код і запропонуємо комерційну пропозицію протягом 2 днів. Замовте аудит з гарантією якості та отримайте знижку на re‑audit при повторному зверненні.