Розгортання ноди BSC

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розгортання ноди BSC
Середній
від 1 дня до 3 днів
Часті запитання

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

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1308
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1221
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    921
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1149
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    611
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    886

Розгортування ноди BSC

BSC (BNB Smart Chain) — EVM-сумісна мережа з консенсусом Proof of Staked Authority (21 валідатор). Повна нода BSC займає значно більше місця, ніж Ethereum: на момент 2024 року повний chaindata перевищує 3 TB, що робить вибір типу ноди критичним рішенням.

Типи нод BSC

Тип Розмір Можливості Use case
Full Node (fast sync) ~1.5 TB Поточний стан + недавня історія RPC для dApp, моніторинг
Full Node (snap sync) ~700 GB Поточний стан Швидкий старт
Archive Node 3+ TB Повна історія всіх станів eth_call на старих блоках, аналітика
Validator Node ~700 GB Участь у консенсусі Стейкінг BNB

Для більшості задач (власний RPC, індексування подій, взаємодія з контрактами) достатньо Full Node з snap sync.

Вимоги до сервера

CPU:   16+ vCPU (BSC більш вимогливий до CPU, ніж Ethereum, через часті блоки)
RAM:   32 GB мінімум, 64 GB рекомендується для стабільної роботи
Disk:  2 TB NVMe SSD (HDD не підходить — занадто повільні I/O)
Net:   100 Mbps+, бажано з низькою затримкою до азійських пірів
OS:    Ubuntu 22.04 LTS

BSC виробляє блок кожні ~3 секунди (проти 12 с у Ethereum). Це означає в 4 рази більше блоків за той же період та пропорційно більшу нагрузку на I/O та CPU при синхронізації.

Установка geth (BSC fork)

BSC використовує форк go-ethereum — bsc (Binance Chain go-ethereum fork):

# Установка залежностей
apt-get update && apt-get install -y build-essential git golang-go

# Або через предсобранний бінарник (рекомендую для production)
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

# Скачати genesis та mainnet конфіг
wget https://github.com/bnb-chain/bsc/releases/latest/download/mainnet.zip
unzip mainnet.zip

# Ініціалізація genesis блоку
geth --datadir /data/bsc init genesis.json

Конфігураційний файл config.toml:

[Eth]
NetworkId = 56
SyncMode = "snap"      # snap для швидкого старту, full для повної верифікації

[Eth.TxPool]
Locals = []
Journal = "transactions.rlp"
Rejournal = 3600000000000
PriceLimit = 3000000000   # 3 Gwei мінімум (BSC специфіка)
PriceBump = 10
AccountSlots = 512
GlobalSlots = 10240
AccountQueue = 256
GlobalQueue = 5120
Lifetime = 10800000000000

[Node]
DataDir = "/data/bsc"
HTTPHost = "0.0.0.0"
HTTPPort = 8545
HTTPVirtualHosts = ["*"]
HTTPModules = ["eth", "net", "web3", "txpool"]
WSHost = "0.0.0.0"
WSPort = 8546
WSModules = ["eth", "net", "web3"]

[Node.P2P]
MaxPeers = 50

Запуск

geth \
  --config /data/bsc/config.toml \
  --datadir /data/bsc \
  --cache 16384 \          # 16 GB RAM для кешу — критично для швидкості
  --rpc.allow-unprotected-txs \
  --history.transactions 90 \   # зберігати tx index за останні 90 днів
  --txlookuplimit 0 \
  --syncmode snap \
  --snapshot \
  --diffsync \             # BSC-специфічна оптимізація синхронізації
  2>&1 | tee /var/log/bsc-node.log

Systemd unit

[Unit]
Description=BSC Full Node
After=network.target

[Service]
Type=simple
User=bsc
ExecStart=/usr/local/bin/geth \
  --config /data/bsc/config.toml \
  --datadir /data/bsc \
  --cache 16384 \
  --syncmode snap \
  --snapshot \
  --diffsync
Restart=on-failure
RestartSec=10
LimitNOFILE=65536
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Моніторинг синхронізації

# Поточний блок ноди
geth attach /data/bsc/geth.ipc --exec "eth.blockNumber"

# Статус синхронізації
geth attach /data/bsc/geth.ipc --exec "eth.syncing"
# Повертає false якщо синхронізована, або об'єкт з прогресом

# Кількість пірів
geth attach /data/bsc/geth.ipc --exec "net.peerCount"
# Якщо 0 — проблема з P2P підключенням (firewall, порти)

Порти, які потрібно відкрити: 30303/tcp та 30303/udp для P2P. RPC (8545) та WS (8546) — лише на localhost або за reverse proxy з аутентифікацією.

Snap sync: що відбувається

При snap sync нода не скачує та не верифікує кожен історичний блок. Замість цього скачується snapshot поточного стану (state trie), а потім нода догоняє свіжі блоки. Це значно швидше (години замість днів), але нода не може відповідати на запити типу eth_call або eth_getBalance для історичних блоків — лише для недавніх.

Snap sync займає ~6–24 години на NVMe SSD при хорошому зв'язку.

Nginx reverse proxy з rate limiting

Не виставляйте RPC напрямку. Мінімальна захист:

upstream bsc_rpc {
    server 127.0.0.1:8545;
}

server {
    listen 443 ssl;
    server_name rpc.yourdomain.com;

    location / {
        limit_req zone=rpc_limit burst=50 nodelay;
        proxy_pass http://bsc_rpc;
        proxy_set_header Host $host;
    }
}

# У http блоці:
limit_req_zone $binary_remote_addr zone=rpc_limit:10m rate=100r/s;

Відкритий без захисту RPC швидко починає отримувати запити від ботів, що сканують мережу.