Требования к ноде BNB Smart Chain в 2026 году: полная, быстрая и архивная нода

Согласно документации BNB Chain, полной ноде BNB Smart Chain нужны 16 ядер, 64 ГБ оперативной памяти, быстрый SSD и канал 5 МБ/с, а валидатору — 128 ГБ, 7 ТБ NVMe и 512 Мбит/с. Диск — величина подвижная: снапшоты за октябрь 2026 г. в сжатом виде занимали около 1,9 ТБ с обрезкой и 7,4 ТБ с полной историей.

Большинство этих цифр относится ко времени до хардфорка Fermi 14 января 2026 г., который сократил интервал между блоками в BSC до 0,45 с. Ниже мы сравниваем их со снапшотами за октябрь 2026 г., называем архивный клиент, пришедший на смену BSC-Erigon, и подбираем сервер для каждого типа ноды.

Коротко

Размеры снапшотов приведены для сжатых загружаемых файлов; для их распаковки BNB Chain просит предусмотреть дополнительное место. Цифры для архивной ноды в документации писались для Erigon, который больше не поддерживается.

Официальные аппаратные требования BNB Chain

Требования BNB Chain разбросаны по страницам, которые обновлялись не одновременно. Страница Node Best Practices, последний раз обновлённая 18 июля 2024 г., задаёт для любого типа ноды 16 ядер и не менее 5 МБ/с, а также:

• Быстрая нода, помеченная как «рекомендуемая конфигурация»: 32 ГБ оперативной памяти и SSD на 2 ТБ.
• Полная нода: 64 ГБ оперативной памяти и SSD на 3 ТБ.
• Архивная нода: 128 ГБ оперативной памяти и 10 ТБ SSD, причём NVMe «рекомендуется для оптимальной производительности».

README клиента bsc добавляет требования к производительности диска для полной ноды основной сети: «3 ТБ (дек. 2023 г.) свободного места на диске», 8k IOPS, 500 МБ/с и задержка чтения менее 1 мс на NVMe для snap-синхронизации, а также 16 ядер, 64 ГБ и 5 МБ/с на приём и на передачу, то есть около 40 Мбит/с. Страница Node Maintenance, обновлённая в феврале 2026 г., повторяет цифры для диска.

С апреля 2025 г. три хардфорка сократили интервал между блоками с 3 секунд до 1,5, 0,75 и 0,45, и объём данных рос вместе с ними: по собственному правилу репозитория снапшотов, согласно которому свободного места должно быть вдвое больше размера снапшота, указанных в README 3 ТБ уже не хватает даже для снапшота с обрезкой.

Сколько места на диске нужно ноде BSC в октябре 2026 г.

BNB Chain не рекомендует синхронизироваться с генезис-блока и ежемесячно публикует снапшоты Geth в своём репозитории bsc-snapshots: полный снапшот со всеми блоками начиная с генезис-блока и снапшот с обрезкой, содержащий только состояние и недавние блоки. Сумма размеров файлов из их списков даёт такую кривую роста (в сжатом виде):

За двенадцать месяцев в цепочку добавилось около 62 млн блоков; полный снапшот вырос на 73%, то есть примерно на 260 ГБ в месяц, а снапшот с обрезкой — на 48%, примерно на 50 ГБ в месяц, причём с августа темп ускорился (около 350 и 75 ГБ). Это наш расчёт на основе списков файлов BNB Chain, а не официальный прогноз. Из этого следуют три вывода:

• Закладывайте больше места, чем занимает загрузка. README требует «дополнительного места на диске для распаковки», а более старое руководство — «как минимум вдвое больше размера снапшота». Снапшот с обрезкой — это один архив на 1 899 ГБ, который хранится рядом с распакованными данными, если только не передавать загрузку потоком прямо в tar, отказавшись от проверки MD5.
• Существуют снапшоты сообщества меньшего размера. 48Club, упомянутый в репозитории BNB Chain, 15 октября 2026 г. опубликовал снапшоты в формате zstd на 1 371,98 ГБ (полная нода) и 460,87 ГБ (быстрая нода) на блоке 127 680 000; оба настроены на хранение последних 600 000 блоков.
• Время восстановления определяется пропускной способностью канала. При устойчивой скорости 1 Гбит/с загрузка снапшота с обрезкой занимает около 4 часов, полного — около 16½; при указанных в документации 5 МБ/с — около 4½ и 17 дней соответственно.

Быстрая нода, нода с обрезкой или полная история: что вам нужно

Все три варианта работают на клиенте bnb-chain/bsc на основе Geth и различаются объёмом хранимой истории и проверкой состояния:

• Полная история используется по умолчанию (--history.blocks 0, «вся цепочка»). Такая нода отдаёт любой старый блок, транзакцию или квитанцию, как того требуют обозреватели блоков и индексаторы, и обходится в указанные выше 7,4 ТБ.
• Недавняя история: снапшот с обрезкой с параметром --history.blocks=600000 и соответствующими ограничениями индексов хранит блоки примерно за 75 часов и при этом проверяет каждый корень состояния (--tries-verify-mode=local, значение по умолчанию).
• Быстрая нода: --tries-verify-mode none пропускает проверку корней состояния, и, как сказано в справке клиента, остаётся «очень небольшая вероятность того, что состояние не будет согласовано с другими пирами». После выполнения geth db delete-trie-state «вернуться к полной ноде невозможно» без нового снапшота.

Ни один из этих вариантов не является архивной нодой. В FAQ по снапшотам BNB Chain сказано, что «через RPC можно запросить состояние только последних 129(128+1) блоков» — это меньше минуты при 0,45 с на блок, — и что быстрая нода при отсутствии состояния может вернуть 0 вместо ошибки. Для балансов или состояния контрактов на более старых блоках нужна архивная нода.

Ловушка в документации: страница Node Maintenance по-прежнему рекомендует --pruneancient и офлайн-инструмент prune-block. Выпуск v1.5.18 объявил первый устаревшим, а второй удалил; на смену обоим пришёл --history.blocks.

Архивная нода BSC: Reth-BSC пришёл на смену Erigon

Страница BNB Chain об архивной ноде, последний раз обновлённая в январе 2025 г., по-прежнему рекомендует BSC-Erigon от NodeReal, который способен «синхронизировать архивную ноду с нуля всего за 3 дня, используя 4,3 ТБ дискового пространства», при 64 ГБ оперативной памяти и минимум 5 ТБ на диске. Этот совет устарел. Согласно уведомлению о прекращении поддержки BSC-Erigon, разработка и сопровождение клиента прекращены после 31 декабря 2025 г., а пользователей направляют на Reth-BSC; репозиторий был архивирован 23 апреля 2026 г. Последний выпуск, v1.4.3, вышел до хардфорков Mendel (апрель 2026 г.) и Pasteur (август 2026 г.), а оба они — обязательные обновления.

Его преемник, Reth-BSC, находится в организации bnb-chain на GitHub:

• Зрелость. README называет проект «экспериментальным и находящимся в активной разработке». Выпуск v0.1.1 от июля 2026 г. назначил хардфорк Pasteur в основной сети; v0.1.2 исправил проблему с корнем состояния на этом переходе.
• Объём. Архивный снапшот основной сети от 2 октября 2026 г. занимает в сумме 7 461,58 ГБ в восьми сжатых файлах и требует параметра --db.max-size=12TB. На диске он занимает больше: в сентябре 2025 г. README называл 10,6 ТБ, а в сентябре 2026 г. один из операторов сообщил о 793 ГБ в MDBX плюс 12 ТБ статических файлов.
• Скорость диска. В двух задачах (issues) за сентябрь и октябрь 2026 г. об отставании архивных нод на виртуальных или облачных дисках один из участников проекта назвал вероятным узким местом производительность диска и посоветовал использовать локальный NVMe. У одного оператора нода начинала отставать при нагрузке выше примерно 180 RPC-запросов в секунду.

Планируйте архивную ноду из расчёта 16 ТБ локального NVMe или больше, а не 10 ТБ, указанных в 2024 г., и не менее 16 ядер и 128 ГБ памяти. README Reth-BSC помечает режим --full как «рекомендуемый»; снапшот основной сети для этого режима на 2 октября занимал 3 473,25 ГБ.

Требования к валидатору BSC: оборудование и стейк

Страница Run BSC Validator, обновлённая 6 февраля 2026 г., задаёт более высокую планку, чем для любого другого типа ноды:

• Вычисления: AWS i7i.8xlarge или i7ie.6xlarge, «лучше отключить HyperThread, что может дать прирост производительности 10%+», «или другая конфигурация инстанса, обеспечивающая >=400 mgasps». По данным AWS, это 32 vCPU с 256 ГиБ и 24 vCPU с 192 ГиБ на процессорах Xeon Scalable 5-го поколения с турбочастотой 3,2 ГГц на всех ядрах, то есть 16 и 12 ядер без Hyper-Threading.
• Память: 128 ГБ.
• Диск: «ВАЖНО: 7 ТБ, NVMe SSD, 40k IOPS, пропускная способность 500 МБ/с, задержка чтения <1 мс».
• Сеть: 512 Мбит/с или больше.

Клиент записывает в лог показатель mgasps (миллионы единиц газа в секунду) в каждой строке «Imported new chain segment»; проверьте его, пока нода догоняет сеть после восстановления из снапшота, — ещё до регистрации валидатора.

Сверх этого нужен стейк: не менее 2 000 BNB самоделегирования. Ежедневные выборы определяют 45 валидаторов с наибольшим стейком — 21 в группе «Cabinets» и 24 в группе «Candidates», — и в каждой эпохе блоки производят 21 из них. Пропуск более 50 блоков за 24 часа лишает вознаграждения; пропуск более 150 обходится в 10 BNB и два дня блокировки (jail); одновременная подпись одними и теми же ключами на двух машинах считается двойной подписью (double sign) и наказывается слэшингом 200 BNB и блокировкой на 30 дней.

Поэтому резервная нода, которую рекомендует BNB Chain, берёт работу на себя через miner.stop() на одной машине и miner.start() на другой и никогда не работает как второй активный подписант; закладывайте в бюджет два сервера. Валидатор может открыть свой IP или скрыться за sentry-нодами, как описано в руководстве по Enhanced Validator Network (EVN). Это руководство не называет конкретного региона, но приводит измеренные в AWS задержки: около 100 мс из Азиатско-Тихоокеанского региона в Европу, 80 мс из Азиатско-Тихоокеанского региона в США и 35 мс из США в Европу — при интервале между блоками 450 мс.

Порты и пропускная способность

В разделе документации BNB Chain о файрволе для TCP- и UDP-портов Geth указан 30303, а JSON-RPC предлагается держать закрытым, «потому что через него можно выполнять административные операции». Однако в config.toml, поставляемом с v1.7.8, задано ListenAddr = ":30311" — порт, который указан в списках пиров EVN и Reth-BSC; откройте тот, который использует ваша конфигурация. В примере со снапшотом Reth-BSC привязывает RPC к 0.0.0.0, поэтому закройте его файрволом.

Месячный объём трафика не оценивает ни одна страница; поставляемая конфигурация допускает 200 пиров (MaxPeers = 200). На порту 10 Гбит/с без учёта трафика ни загрузка снапшотов, ни трафик с пирами в счёте не отражаются.

Какой сервер PowerDedi выбрать для ноды BSC

У каждой конфигурации ниже — собственный порт 10 Гбит/с без учёта трафика и помесячная оплата. Схему дисков вы выбираете при заказе или переустановке: на серверах с двумя накопителями по умолчанию используется RAID 1, также доступны RAID 0 и No RAID (без RAID); на EPYC 9555P и 9965 с четырьмя накопителями по умолчанию используется RAID 10, также доступны RAID 5 и RAID 0 — подробнее в нашем руководстве по программному RAID.

Компромиссы без обиняков:

• RAID 0 — это ставка на снапшоты. Чередование удваивает ёмкость сервера с двумя накопителями, но отказ накопителя означает переустановку и восстановление: несколько часов для ноды с обрезкой и большая часть суток для полной истории при 1 Гбит/с. Зеркало переживает отказ накопителя; для валидатора же настоящее резервирование — это резервная нода.
• Полная история перерастает два накопителя. При 7,4 ТБ в сжатом виде и приросте от 260 до 350 ГБ в месяц на двух накопителях по 3,84 ТБ для неё нет места даже в режиме чередования. На EPYC 9555P RAID 5 оставляет около 4 ТБ сверх сжатого объёма — примерно на год при таком темпе; RAID 0 даёт 15,36 ТБ, но без защиты от отказа.
• Восстановление на 3,84 ТБ — впритык. На 9950X3D в зеркале или 9950X в режиме чередования правило BNB Chain о двойном объёме снапшота для архива с обрезкой на 1 899 ГБ занимает почти весь том; передавайте загрузку потоком или используйте снапшот 48Club меньшего размера. У EPYC 4585PX ($179/мес) те же накопители, что у 9950X, плюс память ECC.
• Альтернативы для архива. EPYC 9555P в RAID 0 тоже даёт 15,36 ТБ, причём дешевле, но без резервирования и с небольшим запасом. Наши серверы хранения не подходят: их ёмкость приходится на жёсткие диски, а BNB Chain везде требует SSD или NVMe.
• Когда PowerDedi — не лучший выбор. При нагрузке ниже примерно 33 запросов в секунду и без eth_getLogs может хватить публичных эндпоинтов BNB Chain (см. ниже).

Локации: 9950X — в Амстердаме, Франкфурте, Лондоне, Нью-Йорке, Майами, Лос-Анджелесе, Сингапуре и Токио; 9950X3D — в Амстердаме, Франкфурте, Нью-Йорке и Лос-Анджелесе; 9555P — в Амстердаме, Франкфурте, Нью-Йорке и Токио; 9965 — в Амстердаме, Франкфурте и Нью-Йорке. Размещайте RPC-ноду рядом с вашим приложением; для валидатора BNB Chain не даёт рекомендаций по региону, поэтому после синхронизации измерьте задержку до пиров.

Как запустить полную ноду BSC: краткий план настройки

Эти шаги следуют руководству BNB Chain по полной ноде и README снапшотов с одним изменением: зафиксируйте выпуск. Руководство скачивает «последний» (latest) выпуск с GitHub, которым в октябре 2026 г. был v1.8.0-alpha — предварительная версия, «не предназначенная для продакшена»; самым новым стабильным выпуском был v1.7.8 от 11 августа 2026 г.

# 1. Pinned binary and mainnet config (config.toml, genesis.json)
wget https://github.com/bnb-chain/bsc/releases/download/v1.7.8/geth_linux
mv geth_linux geth
chmod -v u+x geth
wget https://github.com/bnb-chain/bsc/releases/download/v1.7.8/mainnet.zip
unzip mainnet.zip

# 2. Download, verify and extract the pruned snapshot into the datadir
wget https://raw.githubusercontent.com/bnb-chain/bsc-snapshots/main/dist/fetch-snapshot.sh
bash fetch-snapshot.sh -d -e -c -p --auto-delete -D /data/snapshot -E /data/bsc mainnet-geth-pbss-20261009

# 3. Start with recent history only (docs: --cache of about a third of RAM)
./geth --config ./mainnet/config.toml --datadir /data/bsc --cache 20000 --rpc.allow-unprotected-txs --syncmode=full --tries-verify-mode=local --history.transactions=600000 --history.blocks=600000 --history.logs=600000

# 4. Follow the import speed (mgasps)
tail -f /data/bsc/bsc.log | grep "Imported new chain segment"

Останавливайте ноду командой kill -HUP, как в документации, а не kill -9, после которого приходится заново воспроизводить недавние блоки. Запускайте её как службу systemd и открывайте только SSH и P2P-порт. Валидатору дополнительно нужны --mine --vote, а также ключ консенсуса и ключ голосования BLS, созданные командами geth account new и geth bls account new.

Частые вопросы

Нужна ли собственная нода, чтобы пользоваться BNB Smart Chain? Для эпизодического использования — нет. Публичные эндпоинты основной сети BNB Chain допускают 10 000 запросов за пять минут, то есть около 33 в секунду, причём eth_getLogs на них отключён. Индексаторы, биржи и торговые системы, которые читают логи событий или которым нужна большая пропускная способность, запускают собственную ноду или платят RPC-провайдеру.

Можно ли запустить её на VPS или облачном инстансе? README упоминает «VPS», а страница о валидаторах называет инстансы AWS с локальным NVMe. Слабое место — сетевое блочное хранилище: обе отстававшие ноды Reth-BSC, о которых говорилось выше, работали на виртуальных или облачных дисках.

Является ли запуск валидатора «майнингом»? Нет. Флаг --mine включает производство блоков по алгоритму Proof of Staked Authority. Запуск нод и валидаторов на PowerDedi разрешён, а майнинг криптовалют — нет.

О других EVM-блокчейнах читайте в нашем руководстве по оборудованию для нод Ethereum. Актуальное наличие серверов — на странице хостинга блокчейн-нод, оплата в BTC, ETH, XMR, USDT в сети TRON или SOL.

Источники

• Конфигурация ноды BNB Smart Chain (BSC): лучшие практики — документация BNB Chain (обновлено 18 июля 2024 г.)
• Запуск валидатора BSC — документация BNB Chain (обновлено 6 февраля 2026 г.)
• Полная нода, Быстрая нода в BNB Smart Chain и Обслуживание нод — документация BNB Chain (обновлено 6 февраля 2026 г.)
• Как запустить архивную ноду в BNB Smart Chain — документация BNB Chain (обновлено 23 января 2025 г.)
• Обзор валидаторов BSC (обновлено 17 июля 2025 г.) и Лучшие практики EVN — документация BNB Chain
• Эндпоинт JSON-RPC — документация BNB Chain (обновлено 19 августа 2026 г.)
• README bnb-chain/bsc и выпуски, в том числе v1.5.10, v1.5.18 и v1.6.4, а также config.toml для основной сети из выпуска v1.7.8 — BNB Chain на GitHub
• О снапшотах BSC (снапшот от 9 октября 2026 г. и прошлые списки файлов) и FAQ — bnb-chain/bsc-snapshots на GitHub
• bsc-snapshots — 48Club на GitHub (блок 127 680 000, 15 октября 2026 г.)
• Reth @ BSC, его выпуски и задачи #500, #517 и #544 — bnb-chain/reth-bsc на GitHub (сентябрь и октябрь 2026 г.)
• Клиент BSC-Erigon: уведомление о прекращении поддержки — node-real/bsc-erigon на GitHub (архивирован 23 апреля 2026 г.)
• Инстансы Amazon EC2 I7i — Amazon Web Services (описаны I7i и I7ie)