Розробка системи моніторингу безпеки крос-чейн мостів

Більшість експлойтів на крос-чейн мостах тривають від однієї транзакції до кількох хвилин. Атака на Wormhole ($326M) — одна підписана транзакція, 0 часу на реакцію. Ronin Bridge ($620M) — 5 з 9 валідаторів скомпрометовано, міст жив 6 днів до виявлення. Якщо система моніторингу не аналізує як on-chain активність, так і стан валідаторів — кошти губляться безповоротно. Наше завдання: побудувати систему, яка ловить атаку до або під час, даючи час на паузу протоколу.

Ми розробляємо не просто дашборд із графіками. Це продуктивна система з alert-логікою, circuit breaker-ами та чіткими playbook реагування. Наш досвід включає інтеграцію з OpenZeppelin Defender та Tenderly Web3 Actions для автоматизованої зупинки мосту при аномаліях. За 5+ років ми реалізували 15+ систем моніторингу для DeFi-протоколів, що дозволяє нам гарантувати надійність рішення.

Основні загрози для крос-чейн мостів

Мости — критична інфраструктура DeFi. Основні вектори атак:

• Reentrancy у смарт-контрактах — класична атака, посилена cross-chain викликами.
• Компрометація валідаторів / relayer — зловмисник отримує більшість підписів і підтверджує неправдиві транзакції.
• Oracle manipulation — маніпуляція ціновим фідом для нечесного обміну.
• Flash loan атаки — миттєва позика коштів для створення дисбалансу пулу.

Система моніторингу повинна відстежувати кожен із цих сценаріїв як на вихідному ланцюзі, так і на цільовому.

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

Система будується на трьох рівнях, кожен з різним часом реакції:

Рівень 1 — on-chain real-time (< 1 блок). Моніторинг pending транзакцій у mempool на підозрілі патерни: множинні cross-chain виклики, незвичні обсяги, взаємодія з новими контрактами. Технічно складно (потрібен доступ до private mempool через Flashbots або Eden), але дає найраніше попередження.

Рівень 2 — on-chain per-block (< 12 секунд на Ethereum). Аналіз кожного нового блоку: події мосту (BridgeInitiated, BridgeFinalized), зміни балансів у пулах ліквідності, аномальні накопичення голосів валідаторів.

Рівень 3 — off-chain aggregated (хвилини-години). Агрегація даних за період, trend analysis, cross-chain кореляції. Виявляє повільно розвиваючі атаки: дрейф лімітів, накопичення підписів неактивними валідаторами.

Як працює on-chain circuit breaker для мостів?

Найцінніший компонент — можливість автоматично або напівавтоматично паузити міст при виявленні атаки. На відміну від стандартного Pausable (OZ), ми використовуємо rate limiting на рівні контракту, який спрацьовує автоматично при аномальному обсязі переказу:

contract BridgeWithCircuitBreaker is Pausable, AccessControl { bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE"); uint256 public maxTransferPerBlock; uint256 public maxTransferPerHour; uint256 private _transferredThisBlock; uint256 private _transferredThisHour; uint256 private _lastBlockNumber; uint256 private _lastHourTimestamp; modifier withinRateLimit(uint256 amount) { _updateRateLimitCounters(); require(_transferredThisBlock + amount <= maxTransferPerBlock, "Block rate limit exceeded"); require(_transferredThisHour + amount <= maxTransferPerHour, "Hour rate limit exceeded"); _transferredThisBlock += amount; _transferredThisHour += amount; _; } function transfer(address token, uint256 amount, address to) external whenNotPaused withinRateLimit(amount) { // ... логіка переказу } function emergencyPause() external onlyRole(GUARDIAN_ROLE) { _pause(); emit EmergencyPause(msg.sender, block.timestamp); } function _updateRateLimitCounters() private { if (block.number > _lastBlockNumber) { _transferredThisBlock = 0; } if (block.timestamp >= _lastHourTimestamp + 1 hours) { _transferredThisHour = 0; _lastHourTimestamp = block.timestamp; } } } 

Rate limits не блокують нормальну роботу, але зупиняють drain-атаку з великими обсягами. Встановити ліміти на рівні 2-3x типового обсягу мосту — баланс між UX та безпекою.

Чому інваріантний моніторинг ефективний проти експлойтів?

Для кожного крос-чейн мосту існують математичні інваріанти, які завжди повинні дотримуватися. Моніторинг інваріантів — елегантний спосіб зловити експлойт:

• Bridge з mint/burn: sum(totalSupplyOnSource) + sum(totalSupplyOnDestination) == constant (без урахування комісій).
• AMM міст: reserve0 * reserve1 >= k для кожної пари.

Приклад Python-функції для перевірки:

async def check_invariants(block_number: int): total_locked = await bridge.functions.totalLocked().call(block_identifier=block_number) total_minted = await bridge.functions.totalMinted().call(block_identifier=block_number) if total_locked != total_minted: await alert_critical(f"INVARIANT VIOLATED at block {block_number}: locked ({total_locked}) != minted ({total_minted})") 

Порушення інваріанту — вірна ознака багу або активної атаки.

Автоматична пауза через off-chain Keeper

OpenZeppelin Defender Actions — serverless функції, що реагують на on-chain події. Приклад: моніторинг TVL пулу мосту та автоматична пауза при різкому падінні:

const { ethers } = require("ethers"); module.exports = async function(credentials) { const provider = new ethers.providers.JsonRpcProvider(credentials.secrets.ALCHEMY_URL); const vault = new ethers.Contract(VAULT_ADDRESS, VAULT_ABI, provider); const currentTVL = await vault.totalAssets(); const previousTVL = await storage.get('previousTVL') || currentTVL; const dropPercent = (previousTVL - currentTVL) * 100n / previousTVL; if (dropPercent > 15n) { const signer = credentials.relayer.getSigner(); const guardian = new ethers.Contract(GUARDIAN_ADDRESS, GUARDIAN_ABI, signer); await guardian.emergencyPause(); await notifySlack(`CRITICAL: TVL dropped ${dropPercent}% — bridge paused`); } await storage.put('previousTVL', currentTVL.toString()); }; 

Alerting та incident response

Severity алертів налаштована так:

P1/P2 алерти відправляються в PagerDuty з on-call ротацією, P3 — у Telegram чат, P4 — у Slack daily digest.