Архивный узел Эфириума

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

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

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

Что такое архивный узел

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

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

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

Можно представить статус, как мгновенный сетевой снимок определённого блока, а архив, как воспроизведение истории.

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

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

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

Примеры использования

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

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

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

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

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

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

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

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

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

Рекомендации по практическому применению

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

Аппаратное обеспечение

Всегда проверяйте требования к оборудованию для данного режима в документации клиента. Самым большим требованием для архивных узлов является дисковое пространство. В зависимости от клиента, оно колеблется от 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), если ваша система ее поддерживает. Объем оперативной памяти (RAM) рекомендуется выбирать таким же, как и для полного узла, однако больший объем оперативной памяти может помочь ускорить синхронизацию.

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

Дополнительные материалы

Полный узел Ethereum в сравнении с архивным узлом (opens in a new tab) - QuickNode, сентябрь 2022 г.
Создание собственного архивного узла Ethereum (opens in a new tab) - Thomas Jay Rush, август 2021 г.
Как настроить Erigon, RPC-сервер Erigon и TrueBlocks (сбор данных и API) в качестве служб (opens in a new tab) – Magnus Hansson, обновлено в сентябре 2022 г.