Развертывание ноды 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
    1220
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    921
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1148
  • 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 minimum, 64 GB рекомендуется для стабильной работы
Disk:  2 TB NVMe SSD (HDD не подходит — слишком медленные I/O)
Net:   100 Mbps+, желательно с хорошей задержкой до азиатских пиров
OS:    Ubuntu 22.04 LTS

BSC производит блок каждые ~3 секунды (vs 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 быстро начинает получать запросы от ботов, сканирующих сеть.