Требования к ноде Avalanche в 2026 году: AvalancheGo и валидаторы

Согласно документации Avalanche на октябрь 2026 г., валидатору Avalanche при небольшом стейке нужны 4 ядра/8 потоков, 16 ГБ оперативной памяти, локальный NVMe SSD на 1 ТБ и симметричный канал 100 Мбит/с, а при крупном стейке — 8 ядер/16 потоков, 32 ГБ, 2 ТБ и 1 Гбит/с. Архивной ноде C-Chain нужно 12,5 ТБ или больше.

Эти цифры взяты со страницы системных требований (System Requirements) в Avalanche Builder Hub, пересмотренной в начале октября 2026 г. в связи с обновлением Helicon, которое действует в основной сети с 22 сентября 2026 г. Helicon не изменил уровни требований к оборудованию, но изменил обслуживание диска и правила стейкинга. Это руководство посвящено оборудованию, планированию дискового пространства и настройке; оно не является рекомендацией по стейкингу или финансовой консультацией.

Коротко

В строке L1 приведены уровни для низкой, средней и высокой пропускной способности. Для каждого уровня указаны Ubuntu 22.04 LTS или macOS 12 и новее, каждая нода должна принимать входящие TCP-подключения на порт 9651, а валидатор Primary Network ставит в стейк не менее 2 000 AVAX.

Оборудование валидатора: почему уровень зависит от стейка

Avalanche определяет требования к валидаторам Primary Network по весу стейка: «Валидаторы с более крупным стейком получают больше трафика и должны обрабатывать больше данных, что требует более мощного оборудования». Валидаторы опрашивают друг друга с вероятностью, пропорциональной стейку, поэтому нода с большим объёмом делегирования отвечает на большее число запросов. Документация приводит примеры процессоров — Ryzen 5 или Core i5 для небольшого стейка и Ryzen 7/9 или Core i7/i9 для крупного, — но не указывает порога между уровнями и советует начинать с нижнего уровня, а наращивать ресурсы, когда процессор, память или сеть загружены до предела.

Минимальные требования приводят три официальных источника:

Если считать vCPU аппаратными потоками, 8 vCPU из README соответствуют уровню для небольшого стейка. В вопросе о типе хранилища источники расходятся: страница требований говорит, что валидаторы обязаны использовать локальный NVMe, поскольку облачное блочное хранилище «вносит задержки, которые приводят к низкой производительности, пропущенным блокам и возможному отстранению (benching)», а ACP-256 допускал бы сетевое хранилище для валидаторов, чьё хранимое состояние занимает менее 500 ГБ. На выделенном сервере с NVMe в корпусе такой вопрос не возникает.

Сколько места на диске нужно ноде Avalanche

Для ноды Primary Network документация определяет объём диска по состоянию EVM в C-Chain:

Ориентируйтесь на среднюю строку. Со схемой состояния hash, используемой по умолчанию, нода с обрезкой каждые 4 096 блоков записывает снапшот для синхронизации состояния, с которого могут синхронизироваться другие ноды, и «в этом состоянии работает большинство давно запущенных валидаторов». Нода, начавшая с 500 ГБ, может за несколько месяцев превысить 1 ТБ. Документация рекомендует оповещения о заполнении диска на 80% и 90% и называет использование диска «самой распространённой проблемой валидаторов».

Helicon убрал возможность исправить это на месте. Раньше эти снапшоты удалялись офлайн-обрезкой на той же машине. После Helicon C-Chain в AvalancheGo v1.15.0 и новее игнорирует offline-pruning-enabled, а документация называет новую синхронизацию состояния «единственным способом удалить накопившиеся снапшоты». Периодическая синхронизация состояния устроена так: вторая нода работает, пока не синхронизируется, затем обе ноды останавливают и переносят staker.crt, staker.key и signer.key на новую, которая продолжает валидацию под тем же NodeID после остановки, обычно длящейся от 5 до 15 минут. Цепочки L1 на Subnet-EVM по-прежнему могут выполнять офлайн-обрезку.

От объёма диска зависит, как часто придётся выполнять повторную синхронизацию. При старте с 500 ГБ, росте на 150–200 ГБ в месяц и реагировании на оповещение при 80% (наши расчёты):

• 1 ТБ: повторная синхронизация каждые 1,5–2 месяца.
• 1,92–2 ТБ: каждые 5–7 месяцев.
• 3,84 ТБ: каждые 13–17 месяцев.

Насколько актуальны эти размеры? История репозитория документации позволяет их датировать: цифра 12,5 ТБ для архива появилась 18 декабря 2025 г. (заменив «~3 ТБ+»), цифра ~13 ТБ — 22 декабря, а темпы роста — 4 февраля 2026 г., когда оценка роста архива увеличилась примерно с 250 до 500 ГБ в месяц. Ревизия под Helicon ни одну из них не изменила. Если применить эти темпы к декабрьской цифре, к середине октября 2026 г. полный архив составит примерно 15–18 ТБ: это наша экстраполяция, а не измерение, и именно поэтому мы подбираем серверы для архивов из расчёта 20 ТБ или больше.

Синхронизация состояния и бутстрап после Helicon

Синхронизация состояния (state sync), включённая по умолчанию для C-Chain и рекомендуемая для новых валидаторов, загружает последнее состояние с других валидаторов вместо воспроизведения каждого блока с генезис-блока: часы вместо дней. Примечания к выпуску v1.15.0 добавляют три ограничения:

• Перезапуск ноды посреди синхронизации «запустит синхронизацию с самого начала», поэтому сначала завершите обновления ОС и перезагрузки.
• Отключение синхронизации состояния после частичной синхронизации «может привести к неустранимой ошибке FATAL»; для восстановления придётся удалить базу данных.
• Экспериментальная схема состояния Firewood не поддерживает синхронизацию состояния, поэтому нода на Firewood в основной сети исполняет каждый блок начиная с генезис-блока.

Требования к архивной ноде C-Chain

Архив хранит состояние на каждом блоке — для запросов вроде баланса аккаунта на блоке 1 000 000; по документации, он нужен только «обозревателям блоков, индексаторам и специализированным аналитическим приложениям». Для него требуются "pruning-enabled": false и "state-sync-enabled": false в конфигурации C-Chain, а затем полная синхронизация с генезис-блока. Чтобы превратить в архив существующую ноду, потребуется бутстрап с нуля.

Более лёгкий вариант — синхронизация состояния с отключённой обрезкой — даёт ноду «архивного RPC» с полным состоянием начиная с высоты синхронизации: сначала 750 ГБ–1 ТБ, затем рост как у архива. Такая нода не может отвечать на запросы о более ранних блоках, но обходится в малую долю стоимости архива с генезис-блока.

Для архивов Avalanche не приводит цифр по процессору и ОЗУ. ACP-256 называет для них локальный NVMe обязательным, а в версии v1.15.1, выпущенной 1 октября 2026 г., исправлено отставание исполнения блоков «на больших архивах hashdb», поэтому используйте актуальный выпуск.

Правила стейкинга для валидаторов после Helicon

Правила Primary Network в основной сети на октябрь 2026 г.:

Вознаграждения выплачиваются по принципу «всё или ничего», без слэшинга: валидатор ниже порога сохраняет основную сумму стейка, но лишается вознаграждений. Аптайм оценивают другие валидаторы с учётом веса их стейка, поэтому проверяйте info.uptime и панель Validator Health. Допустимые 10% простоя — это 4,8 ч при валидации длительностью 48 ч и 33,6 ч при двухнедельной. Валидатор со сроком стейкинга менее двух недель не может получать делегирования, поскольку делегирование должно длиться две недели и укладываться в период валидатора.

Helicon также добавил стейкинг с автопродлением (ACP-236): валидатор задаёт длину цикла и долю повторного стейкинга и продлевается на границе каждого цикла, пока выполняет требование по аптайму; установка периода в 0 останавливает продление. Классическую валидацию после создания нельзя изменить или досрочно отозвать.

Валидаторы L1 после ACP-77 (Avalanche9000)

Обновление Etna, также известное как Avalanche9000, активировало ACP-77 в основной сети 16 декабря 2024 г. и отделило валидацию L1 от Primary Network. Валидатор L1:

• Не ставит в стейк 2 000 AVAX и не валидирует C-Chain и X-Chain. Правила стейкинга задаёт собственный менеджер валидаторов L1, а правило аптайма 90% из ACP-267 не применяется.
• Платит непрерывную комиссию P-Chain с предоплаченного баланса: не менее 512 nAVAX в секунду, около 1,33 AVAX в месяц, пока активно не более 10 000 валидаторов L1. Сверх этого целевого значения ставка растёт экспоненциально, а валидатор с исчерпанным балансом деактивируется.
• Синхронизирует только P-Chain с флагом --partial-sync-primary-network=true. Без этого флага нода синхронизирует также X-Chain и C-Chain, и, согласно документации, к требованиям нужно добавить требования Primary Network.

При частичной синхронизации требования растут вместе с трафиком: 2 ядра, 4 ГБ и 100 ГБ — при нагрузке ниже примерно 10 TPS; 4 ядра, 8 ГБ и SSD на 500 ГБ — до 100 TPS; 8+ ядер, 16 ГБ+ и 1 ТБ+ NVMe — при более высокой нагрузке.

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

Валидатору с недоступным портом 9651 или неверно объявленным адресом грозит низкий аптайм; руководство по стейкингу предлагает решение — --public-ip плюс открытый порт. Установщик спрашивает, должен ли RPC быть публичным или приватным, и предупреждает, что у нод валидаторов «НЕ ДОЛЖНО быть открытого RPC-порта».

Avalanche указывает пропускную способность как скорость канала и не приводит месячного объёма трафика. У каждого сервера PowerDedi собственный порт 10 Гбит/с без учёта трафика, поэтому ни трафик валидатора, ни повторная синхронизация на 500 ГБ не попадают в счёт. Перед портом 9651 работает постоянно включённая сетевая защита от DDoS, а маршрутизируемая подсеть IPv6 /64 включена в стоимость.

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

У всех конфигураций ниже локальный NVMe и помесячная оплата; наша политика допустимого использования разрешает ноды и валидаторы, но не майнинг. На серверах с двумя накопителями по умолчанию используется RAID 1 — зеркало с ёмкостью одного накопителя; RAID 0 или No RAID (без RAID) можно выбрать при заказе или переустановке, как объясняется в нашем руководстве по программному RAID. На серверах с четырьмя накопителями по умолчанию используется RAID 10, также доступны RAID 5 и RAID 0.

Четыре оговорки:

• Чередование или зеркало. Данные блокчейна можно синхронизировать заново, поэтому RAID 0 — разумный компромисс ради ёмкости, если ключи стейкинга сохранены в резервной копии вне сервера. Но тогда отказ накопителя обойдётся в несколько часов синхронизации состояния, а правило 90% оставляет лишь 4,8 ч при валидации длительностью 48 ч. При коротких валидациях оставайтесь на зеркале.
• Для повторной синхронизации нужна вторая машина. Согласно документированной процедуре, новый сервер синхронизируется, пока старый продолжает валидацию; конфигурации из наличия выдаются примерно через 15 минут после подтверждения платежа в блокчейне. Наш совет: чередуйте два сервера, удаляя ключи и базу данных старой ноды после каждой смены. Никогда не запускайте одновременно две ноды с одними и теми же ключами стейкинга.
• Сервер для архива — это прежде всего диски. Только EPYC 9965 вмещает архив с генезис-блока с запасом, поэтому вы арендуете 192 ядра ради 30,72 ТБ сырой ёмкости NVMe. RAID 5 добавляет запись данных чётности; RAID 0 отдаёт весь объём, но без защиты. Наши серверы хранения держат основную ёмкость на жёстких дисках, а их исключает требование локального NVMe.
• Расположение. Документация Avalanche не предъявляет требований к расположению, поэтому выбирайте город, удобный для вашей работы.

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

Быстрее всего на свежем сервере Ubuntu воспользоваться скриптом-установщиком Avalanche: он поддерживает дистрибутивы семейств Debian и RHEL на amd64 или arm64 и устанавливает последнюю версию AvalancheGo как службу systemd — на середину октября 2026 г. это v1.15.1, а после Helicon для основной сети нужна версия v1.15.0 или новее. Команды из документации:

# 1. Download the installer
wget -nd -m https://raw.githubusercontent.com/ava-labs/builders-hub/master/scripts/avalanchego-installer.sh
chmod 755 avalanchego-installer.sh

# 2. Validator: fixed IP, local-only RPC, state sync on
#    (public API node: --rpc public, behind a firewall)
./avalanchego-installer.sh --ip static --rpc private --state-sync on

# 3. Follow the bootstrap, then check the C-Chain
sudo journalctl -u avalanchego -f
curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.isBootstrapped","params":{"chain":"C"}}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info

# 4. NodeID, BLS public key and proof of possession, needed to stake
curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.getNodeID"}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info

Для полного архива флаг установщика --archival отключает обрезку. В скрипте, который мы скачали 15 октября 2026 г., при сочетании этого флага с --state-sync off две настройки записываются без запятой между ними, а это невалидный JSON. Пока это не исправлено, после установки остановите службу (sudo systemctl stop avalanchego), приведите ~/.avalanchego/configs/chains/C/config.json в соответствие с блоком ниже, проверьте его с помощью python3 -m json.tool и снова запустите службу:

{
  "pruning-enabled": false,
  "state-sync-enabled": false
}

Затем сохраните резервные копии staker.crt, staker.key и signer.key из ~/.avalanchego/staking вне сервера: при потере staker.key нода получит новый NodeID, а при потере signer.key BLS-ключ перестанет соответствовать вашему зарегистрированному валидатору. Закройте файрволом всё, кроме SSH и порта 9651, по нашему чек-листу по защите сервера в первый час и зарегистрируйте валидатор через Core web, platform-cli или инструмент стейкинга в Builder Console.

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

Нужна ли мне собственная нода, чтобы стейкать AVAX? Нет. Для делегирования существующему валидатору нужны 25 AVAX минимум на две недели и никакого оборудования; валидатор удерживает комиссию не менее 2% от ваших вознаграждений.

Можно ли запустить валидатор на VPS или облачном инстансе? Только с локальным NVMe: страница требований исключает облачное блочное хранилище, такое как AWS EBS или GCP Persistent Disk.

Работает ли AvalancheGo в Windows? Больше нет: в версии v1.13.3, выпущенной 22 июля 2025 г., поддержка Windows удалена.

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

Источники

• Системные требования — Avalanche Builder Hub (редакция октября 2026 г.)
• Управление состоянием цепочки и Периодическая синхронизация состояния — Avalanche Builder Hub
• Введение и Как участвовать в стейкинге — Avalanche Builder Hub
• Обновление Helicon — Avalanche Builder Hub; Helicon: улучшенная экономика стейкинга и непрерывное исполнение — блог Avalanche Builder Hub (8 сентября 2026 г.)
• Конфигурация C-Chain и Флаги конфигурации AvalancheGo — Avalanche Builder Hub
• Установка AvalancheGo, Конфигурация и обслуживание ноды и Подготовка окружения — Avalanche Builder Hub; avalanchego-installer.sh — ava-labs/builders-hub на GitHub (просмотрено 15 октября 2026 г.)
• ACP-77: переосмысление Subnets и ACP-256: рекомендации по оборудованию — Avalanche Builder Hub
• Предпосылки Avalanche9000 — блог Avalanche Builder Hub
• README AvalancheGo — ava-labs/avalanchego на GitHub
• Выпуски AvalancheGo — Avalanche Builder Hub; примечания к выпускам v1.15.0, v1.15.1 и v1.12.0 (Etna) — ava-labs/avalanchego на GitHub
• История system-requirements.mdx и коммиты 291f09e, 972995c и 48c5190 — ava-labs/builders-hub на GitHub