ГЛАВНАЯ / ИНСТРУКЦИИ / ARCHIVE NODE И FULL NODE ETHEREUM: ДОСТУП К ИСТОРИИ И ТРЕБОВАНИЯ ХРАНЕНИЯ
Archive node и full node Ethereum: доступ к истории и требования хранения
Full node проверяет блоки и поддерживает текущее состояние Ethereum, но execution-клиент может удалять старые снимки состояния. Archive node сохраняет исторические state данные для прямых запросов на старых блоках. Это разные режимы хранения; блоки и квитанции при этом не равны полному архиву состояния.
Full node проверяет цепь, но не обязан хранить каждый старый state
Full node участвует в проверке блоков по правилам сети и держит данные, необходимые для работы с текущей цепью. Execution-клиент может pruning-ом удалять старые state snapshots, когда они больше не нужны для обычной синхронизации.
В зависимости от клиента и режима узел может получить старое состояние повторным исполнением истории от доступной точки или нуждаться в archive-данных для оперативного ответа. Полная проверка новых блоков не означает, что каждый баланс контракта сохранён в базе на каждый блок с genesis.
- проверка блоков отделена от хранения старых snapshots;
- объём данных определяется клиентом и режимом;
- узел без archive state всё ещё способен следить за текущей цепью.
Archive node сохраняет исторические состояния для прямых запросов
Archive node сохраняет исторические состояния, которые обычный pruned full node может уже не держать непосредственно. Это полезно сервисам аналитики и обозревателям, которым нужен запрос баланса или storage контракта на далёком прошлом блоке.
Архивный режим требует существенно больше места и обслуживания, но точные характеристики меняются с клиентом, версией, настройками и используемым типом данных. Не выбирайте режим по универсальной цифре диска: сначала определите RPC-запросы, частоту и глубину истории.
| Потребность | Что обычно подходит | Что проверить |
|---|---|---|
| Текущее состояние и обычная синхронизация | Full node | Поддерживаемый режим и pruning |
| Исторические balance/storage запросы | Archive state или услуга, которая его хранит | Метод, block number и период |
| Сырые блоки и receipts | Хранилище блоков/квитанций | Политика retention клиента |
| Редкие старые запросы | Удалённый archive RPC или пересчёт | Доверие к endpoint и время ответа |
Исторический блок, receipt и состояние аккаунта – разные данные
Блоки, транзакции и receipts содержат историю исполнения, включая включённые операции и журналы событий. State отражает результат исполнения на выбранном блоке: баланс, nonce, код и storage. Хранение первого набора не означает, что база готова немедленно вернуть любой старый state.
Методы eth_getBalance, eth_call и другие state-запросы используют block parameter. Узнайте, поддерживает ли endpoint нужный старый номер для конкретного метода. Старый блок может быть доступен, хотя соответствующее состояние нужно пересчитать или получить у archive-источника.
- запрос содержит точный block number или tag;
- нужный вид данных определён;
- поддержка метода проверена на целевом блоке;
- история транзакций не принята за архив состояния.
Название режима клиента не заменяет проверку сохранённых данных
Клиенты предлагают разные sync modes и политики удаления данных. Например, snap sync и похожие стратегии могут быстро получить актуальную цепь, проверяя данные согласно правилам клиента, и не строить архив всех состояний. Настройки и возможности со временем меняются.
Для рабочей системы проверьте актуальную документацию выбранного execution-клиента: какие state данные он хранит, что удаляет, способен ли пересчитать старое значение и какие дополнительные индексы требуются. Consensus-клиент отдельно хранит данные consensus layer; это не делает execution-узел archive node.
Сначала составьте список запросов и только затем выбирайте архив
Зафиксируйте нужные методы, диапазон блоков, частоту запросов, допустимую задержку и требование независимого хранения. Проверьте тестовым запросом, отвечает ли собственный или удалённый endpoint на нужной высоте.
Если исторические запросы редки, отдельный архивный сервис может быть практичнее собственного archive node, но добавляет доверие к провайдеру и его хранению. Сверяйте критичный результат с другим источником или пересчитывайте его самостоятельно, если задача требует самостоятельной проверки.
- требуемый период записан в номерах блоков;
- блоки, receipts и state разделены;
- клиент и sync mode проверены по документации;
- источник archive state выбран осознанно;
- тестовый RPC-запрос подтвердил нужный метод.
Частые вопросы
Full node хранит все балансы с genesis?
Не обязательно. Execution-клиенты часто удаляют старые state данные и могут пересчитывать часть значений по истории.
Archive node нужен для обычного кошелька?
Обычно нет. Он нужен, если сервис регулярно запрашивает старые состояния напрямую.
Если блок виден в обозревателе, его state тоже доступен?
Не обязательно. Блок и receipts могут храниться отдельно от исторических состояний.
Сколько диска нужно archive node?
Зависит от клиента, версии и конфигурации; проверяйте текущие требования конкретного ПО и своих запросов.
Чек-лист: archive node и full node ethereum: доступ к истории и требования хранения
- задачи узла определены;
- исторические блоки и state различены;
- execution-клиент и sync mode проверены;
- поддержка block tag проверена для нужного метода;
- не использованы универсальные требования к диску;
- доверие к удалённому archive endpoint учтено;
- резервирование и обновления узла запланированы.
Материал подготовлен редакцией сайта и проверен 23 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.