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

Когда смарт-контракты готовы, проект часто упирается в инфраструктуру: ноды падают, RPC-лимиты тормозят, события теряются. Мы разрабатываем блокчейн-инфраструктуру под ключ — от настройки нод и 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% проектов достаточно внешнего провайдера. Своя нода — когда нагрузка или требования к контролю превышают лимиты.

Критерий Своя нода RPC провайдер
Стоимость на 1 million запросов ~$0.5–1 (железо) $5–40
Время запуска 2–4 дня для sync Мгновенно
Rate limits Нет Есть
Debug/trace методы Да Нет
Надёжность Требует проактивного мониторинга SLA 99.9%

Запуск 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);
  }
}

Событийный pipeline: состав и необходимость

Pipeline обрабатывает события блокчейна: слушает новые блоки, парсит логи, сохраняет данные и уведомляет сервисы. 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"
  })
}

Типовые этапы и сроки

Фаза Содержание Срок
Assessment Анализ требований, архитектура 1–3 дня
Node setup Нода / RPC конфигурация 3–5 дней
Indexer Subgraph или кастомный индексер 1–2 недели
Event pipeline Kafka/Redis, processors, webhooks 3–5 дней
Monitoring Prometheus + Grafana + алерты 2–3 дня
Load testing Нагрузочное тестирование 2–3 дня
Documentation Runbook, incident response 1–2 дня

Что входит в работу

  • Архитектурная документация (диаграммы, описание стека)
  • Доступы к мониторингу и дашбордам
  • Обучение команды (проведение воркшопа по 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.

Направления блокчейн-разработки

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1141