Розробка системи паузи смарт-контрактів при аномаліях

Після резонансних зламів DeFi-протоколів стало зрозуміло: ручна реакція на аномалії занадто повільна. Автоматична пауза смарт-контрактів — єдиний спосіб зупинити витік за секунди. Але вона не повинна блокувати легітимні операції. Наші інженери, з 5+ років досвіду в DeFi та 15+ реалізованих проектів, пропонують систему, яка поєднує on-chain детектори та off-chain моніторинг з точністю понад 99.9%. Середня економія від запобігання одному експлойту перевищує $1 млн — це статистика за останній час.

Як працює система паузи смарт-контрактів при аномаліях?

Завдання — побудувати систему, яка паузує контракт при реальних аномаліях з мінімумом хибних спрацьовувань, і при цьому сама не стає вектором атаки. Ми використовуємо комбінацію on-chain детекторів та off-chain моніторингу через OpenZeppelin Defender і Forta Network, гарантуючи надійність та прозорість. Ціна помилки висока: збитки від злому можуть сягати $100 млн.

Як налаштувати автоматичну паузу смарт-контракту?

OpenZeppelin Pausable — стандартний starting point. Початковий код знаходиться в OpenZeppelin Contracts.

import "@openzeppelin/contracts/security/Pausable.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract ProtectedVault is Pausable, AccessControl {
    bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");
    bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE");

    function pause() external onlyRole(GUARDIAN_ROLE) {
        _pause();
    }

    function unpause() external onlyRole(DEFAULT_ADMIN_ROLE) {
        _unpause();
    }

    function deposit(uint256 amount) external whenNotPaused {
        // ...
    }

    function withdraw(uint256 amount) external whenNotPaused {
        // ...
    }
}

Ключове: різні ролі для pause та unpause. Автоматичний guardian може бути скомпрометований або помилитися — але розпаузити можуть лише люди через multisig/governance. Це асиметрія навмисна.

Які аномалії детектуємо?

TVL anomaly та великі транзакції — розробка системи паузи

Якщо за N блоків з контракту вийшло більше X% TVL — це сигнал. Також відстежуємо одиничні транзакції, що перевищують 5% TVL. Замість автоматичної паузи на них емітуємо подію для off-chain аналізу.

contract AnomalyDetector {
    uint256 public constant MAX_TVL_DROP_BPS = 1000; // 10% за період
    uint256 public constant MONITORING_WINDOW = 100; // блоків

    function checkTVLAnomaly(uint256 currentTVL) internal {
        // ...
    }

    modifier checkWithdrawAnomaly(uint256 amount) {
        uint256 tvl = totalAssets();
        if (tvl > 0 && (amount * 10000 / tvl) > 500) { // 5% TVL
            emit LargeWithdrawal(msg.sender, amount, tvl);
        }
        _;
    }
}

Reentrancy detection on-chain

Доповнення до стандартного nonReentrant — при детекції спроби реентрансі викликається пауза контракту, а не тільки revert.

uint256 private _callDepth;

modifier noDeepCalls() {
    _callDepth++;
    if (_callDepth > 1) {
        _triggerPause("Reentrancy detected");
        revert("Reentrancy");
    }
    _;
    _callDepth--;
}

Чому off-chain моніторинг ефективніший?

On-chain детектори обмежені: вони бачать лише те, що відбувається в поточній транзакції. Більш потужний паттерн — off-chain моніторинг + privileged pause transaction. Ми використовуємо OpenZeppelin Defender та Forta Network — це в 5 разів знижує час реакції порівняно з on-chain тільки.

OpenZeppelin Defender

OZ Defender Sentinel + Autotask — стандартний стек:

const { DefenderRelayProvider, DefenderRelaySigner } = require('@openzeppelin/defender-relay-client/lib/ethers');

exports.handler = async function(credentials) {
    const provider = new DefenderRelayProvider(credentials);
    const signer = new DefenderRelaySigner(provider, credentials, { speed: 'fast' });
    const contract = new ethers.Contract(VAULT_ADDRESS, VAULT_ABI, signer);
    const tvl = await contract.totalAssets();
    const threshold = await contract.pauseThreshold();
    if (tvl < threshold) {
        const tx = await contract.pause();
        await tx.wait();
    }
};

Forta Network

Forta — децентралізована мережа detection ботів. Алерти інтегруються в Defender через webhook. Для точної оцінки вашого сценарію отримайте консультацію у наших інженерів.

Як працює circuit breaker?

Більш гнучкий паттерн: не повна пауза, а circuit breaker — тимчасове обмеження операцій при аномалії. Концепція запозичена з Circuit breaker design pattern.

contract CircuitBreaker {
    enum Status { Normal, Restricted, Paused }
    Status public status;
    uint256 public dailyWithdrawLimit;
    uint256 public dailyWithdrawn;
    uint256 public lastResetDay;

    function withdraw(uint256 amount) external {
        require(status != Status.Paused, "Paused");
        if (status == Status.Restricted) {
            require(amount <= restrictedWithdrawLimit, "Exceeds restricted limit");
        }
        // ...
    }
}

Перевага circuit breaker: при перевищенні денного ліміту протокол не паузується — просто відхиляє транзакції понад ліміт. Користувачі можуть продовжувати роботу в межах нормального обсягу. MakerDAO, Compound, Aave використовують подібні механізми.

Покрокова інструкція впровадження

1. Імпортуйте Pausable та AccessControl у ваш контракт, налаштуйте ролі guardian та admin.
2. Додайте on-chain детектори: TVL drop, великі транзакції, reentrancy detection.
3. Підключіть off-chain моніторинг: налаштуйте Defender Sentinel на події LargeWithdrawal та TVL drop, створіть Autotask для автоматичної паузи.
4. Інтегруйте Forta Network: налаштуйте detection боти та webhook для виклику pause при аномаліях.
5. Протестуйте сценарії: нормальна робота, хибні спрацьовування, атаки. Використовуйте формальну верифікацію та fuzzing.

Що входить в роботу?

Терміни розробки: базова система (Pausable + Defender моніторинг) — 2-3 тижні. Повна з circuit breaker, Forta та governance — 5-7 тижнів. Ми гарантуємо прозорість кожного етапу.

Для захисту вашого DeFi-протоколу отримайте консультацію — ми оцінимо проект безкоштовно. Зв'яжіться з нами. Замовте розробку системи паузи для вашого контракту.

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

Коли протокол втрачає значні кошти через 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 при повторному зверненні.