Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем увеличиваются. Это происходит в двух аспектах:
Исторические данные: Все сделки и созданные аккаунты, происходившие в любой момент времени в истории, должны быть постоянно хранимы всеми клиентами и загружены любым новым клиентом для полной синхронизации с сетью. Это приводит к постоянному увеличению нагрузки на клиентов и времени синхронизации, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций намного проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать мощное противодействие этим двум тенденциям, со временем снижая сложность и расширение. В то же время нам нужно сохранить одно из ключевых свойств, которое делает блокчейн великим: долговечность. Вы можете разместить NFT, любовные письма в транзакционных записях или смарт-контракт на 1 миллион долларов на цепочке, и через 10 лет он все равно будет ждать вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно L1 самой.
Если мы решим добиться баланса между этими двумя потребностями и минимизировать или обратить вспять громоздкость, сложность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, а узлы Beacon Chain хранили старые данные не более чем за шесть месяцев. Найти этот путь для Ethereum более универсальным способом и двигаться к долгосрочному стабильному итоговому результату - это конечный вызов для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
Основная цель The Purge:
Снизить требования к хранилищу клиента, уменьшив или устранив необходимость в постоянном хранении всех историй и даже конечного состояния на каждом узле.
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен гигабайт дискового пространства для клиентской части консенсуса. Основная часть данных - это исторические данные: информация о исторических блоках, транзакциях и квитанциях, из которых большая часть имеет многолетнюю историю. Это означает, что даже если лимит Gas вовсе не увеличится, размер узла будет продолжать увеличиваться на несколько сотен гигабайт каждый год.
Что это такое и как это работает?
Ключевой упрощенной особенностью проблемы хранения истории является то, что каждый блок, связанный через хэш ( и другие структуры ), указывает на предыдущий блок, поэтому для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Если сеть достигнет консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (, такие как баланс счета, случайное число, код, хранилище ), могут быть предоставлены любым отдельным участником, а также с помощью доказательства Меркла, которое позволяет любому другому участнику проверить его корректность. Консенсус представляет собой модель доверия N/2 из N, в то время как история - модель доверия N из N.
Это дает нам много возможностей для хранения исторических записей. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распределяет миллионы файлов, каждый участник хранит и распределяет лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если, сделав работу узлов более экономически выгодной, мы сможем создать сеть из 100,000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая запись данных будет скопирована 10,000 раз – что совершенно соответствует коэффициенту копирования сети из 10,000 узлов, где каждый узел хранит все содержимое.
Сегодня Ethereum уже начинает отходить от модели, в которой все узлы постоянно хранят всю историю. Консенсусный блок ( связан с частью консенсуса на основе доказательства доли ), которая хранит данные примерно 6 месяцев. Blob хранится примерно 18 дней. EIP-4444 предназначен для введения годового срока хранения для исторических блоков и квитанций. Долгосрочная цель заключается в создании единого периода (, который может составлять около 18 дней ), в течение которого каждый узел отвечает за хранение всего содержимого, а затем создание сети пир-то-пир из узлов Ethereum, которая будет хранить старые данные в распределенной сети.
Коды стирания могут быть использованы для повышения устойчивости, сохраняя при этом одинаковый коэффициент репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и включение данных о выполнении и блоке согласования также в blob.
с существующими исследованиями какие связи?
ЭИП-4444
Торренты и EIP-4444
Портальная сеть
Портальная сеть и EIP-4444
Распределенное хранение и извлечение объектов SSZ в Portal
Как увеличить лимит газа(Paradigm)
Что еще нужно сделать, что нужно учитывать?
Оставшаяся основная работа включает в себя построение и интеграцию конкретного распределенного решения для хранения истории — по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение — это (i) просто внедрить существующую библиотеку торрент, а также (ii) решение на основе Эфира, называемое Portal Network. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл включить его одновременно для всех клиентов, иначе существует риск, что клиенты выйдут из строя из-за подключения к другим узлам с ожиданием загрузки полной истории, но на самом деле не получат ее.
Основные компромиссы связаны с тем, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — это завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это подрывает статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала создать и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторических хранилищ в протокол?
Экстремальный параноидальный подход к ( будет включать доказательство хранения: фактически требуя от каждого валидатора доказательства доли хранить определенный процент исторических данных и регулярно проверять их на это в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента истории, хранимой каждым клиентом.
Что касается ), базовая реализация касается только работы, завершенной на сегодня: Портал уже сохранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то хочет синхронизировать полный архивный узел или узел хранения истории, даже если другие архивные узлы не находятся в сети, они могут достичь этого с помощью прямой синхронизации с сети Портала.
( Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали исключительно простыми, то уменьшение требований к хранению истории можно считать более важным, чем безсостояние: из необходимых 1.1 ТБ для узла примерно 300 ГБ составляют состояние, а оставшиеся около 800 ГБ стали историей. Только достижение безсостояния и EIP-4444 позволит реализовать видение запуска узла Ethereum на умных часах и его настройки всего за несколько минут.
Ограничение исторического хранения также делает более новые узлы Ethereum более жизнеспособными, поддерживая только последнюю версию протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении на клиенте будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут заплатить единовременную плату, тем самым навсегда обременяя текущих и будущих клиентов Ethereum.
Состояние сложнее "исторического" в том смысле, что EVM изначально была спроектирована с предположением, что как только объект состояния создан, он будет существовать всегда и может быть прочитан в любой момент любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ), даже включая списки генерации! ### могут работать без состояния. Однако есть мнение, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим для поддержания децентрализации Ethereum.
( Что это такое, как это работает
Сегодня, когда вы создаете новый объект состояния, ) это может произойти одним из трех способов: ###i ( отправить ETH на новый аккаунт, (ii ) создать новый аккаунт с помощью кода, (iii ) установить ранее не затронутый слот хранения (, этот объект состояния всегда будет в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал со временем. Ключевая задача состоит в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны потерять доступ к ETH, ERC20, NFT, CDP позициям...
Дружелюбие к разработчикам: разработчики не обязаны переходить на совершенно незнакомую модель мышления. Кроме того, приложения, которые в настоящее время устарели и не обновляются, должны продолжать нормально работать.
Несоблюдение этих целей может привести к простым решениям. Например, вы можете позволить каждому объекту состояния также хранить счетчик даты истечения ), который может быть продлен за счет сжигания ETH. Это может автоматически происходить в любое время при чтении или записи ) и включает процесс обхода состояния для удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычисления ( и даже требования к хранению ), и это определенно не может удовлетворить требования к удобству для пользователей. Разработчикам также трудно рассуждать о крайних случаях, когда значения хранятся и иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в рамках контракта, это технически упрощает жизнь разработчикам, но усложняет экономическую ситуацию: разработчики должны учитывать, как "переложить" постоянные затраты на хранение на пользователей.
Это проблемы, которые ядро разработчиков Ethereum работало над решением в течение многих лет, включая предложения, такие как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее худших решений":
Решение для части статуса, срок действия которого истек
Рекомендации по истечению срока состояния на основе периодов адреса
( Частичное истечение состояния
Некоторые предложения о состоянии истекают, следуя одним и тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке будут храниться только в том случае, если они были недавно доступны. Существует механизм "воскрешения", если они больше не хранятся.
Основное отличие между этими предложениями заключается в том, как мы определяем "недавно": )i### и как мы определяем "блок"? Одно конкретное предложение - EIP-7736, которое основывается на дизайне "стеблей" для введения Verkle-дерева (, хотя и совместимо с любой формой безстатусного состояния, например, бинарным деревом ). В этом дизайне заголовки, код и хранилища, находящиеся рядом друг с другом, хранятся под одним "стеблем". Данные, хранящиеся под одним стеблем, могут составлять не более 256 * 31 = 7,936 байт. В многих случаях весь заголовок и код аккаунта, а также множество хранилищ ключей будут храниться под одним и тем же стеблем. Если данные под данным стеблем не считываются или не записываются в течение 6 месяцев, они больше не хранятся, а хранится только 32 байта этих данных.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
6
Поделиться
комментарий
0/400
LadderToolGuy
· 08-01 17:23
Исторические данные даже смеют удалять.
Посмотреть ОригиналОтветить0
Ser_APY_2000
· 08-01 13:46
Виталик действительно умеет делать дела
Посмотреть ОригиналОтветить0
TrustlessMaximalist
· 07-29 18:30
Виталик Бутерин говорит очень основательно.
Посмотреть ОригиналОтветить0
ConfusedWhale
· 07-29 18:27
Виталик все еще говорит так глубоко.
Посмотреть ОригиналОтветить0
hodl_therapist
· 07-29 18:17
Старый V не ошибается.
Посмотреть ОригиналОтветить0
MetaverseLandlord
· 07-29 18:06
Хранение пространства слишком дорого, лучше очистить его, чем накапливать.
Ethereum The Purge: Падение исторического хранения Упрощение Протокола Повышение устойчивости
Возможное будущее Ethereum: чистка
Автор: Виталик Бутерин
Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем увеличиваются. Это происходит в двух аспектах:
Исторические данные: Все сделки и созданные аккаунты, происходившие в любой момент времени в истории, должны быть постоянно хранимы всеми клиентами и загружены любым новым клиентом для полной синхронизации с сетью. Это приводит к постоянному увеличению нагрузки на клиентов и времени синхронизации, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций намного проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать мощное противодействие этим двум тенденциям, со временем снижая сложность и расширение. В то же время нам нужно сохранить одно из ключевых свойств, которое делает блокчейн великим: долговечность. Вы можете разместить NFT, любовные письма в транзакционных записях или смарт-контракт на 1 миллион долларов на цепочке, и через 10 лет он все равно будет ждать вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно L1 самой.
Если мы решим добиться баланса между этими двумя потребностями и минимизировать или обратить вспять громоздкость, сложность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, а узлы Beacon Chain хранили старые данные не более чем за шесть месяцев. Найти этот путь для Ethereum более универсальным способом и двигаться к долгосрочному стабильному итоговому результату - это конечный вызов для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
Основная цель The Purge:
! Виталик: возможное будущее для Ethereum, чистка
История истечения
Какую проблему это решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен гигабайт дискового пространства для клиентской части консенсуса. Основная часть данных - это исторические данные: информация о исторических блоках, транзакциях и квитанциях, из которых большая часть имеет многолетнюю историю. Это означает, что даже если лимит Gas вовсе не увеличится, размер узла будет продолжать увеличиваться на несколько сотен гигабайт каждый год.
Что это такое и как это работает?
Ключевой упрощенной особенностью проблемы хранения истории является то, что каждый блок, связанный через хэш ( и другие структуры ), указывает на предыдущий блок, поэтому для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Если сеть достигнет консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (, такие как баланс счета, случайное число, код, хранилище ), могут быть предоставлены любым отдельным участником, а также с помощью доказательства Меркла, которое позволяет любому другому участнику проверить его корректность. Консенсус представляет собой модель доверия N/2 из N, в то время как история - модель доверия N из N.
Это дает нам много возможностей для хранения исторических записей. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распределяет миллионы файлов, каждый участник хранит и распределяет лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если, сделав работу узлов более экономически выгодной, мы сможем создать сеть из 100,000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая запись данных будет скопирована 10,000 раз – что совершенно соответствует коэффициенту копирования сети из 10,000 узлов, где каждый узел хранит все содержимое.
Сегодня Ethereum уже начинает отходить от модели, в которой все узлы постоянно хранят всю историю. Консенсусный блок ( связан с частью консенсуса на основе доказательства доли ), которая хранит данные примерно 6 месяцев. Blob хранится примерно 18 дней. EIP-4444 предназначен для введения годового срока хранения для исторических блоков и квитанций. Долгосрочная цель заключается в создании единого периода (, который может составлять около 18 дней ), в течение которого каждый узел отвечает за хранение всего содержимого, а затем создание сети пир-то-пир из узлов Ethereum, которая будет хранить старые данные в распределенной сети.
Коды стирания могут быть использованы для повышения устойчивости, сохраняя при этом одинаковый коэффициент репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и включение данных о выполнении и блоке согласования также в blob.
с существующими исследованиями какие связи?
Что еще нужно сделать, что нужно учитывать?
Оставшаяся основная работа включает в себя построение и интеграцию конкретного распределенного решения для хранения истории — по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение — это (i) просто внедрить существующую библиотеку торрент, а также (ii) решение на основе Эфира, называемое Portal Network. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл включить его одновременно для всех клиентов, иначе существует риск, что клиенты выйдут из строя из-за подключения к другим узлам с ожиданием загрузки полной истории, но на самом деле не получат ее.
Основные компромиссы связаны с тем, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — это завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это подрывает статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала создать и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторических хранилищ в протокол?
Экстремальный параноидальный подход к ( будет включать доказательство хранения: фактически требуя от каждого валидатора доказательства доли хранить определенный процент исторических данных и регулярно проверять их на это в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента истории, хранимой каждым клиентом.
Что касается ), базовая реализация касается только работы, завершенной на сегодня: Портал уже сохранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то хочет синхронизировать полный архивный узел или узел хранения истории, даже если другие архивные узлы не находятся в сети, они могут достичь этого с помощью прямой синхронизации с сети Портала.
( Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали исключительно простыми, то уменьшение требований к хранению истории можно считать более важным, чем безсостояние: из необходимых 1.1 ТБ для узла примерно 300 ГБ составляют состояние, а оставшиеся около 800 ГБ стали историей. Только достижение безсостояния и EIP-4444 позволит реализовать видение запуска узла Ethereum на умных часах и его настройки всего за несколько минут.
Ограничение исторического хранения также делает более новые узлы Ethereum более жизнеспособными, поддерживая только последнюю версию протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
![Виталик: Возможное будущее Эфира, Уничтожение])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp###
Истечение срока действия
( Какую проблему решает?
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении на клиенте будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут заплатить единовременную плату, тем самым навсегда обременяя текущих и будущих клиентов Ethereum.
Состояние сложнее "исторического" в том смысле, что EVM изначально была спроектирована с предположением, что как только объект состояния создан, он будет существовать всегда и может быть прочитан в любой момент любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ), даже включая списки генерации! ### могут работать без состояния. Однако есть мнение, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим для поддержания децентрализации Ethereum.
( Что это такое, как это работает
Сегодня, когда вы создаете новый объект состояния, ) это может произойти одним из трех способов: ###i ( отправить ETH на новый аккаунт, (ii ) создать новый аккаунт с помощью кода, (iii ) установить ранее не затронутый слот хранения (, этот объект состояния всегда будет в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал со временем. Ключевая задача состоит в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны потерять доступ к ETH, ERC20, NFT, CDP позициям...
Дружелюбие к разработчикам: разработчики не обязаны переходить на совершенно незнакомую модель мышления. Кроме того, приложения, которые в настоящее время устарели и не обновляются, должны продолжать нормально работать.
Несоблюдение этих целей может привести к простым решениям. Например, вы можете позволить каждому объекту состояния также хранить счетчик даты истечения ), который может быть продлен за счет сжигания ETH. Это может автоматически происходить в любое время при чтении или записи ) и включает процесс обхода состояния для удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычисления ( и даже требования к хранению ), и это определенно не может удовлетворить требования к удобству для пользователей. Разработчикам также трудно рассуждать о крайних случаях, когда значения хранятся и иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в рамках контракта, это технически упрощает жизнь разработчикам, но усложняет экономическую ситуацию: разработчики должны учитывать, как "переложить" постоянные затраты на хранение на пользователей.
Это проблемы, которые ядро разработчиков Ethereum работало над решением в течение многих лет, включая предложения, такие как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее худших решений":
( Частичное истечение состояния
Некоторые предложения о состоянии истекают, следуя одним и тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке будут храниться только в том случае, если они были недавно доступны. Существует механизм "воскрешения", если они больше не хранятся.
Основное отличие между этими предложениями заключается в том, как мы определяем "недавно": )i### и как мы определяем "блок"? Одно конкретное предложение - EIP-7736, которое основывается на дизайне "стеблей" для введения Verkle-дерева (, хотя и совместимо с любой формой безстатусного состояния, например, бинарным деревом ). В этом дизайне заголовки, код и хранилища, находящиеся рядом друг с другом, хранятся под одним "стеблем". Данные, хранящиеся под одним стеблем, могут составлять не более 256 * 31 = 7,936 байт. В многих случаях весь заголовок и код аккаунта, а также множество хранилищ ключей будут храниться под одним и тем же стеблем. Если данные под данным стеблем не считываются или не записываются в течение 6 месяцев, они больше не хранятся, а хранится только 32 байта этих данных.