Full node и archive node решают разные задачи хранения и выдачи данных. Полный узел проверяет правила сети и поддерживает актуальное состояние, а архивный дополнительно сохраняет исторические состояния после каждого блока. Оба могут быть частью инфраструктуры Ethereum, но архив нужен главным образом тем, кто часто запрашивает состояние аккаунтов и контрактов на старых высотах. Для отправки транзакций, чтения актуального баланса или обычной работы приложения постоянный архив обычно не требуется.
Что именно хранит Ethereum-узел
Ethereum работает как система, в которой выполнение транзакций меняет состояние аккаунтов и контрактов. В этом состоянии есть балансы, nonce, код контрактов и значения их хранилища. Исполняющий клиент обрабатывает блоки и поддерживает состояние, нужное для проверки новых операций. Полный узел получает блоки, проверяет их по правилам протокола и помогает другим участникам получить данные. Второй компонент, консенсусный клиент, синхронизируется с Beacon Chain; вместе они образуют обычный Ethereum-узел после перехода сети на Proof of Stake.
Термин «полный» не означает, что узел навсегда сохраняет каждую версию состояния с момента генезиса. Большинство стандартных конфигураций удаляет старые промежуточные состояния после того, как они перестают быть нужны для недавних проверок и обработки возможных реорганизаций. Исторические блоки и транзакции при этом отличаются от промежуточных состояний: блоки нужны для воспроизведения истории, а состояние аккаунта на произвольной старой высоте можно получить, повторно выполнив предыдущие транзакции. Практические детали хранения зависят от клиента и выбранного режима синхронизации.
Как full node проверяет цепочку
Полный узел проверяет блоки и состояние согласно правилам клиента. При синхронизации он может использовать контрольную точку и быстрый режим получения актуальных данных, но дальше продолжает следить за новыми блоками. Если старое промежуточное состояние было удалено, его иногда можно восстановить исполнением исторических транзакций от более близкой сохранённой точки. Такая работа требует процессорного времени, поэтому запрос к старой высоте может быть заметно медленнее, чем к текущему состоянию. Это не означает, что узел сломался: он просто не держит все снимки истории рядом.
Проверка блоков не равна роли валидатора. Узел может проверять данные и обслуживать RPC-запросы, не внося депозит в стейкинг и не предлагая блоки. Для участия в консенсусе требуется отдельная настройка валидатора, а для повседневного взаимодействия часто достаточно пользоваться узлом через локальный или доверенный RPC. Различие между receipt операции и состоянием сети описано в материале о результате транзакции и состоянии сети.
Зачем нужен архивный режим
Archive node сохраняет историю промежуточных состояний, поэтому может быстро отвечать на запрос «какой был баланс адреса на блоке N?» или «какое значение хранилось в контракте на той высоте?». Без такого архива full node может пересчитать состояние из транзакций, но запрос будет тяжелее и может занять больше времени. Архивные RPC используют обозреватели блоков, аналитические сервисы, исследовательские команды, аудиторы и приложения, которым приходится регулярно сверять данные за прошлые периоды.
Архив не является обязательной частью безопасности консенсуса. Новые блоки проверяются по актуальным правилам, а не потому, что каждый участник сети хранит все старые снимки. Архивные данные полезны для доступности и скорости исторических запросов, но экономически их разумно держать только тогда, когда есть регулярная потребность. Если исторические проверки эпизодические, иногда проще обратиться к поставщику данных или повторно вычислить нужный срез на собственном узле. Для анализа событий смарт-контрактов полезно также понимать разницу между логами событий и состоянием контракта.
Диск, синхронизация и обслуживание
Архивная конфигурация заметно увеличивает требования к накопителю, хотя точный объём нельзя назвать одной постоянной цифрой. Он меняется вместе с сетью, реализацией клиента, типом индекса, параметрами хранения и способом архивирования. Документация Geth описывает разные схемы хранения исторического состояния, а актуальные оценки следует проверять для конкретной версии. Быстрый накопитель влияет не только на загрузку архива, но и на поведение запросов и регулярное обслуживание базы. Перед выделением сервера стоит оценить рост данных и резерв дискового пространства.
Начальная синхронизация архивного узла может быть длительной: клиенту приходится получить историю, выполнить блоки и сохранить состояния. После запуска всё равно нужны обновления клиента, мониторинг диска, контроль синхронизации и ограничение доступа к RPC. Публичный JSON-RPC без защиты может позволить посторонним перегружать процесс или использовать его как транзитный сервис. Узел следует регулярно обновлять по инструкциям команды клиента, хранить конфигурацию и планировать восстановление после отказа диска. Не стоит менять параметры очистки, не понимая, какие старые данные будут недоступны.
Как выбрать тип узла
Для домашнего пользователя или разработчика, которому важна самостоятельная проверка актуального состояния, обычно достаточно full node. Для обозревателя, индексатора или аналитической платформы archive node оправдан, если приложение постоянно запрашивает исторические балансы и storage. Для кошелька, который проверяет ограниченный набор данных через заголовки и доказательства, задача может решаться light client. Эти роли не следует сводить к рейтингу «лучше-хуже»: они отличаются затратами, объёмом локальных данных и профилем запросов.
Перед запуском сформулируйте конкретный запрос, который будет получать приложение. Если сервис требует только текущие балансы, полная история состояний может лежать без дела. Если сервис сравнивает состояние контракта за годы, пересчёт каждого запроса на обычном узле окажется неудобным. Если важна независимость от внешнего API, собственный узел повышает контроль, но переносит на оператора обязанности по обновлению и хранению. Также учитывайте, что переиндексация данных для поискового сервиса может потребовать отдельной базы поверх узла.
Коротко: full node проверяет цепь и предоставляет актуальные данные, сохраняя ограниченный набор старых состояний; archive node тратит больше ресурсов ради быстрого доступа к истории состояний. Ethereum не зависит от того, что каждый пользователь держит такой архив. Выбирать режим следует по фактической нагрузке приложения, а требования к диску и синхронизации сверять с документацией выбранной версии клиента. Перестановки и откаты блоков описаны в статье о реорганизации блокчейна.
