Разработка системы детекции аномалий транзакций на блокчейне

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска 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 integration + dashboard): 3–5 месяцев.

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

Свяжитесь с нами, чтобы обсудить детали вашего проекта. Наш опыт — 5 лет в безопасности DeFi и 20+ внедрённых систем мониторинга.

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

Когда протокол теряет $197M через 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 имеет смысл для контрактов, которые: управляют > $50M, обновляются редко, имеют чётко формализуемые инварианты. Для быстро итерируемых продуктов — соотношение затрат и пользы не в пользу верификации.

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

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 (Wikipedia).

Oracle manipulation через TWAP. Spot price — стандартная цель для flash loan атаки (Wikipedia). 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 Drain funds, unauthorized ownership transfer Всегда
High Manipulation, 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 > $3B. Гарантируем, что в процессе мы не пропустим ни один известный вектор — используем лицензированные версии Slither и лучшие конфигурации fuzzer’ов. Предотвращённые убытки для клиентов оцениваются более чем в $50M.

Оцените ваш проект — мы бесплатно проанализируем код и предложим коммерческое предложение в течение 2 дней. Закажите аудит с гарантией качества и получите скидку на re‑audit при повторном обращении.