Архивная нода Эфириума

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

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

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

Что такое архивная нода

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

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

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

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

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

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

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

Сценарии использования

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

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

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

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

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

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

Реализации и использование

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

Прежде чем запускать собственную архивную ноду, изучите различия между клиентами и особенно различные требования к оборудованию. Большинство клиентов не оптимизированы для этой функции, и их архивы требуют более 12 ТБ пространства. В отличие от них, такие реализации, как Эригон, могут хранить те же данные в объеме менее 3 ТБ, что делает их наиболее эффективным способом запуска архивной ноды.

Рекомендуемые практики

Помимо общих рекомендаций по запуску узла, архивная нода может быть более требовательной к оборудованию и обслуживанию. Учитывая ключевые особенности (opens in a new tab) Эригона, наиболее практичным подходом является использование реализации клиента Эригон.

Оборудование

Всегда проверяйте требования к оборудованию для заданного режима в документации клиента. Самое большое требование для архивных нод — это дисковое пространство. В зависимости от клиента оно варьируется от 3 ТБ до 12 ТБ. Даже если HDD может считаться лучшим решением для больших объемов данных, его синхронизация и постоянное обновление вершины цепи потребуют SSD-накопителей. Накопителей SATA (opens in a new tab) вполне достаточно, но они должны быть надежного качества, как минимум TLC (opens in a new tab). Диски можно установить в настольный компьютер или сервер с достаточным количеством слотов. Такие выделенные устройства идеально подходят для запуска узла с высоким временем безотказной работы. Вполне возможно запустить его на ноутбуке, но за портативность придется заплатить дополнительную цену.

Все данные должны помещаться на одном томе, поэтому диски необходимо объединить, например, с помощью RAID0 (opens in a new tab) или LVM. Также стоит рассмотреть возможность использования ZFS (opens in a new tab), поскольку она поддерживает механизм «копирование при записи» (Copy-on-write), который гарантирует правильную запись данных на диск без каких-либо низкоуровневых ошибок.

Для большей стабильности и безопасности в предотвращении случайного повреждения базы данных, особенно в профессиональной среде, рассмотрите возможность использования памяти ECC (opens in a new tab), если ваша система ее поддерживает. Объем оперативной памяти обычно рекомендуется таким же, как и для полного узла, но больший объем ОЗУ может помочь ускорить синхронизацию.

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