Розробка системи відстеження транзакцій

Розробка системи відслідковування трансакцій

Наївна реалізація моніторингу трансакцій — це polling JSON-RPC кожні N секунд: eth_getBlockByNumber, перебір трансакцій, пошук потрібної адреси. При навантаженні в 10+ адресу це швидко перетворюється на проблему: зростаючий lag, rate-limit від RPC-провайдера, пропущені трансакції при кратковременних збоях. Правильна система будується на іншій архітектурі — event-driven, з реорганізацією ланцюга і гарантованою обробкою.

Архітектура: три основних підходи

1. 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 eventos 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 за пропущений діапазон блоків при реконнекті.

2. 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 блоків за раз).

3. Webhook-провайдери (самий швидкий deployment)

Helius (Solana), Alchemy (EVM), QuickNode Streams беруть моніторинг на себе, викликаючи ваш endpoint при подіях. Підходить, коли інфраструктурна простота важливіша за повний контроль.

Реорганізація ланцюга (chain reorg)

Це найнеочевидніше місце. Blockchain reorg — це нормальне явище, особливо на малих глибинах. Трансакція з 3 confirmations може зникнути. Система, яка не обробляє reorg, періодично показує користувачам "оплачені" замовлення, які потім відкатуються.

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

Реалізація статусної машини для трансакції:

pending → confirming (1+ conf) → confirmed (12+ conf) → finalized
                                         ↓
                                      reorged → needs_retry

При обнаруженні reorg (блок з нашою трансакцією був замінений): відкат статусу, уведомлення, повторна перевірка.

Зберігання та індексування

Мінімальна схема таблиці трансакцій:

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 — сталася fork.

Моніторинг самого indexer'а

Метрика indexer_lag_blocks — наскільки indexer відстає від head ланцюга. Якщо lag > 50 блоків — алерт: або RPC впав, або indexer перегружен. Додаємо в Prometheus/Grafana або хоча б Uptime Robot з webhook.

Що входить в розробку системи

• Компонент отримання подій (WebSocket + fallback polling)
• Обробник reorg з откатом статусів
• Worker підтвердження (оновлює лічильник confirmations)
• REST/WebSocket API для фронтенду
• Webhook delivery для зовнішніх систем (з retry і dead-letter queue)
• Dashboard поточного стану indexer'а