Система 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 для мостів: детекція аномалій TVL

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

Наші досягнення: 5+ років досвіду в безпеці DeFi, 50+ успішних впроваджень, оброблено понад 10 000 алертів з точністю 99.5%. Клієнти з сумарним TVL понад $2 млрд.

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. Деплой та моніторинг — запускаємо в продакшн, передаємо документацію та навчання

Готові взятися за ваш проект? Пишіть нам для попереднього аудиту. Оцінимо терміни та вартість безкоштовно.

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

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

Терміни та вартість

Орієнтовні терміни — від 14 до 30 днів залежно від складності моста (кількість підтримуваних ланцюгів, кастомні контракти). Вартість розраховується індивідуально після аудиту. Ми пропонуємо впровадження під ключ: ви отримуєте готову систему, документацію та навчання.

Склад роботи:

  • Документація (архітектура, інструкція, runbook)
  • Код (приватний репозиторій)
  • Інтеграція зі сповіщеннями
  • Дашборд з реальним часом
  • Навчання команди (2 сесії)
  • Підтримка протягом місяця

Наші переваги

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

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

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

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