НовостиКриптовалютыСинхронизация узлов Ethereum сокращена до менее чем полудня благодаря оптимизациям EIP-4444

Синхронизация узлов Ethereum сокращена до менее чем полудня благодаря оптимизациям EIP-4444

Автор: CryptoBriefing·

Ключевые выводы

  • •EIP-4444 был активирован 8 июля 2025 года, позволив исполняющим клиентам Ethereum удалять исторические данные, предшествующие переходу на proof of stake в сентябре 2022 года.
  • •Обновление сокращает потребность узлов в хранилище на 300–500 ГБ и позволяет новым узлам полностью синхронизироваться менее чем за полдня, при некоторых конфигурациях работая на общем хранилище менее 0,5 ТБ.
  • •Механизм частичного устаревания истории первоначально предполагал хранение примерно 33 000 эпох данных, но затем был пересмотрен до примерно 82 000 эпох, что эквивалентно примерно одному году истории цепи.
  • •Все пять основных исполняющих клиентов Ethereum — Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 и Reth v1.5.0 — выпустили поддержку этой функции.
  • •Архивные узлы, обслуживающие исторические запросы обозревателей блоков и аналитических платформ, продолжат хранить все данные, а Portal Network и аналогичные одноранговые решения призваны сохранить доступность удаленной истории в переходный период.
Синхронизация узлов Ethereum сокращена до менее чем полудня благодаря оптимизациям EIP-4444

После активации EIP-4444 8 июля 2025 года исполняющие клиенты Ethereum могут удалять исторические данные, созданные до перехода на Merge — смену механизма консенсуса сети на proof of stake в сентябре 2022 года, — сокращая требования к хранилищу на 300–500 ГБ и позволяя новым узлам синхронизироваться менее чем за полдня. При агрессивных настройках операторы могут запускать полнофункциональный узел на диске объемом 2 ТБ, удерживая общее хранилище ниже 0,5 ТБ.

Что на самом деле меняет EIP-4444

Улучшение основано на механизме, известном как «частичное устаревание истории» (partial history expiry). Вместо требования хранить полную историю блокчейна Ethereum на каждом узле EIP-4444 позволяет узлам удалять старые данные по истечении определенного периода хранения. Первоначальный дизайн предусматривал примерно 33 000 эпох — каждая эпоха представляет собой 6,4-минутный отрезок времени консенсуса, — однако этот показатель позднее был пересмотрен до приблизительно 82 000 эпох, или около одного года истории цепи.

Валидация текущей вершины цепи опирается на контрольные точки слабой субъективности — недавние состояния, которые клиенты получают из доверенного источника, вместо проверки всей цепи с генезиса. Консенсусный слой может выйти в сеть за считанные минуты благодаря checkpoint sync, а исполняющему слою больше не требуется загружать и проверять десять лет квитанций о транзакциях. Для операторов, которым нужен архивный доступ, механизмы получения исторических данных остаются доступными в качестве дополнительной функции.

Все пять основных исполняющих клиентов Ethereum уже поддерживают нововведение. Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 и Reth v15.0 включают необходимые флаги и конфигурации.

Почему хранилище становилось проблемой

До EIP-4444 полному узлу требовалось более 400 ГБ дискового пространства, и эта цифра двигалась только в одну сторону. Каждый новый блок, каждое взаимодействие со смарт-контрактом и каждый перевод токенов увеличивали объем.

Важно отметить ключевое различие: изменения касаются полных узлов и валидаторов, но не архивных узлов. Архивные узлы, которые обслуживают исторические запросы для обозревателей блоков и аналитических платформ, продолжат хранить все данные.

Уравнение доступности

Синхронизация менее чем за полдня при хранилище менее 0,5 ТБ означает, что в сети Ethereum может участвовать относительно скромный потребительский компьютер с приличным SSD. Для операторов это означает возможность проверять транзакции и балансы на собственном оборудовании, не полагаясь на сторонних провайдеров. Это контрастирует с многодневными процессами синхронизации и требованиями к хранилищу объемом более терабайта, с которыми раньше сталкивались новые операторы узлов.

EIP-4444 относится к фазе «Purge» («Очищение») дорожной карты Ethereum, которую Виталик Бутерин описывал как направленную на снижение сложности протокола и требований к узлам.

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

Источник: CryptoBriefing