Мы разрабатываем системы отслеживания блокчейн-транзакций, которые гарантируют доставку каждого события даже при реорганизации цепи. Потеря транзакции может стоить пользователю денег, а бизнесу — репутации. Наивная реализация с polling JSON-RPC каждые N секунд (eth_getBlockByNumber, перебор транзакций) при нагрузке 10+ адресов быстро превращается в проблему: растущий lag, rate-limit от RPC-провайдера, пропущенные события при сбоях. За 5 лет мы реализовали 15+ проектов для Ethereum (как через WebSocket, так и через собственные indexer'ы на ethers.js), Solana (используя Helius) и Polygon — накопили паттерны, которые работают в продакшене. Один из наших клиентов обрабатывал 50 000 транзакций в день с lag менее 2 секунд — это стало возможным благодаря комбинации WebSocket и fallback polling.
Мы оказываем услуги разработки под ключ систем мониторинга криптовалютных транзакций с event-driven архитектурой. Наш опыт включает интеграцию с Chainlink илиacles, обработку flash loan атак и настройку slippage для AMM пулов — все эти сценарии требуют надёжного отслеживания транзакций в реальном времени. Ниже — проверенные решения для разных нагрузок: от простого WebSocket-мониторинга до масштабируемого indexer'а с гарантированной доставкой.
Какую архитектуру выбрать для мониторинга транзакций?
WebSocket-подписки (для небольших систем) — разработка системы отслеживания
Ethereum WebSocket API поддерживает eth_subscribe:
-
newHeads— новые блоки -
logs— события смарт-контрактов по фильтру -
newPendingTransactions— mempool (ненадёжно, не использовать для финансов)
const { ethers } = require("ethers"); const provider = new ethers.WebSocketProvider(process.env.WS_RPC_URL); // Подписка на Transfer события ERC-20 const filter = { address: USDC_CONTRACT, topics: [ ethers.id("Transfer(address,address,uint256)"), null, ethers.zeroPadValue(WATCHED_ADDRESS, 32), // только входящие ], }; provider.on(filter, async (log) => { const parsed = iface.parseLog(log); await processIncomingTransfer({ txHash: log.transactionHash, from: parsed.args.from, amount: parsed.args.value, blockNumber: log.blockNumber, }); }); Проблема: WebSocket-соединение падает. Нужен reconnect с восстановлением пропущенных событий — запрос eth_getLogs за пропущенный диапазон блоков при реконнекте. ethers.js упрощает эту логику, но требует ручной обработки разрывов.
Indexer-сервис (для средних и крупных систем)
The Graph, Ponder, или собственный indexer на базе eth_getLogs с курсором. Схема:
RPC Node → Indexer Worker → PostgreSQL (indexed events) → API → Clients Indexer хранит last_processed_block, при рестарте продолжает с того же места. Batching запросов: eth_getLogs за диапазон блоков (рекомендуется по 1000–2000 блоков за раз). Такой подход обрабатывает до 100 раз больше адресов, чем WebSocket, без роста lag.
Webhook-провайдеры (самое быстрое внедрение)
Helius (Solana), Alchemy (EVM), QuickNode Streams берут мониторинг на себя, вызывая ваш endpoint при событиях. Сокращают время внедрения в 3 раза по сравнению с собственным indexer'ом. Подходит, когда инфраструктурная простота важнее полного контроля.
| Критерий | WebSocket-подписки | Indexer-сервис | Webhook-провайдеры |
|---|---|---|---|
| Макс. кол-во адресов | До 10 | 100+ | Неограниченно |
| Lag | Малый (секунды) | Средний (блоки) | Малый (секунды) |
| Сложность разработки | Низкая | Высокая | Нулевая |
| Контроль над данными | Полный | Полный | Ограниченный провайдером |
| Риск потери событий | При падении соединения | Низкий (с курсором) | Зависит от провайдера |
Если сомневаетесь в выборе — свяжитесь с нами, поможем подобрать архитектуру под ваш бюджет и нагрузку.
Как обрабатывать реорганизацию цепи (chain reorg)?
Blockchain reorg — нормальное явление, особенно на малых глубинах. Транзакция с 3 confirmations может исчезнуть. Система, которая не обрабатывает reorg, периодически показывает пользователям оплаченные заказы, которые потом откатываются.
Правило: не помечать транзакцию как финальную до достижения безопасной глубины:
| Сеть | Безопасная глубина | Финализация |
|---|---|---|
| Ethereum | 12+ подтверждений (~2.5 мин) | Checkpoint (slots, ~13 мин) |
| Bitcoin | 6 подтверждений (~60 мин) | Probabilistic |
| Polygon PoS | 256 подтверждений (~8 мин) | Checkpoint в Ethereum |
| Solana | finalized (~15 сек) | Однозначная |
Реализация статусной машины для транзакции:
pending → confirming (1+ conf) → confirmed (12+ conf) → finalized ↓ reorged → needs_retry При обнаружении reorg (блок с нашей транзакцией был заменён): откат статуса, уведомление, повторная проверка.
Как работает детектор реорганизации
При поступлении нового блока мы проверяем его parentHash. Если parentHash не совпадает с последним известным блоком, это может быть reorg. Запускаем перепроверку всех транзакций, начиная с блоков с меньшей глубиной. Если находим заменяющий блок — меняем статус на 'reorged'.
Как хранить данные транзакций?
Минимальная схема таблицы транзакций:
CREATE TABLE tracked_transactions ( id BIGSERIAL PRIMARY KEY, tx_hash VARCHAR(66) NOT NULL, network VARCHAR(20) NOT NULL, block_number BIGINT, block_hash VARCHAR(66), -- для детекта reorg from_address VARCHAR(42), to_address VARCHAR(42), value_raw NUMERIC(78, 0), -- wei/lamports, без потери точности token_contract VARCHAR(42), status VARCHAR(20) DEFAULT 'pending', confirmations INT DEFAULT 0, metadata JSONB, first_seen_at TIMESTAMPTZ DEFAULT now(), confirmed_at TIMESTAMPTZ, UNIQUE(tx_hash, network) ); CREATE INDEX idx_tracked_tx_address ON tracked_transactions(to_address); CREATE INDEX idx_tracked_tx_status ON tracked_transactions(status) WHERE status NOT IN ('finalized', 'failed'); block_hash позволяет обнаружить reorg: если блок с нашим block_number имеет другой hash — произошёл форк.
Почему важно мониторить сам indexer?
Метрика indexer_lag_blocks — насколько indexer отстаёт от head цепи. Если lag > 50 блоков — алерт: либо RPC упал, либо indexer перегружен. Добавляем в Prometheus/Grafana или хотя бы Uptime Robot с webhook.
Какие типичные ошибки допускают при создании мониторинга?
- Игнорирование chain reorg: транзакция помечается оплаченной после 1 confirmation, а через минуту исчезает. Последствия — финансовые потери и споры с клиентами.
- Использование только polling без fallback: при пропуске нескольких блоков из-за сбоя — потеря всех событий за этот промежуток.
- Отсутствие dead-letter очереди для webhook: если внешняя система недоступна, уведомления теряются безвозвратно.
- Неправильный выбор глубины подтверждений: для Ethereum достаточно 12 подтверждений, но для крупных сумм некоторые проекты используют 30+.
Что входит в разработку системы мониторинга
- Компонент получения событий (WebSocket + fallback polling)
- Обработчик reorg с откатом статусов
- Worker подтверждений (обновляет счётчик confirmations)
- REST/WebSocket API для фронтенда
- Webhook delivery для внешних систем (с retry и dead-letter queue)
- Dashboard текущего состояния indexer'а
Как мы работаем
- Аналитика: определяем список адресов и событий, выбираем сеть и архитектуру.
- Проектирование: схема БД, статусная машина, механизм реконнекта.
- Реализация: пишем код на Solidity/Rust (если это смарт-контракт), бэкенд на Node.js/Python с интеграцией ethers.js или Web3.py.
- Тестирование: эмуляция chain reorg в тестовой сети, нагрузочное тестирование.
- Деплой: CI/CD, мониторинг, документация.
Сроки: от 2 до 6 недель в зависимости от сложности. Закажите консультацию — оценим ваш проект за 1 день.