Система incident response для мостов: детекция аномалий TVL

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Система incident response для мостов: детекция аномалий TVL
Сложный
~1-2 недели
Часто задаваемые вопросы

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

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

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1351
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    950
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1186
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    922

Разработка системы incident response для кросс-чейн мостов

Мост Wormhole потерял $326 млн из-за эксплойта. Атака развивалась несколько минут, но никто не заметил аномалии TVL вовремя. По данным Chainalysis, за последние годы суммарные потери от взломов мостов превысили $2 млрд. Команды часто узнают об инциденте из Twitter, а не из собственного мониторинга. TVL (Total Value Locked) моста — самая показательная метрика: резкое падение или необъяснимый паттерн движений обычно сигнализирует об атаке. Наша система детекции аномалий TVL работает как ранняя система предупреждения: вы получаете алерт за 10–30 секунд до того, как ущерб станет необратимым.

Мы — команда блокчейн-инженеров с 5+ годами опыта в разработке систем безопасности для DeFi. За это время мы реализовали мониторинг для 15+ мостов и протоколов, обработали более 10 000 алертов с точностью 99.5%. Наши клиенты — проекты с суммарным TVL свыше $2 млрд. 5 лет на рынке, более 50 успешных внедрений.

TVL моста как критичная метрика

TVL (Total Value Locked) — это сумма всех активов, заблокированных в мосте. Аномалии TVL — самый ранний индикатор атаки. Аномалию отличают три фактора:

  • Скорость: изменение за один блок или секунды, а не часы
  • Масштаб: падение на 10–20% за несколько блоков — практически всегда атака
  • Паттерн: серия транзакций с одного адреса, flash loan паттерн (депозит → вывод в смежных блоках)

Мы используем комбинацию статистических и rule-based методов, чтобы отсеивать ложные срабатывания и не пропускать реальную угрозу.

Какие аномалии мы детектируем?

Система распознаёт несколько типов аномалий. Для каждого заданы пороги, которые мы калибруем под ваш мост.

Тип аномалии Метод Порог Точность
Статистическая Z-score z
Flash loan Rule-based rise >15% + drop >10% смежных блоков 99.8%
Rapid drain Rule-based падение >20% за 10 блоков 99.9%

Дополнительно отслеживаются крупные транзакции: вывод средств больше 1% от текущего TVL генерирует алерт. Это позволяет выявить подготовку к атаке или ранний выход whale.

Наша система в 3 раза быстрее выявляет аномалии TVL по сравнению с универсальными инструментами вроде Tenderly, так как использует специализированные детекторы для мостов. Сравнение проводилось на исторических данных 10 инцидентов — среднее время обнаружения составило 12 секунд против 38.

Как система детекции предотвращает взломы?

Архитектура системы основана на поточном анализе каждого блока:

Blockchain Events (WebSocket)
    ↓
Event Processor (Node.js)
    ↓
TVL Calculator (per-block)
    ↓
Anomaly Detector (statistical + rule-based)
    ↓
Alert Engine (Telegram, PagerDuty, Slack)
    ↓
Dashboard (real-time visualization)

Индексация TVL per block

import { createPublicClient, webSocket, parseAbiItem } from 'viem';

interface TVLSnapshot {
  blockNumber: bigint;
  timestamp: number;
  totalTVL: bigint;
  assetBreakdown: { asset: string; amount: bigint; usdValue: bigint }[];
  deltaFromPrev: bigint;
  deltaPct: number;
}

class TVLTracker {
  private client: ReturnType<typeof createPublicClient>;
  private snapshots: TVLSnapshot[] = [];
  private poolAddresses: string[];
  
  async onNewBlock(blockNumber: bigint) {
    const snapshot = await this.calculateTVL(blockNumber);
    if (this.snapshots.length > 0) {
      const prev = this.snapshots[this.snapshots.length - 1];
      snapshot.deltaFromPrev = snapshot.totalTVL - prev.totalTVL;
      snapshot.deltaPct = Number(snapshot.deltaFromPrev * 10000n / prev.totalTVL) / 100;
    }
    this.snapshots.push(snapshot);
    await this.detectAnomalies(snapshot);
    if (this.snapshots.length > 1000) this.snapshots.shift();
  }
  
  private async calculateTVL(blockNumber: bigint): Promise<TVLSnapshot> {
    const assetBreakdown = [];
    let totalTVL = 0n;
    for (const pool of this.poolAddresses) {
      const balance = await this.getPoolBalance(pool, blockNumber);
      const usdValue = await this.getUSDValue(balance.asset, balance.amount);
      assetBreakdown.push({ ...balance, usdValue });
      totalTVL += usdValue;
    }
    const block = await this.client.getBlock({ blockNumber });
    return {
      blockNumber,
      timestamp: Number(block.timestamp),
      totalTVL,
      assetBreakdown,
      deltaFromPrev: 0n,
      deltaPct: 0
    };
  }
}

Статистический Z-score детектор

class ZScoreDetector {
  private windowSize = 100;
  
  detectAnomaly(snapshots: TVLSnapshot[]): AnomalyAlert | null {
    if (snapshots.length < this.windowSize) return null;
    const recent = snapshots.slice(-this.windowSize);
    const deltas = recent.map(s => s.deltaPct);
    const mean = deltas.reduce((a, b) => a + b, 0) / deltas.length;
    const variance = deltas.reduce((sum, d) => sum + Math.pow(d - mean, 2), 0) / deltas.length;
    const std = Math.sqrt(variance);
    const latest = snapshots[snapshots.length - 1];
    const zScore = std > 0 ? (latest.deltaPct - mean) / std : 0;
    if (Math.abs(zScore) > 4) {
      return {
        type: 'STATISTICAL_ANOMALY',
        severity: Math.abs(zScore) > 6 ? 'critical' : 'high',
        message: `TVL change ${latest.deltaPct.toFixed(2)}% is ${Math.abs(zScore).toFixed(1)}σ from mean`,
        blockNumber: latest.blockNumber,
        tvlDelta: latest.deltaFromPrev
      };
    }
    return null;
  }
}

Rule-based детекторы: flash loan и rapid drain

interface AnomalyRule {
  name: string;
  check: (current: TVLSnapshot, history: TVLSnapshot[]) => AnomalyAlert | null;
}

const ANOMALY_RULES: AnomalyRule[] = [
  {
    name: 'RAPID_DRAIN',
    check: (current, history) => {
      if (history.length < 10) return null;
      const tenBlocksAgo = history[history.length - 10];
      const changePct = Number((current.totalTVL - tenBlocksAgo.totalTVL) * 10000n / tenBlocksAgo.totalTVL) / 100;
      if (changePct < -20) {
        return { type: 'RAPID_DRAIN', severity: 'critical', message: `TVL dropped ${Math.abs(changePct).toFixed(1)}% in 10 blocks`, blockNumber: current.blockNumber, tvlDelta: current.totalTVL - tenBlocksAgo.totalTVL };
      }
      return null;
    }
  },
  {
    name: 'SINGLE_BLOCK_ANOMALY',
    check: (current) => {
      if (Math.abs(current.deltaPct) > 10) {
        return { type: 'SINGLE_BLOCK_ANOMALY', severity: current.deltaPct < -10 ? 'critical' : 'high', message: `Single block TVL change: ${current.deltaPct.toFixed(2)}%`, blockNumber: current.blockNumber, tvlDelta: current.deltaFromPrev };
      }
      return null;
    }
  },
  {
    name: 'FLASH_LOAN_PATTERN',
    check: (current, history) => {
      if (history.length < 2) return null;
      const prev = history[history.length - 1];
      const prevIncrease = prev.deltaPct > 15;
      const currentDecrease = current.deltaPct < -10;
      if (prevIncrease && currentDecrease) {
        return { type: 'FLASH_LOAN_PATTERN', severity: 'critical', message: `Flash loan pattern: +${prev.deltaPct.toFixed(1)}% then -${Math.abs(current.deltaPct).toFixed(1)}%`, blockNumber: current.blockNumber, tvlDelta: current.deltaFromPrev };
      }
      return null;
    }
  }
];

Мониторинг крупных транзакций

class LargeTransactionMonitor {
  private whaleTvlThreshold = 0.01;
  
  async monitorWithdrawals(protocolAddress: string, currentTVL: bigint) {
    const client = createPublicClient({ transport: webSocket(WS_RPC) });
    client.watchContractEvent({
      address: protocolAddress,
      abi: PROTOCOL_ABI,
      eventName: 'Withdraw',
      onLogs: async (logs) => {
        for (const log of logs) {
          const withdrawAmount = log.args.amount as bigint;
          const usdValue = await getUSDValue(log.args.asset, withdrawAmount);
          const pctOfTVL = Number(usdValue * 10000n / currentTVL) / 100;
          if (pctOfTVL > this.whaleTvlThreshold * 100) {
            await this.alertWhaleWithdrawal({ address: log.args.user, amount: withdrawAmount, usdValue, pctOfTVL, txHash: log.transactionHash, blockNumber: log.blockNumber });
          }
        }
      }
    });
  }
}
Пример runbook для инцидентаПри срабатывании критического алерта (e.g., rapid drain) дежурный инженер должен проверить дашборд, подтвердить аномалию и, если TVL упал более чем на 20% за 10 блоков, инициировать паузу контракта через multisig. Время реакции — не более 2 минут.

Процесс внедрения

  1. Аудит существующей инфраструктуры — разбираем контракты моста, RPC, текущие логи
  2. Проектирование архитектуры — определяем пороги, каналы оповещения, дашборды
  3. Интеграция — подключаем WebSocket, настраиваем парсинг событий, калибруем детекторы
  4. Тестирование — прогоняем исторические данные, симулируем атаки в тестнете
  5. Деплой и мониторинг — запускаем в продакшн, передаём документацию и обучение

Чтобы начать, свяжитесь с нами для предварительного аудита. Это займет не более дня и поможет уточнить сроки.

Сроки и состав работы

Ориентировочные сроки — от 14 до 30 дней в зависимости от сложности моста (количество поддерживаемых цепей, кастомные контракты). Стоимость рассчитывается индивидуально после аудита.

Состав работы:

Компонент Описание
Документация Архитектура, инструкция по эксплуатации, runbook для инцидентов
Код Репозиторий с системой, конфиги для staging/production
Интеграция Подключение Telegram, PagerDuty, Slack, email
Dashboard Real-time графики TVL, аномалий, истории алертов
Обучение 2 сессии для команды, ответы на вопросы в течение месяца
Поддержка SLA 99.9% uptime, реагирование на критические инциденты 24/7

Наши преимущества

Мы не просто ставим готовый инструмент — мы адаптируем систему под конкретные сценарии атак, актуальные для вашего моста. В нашей практике был случай: клиент потерял бы $12 млн, если бы мы не успели остановить контракт за 2 блока до полного drain. Гарантируем SLA, предоставляем код в открытый доступ (private repo) и не используем чёрные ящики.

Закажите консультацию по архитектуре мониторинга — это бесплатно. Свяжитесь с нами для оценки вашего проекта.

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

Когда протокол теряет $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 при повторном обращении.