Исследователи Ethereum Foundation предупреждают о нагрузке на хранилище из-за "раздувания состояния" и предлагают пути для снижения узких мест узлов

Команда Stateless Consensus Фонда Ethereum изложила ряд идей по сдерживанию «раздувания состояния», предупредив, что постоянно растущий объем записей об аккаунтах, хранилище контрактов и байткоде становится все сложнее хранить, обслуживать и синхронизировать операторам узлов.

«Состояние» Ethereum охватывает все, что сеть знает на данный момент, включая балансы аккаунтов, хранилище контрактов и код, который обеспечивает работу приложений. Фонд отметил, что система стала критически важной частью глобальной инфраструктуры, которая «обеспечивает расчеты на миллиарды долларов» и координирует работу тысяч приложений.

Однако исследователи EF утверждают, что ее важность теперь породила серьезную проблему: состояние только растет; оно никогда не уменьшается.

По мере накопления данных запуск полного узла становится все более дорогим и уязвимым. В блоге EF отмечается, что «если состояние станет слишком большим, слишком централизованным или слишком сложным для обслуживания, все эти уровни становятся более уязвимыми, более дорогими и сложнее для децентрализации».

Улучшения масштабируемости, такие как расширение Layer 2, EIP-4844 (proto-danksharding) и увеличение лимита газа, позволили увеличить активность, но также ускоряют рост состояния.

Исследователи предупредили, что если только небольшой круг опытных операторов сможет позволить себе хранить и обслуживать полное состояние, устойчивость Ethereum к цензуре, его нейтральность и надежность могут ослабнуть. Команда заявила, что активно проводит стресс-тестирование, чтобы определить, когда «рост состояния становится узким местом масштабирования», когда «размер состояния затрудняет узлам следовать за головой цепи» и когда «реализации клиентов начинают давать сбои при экстремальном размере состояния».

Статическая валидация поднимает новый вопрос: кто хранит данные?

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

Хотя это снижает нагрузку на валидаторов и открывает путь к более высокой пропускной способности, это также перекладывает ответственность за хранение исторического состояния на меньшую, более специализированную группу. Исследователи написали, что в статической архитектуре «большинство состояния, скорее всего, будет храниться только: строителями блоков, RPC-провайдерами [и] другими специализированными операторами, такими как MEV searchers и block explorers».

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

Три предложенных пути

Команда Stateless Consensus предложила три возможных подхода, чтобы сделать хранение и обслуживание состояния более управляемым.

Первый — State Expiry — удаляет неактивные данные из активного набора, позволяя пользователям восстанавливать их с помощью доказательств. Команда отметила, что примерно «80% состояния не использовалось более 1 года», однако все узлы по-прежнему должны хранить его. Рассматриваются два варианта: «отметить, удалить, восстановить», который помечает и удаляет редко используемые записи, и «multi-era expiry», который группирует данные по эпохам и замораживает более старые.

Второй путь — State Archive — отделяет горячее состояние от холодного. Горячие данные остаются ограниченными по объему и быстрыми для доступа, в то время как холодные данные сохраняются для истории и проверки. Это позволит производительности узлов «оставаться примерно стабильной со временем, вместо того чтобы ухудшаться по мере старения цепи», даже несмотря на общий рост состояния.

Последний вариант — Partial Statelessness — позволяет узлам хранить только подмножества состояния, в то время как кошельки и легкие клиенты кэшируют необходимые им данные. Это может расширить участие, снизив затраты на хранение и уменьшив зависимость от крупных RPC-провайдеров.

Во всех трех подходах цель — «уменьшить состояние как узкое место производительности, снизить стоимость его хранения и упростить обслуживание».

Что дальше?

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

Согласно публикации, к ним относятся разработка архивов, улучшение инфраструктуры RPC и упрощение запуска частично статических узлов. Команда также подчеркнула, что эти инициативы были выбраны потому, что «они сразу полезны и совместимы с будущими изменениями».

В дальнейшем фонд пригласил разработчиков, операторов узлов и инфраструктурные команды к участию.

«По мере продвижения мы будем продолжать делиться нашим прогрессом и открытыми вопросами. Но мы не можем решить это в одиночку», — написали исследователи. «Если вы разрабатываете клиент, запускаете узел, управляете инфраструктурой, строите на Layer 2 или просто заботитесь о долгосрочном здоровье Ethereum, мы приглашаем вас присоединиться: делитесь отзывами о наших предложениях, участвуйте в обсуждениях на форумах и звонках и помогайте тестировать новые подходы на практике».

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