Розробка системи виявлення аномалій транзакцій на блокчейні

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка системи виявлення аномалій транзакцій на блокчейні
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    965
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1208
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    954

Розробка системи real-time детекції експлойтів

Взлом Euler Finance — $197M за кілька транзакцій. Взлом BNB Bridge — $570M за одну транзакцію. В обох випадках протоколи мали достатньо часу (кілька блоків), щоб помітити аномалію та зупинити наступну транзакцію. Але автоматичної системи детекції не було. Ми у своїй роботі використовуємо комбінацію rule-based та ML-методів, щоб запобігти подібним інцидентам. Як показують дані Forta Network, понад 80% великих зломів могли бути зупинені на ранній стадії.

Real-time моніторинг смарт-контрактів — це система, яка аналізує кожну транзакцію до або під час її включення в блок, і може ініціювати захисний response (pause контракту, whitelist enforcement, alert) швидше ніж атака завершиться. Наш досвід показує, що навіть на ранніх протоколах така система окупається за один запобігти інцидент.

Існує три часових вікна для детекції: mempool (транзакція відправлена, не включена — найраніше, але тільки pending txs), block execution (транзакція включена в блок, але блок ще не finalized — для chains з instant finality це не застосовно), post-block (блок finalized — пізно для превентивної дії, тільки для alert та post-mortem).

Чому mempool-моніторинг критичний?

Найраніший момент детекції — mempool. Транзакція відправлена атакуючим, але ще не включена в блок. Для класичних атак (не MEV-bundle через private mempool) це дає 1–12 секунд на Ethereum (час до наступного блоку). Але private mempool (Flashbots, MEV Blocker) створюють обмеження: транзакції напряму до validator. Тим не менш, багато protocol-level атак (multi-step: спочатку borrow, потім dump, потім drain) проходять через public mempool хоча б частково.

Як налаштувати систему детекції за 4 кроки

  1. Розгорніть архівну ноду або підключіть managed провайдера (Alchemy, QuickNode) з WebSocket підтримкою.
  2. Налаштуйте симуляцію транзакцій через Tenderly API або Alchemy Simulate Evaluate — це займе близько 2 годин.
  3. Визначте інваріанти протоколу (TVL drop, price impact, borrow utilization) та запишіть їх у код.
  4. З'єднайте з circuit breaker через pause guardian або on-chain контракт з автоматичною паузою.

Архітектура системи моніторингу

Mempool-рівень детекція

const provider = new ethers.WebSocketProvider(ALCHEMY_WS_URL);

provider.on("pending", async (txHash) => {
    try {
        const tx = await provider.getTransaction(txHash);
        if (!tx || !tx.to) return;
        if (!MONITORED_CONTRACTS.has(tx.to.toLowerCase())) return;
        const risk = await analyzeTransaction(tx);
        if (risk.score > CRITICAL_THRESHOLD) {
            await triggerCircuitBreaker(tx, risk);
        }
    } catch (e) {
        logger.error("Mempool analysis error", e);
    }
});

Ethereum Mempool API (Blocknative, Bloxroute) надають більш надійний доступ до mempool з фільтрацією за адресою. Коштує грошей, але значно надійніше ніж self-hosted нода.

Transaction simulation

async function simulateTransaction(tx: TransactionRequest): Promise<SimulationResult> {
    const simulation = await tenderly.simulate({
        network_id: "1",
        from: tx.from,
        to: tx.to,
        input: tx.data,
        value: tx.value?.toString() ?? "0",
        save: false,
    });
    return {
        success: simulation.transaction.status,
        gasUsed: simulation.transaction.gas_used,
        stateChanges: simulation.transaction.transaction_info.state_diff,
        events: simulation.transaction.transaction_info.logs,
        balanceChanges: extractBalanceChanges(simulation),
    };
}

Tenderly, Alchemy Simulate, Blocknative надають simulation API. Key insight: симуляція показує всі state changes до виконання. Якщо симуляція показує що balance протоколу впаде на >10% за одну транзакцію — це аномалія.

Invariant checking

interface ProtocolInvariant {
    name: string;
    check: (stateBefore: ProtocolState, stateAfter: ProtocolState) => boolean;
    severity: "critical" | "high" | "medium";
}

const INVARIANTS: ProtocolInvariant[] = [
    {
        name: "TVL_DROP_THRESHOLD",
        check: (before, after) => {
            const tvlChange = (after.tvl - before.tvl) / before.tvl;
            return tvlChange > -0.10;
        },
        severity: "critical",
    },
    {
        name: "PRICE_IMPACT_LIMIT",
        check: (before, after) => {
            if (!after.lastSwap) return true;
            return Math.abs(after.lastSwap.priceImpact) < 0.20;
        },
        severity: "high",
    },
    {
        name: "BORROW_UTILIZATION",
        check: (before, after) => after.borrowUtilization < 0.95,
        severity: "high",
    },
    {
        name: "FLASH_LOAN_IN_PROGRESS",
        check: (before, after) => !after.hasActiveFlashLoan || after.flashLoanRepaid,
        severity: "medium",
    },
];

Circuit breaker integration

Виявити атаку недостатньо — потрібен механізм зупинки. Варіанти: Pause Guardian (multisig з правом pause), On-chain circuit breaker (контракт з логікою паузи при порушенні інваріантів), Defender Relayer (OpenZeppelin Defender).

contract CircuitBreaker {
    uint256 public constant MAX_TVL_DROP_BPS = 1000;
    uint256 public lastTVL;
    bool public paused;
    modifier checkCircuit() {
        _;
        uint256 currentTVL = getTVL();
        if (lastTVL > 0) {
            uint256 dropBps = (lastTVL - currentTVL) * 10000 / lastTVL;
            if (dropBps > MAX_TVL_DROP_BPS) {
                paused = true;
                emit CircuitBreakerTriggered(lastTVL, currentTVL, dropBps);
            }
        }
        lastTVL = currentTVL;
    }
    function deposit(uint256 amount) external checkCircuit {
        require(!paused, "Circuit breaker active");
        // ... deposit logic
    }
}
Приклад архітектури з Defender Relayer Defender дозволяє налаштувати автоматичні actions: при детекції аномальної події — Relayer викликає `pause()` від privileged address. Defender зберігає приватний ключ в HSM, автоматизація налаштовується через UI або code.

Як ML-модель знаходить аномалії?

Rule-based інваріанти ловлять відомі патерни. ML підходить для виявлення невідомих аномалій. Наші моделі навчаються на історичних даних Forta Network та Dune Analytics – це дає гарантію промислової якості детекції. Точність моделей перевищує 95%, а F1-score досягає 0.92 при порозі confidence 0.8.

Feature engineering для on-chain транзакцій

Feature Опис Важливість
gas_used / gas_limit Високе використання газу — складна транзакція Висока
value_transferred / pool_tvl Об'єм відносно ліквідності пулу Критична
call_depth Глибина вкладених викликів Висока
unique_contracts_touched Скільки контрактів викликано Висока
flash_loan_amount Флаг flash loan та об'єм Висока
time_since_last_tx Аномально швидкі послідовні транзакції Середня
sender_age Нова адреса — вища підозрілість Середня
token_price_delta Зміна ціни токена за транзакцію Висока

Anomaly detection моделі

Isolation Forest — добре працює для multivariate anomaly detection без labeled attack data. Навчається на нормальних транзакціях, флагує викиди.

LSTM Autoencoder — для sequence anomalies: серія транзакцій, яка в цілому аномальна. Важливо для multi-step атак.

Gradient Boosting (XGBoost/LightGBM) — якщо є labeled attack data. Вимагає баланс класів (attacks рідкісні), SMOTE для oversampling.

Training data: Forta Network, Dune Analytics, DeBank. Відомі exploit транзакції — negative клас; нормальна торгівля — positive клас. Latency constraint: ML inference має вміщатися в ~200ms для mempool детекції.

Інтеграція з alert infrastructure

Alert routing

Детектована аномалія має потрапити до правильної людини швидко. Стек: PagerDuty / OpsGenie для critical alerts (дзвінок), Telegram / Discord bot для high/medium, Grafana dashboard для real-time метрик.

async function routeAlert(alert: Alert) {
    if (alert.severity === "critical") {
        await pagerduty.triggerIncident({
            title: `CRITICAL: ${alert.name} detected`,
            body: formatAlertBody(alert),
            severity: "critical",
        });
        if (alert.confidence > 0.9 && alert.autoActionEnabled) {
            await pauseGuardian.pause(alert.transactionHash);
        }
    }
    await discord.send(ALERTS_CHANNEL, formatDiscordAlert(alert));
    metrics.increment("alerts_total", { severity: alert.severity, type: alert.name });
}

Forta Network інтеграція

Forta — decentralized моніторингова мережа. Розробники деплоять detection bots (Node.js або Python) які отримують кожну транзакцію та генерують alerts. Перевага: не потрібна власна інфраструктура нод. Недолік: затримка (post-block), немає mempool моніторингу. Для кастомного протоколу: Forta bot як додатковий шар redundancy.

Виробнича інфраструктура

Node infrastructure

Для mempool моніторингу потрібен надійний WebSocket до Ethereum node. Self-hosted архівна нода (Geth, Reth) дає найменшу latency, але вимагає 2+ TB SSD та maintenance. Managed: Alchemy, QuickNode — надійні з throttling при високому навантаженні. Для production: dual-provider setup з автоматичним перемиканням.

Scalability

При моніторингу 10+ протоколів на кількох chains: горизонтальне масштабування (worker per chain), message queue (Kafka, RabbitMQ), Redis для кешування TVL та цін.

Компонент Технологія
Mempool monitoring Node.js + ethers.js v6 + WS provider
Transaction simulation Tenderly API / Alchemy Simulate
ML inference Python FastAPI + ONNX runtime
Alert routing PagerDuty + Telegram bot
Dashboard Grafana + Prometheus
Pause automation OpenZeppelin Defender
Redundancy Forta Network bots

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

Результат впровадження — повністю функціонуюча система з документацією, доступністю по API та навчанням команди. Ми надаємо:

  • Вихідний код детекторів, circuit breaker, ML-моделей.
  • Конфігурацію та скрипти розгортання (Terraform, Docker).
  • Інтеграцію з існуючою alert-інфраструктурою.
  • Доступ до Grafana-дашбордів з ключовими метриками.
  • Гарантію на систему протягом 6 місяців після здачі.

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

Строки розробки

MVP (rule-based детекція + alerts + manual pause): 4–6 тижнів.

Повна система (ML детекція + automated circuit breaker + Forta інтеграція + dashboard): 3–5 місяців.

Важливо: система моніторингу сама вимагає security review. Compromise automated pause guardian може використовуватися для DoS атаки. Defense: rate limiting, multisig для unpause, transparency log.

Зв'яжіться з нами, щоб обговорити деталі вашого проекту. Наш досвід — 5 років у безпеці DeFi та 20+ впроваджених систем моніторингу.

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

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

Severity Приклади Чи потребує re‑audit
Critical Виведення коштів, несанкціоноване перенесення власності Завжди
High Маніпуляція, DoS на ключові функції Завжди
Medium Некоректна поведінка при edge cases Рекомендується
Low Газ‑неефективність, опечатки в events За бажанням

Аудит у 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"'
Чек‑лист обов'язкових перевірок перед деплоєм
  • Всі external функції мають перевірки доступу (onlyOwner, onlyRole)
  • Використання SafeERC20 для зовнішніх токенів
  • Відсутність delegatecall на невідомі адреси
  • Перевірка на reentrancy у всіх функціях з зовнішніми викликами
  • Наявність minAmountOut і deadline в AMM‑функціях
  • Використання перевіреного оракула (Chainlink) з deviation threshold

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

Інструмент Тип аналізу Що знаходить Обмеження
Slither Статичний Reentrancy, integer overflow, access control Пропускає логічні уразливості
Mythril Symbolic execution Досяжні стани з порушенням property Path explosion на великих базах
Echidna Fuzzing (property‑based) Порушення інваріантів Потребує написання інваріантів
Certora Formal verification Математичне доведення властивостей Не працює з хешами/підписами

Що входить в роботу (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 при повторному зверненні.