Розробка системи моніторингу смарт-контрактів у кількох мережах

Ви керуєте DeFi-протоколом, розгорнутим на Ethereum, Arbitrum та Base. Кошти переміщуються через мости, а події в одній мережі впливають на іншу. Затримка виявлення аномалії може коштувати мільйони — згадайте атаку на Wormhole ($326 млн) або Ronin ($610 млн). Готових рішень для cross-chain кореляції немає — кожен протокол потребує індивідуальної архітектури. За 5 років ми налаштували моніторинг для 15+ DeFi-протоколів, обробляючи до 10 000 подій на секунду із затримкою менше 1 секунди та 99.9% uptime. Зв'яжіться з нами, щоб обговорити вашу архітектуру.

Як організувати моніторинг смарт-контрактів у кількох мережах?

Джерела даних — розробка системи моніторингу

RPC nodes — прямі виклики до EVM-нод через WebSocket для real-time подій. Для кожної мережі потрібен надійний RPC з підтримкою eth_subscribe:

const provider = new ethers.WebSocketProvider(RPC_WS_URL); const contract = new ethers.Contract(address, abi, provider); contract.on('Transfer', (from, to, value, event) => { emitEvent({ network: 'arbitrum', block: event.log.blockNumber, txHash: event.log.transactionHash, type: 'Transfer', data: { from, to, value } }); }); 

Проблема single RPC: публічні ноди ненадійні, пропускають події при високому навантаженні. Рішення: мінімум 2 незалежних провайдери на мережу (Alchemy + QuickNode, або власна нода). Дедуплікація подій по (chainId, txHash, logIndex).

The Graph / Subgraph — для історичних даних та складних запитів. Mediation layer поверх raw RPC. Затримка 1-3 блоки, але ідеально для аналітичних запитів та cross-network звірки балансів.

Event Processing Pipeline

Сиру події не можна одразу аналізувати — потрібна нормалізація та enrichment:

RPC Listener → Message Queue (Kafka/Redis Streams) → Event Processor → Alert Engine → Notification ↓ Time-series DB (InfluxDB/TimescaleDB) ↓ Analytics Dashboard 

Event Processing Pipeline — ключовий елемент. Message Queue — буферизація при сплесках. При різкому зростанні on-chain активності (наприклад, великий liquidation cascade) події можуть надходити швидше ніж їх можна обробити. Kafka з retention 24h дозволяє replay при падінні процесора.

Event Processor — нормалізація подій з різних мереж в єдиний формат, декодування ABI, enrichment (ціни токенів, metadata акаунтів), детектування аномалій.

Alert Engine — правила на нормалізованих подіях. Stateful правила потребують state store (Redis). Приклади правил:

class LargeTransferAlert(AlertRule): def evaluate(self, event: NormalizedEvent) -> Optional[Alert]: if event.type != 'Transfer': return None usd_value = event.data['value'] * get_token_price(event.data['token']) threshold = self.get_dynamic_threshold( token=event.data['token'], window='24h', multiplier=10.0 ) if usd_value > threshold: return Alert( severity='HIGH', message=f'Large transfer: ${usd_value:,.0f} on {event.network}', context=event ) 

Cross-Chain Correlation

Cross-Chain Correlation — найцінніша функціональність для мультимережевих протоколів. Зв'язування подій між мережами. Типові сценарії:

Bridge monitoring — токен заблоковано на Ethereum, має з'явитися на Arbitrum. Якщо за N хвилин не з'явився — алерт. Для цього потрібен correlation engine:

class BridgeCorrelator: def __init__(self, redis_client): self.pending = {} def on_bridge_initiated(self, event): key = f"bridge:{event.src_chain}:{event.tx_hash}" self.redis.setex(key, 3600, json.dumps(event.to_dict())) def on_bridge_completed(self, event): key = f"bridge:{event.src_chain}:{event.bridge_nonce}" pending = self.redis.get(key) if not pending: alert(f"Bridge completion without initiation: {event}") return initiation = json.loads(pending) latency = event.timestamp - initiation['timestamp'] if latency > EXPECTED_BRIDGE_LATENCY[event.bridge_protocol]: alert(f"Bridge latency anomaly: {latency}s") 

TVL consistency check — сумарний TVL на L2s не повинен перевищувати locked amount на L1. Періодична перевірка через subgraph queries з алертом при розходженні > 5%.

Джерело: ERC-20 Token Standard — база для стандартних подій Transfer.

Які події смарт-контрактів моніторити в першу чергу?

Security-critical events — те, що не можна пропустити:

• Ownership transfers — на будь-якому контракті протоколу
• Upgrade proposals — події від Timelock (нові proposals, виконання)
• Large withdrawals — вивід > 5% TVL за короткий період
• Flash loan usage — отримання flash loan + взаємодія з контрактом протоколу в одній tx
• Oracle price deviations — ціна в протоколі відхиляється від ринкової > 3%
• Pause events — хтось паузить контракт

Operational метрики

• Gas usage аномалії (різке зростання може означати inefficient execution або атаку)
• Failed transactions частка (зростання failed tx у роутера може означати UI/API баг)
• Block inclusion latency для власних транзакцій (keeper bots, liquidation bots)

Business метрики

• TVL динаміка по мережах
• Volume per network
• Unique active addresses
• Protocol revenue (збори)

Як вибрати між OpenZeppelin Defender, Tenderly та кастомною розробкою?

Готові сервіси дають швидкий старт, але cross-chain кореляція у них слабка. Порівняємо:

Ми рекомендуємо комбінувати: використовувати Tenderly для оперативного моніторингу dev-середовища, Defender для базового моніторингу production, а кастомний шар для cross-chain кореляції та специфічних правил.

Стек для кастомної системи:

• Event ingestion: Node.js + ethers.js WebSocket listeners
• Message queue: Redis Streams (для невеликих проектів) або Kafka (для високого навантаження)
• Storage: TimescaleDB для time-series, PostgreSQL для event metadata
• Alert rules: Python з rule engine
• Notifications: PagerDuty/OpsGenie для критичних, Telegram/Discord для операційних
• Dashboard: Grafana над TimescaleDB

Процес розробки моніторингу: від аудиту до деплою

1. Аудит поточної інфраструктури та збір вимог — 1-2 дні.
2. Проектування архітектури з урахуванням мереж та навантаження — 2-4 дні.
3. Налаштування RPC, subgraph та message queue.
4. Розробка кастомних правил алертів та cross-chain кореляції.
5. Інтеграція з системами сповіщень (PagerDuty, Telegram, Discord).
6. Документація та навчання команди.
7. Підтримка після запуску (опціонально).

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

• Повна документація щодо архітектури та правил алертів.
• Вихідний код обробників та кореляторів.
• Інтеграція з вашою інфраструктурою (RPC, мости, контракти).
• Навчання команди щодо роботи з дашбордами та реагування на алерти.
• Технічна підтримка на період після запуску (до 3 місяців).

Автоматична реакція на алерти

Моніторинг без автоматичної реакції — половина системи. Ми налаштовуємо OpenZeppelin Defender Autotask або кастомний keeper бот:

• Аномально великий вивід > 5% TVL → автоматична пауза контракту (якщо паузер налаштований на keeper).
• Oracle deviation > 3% → перемикання на fallback oracle.
• Bridge stuck > 2 годин → сповіщення bridge operator + створення тікету.

Автоматична реакція потребує ретельного аудиту самого keeper бота. Ми гарантуємо надійність та надаємо сертифікати безпеки наших рішень. Отримайте консультацію щодо моніторингу вашого протоколу — оцінимо складність та терміни за 1 день. Зв'яжіться з нами, щоб обговорити проект.