На этой странице 8 разделов
По данным EIP-7870 — рекомендаций по оборудованию, которые поддерживают команды клиентов, — полной ноде Ethereum в 2026 году нужны 4-ядерный процессор, 32 ГБ оперативной памяти, NVMe SSD на 4 ТБ и подключение 50/15 Мбит/с. Валидатор должен иметь 8 ядер, 64 ГБ оперативной памяти и процессор с однопоточным рейтингом PassMark около 3 500. Архивная нода умещается примерно в 2–2,5 ТБ при использовании Reth, Erigon или архивного режима Geth на основе путей (path-based), а в устаревшем режиме на основе хешей (hash-based) ей нужно более 12 ТБ.
Коротко
| Роль | CPU | Однопоточный рейтинг (PassMark) | ОЗУ | Хранилище | Канал (приём / отдача) |
|---|---|---|---|---|---|
| Абсолютный минимум (ethereum.org) | От 2 ядер | — | 16 ГБ, рекомендуется 32 ГБ | 2 ТБ NVMe; вероятно, перестанет хватать к 2027 году | 25+ Мбит/с |
| Полная нода (EIP-7870) | 4 ядра / 8 потоков | около 1 000 | 32 ГБ | 4 ТБ NVMe | 50 / 15 Мбит/с |
| Валидатор («attester» по EIP-7870) | 8 ядер / 16 потоков | около 3 500 | 64 ГБ | 4 ТБ NVMe | 50 / 25 Мбит/с |
| Локальный сборщик блоков (EIP-7870) | 8 ядер / 16 потоков | около 3 500 | 64 ГБ | 4 ТБ NVMe | 100 / 50 Мбит/с |
EIP-7870 — информационный «живой» документ, созданный в январе 2025 г. и поддерживаемый в актуальном состоянии разработчиками клиентов; руководство ethereum.org по запуску ноды, последний раз обновлённое в августе 2026 г., повторяет его цифры. Они описывают ноду, которая уверенно успевает за сетью, а не минимальную машину, которая технически способна синхронизироваться.
Место на диске: сколько нужно каждому клиенту
Нода состоит из двух программ: клиента исполнения, который хранит состояние и историю, и клиента консенсуса, который следит за Beacon Chain. Почти весь объём диска приходится на клиент исполнения. Ethereum.org приводит такие размеры для основной сети:
| Клиент исполнения | Полная нода после snap-синхронизации | Полный архив |
|---|---|---|
| Besu | От 800 ГБ | 12+ ТБ |
| Erigon | без snap-синхронизации; около 2 ТБ при полной обрезке | 2,5+ ТБ |
| Geth | От 500 ГБ | 12+ ТБ в режиме hash-based; около 2 ТБ в режиме path-based |
| Nethermind | От 500 ГБ | 12+ ТБ |
| Reth | без snap-синхронизации; около 1,2 ТБ при полной обрезке | 2,2+ ТБ |
Добавьте около 200 ГБ на данные Beacon Chain, которые хранит клиент консенсуса. Затем заложите запас на рост: в документации Geth отмечается, что нода после snap-синхронизации с кэшем по умолчанию растёт примерно на 14 ГБ в неделю, пока не будет выполнена обрезка. Поэтому EIP-7870 требует 4 ТБ, хотя свежая полная нода занимает гораздо меньше 2 ТБ.
Удаление старой истории экономит 300–500 ГБ. С июля 2025 г. все основные клиенты могут удалять тела блоков и квитанции, относящиеся к периоду до The Merge, которые больше не нужны для консенсуса. В Geth (v1.16.0 и новее) запустите новую ноду с --history.chain postmerge или остановите существующую и выполните geth prune-history; Nethermind по умолчанию применяет это к новым нодам начиная с v1.32.2, а у Besu, Erigon и Reth есть собственные флаги, перечисленные в анонсе Ethereum Foundation.
Тип SSD важен не меньше, чем его объём. Ethereum.org не рекомендует накопители без DRAM и на QLC: нода выполняет непрерывный поток мелких случайных операций чтения и записи, а дешёвые потребительские SSD, которые замедляются при длительной нагрузке, могут привести к тому, что нода будет постоянно отставать от сети. Используйте NVMe-накопитель на TLC с DRAM и никогда не размещайте рабочую базу данных на жёстком диске.
Архивные ноды: 2 ТБ или 20 ТБ
Архивная нода хранит все исторические состояния, поэтому может отвечать на вопросы вроде «каким был этот баланс на блоке 15 000 000». Она нужна обозревателям блоков, индексаторам, аналитике и некоторым RPC-сервисам; кошелькам и валидаторам — нет.
- Архив Geth в режиме path-based (v1.16.0 и новее): около 2 ТБ для архива основной сети с полной историей или около 6,5 ТБ, если дополнительно хранить полные плоские состояния, и около двух недель на синхронизацию. Этот режим включается с помощью
--syncmode full --gcmode archive --history.state=0. Для исторических доказательств Меркла черезeth_getProofнужны v1.17 и параметр--history.trienode. - Erigon и Reth изначально спроектированы под компактные архивы: по данным ethereum.org, 2,5+ ТБ и 2,2+ ТБ соответственно.
- Архивы в режиме hash-based (устаревший режим Geth, Besu, Nethermind): более 12 ТБ, причём документация Geth предупреждает, что его hash-based база данных может превысить 20 ТБ, а синхронизация с генезис-блока может занять несколько месяцев.
Архивным нодам идут на пользу большие быстрые массивы NVMe и много памяти под кэши. Кроме того, Geth позволяет перенести историю состояний на более дешёвый и медленный накопитель с помощью --datadir.ancient.
Процессор: важна однопоточная производительность
Обработка блоков в основном последовательна, поэтому одно быстрое ядро значит больше, чем много медленных. EIP-7870 выражает это в виде целевого однопоточного рейтинга PassMark: около 1 000 для полной ноды и около 3 500 для валидатора или локального сборщика блоков, которые должны обрабатывать каждый блок достаточно быстро, чтобы вовремя подписывать аттестации или предлагать блоки. Вот как выглядят распространённые серверные процессоры по однопоточному рейтингу PassMark на октябрь 2026 г.:
| Процессор | Ядра / потоки | Однопоточный рейтинг | Ориентир для валидатора (~3 500) |
|---|---|---|---|
| AMD Ryzen 9 9950X3D | 16 / 32 | 4 737 | Выше |
| AMD Ryzen 9 9950X | 16 / 32 | 4 726 | Выше |
| AMD Ryzen 9 9900X | 12 / 24 | 4 670 | Выше |
| AMD EPYC 4585PX | 16 / 32 | 4 540 | Выше |
| Intel Xeon E-2488 | 8 / 16 | 4 300 | Выше |
| AMD Ryzen 7 7700 | 8 / 16 | 4 050 | Выше |
| AMD EPYC 9355P | 32 / 64 | 3 747 | Выше |
| AMD EPYC 9454P | 48 / 96 | 2 988 | Ниже; подходит для полных и архивных нод |
Многоядерные серверные процессоры жертвуют тактовой частотой ради общей производительности. Поэтому они отлично подходят для архивных нод, индексаторов и нескольких блокчейнов на одной машине и хуже — для чувствительного к задержкам валидатора.
Память и пропускная способность
Память. 32 ГБ достаточно, чтобы клиенты исполнения и консенсуса работали бок о бок; 64 ГБ дают валидатору запас для более крупных кэшей, клиента валидатора, MEV-Boost и мониторинга и исключают свопинг, из-за которого нода пропускает аттестации. Память сверх этого полезна для архивных нод и для нескольких нод на одном сервере.
Пропускная способность. EIP-7870 требует 50 Мбит/с на приём и 15 Мбит/с на отдачу для полной ноды, 25 Мбит/с на отдачу для валидатора и 50 Мбит/с на отдачу для локального сборщика блоков. Это минимальные значения: при первоначальной синхронизации скачиваются сотни гигабайт, а хорошо подключённая нода круглосуточно отдаёт блоки своим пирам. На подключении с учётом трафика следить нужно именно за исходящим трафиком; на порту без учёта трафика это не имеет значения. Документация Geth прямо не рекомендует тарифы с ограничением трафика.
Какой сервер для какой ноды
Вот как эти требования соотносятся с конфигурациями PowerDedi (у всех — порт 10 Гбит/с без учёта трафика):
| Что выбрать | Конфигурация | Почему | Цена |
|---|---|---|---|
| Полная нода или RPC для собственных приложений | Ryzen 9 9950X, 128 ГБ, 2 × 1,92 ТБ NVMe | Однопоточный рейтинг 4 726; всего 3,84 ТБ NVMe (1,92 ТБ в зеркале) | $159/мес |
| Валидатор | Ryzen 9 9950X3D, 192 ГБ, 2 × 3,84 ТБ NVMe | Выше ориентиров EIP-7870 для валидаторов по процессору и памяти; 3,84 ТБ NVMe в зеркале | $219/мес |
| Валидатор с памятью ECC | EPYC 4585PX, 128 ГБ ECC, 2 × 1,92 ТБ NVMe | Те же частоты Zen 5 плюс память с коррекцией ошибок | $179/мес |
| Архивная нода, индексатор или несколько блокчейнов | EPYC 9454P, 256 ГБ ECC, 2 × 3,84 ТБ NVMe | 48 ядер и двенадцать каналов памяти для параллельной работы | $489/мес |
| Большой архив или RPC на нескольких клиентах | EPYC 9555P, 768 ГБ ECC, 4 × 3,84 ТБ Gen5 | Четыре быстрых накопителя и память для больших кэшей | $949/мес |
Две честные оговорки. Ryzen 7 7700 за $79 в месяц соответствует ориентирам по процессору и памяти, но его 2 × 1 ТБ NVMe слишком мало для полной ноды основной сети с запасом на рост; вместо этого мы рекомендуем его для нод Bitcoin. А однопоточный рейтинг EPYC 9454P ниже ориентира EIP-7870 для валидаторов: выбирайте его для архивов и индексации, а не для соло-валидатора.
Советы по настройке, которые избавят от повторной синхронизации
- Используйте синхронизацию с контрольной точки (checkpoint sync) для клиента консенсуса: она начинается с недавнего финализированного состояния, а не воспроизводит Beacon Chain с генезис-блока.
- Удаляйте историю до The Merge на новых нодах с самого начала: это 300–500 ГБ, которые вам не придётся скачивать.
- Держите базу данных на отдельном томе NVMe и следите за свободным местом: клиент исполнения, которому не хватило места на диске, может повредить свою базу данных.
- Откройте P2P-порты своих клиентов (например, 30303 TCP и UDP для P2P-трафика Geth), а RPC-порты держите привязанными к localhost или за файрволом. Остальное описано в нашем чек-листе по защите сервера в первый час.
- Никогда не запускайте одни и те же ключи валидатора на двух машинах. Запуск резервного валидатора с теми же ключами — классический способ получить слэшинг; используйте защиту от слэшинга и переключайтесь на резерв вручную.
Это руководство касается только оборудования и не является рекомендацией по стейкингу или финансовой консультацией. О других блокчейнах читайте в нашем руководстве по подбору серверов для валидаторов и RPC Solana и на странице хостинга блокчейн-нод.
Источники
- EIP-7870: рекомендации по оборудованию и пропускной способности — Ethereum Improvement Proposals
- Запустите собственную ноду Ethereum — ethereum.org (обновлено 17 августа 2026 г.)
- Аппаратные требования — документация Geth
- Архивная нода — документация Geth (изменено 24 февраля 2026 г.)
- Обрезка истории — документация Geth
- Анонс частичного удаления истории — блог Ethereum Foundation, 8 июля 2025 г.
- Однопоточная производительность процессоров — PassMark Software
- AMD EPYC 9355P vs EPYC 9354 и AMD EPYC 9454P vs EPYC 9454 — PassMark Software
