---
title: "Архивная нода Эфириума"
description: "Обзор архивных нод"
lang: ru
sidebarDepth: 2
---

Архивная нода — это экземпляр клиента [Эфириума](/), настроенный для создания архива всех исторических состояний. Это полезный инструмент для определенных сценариев использования, но его запуск может быть сложнее, чем запуск полного узла.

## Предварительные требования {#prerequisites}

Вы должны понимать концепцию [узла Эфириума](/developers/docs/nodes-and-clients/), [его архитектуру](/developers/docs/nodes-and-clients/node-architecture/), [стратегии синхронизации](/developers/docs/nodes-and-clients/#sync-modes), а также практики их [запуска](/developers/docs/nodes-and-clients/run-a-node/) и [использования](/developers/docs/apis/json-rpc/).

## Что такое архивная нода {#what-is-an-archive-node}

Чтобы понять важность архивной ноды, давайте проясним концепцию «состояния». Эфириум можно назвать _машиной состояний на основе транзакций_. Он состоит из аккаунтов и приложений, выполняющих транзакции, которые изменяют их состояние. Глобальные данные с информацией о каждом аккаунте и контракте хранятся в базе данных в виде префиксного дерева (trie), называемой состоянием. Это обрабатывается клиентом уровня исполнения (EL) и включает в себя:

- Балансы аккаунтов и значения nonce
- Код и хранилище контрактов
- Данные, связанные с консенсусом, например, контракт стейкингового депозита

Для взаимодействия с сетью, проверки и создания новых блоков клиенты Эфириума должны отслеживать самые последние изменения (вершину цепи) и, следовательно, текущее состояние. Клиент уровня исполнения, настроенный как полный узел, проверяет и отслеживает последнее состояние сети, но кэширует только несколько прошлых состояний, например, состояние, связанное с последними 128 блоками, чтобы он мог обрабатывать реорганизации цепи и обеспечивать быстрый доступ к недавним данным. Недавнее состояние — это то, что нужно всем клиентам для проверки входящих транзакций и использования сети.

Вы можете представить состояние как моментальный снимок сети на определенном блоке, а архив — как воспроизведение истории.

Исторические состояния можно безопасно удалять (prune), поскольку они не нужны для работы сети, и для клиента было бы бесполезно и избыточно хранить все устаревшие данные. Состояния, существовавшие до некоторого недавнего блока (например, за 128 блоков до вершины), фактически отбрасываются. Полные узлы хранят только исторические данные блокчейна (блоки и транзакции) и периодические исторические снимки, которые они могут использовать для восстановления старых состояний по запросу. Они делают это путем повторного выполнения прошлых транзакций в EVM, что может быть вычислительно затратным, когда желаемое состояние находится далеко от ближайшего снимка.

Однако это означает, что доступ к историческому состоянию на полном узле потребляет много вычислительных ресурсов. Клиенту может потребоваться выполнить все прошлые транзакции и вычислить одно историческое состояние начиная с генезис-блока. Архивные ноды решают эту проблему, сохраняя не только самые последние состояния, но и каждое историческое состояние, созданное после каждого блока. По сути, это компромисс, требующий большего объема дискового пространства.

Важно отметить, что сеть не зависит от архивных нод для хранения и предоставления всех исторических данных. Как упоминалось выше, все исторические промежуточные состояния могут быть получены на полном узле. Транзакции хранятся любым полным узлом (в настоящее время это менее 400 ГБ) и могут быть воспроизведены для создания всего архива.

### Сценарии использования {#use-cases}

Регулярное использование Эфириума, такое как отправка транзакций, развертывание контрактов, проверка консенсуса и т. д., не требует доступа к историческим состояниям. Пользователям никогда не нужна архивная нода для стандартного взаимодействия с сетью.

Главное преимущество архива состояний — быстрый доступ к запросам об исторических состояниях. Например, архивная нода быстро вернет результаты на такие запросы, как:

- _Каким был баланс ETH аккаунта 0x1337... на блоке 15537393?_
- _Каков баланс токена 0x в контракте 0x на блоке 1920000?_

Как объяснялось выше, полному узлу потребовалось бы сгенерировать эти данные путем выполнения в EVM, что использует процессор и занимает время. Архивные ноды обращаются к ним на диске и мгновенно выдают ответы. Это полезная функция для определенных частей инфраструктуры, например:

- Поставщики услуг, такие как обозреватели блоков
- Исследователи
- Аналитики безопасности
- Разработчики децентрализованных приложений (dapp)
- Аудит и соблюдение нормативных требований

Существуют различные бесплатные [сервисы](/developers/docs/nodes-and-clients/nodes-as-a-service/), которые также предоставляют доступ к историческим данным. Поскольку запуск архивной ноды требует больше ресурсов, этот доступ в основном ограничен и работает только для периодических запросов. Если вашему проекту требуется постоянный доступ к историческим данным, вам следует рассмотреть возможность запуска собственной ноды.

## Реализации и использование {#implementations-and-usage}

Архивная нода в этом контексте означает данные, предоставляемые клиентами уровня исполнения, ориентированными на пользователя, поскольку они обрабатывают базу данных состояний и предоставляют конечные точки JSON-RPC. Параметры конфигурации, время синхронизации и размер базы данных могут различаться в зависимости от клиента. Для получения подробной информации обратитесь к документации, предоставленной вашим клиентом.

Прежде чем запускать собственную архивную ноду, изучите различия между клиентами и особенно различные [требования к оборудованию](/developers/docs/nodes-and-clients/run-a-node/#requirements). Большинство клиентов не оптимизированы для этой функции, и их архивы требуют более 12 ТБ пространства. В отличие от них, такие реализации, как Эригон, могут хранить те же данные в объеме менее 3 ТБ, что делает их наиболее эффективным способом запуска архивной ноды.

## Рекомендуемые практики {#recommended-practices}

Помимо общих [рекомендаций по запуску узла](/developers/docs/nodes-and-clients/run-a-node/), архивная нода может быть более требовательной к оборудованию и обслуживанию. Учитывая [ключевые особенности](https://github.com/ledgerwatch/erigon#key-features) Эригона, наиболее практичным подходом является использование реализации клиента [Эригон](/developers/docs/nodes-and-clients/#erigon).

### Оборудование {#hardware}

Всегда проверяйте требования к оборудованию для заданного режима в документации клиента.
Самое большое требование для архивных нод — это дисковое пространство. В зависимости от клиента оно варьируется от 3 ТБ до 12 ТБ. Даже если HDD может считаться лучшим решением для больших объемов данных, его синхронизация и постоянное обновление вершины цепи потребуют SSD-накопителей. Накопителей [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) вполне достаточно, но они должны быть надежного качества, как минимум [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). Диски можно установить в настольный компьютер или сервер с достаточным количеством слотов. Такие выделенные устройства идеально подходят для запуска узла с высоким временем безотказной работы. Вполне возможно запустить его на ноутбуке, но за портативность придется заплатить дополнительную цену.

Все данные должны помещаться на одном томе, поэтому диски необходимо объединить, например, с помощью [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) или LVM. Также стоит рассмотреть возможность использования [ZFS](https://en.wikipedia.org/wiki/ZFS), поскольку она поддерживает механизм «копирование при записи» (Copy-on-write), который гарантирует правильную запись данных на диск без каких-либо низкоуровневых ошибок.

Для большей стабильности и безопасности в предотвращении случайного повреждения базы данных, особенно в профессиональной среде, рассмотрите возможность использования [памяти ECC](https://en.wikipedia.org/wiki/ECC_memory), если ваша система ее поддерживает. Объем оперативной памяти обычно рекомендуется таким же, как и для полного узла, но больший объем ОЗУ может помочь ускорить синхронизацию.

Во время начальной синхронизации клиенты в архивном режиме будут выполнять каждую транзакцию начиная с генезис-блока. Скорость выполнения в основном ограничена процессором, поэтому более быстрый процессор может помочь сократить время начальной синхронизации. На среднем потребительском компьютере начальная синхронизация может занять до месяца.

## Дополнительная литература {#further-reading}

- [Полный узел Эфириума против архивной ноды](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) — _QuickNode, сентябрь 2022 г._
- [Создание собственной архивной ноды Эфириума](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) — _Томас Джей Раш (Thomas Jay Rush), август 2021 г._
- [Как настроить Эригон, RPC Эригона и TrueBlocks (сбор данных и API) в качестве сервисов](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _— Магнус Ханссон (Magnus Hansson), обновлено в сентябре 2022 г._

## Связанные темы {#related-topics}

- [Узлы и клиенты](/developers/docs/nodes-and-clients/)
- [Запуск узла](/developers/docs/nodes-and-clients/run-a-node/)