Ethereum-нода: что на самом деле требуется для её запуска
Проверенные требования к оборудованию, механика синхронизации и нагрузка на обслуживание для самостоятельно размещённой Ethereum-ноды — и REST API, который заменяет её для отправки транзакций и отслеживания депозитов.
Ethereum-нода — это программное обеспечение, которое хранит полную копию состояния сети и позволяет запрашивать его или транслировать транзакции напрямую, не проходя через чужой сервер. Поиск «ethereum node» обычно означает одно из двух: вы хотите понять, что включает в себя запуск ноды, прежде чем выделять на неё серверный бюджет, или вы предположили, что нода — единственный способ читать и отправлять данные Ethereum, и хотите проверить это предположение. Эта страница отвечает на оба вопроса. Цифры ниже взяты из собственной документации Ethereum по запуску нод, проверенной в августе 2026 года, а не с рекламной страницы.
Что такое Ethereum-нода?
Ethereum-нода — это запущенный экземпляр клиентского ПО, который хранит сеть, валидирует новые блоки и ретранслирует транзакции остальной части peer-to-peer сети. После The Merge полная настройка объединяет две программы: клиент исполнения (Geth, Nethermind, Besu, Erigon или Reth), который обрабатывает состояние и транзакции, и клиент консенсуса (Lighthouse, Prysm, Teku, Nimbus или Lodestar), который обрабатывает аттестации proof-of-stake. Оба работают непрерывно и обмениваются данными друг с другом через локальное RPC-соединение. Ноды Ethereum бывают в нескольких профилях хранения: полные ноды хранят недавнее состояние и обрезают старые данные, архивные ноды хранят каждое историческое состояние, когда-либо записанное, а лёгкие ноды получают только заголовки — режим, о котором собственная документация Ethereum отмечает, что в mainnet слишком мало обслуживающих пиров, чтобы быть практичным.
Требования к Ethereum-ноде
Руководство по запуску нод от Ethereum.org (проверено в августе 2026 года) перечисляет следующее как базовый уровень для полной ноды с одним клиентом исполнения и одним клиентом консенсуса:
| Компонент | Минимум | Рекомендуется |
|---|---|---|
| CPU | 2+ ядра | Быстрый CPU, 4+ ядра |
| RAM | 8 ГБ | 16+ ГБ |
| Хранилище | 2 ТБ SSD | Быстрый SSD, 2+ ТБ |
| Пропускная способность | 10+ Мбит/с | 25+ Мбит/с, безлимит |
Две детали из того же источника легко упустить при подборе сервера. Во-первых, хранилище зависит от клиента: при snap sync Geth, Nethermind и Besu каждому нужно примерно 500 ГБ или больше только для данных исполнения, в то время как архивная нода — всё историческое состояние, а не только текущее — занимает 12 ТБ или больше на тех же клиентах, либо в диапазоне 2–2,5 ТБ на Erigon и Reth, которые хранят состояние иначе. Во-вторых, клиент консенсуса — отдельная статья бюджета: закладывайте ещё около 200 ГБ на данные beacon-chain поверх объёма клиента исполнения. Ничто из этого не является разовой стоимостью — использование диска Ethereum-нодой растёт, пока нода остаётся онлайн, потому что сеть продолжает производить блоки. Само время синхронизации зависит от оборудования, скорости сети и выбранного режима синхронизации; официальная документация не публикует фиксированную продолжительность, и мы тоже не будем, так что относитесь к любому конкретному числу дней, которое встретите в другом месте, как к догадке, а не к спецификации.
Как запустить Ethereum-ноду, на высоком уровне
Запуск Ethereum-ноды раскладывается на несколько текущих обязанностей, а не на один шаг установки. Выберите и установите подходящую пару клиентов исполнения и консенсуса. Подготовьте оборудование по таблице выше — занижение размера хранилища является самой распространённой ошибкой, потому что запас прочности сокращается с каждым месяцем, пока нода остаётся синхронизированной. Запустите оба клиента, направьте их на локальные конечные точки RPC друг друга и дайте начальной синхронизации завершиться, прежде чем полагаться на ноду для чего-либо. После этого задача становится операционной: своевременно применяйте обновления клиента (хардфорки этого требуют), отслеживайте количество пиров и запас места на диске и держите машину доступной 24/7, потому что нода, ушедшая офлайн на длительное время, должна догнать сеть, прежде чем снова станет полезной. Ничего из этого не необычно для инфраструктуры — это тот же профиль обслуживания, что и у любого другого сервиса с состоянием, просто с меньшим пространством для исправления состояния постфактум.
Пошаговую сборку с копируемыми командами, настройкой Geth и Lighthouse и unit-файлами systemd смотрите в руководстве по настройке Ethereum-ноды в блоге.
Ethereum на ARM: возможно, но не свободно от тех же ограничений
Команды клиентов действительно публикуют сборки ARM64, и платы уровня Raspberry Pi 5 могут запускать полную ноду. Это реально, но не меняет таблицу требований выше — Pi всё равно нужен внешний накопитель NVMe, рассчитанный на тот же объём в 2+ ТБ, RAM остаётся жёстким минимумом для клиентского ПО, а более медленный CPU обычно растягивает начальную синхронизацию сильнее, чем на сопоставимой машине x86. ARM — это способ запустить ноду дешевле и тише дома, а не способ запустить её с меньшими ресурсами.
Собственная нода против API Chaingateway
Оба варианта дают вам данные Ethereum и возможность отправлять транзакции. Разница в том, кто несёт операционную нагрузку.
| Собственная Ethereum-нода | API Chaingateway | |
|---|---|---|
| Настройка | Установить, настроить и синхронизировать два клиента | Зарегистрироваться и получить API-ключ |
| Хранилище | 2 ТБ+ SSD, растущее каждый месяц | Не требуется с вашей стороны |
| Синхронизация | От часов до дней, зависит от оборудования, разово и после любого простоя | Неприменимо — всегда синхронизировано |
| Аптайм | Ваша ответственность, 24/7 | Обеспечивается сервисом |
| Обновления клиента | Применяются вами, по графику хардфорков | Управляется централизованно |
| Что вы получаете | Полная поверхность JSON-RPC, включая архивные запросы при настройке | REST-эндпоинты для адресов, переводов ERC-20/721/1155 и вебхуков депозитов |
API не обязан заново реализовывать всю поверхность JSON-RPC, чтобы покрыть задачу, ради которой большинство интеграций на самом деле нанимают ноду: создать адрес, отправить токен, получить уведомление о поступлении депозита. Это Ethereum API одним предложением.
Когда вам действительно нужна собственная нода
Собственная нода — правильный выбор, если вы запускаете валидатор, индексируете всю сеть для аналитики, нуждаетесь в историческом состоянии уровня архива или у вас есть требование комплаенса, чтобы ваша инфраструктура никогда не зависела от третьей стороны в доступе к сети. Ничто из этого не подходит для замены API — это по-настоящему другая задача. Если ваше требование уже — генерировать депозитные адреса, отправлять ETH или ERC-20-токены, получать уведомление о поступлении средств, — это именно та поверхность, для которой создан платёжный API, без обязательства в хранилище и аптайме, связанного с этим.
Если ваша реальная задача — отправлять ERC-20-токены и отслеживать депозиты, создайте бесплатный аккаунт и попробуйте ту же задачу через REST, прежде чем закупать 2 ТБ SSD.
Версия без ноды: создание адреса и отправка ERC-20-токена
Никакой конечной точки RPC, никакой пары клиентов, которую нужно держать синхронизированной — один Bearer-токен в заголовке Authorization.
curl -X POST https://app.chaingateway.io/api/v2/ethereum/addresses \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"
curl -X POST https://app.chaingateway.io/api/v2/ethereum/transactions/erc20 \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contractaddress": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
"from": "0xYourHotWallet",
"to": "0xRecipient",
"amount": 100,
"password": "YourWalletPassword"
}'FAQ: Ethereum-ноды
Пропустите ноду, сохраните данные
Создайте аккаунт и отправьте тестовый перевод ERC-20 за несколько минут — 7-дневный пробный период, без карты, без KYC. Полный набор эндпоинтов — в справочнике Ethereum API, а все сети покрывает multi-chain blockchain API.