Блокчейн
Ноды: full, light, archive
Когда ты вызываешь eth_getBalance в своём dApp, ответ приходит за 200 миллисекунд. Но за этим простым числом стоит вопрос, который определяет всю архитектуру блокчейна: кто именно посчитал этот баланс? Сервер Infura, которому ты доверяешь? Твоя собственная нода, которая проверила каждый блок? Или light client на телефоне, который верифицировал Merkle proof? Ответ зависит от типа ноды - и от того, сколько суверенитета ты готов обменять на удобство.
- **Ethereum** - более 6 000 full nodes валидируют каждую транзакцию самостоятельно, обеспечивая децентрализацию сети. Client diversity (Geth, Nethermind, Erigon, Besu, Reth) защищает от катастрофических багов в одном клиенте
- **Alchemy, Infura, QuickNode** - RPC-провайдеры запускают сотни archive nodes и обрабатывают миллиарды запросов в день. Более 80% dApps подключаются к блокчейну через этих посредников, а не через собственные ноды
- **Helios (a16z)** - light client для Ethereum, который позволяет верифицировать RPC-ответы на обычном ноутбуке или смартфоне, используя всего ~60 MB вместо 500 GB. Компромисс между полным суверенитетом full node и слепым доверием провайдеру
Предварительные знания
Full Node: суверенитет через верификацию
Когда ты отправляешь транзакцию через MetaMask, кто проверяет, что она корректна? Кто гарантирует, что баланс отправителя достаточен, что подпись валидна, что nonce правильный? Если ты полагаешься на чужой сервер - ты **доверяешь**. А вся идея блокчейна в том, чтобы **верифицировать**, а не доверять.
**Full node** (полная нода) - это узел сети, который самостоятельно валидирует каждый блок и каждую транзакцию по правилам протокола. Она хранит **текущее состояние** (state) - балансы всех аккаунтов, код смарт-контрактов, storage переменных - и применяет к нему новые блоки, проверяя каждый шаг.
Ключевое слово - **pruned** (обрезанная). Full node в pruned mode хранит текущее состояние и недавнюю историю, но удаляет старые state trie. Ты можешь проверить любую **новую** транзакцию, но не можешь ответить на вопрос «каков был баланс Vitalik.eth в блоке 15 000 000?» - эти данные уже удалены.
Аналогия: свой бухгалтер vs чужой
Зачем запускать собственную full node
Представь, что у тебя крупный бизнес. Вариант 1 (чужая нода): ты звонишь чужому бухгалтеру и спрашиваешь: «Сколько у меня на счёте?» Он может ошибиться, соврать или быть недоступен. Вариант 2 (своя full node): у тебя свой бухгалтер, который проверяет КАЖДЫЙ документ лично. Никто не может тебя обмануть. Три причины запускать свою ноду: 1. Суверенитет - ты сам проверяешь правила 2. Приватность - никто не видит твои запросы 3. Цензуроустойчивость - никто не может заблокировать твой доступ к сети
**Минимальные требования для Ethereum full node (2025):** 4-ядерный CPU, 16 GB RAM, 2 TB NVMe SSD (SATA не подходит - слишком медленный для state access), стабильный интернет 25+ Mbit/s. Стоимость оборудования: ~500-700. Это не серверное железо - подойдёт обычный десктоп или даже мини-ПК вроде Intel NUC.
Почему full node в pruned mode не может ответить на вопрос «каков был баланс адреса 0xABC в блоке 10 000 000»?
Light Client: верификация без терабайтов
500 GB на диске, 16 GB RAM, постоянное интернет-соединение - full node доступна не всем. Что делать пользователю смартфона, который хочет проверить свою транзакцию, не доверяя Infura? Ответ - **light client**: узел, который проверяет данные, не скачивая всю цепочку.
Light client хранит только **заголовки блоков** (block headers) - это ~500 байт на блок вместо ~100 KB полного блока. Для Ethereum это ~60 MB вместо 500 GB. Когда ему нужно проверить конкретные данные (баланс, транзакцию, receipt), он запрашивает **Merkle proof** у full node и верифицирует его локально.
**Helios** - light client для Ethereum от a16z, написанный на Rust. Он подключается к consensus layer, получает заголовки блоков через sync committee (512 валидаторов, ротация каждые ~27 часов), и может верифицировать любой RPC-запрос. Helios превращает **доверие к Infura** в **доверие к 512 валидаторам с залогом**.
**Portal Network** - экспериментальный проект Ethereum Foundation, который идёт ещё дальше: вместо одной full node, light client получает данные от **сети peers** через DHT (аналог BitTorrent). Каждый peer хранит маленький фрагмент данных, а light client собирает нужные фрагменты и верифицирует их через proofs. Это устраняет необходимость в доверенном full node-сервере.
**Trust tradeoff:** full node = zero trust (ты проверяешь всё сам). Light client = minimal trust (ты доверяешь sync committee из 512 валидаторов с 16M+ залогом, но проверяешь Merkle proofs). RPC provider без верификации = полное доверие одной компании. Light client - прагматичный компромисс для мобильных устройств и приложений, где full node невозможна.
Light client запрашивает баланс аккаунта у full node. Как он проверяет, что ответ корректный?
Archive Node: вся история на одном диске
Full node хранит текущий state, light client - только заголовки. Но что, если тебе нужно узнать, сколько ETH было на адресе Tornado Cash **в момент санкций OFAC** (блок 15 300 000, август 2022)? Или отладить смарт-контракт, который упал на конкретном блоке полгода назад? Для этого нужен узел, который помнит **всё**: каждое состояние, в каждом блоке, с самого genesis.
**Archive node** хранит полное состояние сети на **каждом блоке**: все промежуточные state tries, все исторические балансы, весь storage смарт-контрактов в каждый момент времени. Это полная «машина времени» блокчейна.
Разные клиенты по-разному организуют archive-хранение. **Geth** в archive mode хранит каждый state trie полностью - это избыточно и съедает диск. **Erigon** использует flat state model: вместо деревьев - плоские таблицы (key → value на каждом блоке), что значительно компактнее. Erigon archive node занимает ~3 TB против ~15+ TB у Geth.
Аналогия: библиотека vs газетный киоск
Разница между full node и archive node
Full node (pruned) - газетный киоск: у тебя есть сегодняшняя газета и, может быть, несколько вчерашних. Ты знаешь актуальные новости, но не можешь узнать, что было на первой полосе 3 года назад. Archive node - национальная библиотека: хранит КАЖДЫЙ выпуск КАЖДОЙ газеты с первого дня. Можно найти любую статью за любую дату. Но нужно огромное здание (15+ TB диска). RPC providers (Alchemy, Infura) - сервис доставки: у них есть библиотека, и ты можешь запросить любую старую газету. Но ты доверяешь курьеру, что он принесёт настоящую газету, а не подделку.
**Большинство разработчиков не запускают archive node сами.** Вместо этого используют RPC providers: Alchemy (free tier: 300M compute units/мес), Infura, QuickNode, Ankr. Эти компании запускают десятки archive nodes и продают доступ к ним через API. Компромисс: удобство и скорость в обмен на доверие провайдеру.
DeFi-аналитик хочет построить график изменения TVL (Total Value Locked) в Aave за последние 2 года. Какой тип ноды ему нужен?
State Sync: как нода догоняет сеть
Ты решил запустить свою full node. Скачал Geth, настроил hardware, запустил. И тут вопрос: Ethereum работает с 2015 года, в цепочке уже **20+ миллионов блоков**. Как получить текущее состояние? Проигрывать все транзакции с genesis займёт **недели**. Должен быть способ быстрее.
**State sync** - процесс получения текущего состояния сети новой нодой. Существует несколько стратегий, каждая с разным trade-off между скоростью, безопасностью и объёмом данных.
**Snap Sync** (по умолчанию в Geth с 2021 года) - основной метод для новых нод. Вместо воспроизведения всей истории, нода скачивает **snapshot** текущего состояния и проверяет его целостность через state root в заголовке блока. State root - это Merkle-корень всего state trie, и если хоть один байт snapshot'а неверен, корень не совпадёт.
Аналогия: новый бухгалтер в компании
Разница между стратегиями синхронизации
Представь: тебя наняли бухгалтером в компанию, которая работает 10 лет. Full Sync = перепроверить ВСЕ операции за 10 лет. Надёжно, но займёт месяцы. Snap Sync = получить аудированный баланс на сегодня и начать работу с текущего момента. Баланс заверен (state root), можно доверять. Checkpoint Sync = получить справку «всё ОК» от аудитора и начать с чистого листа. Быстрее всего, но доверяешь аудитору.
**Практический совет:** для домашней full node используйте Snap Sync (это default в Geth). На NVMe SSD синхронизация занимает 6-12 часов. На SATA SSD - может занять дни или вообще не завершиться из-за I/O bottleneck. SATA HDD - даже не пытайтесь. Execution Layer (Geth/Reth) + Consensus Layer (Lighthouse/Prysm) с Checkpoint Sync - оптимальная комбинация для старта.
Чтобы полноценно участвовать в Ethereum-сети, нужно скачать и проверить всю историю с genesis блока - иначе ты не можешь быть уверен в корректности текущего состояния
Snap Sync позволяет получить и криптографически верифицировать текущий state без воспроизведения всей истории. State root в заголовке блока, подписанном сотнями валидаторов, гарантирует целостность snapshot. Full sync от genesis нужен только для archive nodes или параноидальной верификации - для обычной full node это избыточно.
Это заблуждение удерживает людей от запуска собственных нод: «мне нужно 15 TB и две недели - лучше буду использовать Infura». В реальности запустить full node можно за 6-12 часов на обычном компьютере с 2 TB SSD. Snap Sync спроектирован так, что криптографические гарантии целостности не уступают full sync - разница только в доступе к историческим состояниям.
Snap Sync позволяет новой Ethereum-ноде синхронизироваться за часы вместо недель. Как нода убеждается, что скачанный state snapshot корректный?
Итоги
- **Full node** хранит текущее состояние (~500 GB) и валидирует каждый блок самостоятельно - это максимальный суверенитет: ты не доверяешь, а проверяешь. Запомни вопрос из начала урока: кто посчитал твой баланс? Full node отвечает: «Я сам, проверив каждый блок»
- **Light client** хранит только заголовки (~60 MB) и проверяет данные через Merkle proofs - прагматичный компромисс для устройств, где full node невозможна. Helios превращает доверие к Infura в доверие к 512 валидаторам с залогом
- **Archive node** хранит все исторические состояния (~15+ TB) - «машина времени» блокчейна для аналитики, отладки и forensics. Большинство разработчиков используют archive nodes через RPC-провайдеров
- **Snap Sync** позволяет запустить full node за 6-12 часов вместо недель, проверяя state snapshot через Merkle root - именно поэтому оправдания «мне нужно 15 TB и две недели» больше не работают. Запустить свою ноду проще, чем кажется, а вопрос «кто посчитал мой баланс» стоит того, чтобы на него ответить
Связанные темы
Типы нод - инфраструктурный слой блокчейна, связывающий сетевой уровень с доступом к данным:
- P2P-сети и gossip протоколы — Full, light и archive ноды используют P2P-сеть для обнаружения peers, получения блоков и обмена данными - без P2P-уровня ни одна нода не может функционировать
- Ethereum аккаунты — Балансы и состояния аккаунтов хранятся в state trie, с которым работают все типы нод - full node хранит текущий state, archive хранит все исторические состояния, light client верифицирует через Merkle proofs
- Хеш-структуры данных — Merkle tries - основа хранения данных в нодах: state trie, storage trie, transactions trie. Merkle proofs позволяют light clients верифицировать данные без скачивания всего дерева
- Indexing и запросы к данным — Archive nodes предоставляют «сырые» данные, а indexing-сервисы (The Graph, Dune) структурируют их для быстрых запросов - следующий шаг от хранения к использованию данных
Вопросы для размышления
- Более 80% dApps подключаются к Ethereum через Alchemy или Infura. Если один из этих провайдеров выйдет из строя, что произойдёт с «децентрализованными» приложениями? Является ли зависимость от RPC-провайдеров скрытой централизацией?
- Helios (light client) доверяет sync committee из 512 валидаторов. Full node не доверяет никому. Какой уровень доверия приемлем для обычного пользователя, отправляющего 100 USDC? А для протокола с 1B TVL?
- Snap Sync полагается на state root в заголовке блока. Если бы атакующий контролировал >2/3 валидаторов и подписал заголовок с поддельным state root, snap sync принял бы поддельный state. Как это связано с economic security и стоимостью атаки на Proof of Stake?