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