Ноды блокчейна: Ethereum, Bitcoin и требования к серверам

В 2024 году криптобиржа решила запустить собственную полную ноду Ethereum вместо использования внешних провайдеров API вроде Infura. Причина — зависимость от третьей стороны и стоимость $500-1000 в месяц за высоконагруженный тариф. Взяли выделенный сервер за €120 в месяц, начали синхронизацию. Через 4 дня процесс остановился на 87% — закончилось место на диске. Оказалось что для полной ноды Ethereum нужно не 2 TB как планировали, а минимум 3 TB с учётом роста. Добавили ещё один диск, пересинхронизировались за 5 дней. Результат: собственная нода обрабатывает 2000 запросов в секунду, latency 15-30 миллисекунд против 150-300 миллисекунд через Infura, полный контроль над данными, экономия €380 в месяц.

Запуск собственной ноды блокчейна — это компромисс между контролем, производительностью и затратами. Для разработки достаточно публичных RPC провайдеров. Для production приложения с высокой нагрузкой или требованиями к приватности нужна собственная нода.

Типы нод: полные, легкие, архивные

Полная нода (full node) хранит весь блокчейн с момента genesis блока и проверяет каждую транзакцию по консенсус-правилам сети. Для Bitcoin это означает все блоки с 2009 года, для Ethereum все блоки с 2015 года. Полная нода может независимо верифицировать любую транзакцию и блок без доверия к третьим сторонам.

Важное уточнение: полная нода Bitcoin хранит полную историю транзакций но может не хранить полное состояние UTXO (unspent transaction outputs) для всех адресов всех времён — это опционально через txindex. Полная нода Ethereum после перехода на proof-of-stake и внедрения синхронизации snap/fast хранит только недавнее состояние (state) и не обязательно все исторические состояния.

Архивная нода (archive node) хранит не только все блоки но и все исторические состояния сети для каждого блока. Для Ethereum это критично если вам нужны запросы типа "какой был баланс адреса на блоке 5,000,000 три года назад". Размер архивной ноды Ethereum превышает 12 TB и растёт на 50-70 GB в неделю. Архивные ноды нужны для блокчейн-эксплореров, аналитических платформ, tax reporting сервисов.

Легкая нода (light node) не хранит полный блокчейн, только заголовки блоков и запрашивает необходимые данные у полных нод по требованию. Легкая нода может работать даже на смартфоне, но зависит от полных нод и доверяет им в определённой степени. Для серверной инфраструктуры легкие ноды почти не используются — если уж запускать ноду, то полную.

Pruned node — это полная нода которая удаляет старые блоки после их обработки, сохраняя только недавние (например последние 550 блоков для Bitcoin). Это экономит дисковое пространство — pruned нода Bitcoin занимает ~10 GB вместо ~600 GB. Но такая нода не может обслуживать запросы к историческим данным и не помогает новым нодам синхронизироваться.

Bitcoin нода: требования и характеристики

Bitcoin Core — официальная реализация полной ноды Bitcoin. Она написана на C++ и работает на Linux, macOS, Windows. Для production серверной ноды используется Linux.

Требования к процессору. Bitcoin нода не требует мощного CPU. Валидация транзакций использует криптографию (SHA-256, ECDSA) которая хоть и CPU-intensive, но современные процессоры справляются легко. Минимально достаточно 2 ядра на частоте 2+ GHz. Для комфортной работы рекомендуется 4 ядра. Во время начальной синхронизации (IBD — initial block download) нода максимально нагружает CPU проверяя все блоки с 2009 года. На процессоре уровня Intel i5 последнего поколения это занимает 6-12 часов чистого CPU времени.

Оперативная память. Bitcoin Core работает эффективно с 2 GB RAM минимум, рекомендуется 4-8 GB. Нода держит в памяти mempool (пул неподтверждённых транзакций), UTXO set (множество неизрасходованных выходов), кэш блоков. С dbcache=4096 (4 GB выделенного кэша) синхронизация идёт заметно быстрее благодаря меньшему количеству обращений к диску.

Дисковое пространство. Полная unpruned нода Bitcoin занимает около 600 GB по состоянию на начало 2026 года. Блокчейн растёт примерно на 60-80 GB в год в зависимости от активности сети. Для работы ноды критически важна скорость диска. На HDD начальная синхронизация может занять неделю или больше из-за огромного количества случайных чтений для валидации. На SATA SSD синхронизация занимает 1-3 дня. На NVMe SSD можно уложиться в 12-24 часа.

Формат хранения данных — LevelDB база данных для chainstate (текущее состояние UTXO) и блоки в виде отдельных файлов по ~128 MB каждый. Случайные чтения из chainstate очень частые во время валидации, поэтому медленный диск убивает производительность.

Сетевые требования. Bitcoin нода активно обменивается данными с другими нодами в P2P сети. Начальная синхронизация загружает ~600 GB данных. После синхронизации трафик составляет примерно 20-50 GB в месяц входящего и 20-50 GB исходящего при стандартных настройках. Если разрешить другим нодам скачивать блоки с вашей ноды (служить seed-нодой для сети), трафик может вырасти до 500 GB+ в месяц исходящего.

Важен стабильный интернет с низкой задержкой. Нода получает новые блоки и транзакции от пиров, и чем быстрее, тем лучше. Задержка в получении нового блока означает что вы позже узнаете о подтверждении транзакций. Для большинства применений это не критично, но для майнинга или высокочастотного трейдинга latency имеет значение.

Порты и firewall. Bitcoin Core использует порт 8333 для P2P коммуникации с другими нодами. Этот порт должен быть открыт для входящих соединений если вы хотите чтобы ваша нода была доступна для остальной сети. Порт 8332 используется для RPC API (JSON-RPC интерфейс для взаимодействия с нодой программно). RPC порт должен быть закрыт извне и доступен только локально или через VPN.

Время синхронизации. Начальная синхронизация полной ноды Bitcoin (initial block download) занимает от 12 часов до нескольких дней в зависимости от железа и канала. На быстром сервере с NVMe SSD, 8 GB RAM, хорошим каналом можно уложиться в 12-18 часов. На медленном VPS с HDD и плохим каналом может растянуться на неделю.

Процесс идёт в несколько этапов: скачивание блоков с пиров (ограничено каналом), валидация блоков (ограничено CPU и диском), построение chainstate (ограничено диском). Узкое место обычно диск на этапе валидации старых блоков где тысячи мелких случайных чтений.

Реальный пример конфигурации. Hetzner сервер AX41-NVMe: AMD Ryzen 5 3600 (6 ядер, 12 потоков, 3.6 GHz), 64 GB RAM, 2x 512 GB NVMe в RAID 1, 1 Гбит/с сеть, стоимость €49 в месяц. На таком сервере Bitcoin полная нода синхронизируется за 14-16 часов, работает стабильно, может обслуживать несколько тысяч RPC запросов в минуту.

Ethereum нода: существенно выше требования

Ethereum после перехода на proof-of-stake (The Merge в сентябре 2022) и последующих обновлений стал менее требовательным к ресурсам чем был, но всё равно тяжелее Bitcoin.

Клиенты Ethereum. Есть несколько реализаций Ethereum ноды на разных языках: Geth (Go), Erigon (Go), Nethermind (C#), Besu (Java). Самый популярный — Geth, он используется примерно на 60% нод. Erigon более эффективен по дисковому пространству благодаря продвинутой архитектуре хранения данных.

После перехода на proof-of-stake нужно запускать два компонента: execution client (Geth/Erigon/etc) обрабатывает транзакции и хранит состояние, consensus client (Prysm/Lighthouse/Teku/Nimbus) участвует в консенсусе и финализации блоков. Оба клиента работают вместе и общаются через Engine API.

Требования к процессору. Ethereum нода заметно нагружает CPU. Во время синхронизации процессор работает на пределе проверяя транзакции и обновляя state. Минимально нужно 4 ядра, рекомендуется 6-8 ядер на частоте 3+ GHz. Более слабый процессор приведёт к тому что нода будет отставать от head of chain — сеть генерирует блоки быстрее чем нода успевает их обрабатывать.

Оперативная память. Это узкое место для Ethereum. Geth требует минимум 16 GB RAM для работы, комфортно 32 GB. Во время синхронизации потребление памяти доходит до 12-16 GB для execution client плюс 2-4 GB для consensus client. Если памяти мало, процесс будет swap-ить на диск что убьёт производительность полностью.

Причина высокого потребления памяти в том что Ethereum state (состояние всех смарт-контрактов и аккаунтов) очень большое и нода держит горячие части в памяти для быстрого доступа. MPT (Merkle Patricia Trie) структура данных для state требует много памяти для эффективной работы.

Дисковое пространство. Здесь Ethereum особенно прожорлив. Полная нода Geth со snap sync (быстрая синхронизация без всех исторических состояний) занимает 1.2-1.5 TB по состоянию на начало 2026 года. Архивная нода занимает 12-14 TB. Рост примерно 50-70 GB в неделю для полной ноды, больше для архивной.

Erigon клиент более эффективен — полная нода занимает ~800 GB, архивная 4-6 TB благодаря продвинутой компрессии и хранению только изменений состояния между блоками. Но Erigon менее стабилен и имеет меньше поддержки чем Geth.

Критически важен быстрый NVMe SSD. На SATA SSD нода будет медленно синхронизироваться и может отставать от head of chain. На HDD запустить полную Ethereum ноду в 2026 году практически невозможно — слишком много случайных операций чтения/записи в state базу.

Сетевые требования. Начальная синхронизация загружает 1.2-1.5 TB данных. После синхронизации трафик составляет 50-100 GB в месяц входящего и аналогично исходящего при умеренной нагрузке. Если ваша нода популярна и много пиров подключаются, трафик может вырасти до 1-2 TB в месяц.

Latency также важна. Ethereum блоки генерируются каждые 12 секунд, и нода должна успевать получить, обработать и передать блок дальше за это время. Плохое соединение приведёт к пропуску блоков и необходимости их запрашивать позже.

Порты. Execution client (Geth) использует 30303 TCP/UDP для P2P, 8545 для HTTP RPC API, 8546 для WebSocket RPC. Consensus client использует 9000 TCP/UDP для P2P, 5052 для Beacon API. Порты P2P должны быть открыты, порты API закрыты извне.

Время синхронизации. Geth с snap sync синхронизируется 12-36 часов на хорошем железе. Erigon может синхронизироваться 6-12 часов благодаря более эффективной архитектуре. Старый full sync который проверяет каждую транзакцию с genesis занимал недели и сейчас не используется.

Consensus client синхронизируется отдельно, это занимает 2-6 часов. Он качает beacon chain (цепь консенсуса) которая гораздо легче execution layer.

Практический пример. Hetzner AX102: AMD Ryzen 9 5950X (16 ядер, 32 потока, 3.4 GHz), 128 GB RAM, 2x 3.84 TB NVMe в RAID 1, 1 Гбит/с сеть, стоимость €169 в месяц. На таком сервере Geth + Lighthouse синхронизируются за 18-24 часа, работают стабильно, могут обслуживать десятки тысяч RPC запросов в минуту. Этого хватит для средней DeFi платформы или NFT маркетплейса.

Сравнение требований Bitcoin vs Ethereum

Прямое сравнение минимальных и рекомендуемых конфигураций:

Bitcoin полная нода минимум: 2 ядра CPU, 4 GB RAM, 700 GB SSD (лучше NVMe), 100 Мбит/с сеть. Синхронизация 1-3 дня. Месячный трафик ~100 GB. Стоимость сервера €30-50/месяц.

Bitcoin полная нода рекомендуется: 4 ядра CPU @ 3 GHz, 8 GB RAM, 1 TB NVMe SSD, 1 Гбит/с сеть. Синхронизация 12-24 часа. Стоимость €50-70/месяц.

Ethereum полная нода минимум: 4 ядра CPU, 16 GB RAM, 1.5 TB NVMe SSD, 100 Мбит/с сеть. Синхронизация 1-3 дня. Месячный трафик ~200 GB. Стоимость €80-120/месяц.

Ethereum полная нода рекомендуется: 8 ядер CPU @ 3+ GHz, 32 GB RAM, 2 TB NVMe SSD, 1 Гбит/с сеть. Синхронизация 12-24 часа. Стоимость €120-170/месяц.

Ethereum архивная нода: 8+ ядер CPU, 64 GB RAM, 14+ TB быстрого хранилища (NVMe RAID), 1 Гбит/с сеть. Синхронизация неделя+. Стоимость €250-400/месяц в зависимости от дискового пространства.

Ethereum требует в 2-3 раза больше ресурсов чем Bitcoin из-за сложности EVM (виртуальной машины для исполнения смарт-контрактов), большого и быстрорастущего состояния сети, более частых блоков (12 секунд vs 10 минут).

Оптимизация и настройка производительности

Bitcoin Core оптимизация. Параметр dbcache в bitcoin.conf контролирует размер кэша базы данных в памяти. По умолчанию 450 MB, но при наличии свободной RAM можно увеличить до 4096-8192 (4-8 GB). Это резко ускоряет валидацию блоков во время синхронизации. После завершения IBD можно вернуть к меньшему значению.

Параметр maxconnections ограничивает количество одновременных соединений с другими нодами. По умолчанию 125, что нормально для домашней ноды. Для серверной ноды с хорошим каналом можно поднять до 200-300. Больше соединений помогает быстрее распространять блоки и транзакции, но ест трафик и немного CPU.

Если не нужна полная история транзакций каждого адреса, не включайте txindex=1. Это сэкономит время синхронизации и дисковые операции. txindex нужен только если вы делаете getrawtransaction для произвольных транзакций по их ID.

Geth оптимизация. Параметр --cache задаёт размер кэша в мегабайтах. По умолчанию 4096 (4 GB), рекомендуется ставить около 50-70% свободной RAM. На сервере с 32 GB RAM можно ставить --cache=16384 (16 GB). Больше кэш — меньше дисковых операций, быстрее синхронизация и работа.

Параметр --maxpeers ограничивает количество пиров. По умолчанию 50, что адекватно. Увеличение до 100 даёт небольшой прирост скорости синхронизации но ест больше трафика и CPU. Для production ноды обычно оставляют 50-70.

Использовать --syncmode=snap для быстрой синхронизации вместо --syncmode=full. Snap качает только текущее состояние сети без всех исторических состояний, экономя недели времени. Full sync нужен только если вы хотите независимо проверить каждую транзакцию с genesis, что для большинства применений избыточно.

Erigon вместо Geth. Если дисковое пространство критично, Erigon занимает в 1.5-2 раза меньше места благодаря умному хранению данных. Но Erigon менее стабилен, чаще бывают баги, обновления могут ломать совместимость. Для production если надёжность важнее места — Geth безопаснее выбор.

Мониторинг ноды. Критически важно мониторить что нода синхронизирована и не отстаёт. Для Bitcoin можно проверять getblockchaininfo RPC вызовом — поле blocks должно совпадать с headers, и verificationprogress должен быть 0.9999+ (почти 1.0). Отставание на десятки блоков нормально во время пиков активности, на сотни блоков — проблема.

Для Ethereum проверяем eth_syncing — должен возвращать false если синхронизировано. Также eth_blockNumber сравниваем с публичными эксплорерами типа Etherscan. Если отставание больше 10-20 блоков постоянно — нода не справляется с нагрузкой, нужно больше ресурсов.

Мониторить использование диска — если свободно меньше 15-20%, скоро закончится место. Ethereum растёт примерно 3-4 GB в день, значит при 100 GB свободного через месяц проблемы. Нужно планировать расширение заранее.

Провайдеры и альтернативы собственной ноде

Managed blockchain node провайдеры. Если не хотите управлять собственной нодой, есть сервисы которые предоставляют доступ к нодам за плату:

Infura — самый популярный для Ethereum. Бесплатный tier даёт 100,000 запросов в день, платные тарифы от $50 до $1000+ в месяц в зависимости от нагрузки. Латентность обычно 150-300 миллисекунд из Европы, выше из других регионов. Риск в централизации — если Infura падает, множество DApps встают.

Alchemy — конкурент Infura с похожими ценами и возможностями. Предлагает дополнительные API для уведомлений о событиях, расширенную аналитику. Бесплатный tier 300 миллионов compute units в месяц, платные от $49/месяц.

QuickNode — ещё один провайдер с акцентом на производительность. Заявляют латентность 50-100 миллисекунд, но стоят дороже — от $49/месяц за базовый tier, $299+ за высокие нагрузки.

GetBlock — европейский провайдер, дешевле американских. От €29/месяц за shared ноду, от €99 за dedicated. Поддерживает Bitcoin, Ethereum, десятки других блокчейнов.

Сравнение стоимости: провайдер vs собственная нода. Если ваше приложение делает 10-20 миллионов запросов в месяц к Ethereum ноде, это обойдётся в $200-500/месяц на Infura/Alchemy. Собственная нода на выделенном сервере за €120-170/месяц справится с миллиардами запросов при правильной архитектуре.

Но есть скрытые затраты собственной ноды: время на настройку (10-20 часов первоначально), мониторинг и обслуживание (5-10 часов в месяц на обновления и решение проблем), риск даунтайма если нода упадёт и некому быстро починить. Для небольшого проекта или MVP managed провайдер дешевле и проще. Для production с высокой нагрузкой или требованиями к приватности — собственная нода выгоднее.

Гибридный подход. Многие проекты используют собственную ноду для основной нагрузки и managed провайдера как fallback. Если своя нода недоступна или отстала — запросы уходят на Infura. Это даёт надёжность при сохранении контроля и экономии на большинстве запросов.

Безопасность и приватность ноды

Защита RPC API. По умолчанию RPC API Bitcoin Core и Geth слушают только на localhost (127.0.0.1). Если нужно разрешить доступ извне (например с другого сервера в вашей инфраструктуре), критически важно настроить аутентификацию и шифрование.

Bitcoin Core поддерживает HTTP Basic Auth через rpcuser и rpcpassword в конфиге. Но HTTP соединение не шифруется, поэтому нужен либо SSH tunnel, либо VPN, либо reverse proxy с TLS (nginx с SSL сертификатом).

Geth можно запускать с --http.api для ограничения доступных методов. Например --http.api=eth,net,web3 разрешит только чтение данных, без personal (управление аккаунтами) и admin (управление нодой). Для production никогда не открывайте полный набор API наружу.

Firewall правила. Открыть только необходимые порты. Для Bitcoin: 8333 TCP/UDP (P2P) должен быть открыт миру, 8332 (RPC) закрыт полностью или доступен только с конкретных IP через whitelist. Для Ethereum: 30303 (execution P2P), 9000 (consensus P2P) открыты миру, 8545/8546 (RPC/WebSocket) закрыты или через VPN.

Использовать iptables или ufw на Linux для жёсткого контроля. Пример для Bitcoin: разрешить 8333 всем, разрешить 8332 только с 10.0.0.5 (ваш app сервер), запретить всё остальное на этих портах.

Приватность и IP адрес. Запуск ноды раскрывает ваш IP адрес всей P2P сети. Все ваши транзакции будут видны как исходящие с этого IP. Если это критично, можно использовать Tor. Bitcoin Core поддерживает работу через Tor из коробки — все соединения идут через Tor сеть, ваш реальный IP скрыт.

Geth тоже можно настроить на работу через Tor но это сложнее и может замедлить синхронизацию. Для большинства применений это избыточно — IP ноды обычно не критичная информация. Но для параноиков или в странах с жёстким регулированием Tor опция есть.

Регулярные обновления. Блокчейн клиенты регулярно обновляются с патчами безопасности и новыми фичами. Критически важно держать ноду на актуальной версии. Уязвимость в старой версии может привести к атаке которая уронит ноду или хуже — позволит украсть средства если на ноде хранятся приватные ключи (что не рекомендуется для production).

Bitcoin Core и Geth выпускают релизы каждые несколько месяцев. Мажорные обновления требуют остановки ноды и перезапуска что может занять несколько минут. Планировать обновления в periods низкой нагрузки.

Реальные кейсы использования нод

DeFi платформа на Ethereum. Децентрализованная биржа DEX использует собственную Geth ноду для чтения состояния смарт-контрактов и отправки транзакций. Нода обрабатывает 50-100 запросов в секунду (балансы токенов, цены в пулах, симуляция свопов). Запущена на Hetzner AX102 за €169/месяц. Латентность 10-20 миллисекунд против 200-400 через Infura. Экономия около €800/месяц по сравнению с Infura Enterprise планом.

Дополнительно держат резервную ноду на другом провайдере (OVH) и Infura как третий fallback. При падении основной ноды трафик автоматически переключается на резервную за 5-10 секунд через health check в load balancer.

NFT маркетплейс. Платформа индексирует все NFT трансферы и metadata с Ethereum блокчейна. Используют Erigon архивную ноду для доступа к историческим событиям смарт-контрактов. Нода занимает 5.2 TB на OVH сервере с 8 TB RAID массивом за €250/месяц.

Каждый новый блок парсится на предмет Transfer событий ERC-721/ERC-1155 контрактов. Обрабатывается 10-50 событий в секунду в периоды активности (NFT минты, крупные распродажи). Архивная нода позволяет делать исторические запросы типа "кто владел NFT #5234 полгода назад" для аналитики и tax reporting.

Криптовалютный платёжный процессор. Сервис принимает Bitcoin платежи для e-commerce сайтов. Запущена полная Bitcoin Core нода на Hetzner AX41 за €49/месяц. Нода мониторит mempool на входящие транзакции к адресам клиентов, детектирует подтверждения блоками.

Работает в связке с Bitcoin Core wallet который генерирует уникальные адреса для каждого платежа. Обрабатывается 200-500 платежей в день, пиковая нагрузка 50 транзакций в час. Собственная нода даёт полный контроль и приватность — никакие адреса клиентов не утекают third-party провайдерам. Латентность детектирования транзакций 1-5 секунд после broadcast в сеть.

Блокчейн аналитика. Компания анализирует Bitcoin транзакции для compliance и AML (anti-money laundering). Используют несколько Bitcoin Core нод с txindex=1 для полного индекса всех транзакций. Ноды реплицированы в разных дата-центрах для отказоустойчивости.

Каждая нода обрабатывает 100-200 запросов в секунду от аналитической системы которая строит графы транзакций, отслеживает подозрительные паттерны, проверяет адреса по blacklist. Полный txindex занимает дополнительные ~200 GB на диске но позволяет мгновенно получить любую транзакцию по ID без медленного сканирования всех блоков.

Выводы и рекомендации

Запуск собственной ноды блокчейна имеет смысл когда нужен полный контроль над данными, низкая латентность, высокая пропускная способность или приватность. Для небольших проектов и MVP managed провайдеры типа Infura удобнее и дешевле. Для production с десятками миллионов запросов в месяц — собственная нода экономически выгоднее.

Bitcoin ноду можно запустить на скромном железе — 4 ядра CPU, 8 GB RAM, 1 TB SSD за €50-70/месяц справятся с большинством применений. Ethereum существенно тяжелее — нужно минимум 8 ядер, 32 GB RAM, 2 TB NVMe за €120-170/месяц. Архивная Ethereum нода для полной истории обойдётся в €250-400/месяц из-за огромного дискового пространства.

Критические факторы успеха: быстрый NVMe SSD (без него синхронизация займёт неделю и нода может отставать), достаточно RAM (иначе swap убьёт производительность), стабильный интернет с низкой латентностью, регулярные обновления клиента, мониторинг синхронизации и ресурсов.

Для отказоустойчивости рекомендуется держать минимум две ноды в разных дата-центрах плюс managed провайдер как финальный fallback. Это защищает от даунтайма при проблемах с одной нодой или дата-центром. Load balancer с health checks автоматически переключает трафик на здоровую ноду.

Безопасность критична — закрыть RPC API от внешнего доступа, использовать аутентификацию и TLS, держать клиент на актуальной версии, не хранить приватные ключи на той же машине где нода. Firewall должен разрешать только необходимые порты.

Начинать внедрение стоит с тестовой ноды на testnet (Sepolia для Ethereum, testnet для Bitcoin) чтобы освоить настройку и мониторинг без риска. После успешного теста можно запускать mainnet ноду для production. Синхронизация займёт день-два, после чего нода готова обслуживать приложение.