Вы управляете 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 сверки балансов.
| Сеть | Block time | Рекомендуемый RPC | Finality |
|---|---|---|---|
| Ethereum | ~12 сек | Alchemy/Infura | ~64 блока (~13 мин) |
| Arbitrum One | ~0.25 сек | Arbitrum RPC / Alchemy | L1 finality |
| Polygon PoS | ~2 сек | Polygon RPC / QuickNode | ~256 блоков |
| Base | ~2 сек | Base RPC / Alchemy | L1 finality |
| Optimism | ~2 сек | Optimism RPC / Alchemy | L1 finality |
| BNB Chain | ~3 сек | BSC RPC / NodeReal | ~75 блоков |
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) events могут приходить быстрее чем их можно обработать. 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.
Пример реализации cross-chain корреляции
Для bridge мониторинга мы используем коррелятор на Redis: при инициации откладываем событие на час, при получении завершения проверяем таймаут. Если время превышает ожидаемое (например, 30 минут для Arbitrum bridge), генерируем алерт. Такой подход позволяет обнаружить застрявшие транзакции до того, как пользователь начнёт паниковать.Какие события смарт-контрактов мониторить в первую очередь?
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 (fees collected)
Как выбрать между OpenZeppelin Defender, Tenderly и кастомной разработкой?
Готовые сервисы дают быстрый старт, но cross-chain корреляция у них слабая. Сравним:
| Подход | Преимущества | Ограничения |
|---|---|---|
| OpenZeppelin Defender | Быстрый старт, встроенные сети | Слабая cross-chain корреляция |
| Tenderly | Отличная dev-среда, визуализация | Не подходит для production под высокой нагрузкой |
| Кастомная система | Полный контроль, гибкость | Время разработки 4-6 недель |
Мы рекомендуем комбинировать: использовать 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-2 дня.
- Проектирование архитектуры с учётом сетей и нагрузки — 2-4 дня.
- Настройка RPC, subgraph и message queue.
- Разработка кастомных правил алертов и cross-chain корреляции.
- Интеграция с системами уведомлений (PagerDuty, Telegram, Discord).
- Документация и обучение команды.
- Поддержка после запуска (опционально).
Что входит в работу
- Полная документация по архитектуре и правилам алертов.
- Исходный код обработчиков и корреляторов.
- Интеграция с вашей инфраструктурой (RPC, мосты, контракты).
- Обучение команды по работе с дашбордами и реагированию на алерты.
- Техническая поддержка на период после запуска (до 3 месяцев).
Автоматическая реакция на алерты
Мониторинг без автоматической реакции — половина системы. Мы настраиваем OpenZeppelin Defender Autotask или кастомный keeper бот:
- Аномально большой вывод > 5% TVL → автоматическая пауза контракта (если паузер настроен на keeper).
- Oracle deviation > 3% → переключение на fallback oracle.
- Bridge stuck > 2 часов → уведомление bridge operator + создание тикета.
Автоматическая реакция требует тщательного аудита самого keeper бота. Мы гарантируем надёжность и предоставляем сертификаты безопасности наших решений. Получите консультацию по мониторингу вашего протокола — оценим сложность и сроки за 1 день. Свяжитесь с нами, чтобы обсудить проект.