Реалізація блокчейн-експлорера на сайті під ключ

Реалізація блокчейн-експлорера на сайті під ключ

Уявіть: ви запускаєте новий блокчейн або sidechain. Користувачі хочуть відстежувати свої транзакції, але без експлорера це неможливо. Побудувати такий сервіс з нуля — нетривіальне завдання: потрібно синхронізувати архівну ноду, індексувати кожен блок, реалізувати швидкий пошук за хешами та адресами. Ми вже робили це для 8 проектів і знаємо всі підводні камені: від реоргів до деградації продуктивності при зростанні ланцюжка. Одного разу до нас звернувся стартап, чий експлорер на основі The Graph падав при 50 запитах на секунду — довелося переписувати повністю.

У цій статті я покажу, як влаштований наш підхід: індексатор на базі PostgreSQL, API на Next.js та декодування смарт-контрактів. Ви дізнаєтеся, як уникнути типових помилок і скоротити час розробки. А також зрозумієте, чому інвестиції в кастомне рішення окупаються вже через півроку активної експлуатації. Ми реалізували вже 8 блокчейн-експлорерів для різних EVM-мереж, включаючи пару сайдчейнів з кастомними фічами.

Компоненти системи

Блокчейн-нода (archive)
    |
    ├── RPC/WebSocket (eth_getBlock, eth_getTransaction...)
    |
Індексатор (власний або The Graph)
    |   Читає блоки → парсить транзакції → зберігає
    |
PostgreSQL + Redis (кеш)
    |
REST API / GraphQL
    |
Frontend (Next.js)
    ├── Пошук (tx hash, address, block)
    ├── Список блоків
    ├── Деталі транзакції
    ├── Профіль адреси (баланс + історія)
    └── Декодування смарт-контракт викликів

Для коректної роботи необхідна архівна нода. Докладніше — в Ethereum development docs.

Як забезпечити мінімальний час відповіді при пошуку за хешем?

Ключ — правильна індексація в базі та кешування. Використовуємо PostgreSQL з індексами на hash і block_number, а Redis — для гарячих даних (останні блоки, популярні адреси). Типова помилка — смикати ноду при кожному пошуку. Ми завжди прокладаємо шар кешу, інакше TTFB може перевищувати 2 секунди.

При навантаженні 100+ запитів на секунду наше рішення тримає середній час відповіді нижче 200 мс. Це досягається за рахунок попереднього розігріву кешу та пагінації при вибірці блоків.

Чому кастомний індексатор кращий за готові рішення?

Готові індексатори (The Graph, Moralis) зручні для старту, але накладають обмеження: залежність від зовнішніх серверів, неможливість тонкого налаштування. Порівняння:

Для продакшену з високим навантаженням (більше 100 запитів/сек) ми завжди рекомендуємо кастомний індексатор. Він дає передбачувану продуктивність і свободу в розширенні. За нашими даними, перехід з готового рішення на кастомне знижує витрати на інфраструктуру на 30–40%.

Як індексувати блоки: три кроки

1. Налаштування ноди та підключення. Розгортаємо архівну ноду (Geth/Nethermind) або використовуємо WebSocket-провайдера. Переконуємося, що нода готова віддавати повні блоки з транзакціями.
2. Реалізація індексатора. За допомогою бібліотеки viem підписуємося на нові блоки та парсимо їх у PostgreSQL. Важливо обробляти реорганізації — зберігаємо хеш попереднього блоку та перевіряємо при форку.
3. Постобробка даних. Після вставки транзакцій оновлюємо статистику адрес (баланси, кількість транзакцій) та поміщаємо гарячі дані в Redis.

import { createPublicClient, webSocket } from 'viem';
import { mainnet } from 'viem/chains';

const client = createPublicClient({
  chain: mainnet,
  transport: webSocket(process.env.ETH_WS_URL)
});

class BlockIndexer {
  async indexBlock(blockNumber: bigint): Promise<void> {
    const block = await client.getBlock({
      blockNumber,
      includeTransactions: true
    });

    await db.transaction(async (trx) => {
      await trx('blocks').insert({
        number: Number(block.number),
        hash: block.hash,
        parent_hash: block.parentHash,
        timestamp: new Date(Number(block.timestamp) * 1000),
        miner: block.miner,
        gas_used: block.gasUsed.toString(),
        gas_limit: block.gasLimit.toString(),
        transaction_count: block.transactions.length,
        base_fee_per_gas: block.baseFeePerGas?.toString() ?? null
      });

      for (const tx of block.transactions) {
        await trx('transactions').insert({
          hash: tx.hash,
          block_number: Number(tx.blockNumber),
          from_address: tx.from.toLowerCase(),
          to_address: tx.to?.toLowerCase() ?? null,
          value: tx.value.toString(),
          gas: tx.gas.toString(),
          gas_price: tx.gasPrice?.toString() ?? null,
          max_fee_per_gas: tx.maxFeePerGas?.toString() ?? null,
          input: tx.input,
          nonce: tx.nonce,
          transaction_index: tx.transactionIndex
        });

        await this.updateAddressStats(trx, tx.from.toLowerCase());
        if (tx.to) await this.updateAddressStats(trx, tx.to.toLowerCase());
      }
    });
  }

  async watchNewBlocks(): Promise<void> {
    const unwatch = client.watchBlocks({
      onBlock: async (block) => {
        await this.indexBlock(block.number);
      },
      onError: (error) => {
        logger.error('Block watch error', error);
      }
    });

    const latestIndexed = await this.getLatestIndexedBlock();
    const currentBlock = await client.getBlockNumber();

    for (let i = latestIndexed + 1n; i <= currentBlock; i++) {
      await this.indexBlock(i);
    }
  }
}

API: пошук

app.get('/api/search', async (req, res) => {
  const query = req.query.q as string;

  if (!query) return res.status(400).json({ error: 'Query required' });

  if (/^0x[0-9a-f]{64}$/i.test(query)) {
    const tx = await db('transactions').where('hash', query.toLowerCase()).first();
    if (tx) return res.json({ type: 'transaction', data: tx });

    const block = await db('blocks').where('hash', query.toLowerCase()).first();
    if (block) return res.json({ type: 'block', data: block });

  } else if (/^0x[0-9a-f]{40}$/i.test(query)) {
    return res.json({ type: 'address', address: query.toLowerCase() });

  } else if (/^\d+$/.test(query)) {
    const block = await db('blocks').where('number', parseInt(query)).first();
    if (block) return res.json({ type: 'block', data: block });
  }

  res.json({ type: 'not_found' });
});

Frontend: декодування input data

import { decodeFunctionData } from 'viem';

async function decodeTransactionInput(
  input: string,
  contractAddress: string
): Promise<DecodedInput | null> {
  if (input === '0x') return null;

  const abi = await getContractAbi(contractAddress);
  if (!abi) return { raw: input };

  try {
    const decoded = decodeFunctionData({ abi, data: input as `0x${string}` });
    return {
      functionName: decoded.functionName,
      args: decoded.args,
      raw: input
    };
  } catch {
    return { raw: input };
  }
}

Що входить в розробку експлорера

Процес роботи

Ми ділимо проект на п'ять етапів:

На етапі аналітики ми уточнюємо, які дані потрібні: тільки блоки та транзакції чи повна картина з внутрішніми викликами та логами подій. Проектування включає підготовку схеми бази даних (зазвичай близько 15-20 таблиць) та специфікацію API у форматі OpenAPI.

Терміни орієнтовно

• MVP-експлорер (транзакції, блоки, адреси) без індексатора (через RPC) — 2-3 тижні.
• Повний індексатор з PostgreSQL + API + Frontend — 6-10 тижнів.
• Експлорер для кастомної EVM-мережі — від 2 місяців.

Витрати на інфраструктуру залежать від розміру мережі і обговорюються індивідуально. Зв'яжіться з нами, щоб отримати попередню оцінку вашого проекту.

Типові помилки при створенні блокчейн-експлорера

• Відсутність backfill після збою індексатора — дані втрачаються. Рішення: зберігати останній оброблений блок в БД і при перезапуску продовжувати з нього.
• Ігнорування реорганізацій (reorg) — блоки можуть змінюватися. Потрібно підписуватися на події block через WebSocket і перевіряти хеші.
• Сканування всіх блоків по RPC без пагінації — нода падає від перевантаження. Використовуйте пакетне завантаження з затримками.

Якщо ви зіткнулися з будь-якою з цих проблем або хочете уникнути їх з самого початку, замовте консультацію — ми допоможемо спроектувати стабільний експлорер.

Що далі?

Кастомний індексатор — це інвестиція у продуктивність та надійність. Не потрібно залежати від зовнішніх сервісів: ваші дані завжди під контролем. Замовте розробку — ми запропонуємо архітектуру під вашу мережу за один робочий день.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.