Налаштування повної ноди Ethereum
Запустити Ethereum ноду зараз простіше, ніж раніше, але все ще є підводні камені. Головний — після The Merge потрібна одночасна робота двох клієнтів: Execution Layer (EL) та Consensus Layer (CL). Вони спілкуються через Engine API з JWT-аутентифікацією, і без CL нода просто не синхронізується. Складність у тому, що неправильна конфігурація одного з клієнтів або ігнорування JWT призводить до помилок engine_exchangeTransitionConfiguration. Наші інженери мають 10+ років досвіду в блокчейні та розгорнули 50+ production нод, тому ми знаємо всі типові помилки. Ми гарантуємо надійність та стабільність роботи ноди з SLA 99.9%. Наші фахівці мають сертифікацію з Ethereum.
Як вибрати комбінацію клієнтів?
Execution Layer: Geth — reference клієнт на Go, займає ~70% ринку. Snap sync працює швидко (4-12 годин). Nethermind (.NET) хороший для Windows-серверів. Erigon (Go) дає найменший розмір бази (~1 TB проти 1.2 TB у Geth), але snapshot sync повільніше. Besu (Java) підходить для enterprise.
Consensus Layer: Lighthouse (Rust) — відмінна продуктивність і низьке споживання пам'яті. Prysm (Go) — найпопулярніший з хорошою документацією. Teku (Java) — варіант для великих організацій.
Рекомендована комбінація: Geth + Lighthouse — обидва стабільні та добре документовані. Geth забезпечує синхронізацію в 1.4 рази швидше, ніж Erigon, а Lighthouse використовує пам'яті в 1.3 рази менше, ніж Prysm.
| Клієнт (EL) | Розмір бази | Швидкість snap sync | Пам'ять (RAM) | Особливості |
|---|---|---|---|---|
| Geth | 1.2 TB | 4-12 год | 4-6 GB | Reference, стабільний, найбільше ком'юніті |
| Erigon | ~1 TB | 12-24 год | 4-6 GB | Мінімальний розмір бази, повільніше sync |
| Nethermind | 1.2 TB | 6-14 год | 4-6 GB | .NET, хороший для Windows |
| Besu | 1.5 TB | 8-16 год | 6-8 GB | Java, enterprise-фічі |
Вимоги до заліза
| Тип ноди | Диск | RAM | CPU |
|---|---|---|---|
| Full node (snap sync) | 1.2 TB NVMe | 16 GB | 4 ядра |
| Archive node | 14+ TB NVMe | 32 GB | 8 ядер |
| Validator | 1.2 TB NVMe | 16 GB | 4 ядра |
Критично важливо: тільки NVMe SSD. HDD та SATA SSD не забезпечать IOPS — нода буде відставати. NVMe SSD в 5 разів швидше за HDD, що критично для синхронізації.
Чому JWT secret критично важливий?
Після The Merge зв'язок між Execution та Consensus клієнтами захищено JWT (JSON Web Token). Без цього файлу клієнти не зможуть спілкуватися через Engine API, і нода не синхронізується. JWT secret Ethereum необхідний для аутентифікації. Генерація проста:
openssl rand -hex 32 > jwt.hex chmod 600 jwt.hex Переконайтеся, що шляхи доступу до jwt.hex в обох клієнтах налаштовані коректно. Помилка в --authrpc.jwtsecret або --execution-jwt — одна з найчастіших при розгортанні. Взаємодія Execution Consensus Layer відбувається через Engine API з JWT.
Покрокове розгортання
- Генеруйте JWT secret:
openssl rand -hex 32 > jwt.hex - Створіть docker-compose.yml для Ethereum з налаштуваннями Geth та Lighthouse.
- Запустіть Execution Layer:
docker-compose up -d geth - Запустіть Consensus Layer:
docker-compose up -d lighthouse - Перевірте синхронізацію через RPC запити.
Детальні кроки описано нижче.
Як забезпечити безперебійну синхронізацію?
Використовуйте --checkpoint-sync-url для Consensus Layer. Це прискорює синхронізацію CL з тижнів до 15 хвилин, завантажуючи фіналізований beacon state. Публічні endpoints: https://mainnet.checkpoint.sigp.io, https://beaconstate.ethstaker.cc. Для Execution Layer використовуйте snap sync Ethereum — Geth завантажує лише знімок стану за 4-12 годин. Комбінація checkpoint sync + snap sync дає максимальну швидкість. Consensus Layer забезпечує finality блоків через механізм GOST (Gasper), де кожен epoch складається з 32 slot, а валідатори надсилають attestations.
Моніторинг
curl -s -X POST http://localhost:8545 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' | jq curl -s http://localhost:5052/eth/v1/node/syncing | jq Додайте до Prometheus через ethereum_exporter та lighthouse_beacon. Графіки готові в офіційних дашбордах і дозволяють відстежувати затримку, кількість пірів, стан синхронізації.
Безпека RPC
- HTTP RPC (8545, 8546) не повинен бути відкритий в інтернет без аутентифікації — будь-хто може дренувати unlocked акаунти або навантажувати ноду атаками
eth_call. - Використовуйте Nginx reverse proxy з rate limiting і, якщо потрібен зовнішній доступ, — Bearer token аутентифікацію.
- Engine API (8551) — тільки localhost або внутрішня docker мережа.
- Firewall: відкриті тільки P2P порти (30303, 9000).
Використовуйте iptables або cloud firewall для блокування вхідних підключень до 8545 ззовні. Розуміння conceptів pruning та state trie допоможе оптимізувати використання диска. Наприклад, Geth автоматично виконує pruning старих state trie вузлів, що зменшує розмір бази.
Що входить у розгортання ноди під ключ?
Ми надаємо: вибір та налаштування клієнтів, генерацію JWT secret, конфігурацію Docker Compose, налаштування моніторингу (Prometheus + Grafana), забезпечення безпеки (firewall, Nginx reverse proxy), документацію конфігурації, навчання вашої команди та місяць технічної підтримки. Ми надаємо гарантію на конфігурацію та технічну підтримку. Для прикладу, оренда подібної хмарної ноди на AWS коштує ~$300/місяць, тоді як одноразове розгортання на власному сервері за нашою послугою коштує від $1500, що дає економію понад $2100 за перший рік.
Типові помилки при розгортанні:
- Використання HDD або SATA SSD — нода відстає.
- Забуто JWT secret — клієнти не з'єднуються.
- Відкритий HTTP RPC без аутентифікації — ризик атак.
- Синхронізація з genesis замість checkpoint/snap — тижні очікування.
- Міскач портів Engine API (8551) — помилка
engine_exchangeTransitionConfiguration.
Зв'яжіться з нами для детальної консультації. Замовте розгортання ноди під ключ — оцінимо ваш проект протягом 2 робочих днів. Економія до 30% порівняно з хмарними провайдерами.