Розгортання ноди BSC
Ми стикалися із завданням розгортання повної ноди BNB Smart Chain для продакшену. BSC виробляє блок кожні 3 секунди — це в 4 рази частіше, ніж Ethereum. В результаті навантаження на CPU та I/O високе, а розмір chaindata перевищує 3 ТБ. Без правильного вибору типу ноди та конфігурації сервера синхронізація може зайняти тижні або взагалі не завершитися. Часта помилка — спроба використовувати HDD або сервер з малим об'ємом RAM. Нода падає з out-of-memory, а швидкість синхронізації падає до нуля. Розберемо, як розгорнути ноду, яка стабільно працює і не перевантажує бюджет.
Як вибрати тип ноди BSC?
Для BSC доступні три типи нод. Вибір залежить від завдань:
| Тип | Розмір на диску | Час синхронізації | Use case |
|---|---|---|---|
| Full Node (fast sync) | ~1.5 TB | 3–7 днів | RPC з історичними даними |
| Full Node (snap sync) | ~700 GB | 6–24 години | Швидкий RPC для dApp |
| Archive Node | 3+ TB | 1–2 тижні | Аналітика, повна історія |
| Validator Node | ~700 GB | 6–24 години | Стейкінг BNB |
Для більшості завдань (власний RPC, індексування подій, взаємодія з контрактами) достатньо Full Node з snap sync. Цей тип займає менше місця і синхронізується за години, а не дні.
Як прискорити синхронізацію?
Snap sync завантажує snapshot поточного стану, а потім доганяє свіжі блоки. Це займає 6–24 години на NVMe SSD. Мінус: нода не може відповідати на історичні eth_call — тільки для недавніх блоків. Якщо потрібна повна історія, використовуйте fast sync або archive node.
Щоб прискорити синхронізацію:
- Збільшіть кеш: параметр
--cache 16384(мінімум 16 GB RAM). - Обмежте кількість пірів:
MaxPeers = 50у конфігурації. - Переконайтеся, що канал не менше 100 Mbps і затримка до азійських пірів мінімальна.
Чому snap sync кращий за fast sync?
Fast sync завантажує всі блоки з нуля — це може зайняти дні. Snap sync використовує snapshot стану, що скорочує час до годин. За даними офіційної документації BNB Chain, snap sync у 4–5 разів швидший за fast sync. Однак snap sync потребує більше оперативної пам'яті на етапі завантаження snapshot.
Вимоги до сервера
Мінімальні та рекомендовані характеристики для Full Node з snap sync:
| Параметр | Мінімум | Рекомендується |
|---|---|---|
| vCPU | 16 | 32+ |
| RAM | 32 GB | 64 GB |
| Диск | 2 TB NVMe SSD | 4 TB NVMe SSD |
| Канал | 100 Mbps | 1 Gbps |
| ОС | Ubuntu 22.04 LTS | Ubuntu 24.04 LTS |
HDD не підходить — BSC виробляє блок кожні 3 секунди, що потребує швидких I/O. Використовуйте NVMe SSD, інакше нода не встигатиме.
Встановлення та налаштування
Встановлення через зібраний бінарник з GitHub:
wget https://github.com/bnb-chain/bsc/releases/latest/download/geth_linux chmod +x geth_linux mv geth_linux /usr/local/bin/geth geth version Завантажити genesis та конфігурацію мережі:
mkdir -p /data/bsc && cd /data/bsc wget https://github.com/bnb-chain/bsc/releases/latest/download/mainnet.zip unzip mainnet.zip geth --datadir /data/bsc init genesis.json Створюємо config.toml з оптимізаціями під snap sync:
[Eth] NetworkId = 56 SyncMode = "snap" PriceLimit = 3000000000 # 3 Gwei min [Node] DataDir = "/data/bsc" HTTPHost = "0.0.0.0" HTTPPort = 8546 HTTPModules = ["eth", "net", "web3", "txpool"] WSHost = "0.0.0.0" WSPort = 8547 [Node.P2P] MaxPeers = 50 Запускаємо:
geth --config /data/bsc/config.toml --datadir /data/bsc --cache 16384 --syncmode snap --diffsync --snapshot 2>&1 | tee /var/log/bsc-node.log Для продакшену додаємо systemd unit.
Моніторинг та безпека
Перевірка синхронізації виконується командами:
geth attach /data/bsc/geth.ipc --exec "eth.blockNumber" geth attach /data/bsc/geth.ipc --exec "eth.syncing" geth attach /data/bsc/geth.ipc --exec "net.peerCount" Порти для P2P: 30303/tcp та 30303/udp. RPC виставляємо тільки через reverse proxy з авторизацією. Використовуйте nginx з rate limiting (наприклад, 100 запитів на секунду) та firewall для порту 8545.
Для моніторингу підключаємо Grafana + Prometheus з готовими дашбордами. Метрики: швидкість синхронізації, кількість пірів, використання ресурсів.
Що робити при помилках?
Якщо синхронізація зупинилася на одному і тому ж блоці — перевірте вільне місце на диску та навантаження на CPU. Нода може зависнути через нестачу RAM. В такому випадку збільшіть --cache або додайте swap. Якщо диск заповнений — видаліть старі snapshot або підключіть SSD більшого об'єму. При помилках підключення до пірів перевірте відкритість порту 30303.
Що входить у розгортання під ключ
Ми пропонуємо повний цикл: підбір сервера під ваше навантаження, встановлення та налаштування ноди, конфігурація моніторингу (Grafana + Prometheus з готовими дашбордами), налаштування nginx reverse proxy з rate limiting, документація з експлуатації та 30 днів технічної підтримки після запуску. Зв'яжіться для розрахунку конфігурації та вартості.
Гарантія стабільності
Ми гарантуємо стабільну роботу ноди. Наші інженери мають тривалий досвід у блокчейн-інфраструктурі та запустили понад 20 нод різних мереж. Отримайте консультацію — допоможемо вибрати оптимальну конфігурацію та розгорнути ноду BSC під ваші завдання.