Как настроить ноду Binance Smart Chain (BSC)

BNB Smart Chain — до сих пор часто ищут под названием Binance Smart Chain, которое действовало до февраля 2022 года — это EVM-сеть, производящая блок каждые 0,45 секунды после хардфорка Fermi в январе 2026 года, после того как Maxwell уже вдвое сократил интервал до 0,75 секунды в середине 2025 года. Такая скорость приятна пользователям и требовательна к операторам нод: full-нода BSC хочет серверного железа и правильной стратегии синхронизации, и ошибка в любом из этих пунктов означает ноду, которая никогда не догонит голову цепи. Этот гайд — версия «копировать-вставить» там, где заканчивается официальная документация: настройка на основе снапшота с форком geth от bnb-chain, systemd-юнит, заметки по безопасности для RPC-нод, расчёт времени синхронизации и затрат, а также честный взгляд на то, когда вам вообще не стоит её запускать.

Что такое нода BSC и какой тип вам нужен?

Нода BSC запускает клиент сети, валидирует блоки и даёт вам локальный JSON-RPC-эндпоинт с тем же интерфейсом, что и Ethereum: eth_blockNumber, eth_call, eth_sendRawTransaction и остальные. На практике важны четыре варианта.

Full-нода хранит недавнее состояние и обслуживает RPC — вариант по умолчанию и тема этого гайда. Fast-нода — это full-нода, запущенная с --tries-verify-mode none; официальная документация рекомендует её для RPC-нагрузок, где скорость импорта важнее строгой проверки state trie. Архивная нода хранит всё историческое состояние, требует места на диске в размере десятков терабайт и имеет смысл только для индексации и аналитики. Валидатор производит блоки, что требует избрания в небольшой набор валидаторов с застейканным BNB — отдельная тема, выходящая за рамки гайда по настройке.

А лёгкая нода? Форк geth унаследовал код light-клиента, но на практике почти ничто в BSC не обслуживает лёгких пиров, так что считайте «лёгкую ноду BSC» недоступной. Если обрезанная full-нода — это больше, чем вам нужно, это именно тот случай, когда лучше подходит API — см. последний раздел.

Тот же выбор в виде таблицы, с цифрами по диску на середину 2026 года:

BSC и Geth: одна кодовая база, две сети

Клиент BSC — это форк go-ethereum, поддерживаемый на github.com/bnb-chain/bsc, а бинарник буквально называется geth. Он говорит на том же JSON-RPC, принимает большинство тех же флагов и добавляет специфику BSC: консенсус proof-of-staked-authority Parlia (один процесс — это вся нода, отдельного клиента консенсуса, как в post-merge Ethereum, здесь нет), плюс флаги вроде --tries-verify-mode. Отсюда следуют два практических вывода. Ваши инструменты для Ethereum работают без изменений против ноды BSC. И вам нужно использовать сборку bnb-chain — апстрим-Geth не может синхронизировать BSC, и это самая частая ошибка новичков с «bsc geth».

Требования к железу для ноды BSC

Базовые цифры взяты из README bnb-chain/bsc, скорректированы с учётом роста данных до 2026 года:

Строка, которая убивает большинство установок, — это IOPS, а не объём. При блоках по 0,45 секунды нода пишет непрерывно, и облачное блочное хранилище со стандартными IOPS отстаёт от головы цепи и никогда не догоняет её. Референс из README — AWS gp3 с 8000 выделенных IOPS и задержкой чтения ниже миллисекунды (класс инстанса m5zn.3xlarge на AWS, c2-standard-16 на Google Cloud); локальный NVMe-диск в выделенном сервере проходит эту планку с запасом.

Пошагово: full-нода BSC из официального снапшота

Синхронизация с генезиса возможна, но это плохая идея. Сама документация не рекомендует этого — для попытки предлагается железо на 40k+ IOPS, и всё равно уходят недели. Поддерживаемый путь: скачать снапшот данных сети, запустить на нём ноду, дать ей догнать голову. Команды рассчитаны на Ubuntu 24.04.

1. Подготовка сервера

sudo apt update && sudo apt install -y aria2 lz4 unzip jq
sudo useradd --no-create-home --shell /usr/sbin/nologin bsc
sudo mkdir -p /var/lib/bsc
sudo chown bsc:bsc /var/lib/bsc
sudo ufw allow 30311 comment 'bsc p2p'

Порт 30311 — это peer-to-peer порт BSC и единственный блокчейн-порт, который должен быть открыт. RPC-порт остаётся на localhost.

2. Скачивание бинарника geth от bnb-chain

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="geth_linux") | .browser_download_url' \
  | xargs wget -O geth_linux
chmod +x geth_linux
sudo mv geth_linux /usr/local/bin/geth-bsc
geth-bsc version

Переименование бинарника в geth-bsc предотвращает классическую ошибку — запуск установленного из дистрибутива апстрим-geth против данных BSC.

3. Получение config.toml и genesis.json

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="mainnet.zip") | .browser_download_url' \
  | xargs wget -O mainnet.zip
unzip -o mainnet.zip
sudo mv config.toml genesis.json /var/lib/bsc/
sudo chown bsc:bsc /var/lib/bsc/config.toml /var/lib/bsc/genesis.json

Примечание: geth-bsc init genesis.json нужен только при синхронизации с генезиса. При пути через снапшот вы пропускаете init — снапшот приносит свою собственную базу данных.

4. Скачивание и распаковка снапшота

Снапшоты лежат на github.com/bnb-chain/bsc-snapshots, официальном репозитории. По состоянию на середину 2026 года там публикуются три набора данных: обрезанный снапшот размером около 1,6 ТБ в сжатом виде (только недавние блоки — правильный выбор для этого гайда), полный снапшот размером около 6 ТБ, и инкрементальные снапшоты, которые забирают только изменения с предыдущего снапшота — дополнение эпохи Fermi (BEP-593). Текущее поколение требует клиент версии v1.7.2 или новее, чему уже удовлетворяет загрузка из шага 2. Репозиторий также предоставляет скрипт fetch-snapshot.sh, который скачивает, проверяет контрольную сумму MD5 (флаг -c) и распаковывает одной командой; ручной путь ниже показывает, что происходит под капотом. Два способа доставить архив на диск:

cd /var/lib/bsc
# Option A: resumable download, needs space for archive + extracted data
sudo -u bsc aria2c -x8 -s8 -c '<PASTE_SNAPSHOT_URL>'
sudo -u bsc bash -c "lz4 -cd geth.tar.lz4 | tar -x"

# Option B: stream-extract, needs space only once, but no resume
sudo -u bsc bash -c "wget -qO- '<PASTE_SNAPSHOT_URL>' | lz4 -d | tar -x"

aria2c скачивает по восьми соединениям и продолжает после обрывов (-c) — с обычным wget прерванная многотерабайтная загрузка начинается заново. После распаковки база данных цепи должна находиться в /var/lib/bsc/geth/chaindata; структура архива менялась между поколениями снапшотов, поэтому при необходимости перенесите внутреннюю папку geth туда. Проверяйте перед распаковкой: сравните MD5 со страницы снапшота, либо пусть этим займётся fetch-snapshot.sh -c — терабайтный архив с испорченным битом обойдётся вам в целый день. Опции A нужно место для архива и распакованных данных одновременно, для обрезанного набора это около 2 ТБ запаса, и именно поэтому рекомендуется диск на 4 ТБ.

5. systemd-юнит

Создайте /etc/systemd/system/bsc.service:

[Unit]
Description=BSC full node (bnb-chain geth fork)
After=network-online.target
Wants=network-online.target

[Service]
User=bsc
Group=bsc
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
LimitNOFILE=65536
ExecStart=/usr/local/bin/geth-bsc \
  --config /var/lib/bsc/config.toml \
  --datadir /var/lib/bsc \
  --cache 8000 \
  --tries-verify-mode none \
  --history.transactions 0 \
  --rpc.allow-unprotected-txs \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3

[Install]
WantedBy=multi-user.target

--tries-verify-mode none — это переключатель «fast node» из официальной документации, рекомендуемый для обслуживания RPC, когда вы принимаете компромисс по согласованности состояния. --history.transactions 0 поддерживает индекс транзакций полным; более старые гайды используют для той же цели устаревший --txlookuplimit 0. TimeoutStopSec=600 даёт ноде десять минут на сброс данных при остановке — жёсткие завершения рано или поздно повреждают базу данных.

6. Запуск и проверка

sudo systemctl daemon-reload
sudo systemctl enable --now bsc
journalctl -fu bsc

Здоровый вывод — это стабильный поток строк «Imported new chain segment». Сравните вашу высоту с публичным эксплорером:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  http://127.0.0.1:8545

Преобразуйте hex-результат и сверьте его с bscscan.com. Когда eth_syncing возвращает false, а высота совпадает, нода в строю.

Защита RPC-ноды BSC

Юнит выше привязывает RPC к 127.0.0.1, что правильно для ноды, которую использует только локальный софт. Если доступ нужен другим машинам, не открывайте порт 8545 напрямую в интернет. Поставьте перед ней nginx или Caddy с TLS, токеном авторизации или allowlist IP-адресов и rate limiting. Держите --http.api на eth,net,web3 — никогда не открывайте admin, debug или txpool на доступной извне ноде. Неаутентифицированные публичные эндпоинты BSC обнаруживаются и заваливаются запросами в течение нескольких дней, а неограниченные вызовы eth_getLogs способны свалить даже мощное железо. P2P-порт 30311 остаётся единственным открытым блокчейн-портом. Стоит упомянуть одно отличие от Ethereum: здесь нет engine API и JWT-секрета, потому что Parlia не нуждается в отдельном клиенте консенсуса — файрвол и привязка к localhost составляют весь периметр, поэтому они должны быть настроены правильно.

Мониторинг и проверки состояния

Нода BSC отказывает одним типичным способом: процесс продолжает работать, пока нода отстаёт от головы. Проверки аптайма на уровне процесса это полностью пропускают, так что проверяйте вместо этого статус синхронизации и высоту.

# false = at the head; a sync object = still catching up
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

# peer count as hex
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

Более строгая проверка сравнивает ваш eth_blockNumber со вторым источником — публичным эндпоинтом или эксплорером — каждые несколько минут и сигнализирует, если разрыв растёт. Откалибруйте порог под темп BSC: 400 блоков звучит как много, а это три минуты времени сети при блоках по 0,45 секунды. Пороги, скопированные из инструментов для Ethereum, здесь сильно занижены.

Форк наследует стек метрик Geth. Начните с --metrics (эндпоинт Prometheus на порту 6060, держите его на localhost), и стандартные дашборды Geth для Grafana в основном работают без изменений. Перед любым дашбордом настройте два алерта: использование диска выше 85 процентов и отсутствие роста локальной высоты блока в течение пяти минут. Ежедневный journalctl -u bsc --since -24h | grep -ci error в письме от cron завершает картину — растущее число ошибок предвещает большинство сбоев за несколько дней.

Время синхронизации и почему снапшоты остаются полезными

Арифметика вместо обещаний: обрезанный снапшот в 1,6 ТБ при устойчивых 100 МБ/с скачивается около 4,5 часов, при 50 МБ/с — около 9. Распаковка ограничена диском и добавляет несколько часов на NVMe. Снапшот отстаёт от головы цепи на день-два; здоровая нода импортирует в несколько раз быстрее реального времени, так что наверстывание стоит часов, а не дней. В целом планируйте один рабочий день. Синхронизация с генезиса, для сравнения, идёт неделями даже на экстремальном железе — поэтому официальная рекомендация — снапшот, и точка.

Рост состояния и pruning

База данных продолжает расти и после первого дня — состояние растёт с каждым новым контрактом и аккаунтом, данные блоков — в темпе, задаваемом блоками по 0,45 секунды. Точный рост зависит от активности сети; вместо того чтобы доверять фиксированному числу, запускайте du -sh /var/lib/bsc/geth/chaindata еженедельно и стройте собственную линию тренда. Ожидаемая закономерность: сотни гигабайт за квартал, а не за год.

Три инструмента держат размер под контролем. geth-bsc snapshot prune-state — встроенный оффлайн-pruning: он отбрасывает узлы состояния, на которые больше ничто не ссылается, занимает много часов на многотерабайтной базе данных, и всё это время нода ничего не обслуживает. Wipe-and-restore — альтернатива, которую предпочитают многие операторы: раз в несколько месяцев удалять datadir и восстанавливать самый свежий обрезанный снапшот. Общее время простоя часто меньше, чем при pruning, и в качестве бонуса вы получаете свежесжатую базу данных.

Третий инструмент появился вместе с Fermi: инкрементальные снапшоты (BEP-593). Вместо повторной загрузки 1,6 ТБ при каждом обновлении, вы забираете только то, что изменилось с уже имеющегося у вас поколения снапшота, что превращает периодическое обновление из ночной задачи в дело нескольких часов. README bsc-snapshots документирует этот рабочий процесс рядом с классическими архивами.

Erigon на BSC — и его преемник

Годами ответом на потребности в архивных данных BSC был bsc-erigon, порт Erigon от NodeReal: полная архивная синхронизация с нуля примерно за три дня, хранящаяся на примерно 4,3 ТБ, тогда как форку geth нужны десятки терабайт. Эта глава закрыта. Поддержка завершилась в 2025 году, а репозиторий node-real/bsc-erigon был заархивирован в апреле 2026 года — только для чтения, без исправлений, без поддержки будущих форков. NodeReal направляет операторов к Reth-BSC, преемнику на Rust, как к рекомендуемому архивному клиенту на будущее.

Что это значит на практике в середине 2026 года: для обрезанной RPC-ноды из этого гайда официальный форк geth остаётся эталоном и самым безопасным выбором. Для архивных нагрузок сначала оцените Reth-BSC, а существующие машины на bsc-erigon рассматривайте как ожидающую миграцию — неподдерживаемый клиент пропустит следующий хардфорк в назначенный срок.

Сколько стоит нода BSC

Воспринимайте это как способ расчёта, а не как прайс-лист. Класс 16 ядер / 64 ГБ / 4 ТБ NVMe — это территория выделенных серверов, ни один честный тариф VPS этого не покрывает. У европейских хостеров машины с такими характеристиками находятся, как порядок величины, в диапазоне от низких до средних сотен евро в месяц. Те же характеристики, собранные из облачных инстансов с 8k выделенных IOPS (референс AWS из README), как правило, обходятся дороже, часто в два раза и более, потому что выделенные IOPS оплачиваются отдельно.

Затем добавьте свои часы: первоначальная настройка — один рабочий день по этому гайду, плюс обновления при хардфорках и обновление снапшотов — несколько часов в месяц. Умножьте на свою почасовую ставку. У большинства команд статья расходов на труд в итоге превышает статью на хостинг — полезно знать это до того, как вы возьмёте на себя обязательства.

Обслуживание: хардфорки и обновления

BSC делает хардфорки с темпом, который удивляет операторов Ethereum. Только 2025 год принёс Lorentz и Maxwell, каждый из которых вдвое сокращал интервал блоков; за ними последовал Fermi 14 января 2026 года, сокративший блоки с 0,75 до 0,45 секунды и добавивший инкрементальные снапшоты вместе с усилением быстрой финальности. У каждого форка есть минимальная версия клиента — v1.6.4 для Fermi — и нода ниже этой версии останавливается на блоке форка с ошибками консенсуса. По состоянию на середину 2026 года линейка релизов находится на v1.7.x, и текущие снапшоты предполагают как минимум v1.7.2.

Поэтому подпишитесь на ленту релизов bnb-chain/bsc на GitHub и относитесь к обновлениям как к рутине, а не как к событиям. Процедура короткая: скачать новый geth_linux, проверить его, остановить сервис, заменить /usr/local/bin/geth-bsc, запустить снова — база данных сохраняется. В release notes указываются изменения конфигурации, а BSC переименовывает флаги чаще, чем апстрим-Geth, так что просматривайте их перед перезапуском, а не после. Закладывайте четверть часа на релиз и ожидайте форк каждые несколько месяцев.

Для сред разработки локальная приватная сеть доступна через тулкит BSC-Deploy вместо запуска mainnet-нод.

Устранение неполадок

Нода импортирует блоки, но продолжает отставать от головы

Почти всегда дело в IOPS диска. Проведите бенчмарк с fio и сравните с референсом в 8k IOPS; сетевое хранилище со стандартными IOPS — обычный виновник. Убедитесь, что установлен --tries-verify-mode none. Если железо ниже таблицы требований, никакой флаг не закроет разрыв.

Ошибки «missing trie node», или нода начинает синхронизацию с блока 0 после восстановления из снапшота

Неверная структура datadir. База данных цепи должна находиться в <datadir>/geth/chaindata — если в логе видно «Writing custom genesis block», geth нашёл пустой datadir и начал заново. Остановите сервис, переместите распакованную папку geth в правильное место, запустите снова.

Число пиров остаётся близким к нулю

Проверьте, что порт 30311 открыт и проброшен. Устаревший config.toml — второй подозреваемый: списки bootstrap- и статических нод меняются со временем, поэтому перекачайте mainnet.zip из последнего релиза. На домашних подключениях дополнительно проверьте NAT.

lz4 сообщает «Decoding error» при распаковке

Архив неполный. Возобновите загрузку с aria2c -c и сравните размер файла с указанным на странице снапшота, прежде чем распаковывать снова. Помните, что опции A нужно свободное место для архива и распакованных данных одновременно.

OOM killer завершает ноду

journalctl -k | grep -i oom решает этот вопрос. Юнит задаёт --cache 8000, а реальное потребление памяти при наверстывании заметно превышает значение кеша — это не проблема при рекомендуемых 64 ГБ, но проблема на урезанном железе. Снижайте --cache прежде, чем снижать что-либо другое, держите swap включённым как буфер на случай сбоя, и помните, что убитая OOM нода ничего не сбрасывает: следующий запуск может встретить вас случаем «missing trie node» из раздела выше.

Диск заполняется

Сначала df -h, затем du -h --max-depth=2 /var/lib/bsc, чтобы найти рост. Забытые архивы снапшотов — самая частая находка: один обрезанный .tar.lz4 весит около 1,6 ТБ, и опция A оставляет его после себя, если вы пропустите очистку. Если проблема в самом chaindata, обновитесь с самого свежего обрезанного снапшота или выполните оффлайн-pruning (см. раздел о росте состояния). На кривой роста BSC заполненный диск — это ошибка планирования, а не невезение; алерт на 85 процентов из раздела о мониторинге существует именно для того, чтобы дать вам нужную неделю.

Часто задаваемые вопросы

Нода Binance Smart Chain — это то же самое, что нода BNB Smart Chain?

Да. Сеть переименовали из Binance Smart Chain в BNB Smart Chain в феврале 2022 года. Документация, бинарники и этот гайд описывают одну и ту же сеть; изменился только брендинг.

Насколько велика full-нода BSC в 2026 году?

Официальный обрезанный (pruned) снапшот занимает примерно 1,6 ТБ в сжатом виде по состоянию на середину 2026 года, полный снапшот — около 6 ТБ, а рабочая база данных вместе с данными для наверстывания — около 2–3 ТБ. С учётом временного места, нужного при распаковке снапшота, реалистичный размер — NVMe-диск на 4 ТБ.

Можно ли запустить ноду BSC на обычном Ethereum Geth?

Нет. BSC использует консенсус Parlia и собственные правила протокола; синхронизировать её может только форк на github.com/bnb-chain/bsc. Идентичное имя бинарника вызывает эту путаницу — отсюда переименование в geth-bsc на шаге 2.

Существует ли лёгкая (light) нода BSC?

Практически нет. Код light-клиента есть в форке, но сеть почти не обслуживает лёгких пиров. Ваши реалистичные варианты — обрезанная full-нода, fast-нода или API.

Зарабатываю ли я BNB, запуская full-ноду?

Нет. Награды за блоки идут избранному набору валидаторов, что требует значительного застейканного BNB и голосов сообщества. Full-нода даёт вам независимый доступ к сети, а не доход.

Запускать собственную ноду — или использовать API?

Честное сравнение, ведь Chaingateway продаёт альтернативу.

Запускайте ноду, когда вы потребляете сырой JSON-RPC в большом, устойчивом объёме — индексация, бэктестинг, сканирование логов по миллионам блоков — или когда никакая третья сторона не должна находиться между вами и сетью. Выделенный сервер — это фиксированная стоимость с неограниченным числом запросов, и начиная с определённого объёма вызовов он обходит любой тарифицируемый план. Точка безубыточности на BSC наступает быстрее, чем на большинстве сетей, именно потому что порог по железу высок, но стабилен.

Используйте API, когда нода была бы просто трубой для платежей. Синхронизированная full-нода BSC даёт вам eth_sendRawTransaction и логи; всё, что реально нужно платёжной системе — депозитные адреса на клиента, обнаружение входящих BEP-20-переводов, подписанные webhook, хранение ключей, повторные попытки — это софт, который вам пришлось бы строить поверх и поддерживать в рабочем состоянии. Эти инженерные часы по ставкам из раздела о расходах намного превышают счёт за сервер.

API BNB Smart Chain от Chaingateway покрывает этот уровень как REST: импорт адресов (POST /api/v2/bsc/addresses/import), отправка BEP-20-токенов (POST /api/v2/bsc/transactions/bep20), и получение подписанных HMAC депозитных webhook — GET /api/v2/bsc/webhooks/notifications/failed перечисляет неудавшиеся доставки, и каждую можно переотправить через эндпоинт повтора. Точка безубыточности одной фразой: выделенный сервер плюс ваши часы на разработку и эксплуатацию против тарифа на /ru/pricing/. Для платёжных потоков API остаётся дешевле далеко за пределами масштаба малого бизнеса; для сырой мощности RPC нода выигрывает рано. Quickstart и гайд по webhook доведут вас до первого теста за минуты, а 7-дневный пробный период не требует KYC (регистрация).

Запускаете и другие сети? См. гайды по настройке для Ethereum и TRON.