Налаштування приватної RPC-ноди Ethereum: Geth, Reth, Lighthouse
Залежність від публічних RPC — Alchemy, Infura, QuickNode — це залежність від чужого uptime, rate limit'ів та цінової політики. Ethereum nodes and clients рекомендує власну інфраструктуру для продакшн-навантажень. При обсязі запитів від 100k/день економіка власної ноди стає вигідною: типова конфігурація окупається за 3–6 місяців, скорочуючи бюджет на інфраструктуру на 50–70% порівняно з тарифами публічних провайдерів. Крім вартості: власна нода дає повний debug_* та trace_* namespace, які публічні провайдери часто відключають або тарифікують окремо. Вартість власного рішення в 2-3 рази нижча за публічний RPC при навантаженні від 500k запитів на день.
Одного разу до нас звернувся проєкт DeFi, у якого публічний RPC-провайдер відключав debug-методи в розпал тестування нового AMM-контракту. Зміна provider'а зайняла б тижні, а дедлайн був завтра. Ми за два дні підняли власну ноду на Reth + Lighthouse, і команда продовжила налагодження без обмежень. Зв'яжіться з нами для консультації щодо вибору конфігурації під ваше навантаження.
Ми налаштовуємо приватні RPC-ноди з 5+ років досвіду, сумарно 50+ проєктів в Ethereum та сайдчейнах. Наші інженери тестують кожен вузол під реальним навантаженням і дають гарантію uptime 99.9% при правильному оточенні.
Який клієнт обрати для Ethereum?
Два основних execution client'и:
Geth (go-ethereum) — найпоширеніший, найбільша документація, стабільний. Archive mode займає ~16 TB. Найповільніший на eth_getLogs по великих діапазонах блоків.
Reth (Paradigm) — написаний на Rust, значно швидший за Geth на запити історії. Archive mode ~2.5 TB (краще стиснення). Рекомендуємо для нових установок.
Erigon — архівна нода ~3 TB, швидкі історичні запити, але складніший у налаштуванні та оновленні.
| Клієнт | Диск (archive) | Синхронізація | Історичні запити |
|---|---|---|---|
| Geth | ~16 TB | 2–4 тиж | Повільно |
| Reth | ~2.5 TB | 3–7 днів | Швидко |
| Erigon | ~3 TB | 3–7 днів | Швидко |
Чому варто налаштовувати власну ноду?
Публічні RPC мають rate limits (зазвичай 100–300 req/s), відсутність debug/trace методів та вартість при перевищенні лімітів. Порівняйте самі:
| Параметр | Публічний RPC | Приватна нода |
|---|---|---|
| Rate limit | 100-300 req/s | Необмежений |
| debug/trace методи | Відсутні або платно | Повний доступ |
| Економія при 1M req/день | - | До 70% бюджету |
| Час синхронізації archive | Миттєво | 3-7 днів (одноразово) |
| Контроль версій | Ні | Так |
Власна нода — це:
- Повний контроль: будь-які
eth_*,debug_*,trace_*методи без доплат. - Ніяких rate limits: ви платите тільки за залізо.
- Швидкі історичні запити: archive node не урізана.
- Незалежність: при збої провайдера ваша нода продовжує роботу.
Детальна специфікація заліза
Для archive-ноди Ethereum mainnet рекомендується:
- CPU: AMD EPYC 64 ядра (або аналогічний Intel Xeon)
- RAM: 256 GB DDR4 ECC
- Диск: 2x 3.84 TB NVMe SSD (RAID1) для Reth, 4x 3.84 TB для Geth
- Мережа: 10 Gbps
Остаточна конфігурація підбирається під ваш RPS та кількість ланцюгів.
Як налаштувати власну RPC-ноду: покрокова інструкція
Процес налаштування включає наступні кроки:
- Встановити execution та consensus клієнти.
- Створити JWT secret для зв'язку між клієнтами.
- Запустити execution layer (Reth).
- Запустити consensus layer (Lighthouse) з checkpoint sync.
- Налаштувати Nginx reverse proxy з SSL та rate limiting.
- Налаштувати моніторинг та алерти.
Встановлення Reth + Lighthouse (Ethereum mainnet)
Ethereum PoS вимагає два клієнти: execution layer (Reth) + consensus layer (Lighthouse/Prysm):
# Reth curl -L https://github.com/paradigmxyz/reth/releases/latest/download/reth-x86_64-unknown-linux-gnu.tar.gz | tar xz sudo mv reth /usr/local/bin/ # Lighthouse (consensus client) curl -L https://github.com/sigp/lighthouse/releases/latest/download/lighthouse-x86_64-unknown-linux-gnu.tar.gz | tar xz sudo mv lighthouse /usr/local/bin/ # JWT secret для зв'язку між клієнтами (Engine API) openssl rand -hex 32 > /etc/ethereum/jwt.hex Запуск execution layer (Reth):
reth node \ --chain mainnet \ --datadir /data/reth \ --http \ --http.addr 127.0.0.1 \ --http.port 8545 \ --http.api eth,net,web3,txpool,debug,trace \ --ws \ --ws.addr 127.0.0.1 \ --ws.port 8546 \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 \ --authrpc.jwtsecret /etc/ethereum/jwt.hex \ --full # full node, для archive додайте --full=false Запуск consensus layer (Lighthouse):
lighthouse beacon_node \ --network mainnet \ --datadir /data/lighthouse \ --execution-endpoint http://127.0.0.1:8551 \ --execution-jwt /etc/ethereum/jwt.hex \ --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \ --disable-deposit-contract-sync --checkpoint-sync-url — синхронізація консенсус-клієнта починається з фінального checkpoint замість genesis. Скорочує час із тижнів до годин.
Налаштування Nginx як reverse proxy
Прямий доступ до RPC-порту ззовні — погано. Nginx + auth + rate limiting:
upstream ethereum_rpc { server 127.0.0.1:8545; keepalive 32; } server { listen 443 ssl; server_name rpc.yourdomain.com; ssl_certificate /etc/letsencrypt/live/rpc.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/rpc.yourdomain.com/privkey.pem; satisfy any; allow 10.0.0.0/8; deny all; location / { proxy_pass http://ethereum_rpc; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_read_timeout 300s; limit_req zone=rpc_limit burst=100 nodelay; } } limit_req_zone $binary_remote_addr zone=rpc_limit:10m rate=100r/s; WebSocket для subscriptions — окремий location:
location /ws { proxy_pass http://127.0.0.1:8546; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s; } Інші EVM-мережі: BSC, Polygon та їх налаштування
Більшість EVM-мереж — форки Geth. Принцип той самий, клієнт свій. Для BSC використовується BSC Geth, для Polygon — Bor (execution) та Heimdall (consensus), аналогічно до зв'язки Reth+Lighthouse. Запускаються з аналогічними параметрами, тільки з конфігами під відповідну мережу. Наприклад, для Polygon потрібно налаштувати два консенсусні шари: Heimdall (на основі Cosmos SDK) та Bor (форк Geth). Це збільшує час налаштування, але ми надаємо готові скрипти.
Моніторинг ноди
Перевірка синхронізації проста: запит eth_syncing повертає статус і відставання. Алерти: нода вважається здоровою, якщо відставання lag < 5 блоків і peers >= 5. При peers = 0 — нода ізольована від мережі, що гірше, ніж просто відставання.
Prometheus + Grafana для довгострокового моніторингу: Reth і Geth експортують метрики нативно (--metrics.port 9001). Готові дашборди — у репозиторіях відповідних клієнтів.
Що входить у налаштування під ключ
- Встановлення та конфігурація execution + consensus клієнтів для обраної мережі.
- Налаштування Nginx reverse proxy з SSL, rate limiting та IP whitelist.
- Моніторинг (Prometheus + Grafana) з алертами на Telegram/Slack.
- Тестування під навантаженням (до 1000 rps) та оптимізація.
- Документація з обслуговування та відновлення.
- Навчання вашої команди (1 година онлайн).
Терміни та вартість
Орієнтовний термін — від 2 до 7 днів залежно від мережі та вимог до архіву. Вартість розраховується індивідуально після аналізу навантаження: зв'яжіться з нами — оцінимо проєкт безкоштовно. Замовте налаштування приватної RPC-ноди та отримайте повний контроль над інфраструктурою. Наші інженери допоможуть підібрати оптимальну конфігурацію під ваш бюджет та навантаження.
Звертайтеся — ми вже налаштували ноди для 50+ проєктів, включаючи high-load DeFi та NFT маркетплейси.