Розробка блокчейн-інфраструктури: ноди, RPC, індекери, моніторинг

Зауважимо: коли смарт-контракти написані та аудит пройдено, проект розбивається об побутову інфраструктуру: ноди падають, RPC ліміти душать, події втрачаються. Ми це бачили не раз. Тому налаштовуємо інфраструктуру так, щоб ви про неї не думали. Production-ready блокчейн-інфраструктура — це не просто нода, а цілий стек: мультиплексування RPC, пайплайн подій, моніторинг та план відкату.

За 3–6 тижнів підіймаємо все з нуля: від вибору стеку до документованого runbook з алертами. Досвід показує, що грамотно спроектована інфраструктура скорочує час інцидентів на 80%.

Production-ready інфраструктура включає виділені ноди з failover, кастомні індекери для подій, моніторинг всіх метрик та автоматизоване відновлення після збоїв. Без цього навіть ідеальний смарт-контракт залишиться недоступним для користувачів. Ми налаштовуємо кожен шар: від вибору клієнта ноди (Reth або Geth) до конфігурації Prometheus-алертів. Розглянемо ключові компоненти на прикладі реального DeFi-проекту з навантаженням 1000 запитів на секунду.

Шари блокчейн-інфраструктури

+-------------------------------------------------+
| Application Layer                                |
| (Frontend, API, Business Logic)                  |
+-------------------------------------------------+
| Data Access Layer                                |
| (GraphQL API, REST API, WebSocket)               |
+-------------------------------------------------+
| Indexing Layer                                   |
| (The Graph / custom indexer / event processor)   |
+-------------------------------------------------+
| Node Layer                                       |
| (Archive node / full node / light client)        |
+-------------------------------------------------+
| Blockchain Layer                                 |
| (Ethereum / L2 / custom chain)                   |
+-------------------------------------------------+

Кожен шар має вимоги до надійності та масштабування. Розберемо ключові.

Власна нода чи RPC провайдер: критерії вибору

Власна нода потрібна, якщо: потрібна archive node для історичних запитів — провайдери беруть за це дорого; rate limits критичні — при 100k+ запитів на день провайдер або дорогий, або обмежує; важлива приватність — провайдер бачить всі запити; потрібні debug/trace методи, які недоступні у провайдерів.

Для 80% проектів достатньо зовнішнього провайдера. Власна нода — коли навантаження або вимоги до контролю перевищують ліміти.

Запуск Reth (Rust Ethereum) швидше Geth — синхронізація full node за 24–48 годин. Приклад конфігу:

reth node \
  --chain mainnet \
  --http \
  --http.addr 0.0.0.0 \
  --http.port 8545 \
  --http.api eth,net,web3,debug,trace \
  --ws \
  --ws.addr 0.0.0.0 \
  --ws.port 8546 \
  --authrpc.addr 127.0.0.1 \
  --authrpc.port 8551 \
  --authrpc.jwtsecret /path/to/jwt.hex \
  --datadir /data/reth

Вимоги до заліза: 4+ CPU, 16+ GB RAM, 2+ TB NVMe, 25 Mbps канал. Навіть з провайдером потрібен failover. Паттерн — load balancer з health checks:

class RpcMultiplexer {
  private providers: JsonRpcProvider[];
  private healthStatus: Map<string, boolean>;

  constructor(endpoints: string[]) {
    this.providers = endpoints.map(url => new JsonRpcProvider(url));
    this.healthStatus = new Map();
    this.startHealthChecks();
  }

  async getHealthyProvider(): Promise<JsonRpcProvider> {
    const healthy = this.providers.filter(
      (p, i) => this.healthStatus.get(String(i)) !== false
    );
    if (healthy.length === 0) throw new Error('No healthy RPC providers');
    return healthy[Math.floor(Math.random() * healthy.length)];
  }

  private startHealthChecks(): void {
    setInterval(async () => {
      for (let i = 0; i < this.providers.length; i++) {
        try {
          await this.providers[i].getBlockNumber();
          this.healthStatus.set(String(i), true);
        } catch {
          this.healthStatus.set(String(i), false);
        }
      }
    }, 15_000);
  }
}

Подієвий пайплайн: склад та необхідність

Пайплайн обробляє події блокчейну: слухає нові блоки, парсить логи, зберігає дані та сповіщає сервіси. The Graph — готове рішення для більшості EVM-проектів. Якщо потрібна складна логіка, пишемо кастомний індекер.

Кастомний індекер будується на TypeScript з курсорним відновленням та транзакційністю. Приклад:

class EventIndexer {
  private db: Pool;
  private provider: JsonRpcProvider;

  async indexFromBlock(startBlock: number): Promise<void> {
    let currentBlock = startBlock;
    const headBlock = await this.provider.getBlockNumber();

    while (currentBlock <= headBlock) {
      const batch = Math.min(currentBlock + 999, headBlock);
      const logs = await this.provider.getLogs({
        fromBlock: currentBlock,
        toBlock: batch,
        address: CONTRACT_ADDRESSES,
      });

      await this.db.query('BEGIN');
      try {
        for (const log of logs) await this.processLog(log);
        await this.updateCursor(batch);
        await this.db.query('COMMIT');
      } catch (e) {
        await this.db.query('ROLLBACK');
        throw e;
      }

      currentBlock = batch + 1;
    }
  }
}

Ключові принципи: курсорне відновлення, ідемпотентність, обробка реоргів.

Для високонавантажених систем використовуємо Kafka як шину: listener пише в топики, processors читають та зберігають у PostgreSQL. Це дає горизонтальне масштабування та стійкість до збоїв.

Чому моніторинг критичний для блокчейн-інфраструктури?

Стек: Prometheus + Grafana. Метрики: відставання індекера (indexer_lag_blocks), кількість оброблених подій (events_processed_total), помилки RPC (rpc_errors_total з мітками method та error_type), час обробки блоку (block_processing_seconds). Алерти: lag > 100 блоків — critical, rpc errors > 10/min — warning, processing > 30s — warning.

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

Для автоматизації використовуємо Terraform та Ansible. Terraform керує хмарними ресурсами (сервери, мережі), Ansible — конфігурацією нод та сервісів. Це дозволяє відтворювати інфраструктуру в різних середовищах та швидко відновлюватися після збоїв. Приклад Terraform-модуля для ноди Ethereum:

resource "aws_instance" "node" {
  ami = data.aws_ami.ubuntu.id
  instance_type = "c6i.4xlarge"
  root_block_device {
    volume_type = "gp3"
    volume_size = 2000
    iops = 3000
  }
  user_data = templatefile("${path.module}/scripts/node-init.sh", {
    chain = "mainnet"
  })
}

Типові етапи та строки

Що входить в роботу

• Архітектурна документація (діаграми, опис стеку)
• Доступи до моніторингу та дашбордів
• Навчання команди (проведення воркшопу з runbook)
• Підтримка при інцидентах перші 30 днів після деплою
• Вихідні коди Terraform/Ansible для відтворення

Як налаштувати failover RPC: покрокова інструкція

1. Розгорніть дві ноди в різних регіонах (AWS eu-west-1 та us-east-1) або використовуйте різних провайдерів.
2. Налаштуйте health check на кожній ноді: проба eth_blockNumber раз на 15 секунд.
3. Встановіть load balancer (HAProxy або NGINX) з алгоритмом round-robin та passive health checks.
4. Додайте retry-логіку на стороні клієнта: при помилці 429 або 503 перемикайтеся на наступний ендпоінт.
5. Налаштуйте алерт в Prometheus: rpc_errors_total > 10 за хвилину — critical.

Документація Ethereum по налаштуванню нод

Управління ключами: read-only ключі для індекерів та API, transaction keys в AWS KMS або Vault, admin keys — тільки multisig. Ротація API-ключів кожні 90 днів.

Типові помилки при налаштуванні інфраструктури

• Використання одного RPC провайдера без failover — призводить до простою при його відмові.
• Відсутність курсорного відновлення в індекері — при збої доводиться переіндексувати все з нуля.
• Ігнорування rate limits провайдера — раптові блокування при піковому навантаженні.
• Неправильний вибір заліза для ноди — повільна синхронізація та часті збої.

Зв'яжіться з нами — отримайте консультацію по вашій інфраструктурі. Гарантуємо uptime 99.9% для рішення. Економія на інфраструктурі може складати до 60% порівняно з комерційними провайдерами при високому навантаженні. Замовте розгортання під ключ.

Рекомендуємо ознайомитись з Ethereum та The Graph.