Розробка блокчейн-інфраструктури: ноди, 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.