Требования к ноде Polygon PoS в 2026 году: Heimdall-v2, Bor и архивная нода

На полной ноде Polygon PoS работают два клиента: Heimdall-v2 и Bor. Документация Polygon требует 8 ядер и 32 ГБ оперативной памяти (рекомендуется 16 ядер и 64 ГБ), 4–6 ТБ быстрого хранилища и 1 Гбит/с; архивной ноде нужны 16 ядер, 64 ГБ и 16 ТБ. В октябре 2026 г. снапшот Bor с полной историей после распаковки занимает около 7,3 ТБ.

Требования взяты из документации Polygon для разработчиков (в которой сеть теперь называется Polygon Chain) по состоянию на 15 октября 2026 г. Большинство старых руководств устарели из-за двух изменений: 10 июля 2025 г. Heimdall-v2 заменил исходный Heimdall, а 1 августа 2026 г. Polygon Labs прекратила поддержку Erigon, поэтому архивные ноды теперь работают на Bor.

Коротко

Цифры «на практике» — это размеры снапшотов от PublicNode, провайдера из сообщества, который указан в документации Polygon; причины расхождения объясняются в разделе о диске.

Официальные аппаратные требования к ноде Polygon PoS

На странице предварительных требований Polygon каждая цифра приведена в формате «минимум/рекомендуемое значение». Нода — это одна машина, на которой работают оба клиента: Heimdall-v2 — уровень консенсуса на базе Cosmos SDK и CometBFT, и Bor — уровень исполнения на базе Go Ethereum, который производит блоки. В руководствах по установке Bor запускается только после того, как Heimdall синхронизировался.

На других официальных страницах цифры другие. Страница по устранению неполадок при медленной синхронизации Bor рекомендует 6 000 IOPS и удвоение характеристик ноды, которая не успевает за сетью; а в README Bor до сих пор указан минимум в 4 ядра, 8 ГБ оперативной памяти и 1 ТБ — намного меньше, чем в таблице, и меньше нынешнего объёма данных блокчейна.

Сколько места на диске нужно полной ноде Polygon?

Страница снапшотов Polygon оценивает размер ноды основной сети так:

Эти цифры не согласуются друг с другом: при росте 105 ГБ в день 3,5 ТБ, остающихся свободными на диске объёмом 8 ТБ после восстановления 4,5 ТБ данных, хватит примерно на месяц. Сколько данные весят сегодня, видно по провайдерам снапшотов. Ниже — список PublicNode на 15 октября 2026 г., пересчитанный из байтов в десятичные единицы; на странице PublicNode размеры показаны в двоичных единицах, поэтому полный снапшот, обозначенный там как «6.0 TB», здесь указан как 6,63 ТБ.

Что это означает при выборе объёма диска:

• Ноде с полной историей нужно больше 8 ТБ. Полный каталог данных (datadir) Bor уже превышает рекомендуемые документацией 6 ТБ и почти заполняет предлагаемые там же 8 ТБ. Команда Bor snapshot prune-block «работает только со схемой хранения на основе хешей», а Bor теперь по умолчанию использует схему path с PebbleDB, поэтому история блоков накапливается.
• Темпы роста неясны. По нашим расчётам, более новая часть полного снапшота с блоками, выпущенными начиная с 2 сентября 2025 г., занимает 4,13 ТБ: в среднем около 10 ГБ в день — десятая часть темпа, указанного в документации. В июне 2026 г. изменились и время блока, и лимит газа, поэтому измеряйте рост на собственной ноде, а при планировании закладывайте осторожную оценку в 105 ГБ в день.
• Ноды с обрезкой компактны, но не описаны в документации. Снапшот Bor с обрезкой достигает той же высоты, занимая 109 ГБ; разница приходится в основном на данные старых блоков. Документация Polygon лишь советует валидаторам «регулярно выполнять обрезку нод, чтобы сократить использование диска», поэтому, прежде чем обслуживать RPC с такой ноды, узнайте у провайдера снапшота, какую историю он сохраняет.
• Heimdall компактен. С июня 2026 г. его штатная конфигурация отключает индекс транзакций CometBFT и выполняет обрезку каждые 10 минут, что, по данным Polygon, освобождает около 23 ГБ на RPC-ноде основной сети. Полная история Heimdall с момента миграции 2025 г. занимает 3,7 ТБ; один только файл генезиса основной сети весит около 3 ГБ.
• Используйте локальный NVMe. Как сказано в документации, от IOPS диска зависят распаковка, синхронизация и уплотнение; хранилище с прямым подключением там названо идеальным, пользователям AWS предлагается выделять 16 000 IOPS, а для архива — 20 000+. Массивы жёстких дисков до этого далеко не дотягивают.

На странице снапшотов перечислены шесть провайдеров из сообщества и агрегатор All4nodes. Со снапшотом нода синхронизируется «за часы, а не за дни»; синхронизация из сети, как предупреждает руководство по полной ноде, занимает несколько дней.

Архивная нода Polygon: Bor с PBSS, а не Erigon

В таблице предварительных требований строка архивной ноды по-прежнему подписана как Erigon, а обзор Polygon Chain всё ещё называет Erigon «также поддерживаемым». И то и другое устарело:

• 17 сентября 2025 г.: с выпуском Erigon v3.1.0 поддержка клиента Polygon PoS перешла от команды Erigon к Polygon Labs.
• 12 мая 2026 г.: Polygon Labs объявила о прекращении поддержки Erigon «к 1 августа» и рекомендовала для архивных нод «Bor с PBSS», то есть со схемой хранения состояния на основе путей.
• 3 августа 2026 г.: репозиторий 0xPolygon/erigon переведён в архив. Его README исключает дальнейшие выпуски и обновления безопасности и предупреждает, что существующие развёртывания будут синхронизироваться только до следующего хардфорка Bor; им стал Austin, активированный 13 августа.

В объявлении приведён config.toml для основной сети. Его ключевые строки:

chain = "mainnet"
datadir = "/var/lib/bor/data"
"db.engine" = "pebble"
"state.scheme" = "path"
syncmode = "full"
gcmode = "archive"

[history]
  transactions = 0   # 0 = index the entire chain
  logs = 0
  state = 0          # 0 = keep state history back to genesis

[cache]
  cache = 24576
  gomemlimit = "55GB"

• Диск. Архив Bor со схемой path от PublicNode занимает 12,95 ТБ — в пределах 16 ТБ из документации. Добавьте 10 ГБ на Heimdall с обрезкой или 3,7 ТБ на архивный Heimdall.
• Память. Кэш на 24 ГБ и лимит памяти Go в 55 ГБ подразумевают не менее 64 ГБ оперативной памяти, как и указано в строке архивной ноды.
• API. Bor поддерживает eth_getProof только для последних 128 блоков. Пространство имён trace_* в стиле Parity по умолчанию отключено и требует архивной ноды и --rpc.enabletrace; trace_block не включает транзакции state-sync до блока 80 084 800.
• Установщик. Шаблон архивной ноды основной сети в пакетах Bor по-прежнему задаёт state.scheme = "hash". Перед первым запуском замените это значение настройками, приведёнными выше.

Требования к валидатору Polygon: sentry-нода плюс валидатор

Валидатор — это две ноды, каждая из которых соответствует требованиям к полной ноде: публичная sentry-нода и валидатор, «доступный только через свою sentry-ноду». Документация Polygon добавляет:

• Дополнительные компоненты. RabbitMQ на валидаторе; RPC-эндпоинт Ethereum — от провайдера или с собственной ноды (см. наше руководство по оборудованию для нод Ethereum); а начиная с Heimdall-v2 — ключ подписи, импортированный в keyring.
• Стейк и слоты. Не менее 100 000 POL собственного стейка для новых валидаторов (PIP-70) и не более 105 активных валидаторов, поэтому новичкам приходится ждать, пока освободится слот; подача заявки его не гарантирует.
• Расходы в Ethereum. Подписывать чекпоинты нужно примерно каждые 15–20 минут, а для их отправки на адресе подписанта нужно держать от 0,5 до 1 ETH.
• Минимальная производительность. Подписание оценивается за последние 700 чекпоинтов относительно 98% от медианы по набору валидаторов; при падении ниже этого порога следуют два льготных периода по 700 чекпоинтов каждый, а затем принудительный вывод из стейкинга.
• Единственное назначение. Только Bor, Heimdall и RabbitMQ, без публичного RPC и без портов, доступных из интернета: 30303 и 26656 открыты только для sentry-ноды, SSH — через VPN.

Если медианный валидатор подписывает каждый чекпоинт, 98% от 700 допускают около 14 пропусков: по нашим расчётам, это от трёх с половиной до почти пяти часов простоя за окно. Это говорит в пользу зеркальных дисков и быстрых перезапусков. В Bor v2.10.3, выпущенном 15 октября 2026 г., переработана предзагрузка trie, которая выполняется при перезапуске, и появилась возможность сохранять её кэш адресов (по умолчанию отключено, около 9 ГБ в основной сети); по данным Polygon, на sentry-ноде основной сети время предзагрузки сократилось примерно с 1 ч 25 мин до 4 с.

Процессор и ОЗУ: почему 16 ядер и 64 ГБ

Документация Polygon указывает число ядер, а не тактовые частоты, но темп работы сети объясняет уровень в 16 ядер. Согласно журналу изменений Polygon, с 3 июня 2026 г. основная сеть выпускает блок каждые 1,5 с, а июньское повышение лимита газа до 160 млн увеличило пропускную способность примерно до 106,66 Mgas/s. Bor исполняет транзакции параллельно с помощью BlockSTM v2, который включён по умолчанию начиная с v2.9.1, а конфигурация Bor по умолчанию выделяет параллельной EVM 8 воркеров.

Скорость проявляется, когда нода догоняет сеть. Страница по устранению неполадок требует импорта быстрее 2 блоков в секунду; при таком минимуме ноде, восстановленной из снапшота суточной давности, нужно около 12 часов, чтобы догнать вершину цепочки, потому что сеть продолжает добавлять по блоку каждые 1,5 с (наши расчёты).

Что касается памяти, минимальные 32 ГБ и рекомендуемые 64 ГБ оставляют место для кэшей Bor: его шаблон sentry-ноды для основной сети отводит под них 4 ГБ, а приведённая выше архивная конфигурация — в шесть раз больше.

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

Таблица объединяет данные со страниц предварительных требований и сетевой конфигурации. Как предупреждает Polygon, без TCP и UDP на порту 30303 нода «будет с трудом находить пиров».

Для всех типов нод требуется 1 Гбит/с, а месячного объёма трафика документация не приводит. Основную часть составляет первая загрузка: 6,6 ТБ снапшотов полной ноды скачиваются примерно за 15 ч при стабильных 1 Гбит/с, архив на 11,9 ТБ — примерно за 26 ч. Порт 10 Гбит/с сокращает это время примерно до 1,5 и 2,6 ч, если сервер-зеркало успевает отдавать данные, а на порту 10 Гбит/с без учёта трафика этот объём никогда не попадает в счёт.

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

Схема RAID выбирается при заказе или переустановке: на серверах с двумя накопителями — RAID 1 (по умолчанию), RAID 0 или без RAID, а на серверах с четырьмя NVMe-накопителями дополнительно RAID 10 (там он используется по умолчанию) и RAID 5; подробности — в нашем руководстве по программному RAID.

Оговорки, без обиняков:

• Ни один сервер с двумя накопителями больше не вмещает ноду основной сети с полной историей. В режиме чередования самые ёмкие пары дают 7,68 ТБ — лишь примерно на 0,4 ТБ больше нынешнего объёма данных. EPYC 9555P — самая младшая из подходящих конфигураций; её запаса в 4,2 ТБ в RAID 5 хватит больше чем на год при среднем темпе роста за 13 месяцев, но лишь примерно на 40 дней при указанных в документации 105 ГБ в день.
• Валидаторам — зеркало, архивам — чередование. Допустимый простой валидатора — несколько часов, поэтому держите RAID 1 на обеих машинах. В строке архивной ноды Polygon сама указывает RAID 0, а архив с чередованием, потерявший накопитель, можно восстановить из снапшотов примерно за сутки загрузки на скорости 1 Гбит/с. RAID 5 — промежуточный вариант: он переживает отказ одного накопителя ценой накладных расходов на запись данных чётности.
• Архив при более скромном бюджете. EPYC 9555P в RAID 0 вмещает нынешний архив Bor на 12,95 ТБ с запасом около 2,4 ТБ, хотя это меньше 16 ТБ из документации. EPYC 9965 соответствует и этой цифре, оставляя запас; его базовая частота 2,25 ГГц — самая низкая среди наших EPYC, так что выбирайте его ради накопителей, а не ядер.
• Что не подходит. Наши серверы хранения: их массивы жёстких дисков не обеспечивают IOPS, которых требует Polygon. Не подходит это и тем, кто только читает данные блокчейна: документация советует им вместо этого RPC-эндпоинты.

Документация Polygon не привязывает размещение нод к региону, поэтому выбирайте город, ближайший к вашим пользователям: 9950X3D доступен в Амстердаме, Франкфурте, Нью-Йорке и Лос-Анджелесе, 9555P — в Амстердаме, Франкфурте, Нью-Йорке и Токио, 9965 — в Амстердаме, Франкфурте и Нью-Йорке.

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

В этих шагах используются установщики пакетов и команды из руководств Polygon по полной ноде с последними выпусками на 15 октября 2026 г.; имена файлов снапшотов условные.

# 1. Install Heimdall-v2 and Bor ("sentry" is the full-node profile)
curl -L https://raw.githubusercontent.com/0xPolygon/install/heimdall-v2/heimdall-v2.sh | bash -s -- v0.12.2 mainnet sentry
curl -L https://raw.githubusercontent.com/0xPolygon/install/main/bor.sh | bash -s -- v2.10.3 mainnet sentry

# 2. Initialize Heimdall for mainnet and fetch the migrated genesis (about 3 GB)
sudo -u heimdall heimdalld init my-node --chain-id=heimdallv2-137 --home /var/lib/heimdall
cd /var/lib/heimdall/config
curl -fsSL https://storage.googleapis.com/mainnet-heimdallv2-genesis/migrated_dump-genesis.json -o genesis.json

# 3. Restore community snapshots into the data directories (follow the provider's steps)
lz4 -dc HEIMDALL_SNAPSHOT.tar.lz4 | tar -x

# 4. Start Heimdall; start Bor only once "catching_up" is false
sudo service heimdalld start
curl localhost:26657/status
sudo service bor start
journalctl -u bor.service -f

Если в ваших шаблонах не заданы seeds для Heimdall и bootnodes для Bor, возьмите их из списка seed-нод в документации. Три предостережения:

• Обновления выходят часто. Основная сеть прошла хардфорки 2 июня, 25 июня (Zurich), 29 июля (Ithaca), 13 августа (Austin, требуется Bor v2.10.0 или новее) и 1 октября 2026 г. (Lugano, Heimdall v0.12.1). Ноды Heimdall, оставшиеся на v0.11.0 или более старой версии, остановились на высоте активации Lugano.
• Пока не используйте руководство по Docker. В нём зафиксированы образы Bor 1.1.0 и Heimdall-v2 0.2.16 из Docker Hub — версии, которые не могут следовать за основной сетью после этих хардфорков, а начиная с Bor v2.10.2 и Heimdall v0.12.2 образы там больше не публикуются.
• После восстановления проверьте владельцев файлов. В совете о правах доступа на странице снапшотов два каталога перепутаны местами: владельцем datadir Bor должен быть пользователь bor, а datadir Heimdall — heimdall.

Прежде чем открывать что-либо, кроме 26656 и 30303, пройдите наш чек-лист по защите сервера в первый час.

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

Нужна ли мне собственная нода Polygon? Не для того, чтобы отправлять транзакции или время от времени читать данные блокчейна: тем, кому нужно лишь подключение, страница предварительных требований предлагает список RPC-эндпоинтов Polygon. Собственная нода имеет смысл для валидаторов, индексаторов и приложений, объём запросов которых перерастает возможности общих эндпоинтов.

Можно ли запустить валидатор Polygon на PowerDedi? Да: наша политика допустимого использования разрешает ноды и валидаторы, но не майнинг. Наличие, локации и способы оплаты криптовалютой — на странице хостинга блокчейн-нод.

Источники

• Предварительные требования и Известные проблемы и ошибки — документация Polygon для разработчиков (проверено 15 октября 2026 г.)
• Синхронизация ноды с помощью снапшотов — документация Polygon для разработчиков
• Использование бинарных файлов, Использование пакетов и Использование Docker — документация Polygon для разработчиков
• Сетевая конфигурация, Обзор Polygon Chain и Изменения по сравнению с v1 — документация Polygon для разработчиков
• Как стать валидатором, Рекомендации для валидаторов и Требования к производительности валидатора — документация Polygon для разработчиков
• Журнал изменений — документация Polygon для разработчиков (записи с 1 июня по 12 октября 2026 г.)
• Прекращение поддержки Erigon (12 мая 2026 г.) и Новости Erigon и планы на будущее (30 сентября 2025 г.) — Polygon Labs на форуме Polygon
• 0xPolygon/erigon — GitHub (переведён в архив 3 августа 2026 г.)
• README Bor, default_config.toml, snapshot prune-block, шаблон архивной ноды для основной сети и примечания к выпускам v2.10.2 и v2.10.3 — 0xPolygon/bor на GitHub
• Примечания к выпускам v0.12.1 (Lugano) и v0.12.2 — 0xPolygon/heimdall-v2 на GitHub
• Плановая миграция Heimdall V1 → V2 — Polygon Status
• Быстрые снапшоты нод для 100+ блокчейнов — PublicNode by Allnodes (проверено 15 октября 2026 г.)