Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию раздувание и сложность любого блокчейн-протокола будут увеличиваться со временем. Это происходит в двух аспектах:
Исторические данные: любые сделки и созданные счета в любое время должны постоянно храниться всеми клиентами и загружаться любым новым клиентом для полной синхронизации с сетью. Это приводит к постоянному увеличению нагрузки на клиентов и времени синхронизации, даже если емкость цепочки остается неизменной.
Функциональность протокола: добавление новых функций намного проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долгое время поддерживаться, нам необходимо оказать мощное противодействие этим двум тенденциям, снижая сложность и экспансию с течением времени. Но при этом нам нужно сохранить одну из ключевых характеристик, делающих блокчейн великим: постоянство. Вы можете разместить NFT, любовное письмо или умный контракт на сумму 1 миллион долларов в сети, зайти в пещеру на десять лет и, выйдя, обнаружить, что он все еще там, ожидая вашего чтения и взаимодействия. Чтобы DApp могли полностью доверять децентрализации и удалить ключи для обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным для них образом — особенно сам L1.
Если мы решим достичь баланса между этими двумя потребностями и минимизировать или обратить вспять громоздкость, сложность и упадок, при этом сохраняя непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют с течением времени, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы цепи Beacon хранили старые данные максимум шесть месяцев. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является высшим вызовом для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
Снижение требований к хранению клиентом путем уменьшения или устранения необходимости для каждого узла постоянно хранить все исторические записи, даже конечное состояние.
Снижение сложности протокола путем устранения ненужных функций.
Содержание статьи:
История истекает(исторические записи истекают)
Состояние истечения(状态到期)
Очистка функций(特征清理)
История истечения срока действия
Какую проблему решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиентского программного обеспечения консенсуса. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и квитанциях, большинство из которых имеют многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевая упрощенная особенность проблемы хранения истории заключается в том, что каждый блок ссылается на предыдущий блок через хэш-ссылку ( и другие структуры ), поэтому достаточно достичь консенсуса по текущему, чтобы достичь консенсуса по истории. Пока сеть достигает консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (, балансы счетов, случайные числа, код, хранилище ) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его правильность. Консенсус представляет собой модель доверия N/2-of-N, тогда как история является моделью доверия N-of-N.
Это дает нам много вариантов для хранения исторических записей. Одним из естественных выборов является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работала сеть семян в течение десятилетий: хотя сеть в целом хранила и распределяла миллионы файлов, каждый участник хранил и распределял лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если мы можем создать экономически выгодную сеть из 100,000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая единица данных будет копироваться 10,000 раз - что совершенно соответствует коэффициенту копирования сети из 10,000 узлов, где каждый узел хранит все содержимое.
Теперь Эфир начинает избавляться от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок ( связан с частью консенсуса на основе доли ), хранящейся только около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 предназначен для введения одного года хранения для исторических блоков и квитанций. Долгосрочная цель состоит в том, чтобы создать единый период (, который может составлять около 18 дней ), в течение которого каждый узел отвечает за хранение всего, а затем создать одноранговую сеть из узлов Эфира, хранящую старые данные в распределенной сети.
Коды стирания могут быть использованы для повышения надежности, одновременно сохраняя одинаковый коэффициент копирования. Фактически, Blob уже использует коды стирания для поддержки выборки доступности данных. Самое простое решение, вероятно, заключается в повторном использовании этих кодов стирания и размещении данных о выполнении и консенсусных блоках также в blob.
Какие связи существуют с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444;
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение SSZ объектов в Portal;
Как повысить лимит газа ( Paradigm ).
Что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ как минимум истории выполнения, но в конечном итоге также включает консенсус и blob. Самым простым решением является (i) простое введение существующей библиотеки torrent, а также (ii) решение на основе Ethereum, называемое сетью Portal. Как только мы введем любое из них, мы сможем открыть 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###) и как мы определяем "блок" ((ii))? Одно из конкретных предложений - EIP-7736, которое основано на дизайне "стебель-лист", введенном для деревьев Verkle ((), хотя оно совместимо с любой формой безстатусного состояния, например, бинарным деревом ()). В этом дизайне соседние заголовки, код и слоты хранения хранятся под одним "стеблем". Данные, хранящиеся под одним стеблем, могут составлять максимум 256 * 31 = 7,936.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
7
Поделиться
комментарий
0/400
NotGonnaMakeIt
· 07-16 18:58
Огромный Блокчейн, наверное, утомил новые машины.
Посмотреть ОригиналОтветить0
MysteryBoxBuster
· 07-15 00:26
Эта цепь становится все более тяжёлой.
Посмотреть ОригиналОтветить0
SquidTeacher
· 07-14 03:56
Есть идеи, все хорошо.
Посмотреть ОригиналОтветить0
GasFeeCrier
· 07-14 03:53
Сейчас, наверное, самое время быть самым толстым?
Посмотреть ОригиналОтветить0
DefiOldTrickster
· 07-14 03:52
в блокчейне опять оказался великий пророк
Посмотреть ОригиналОтветить0
GasBandit
· 07-14 03:47
Когда я смогу обойти инфляцию?
Посмотреть ОригиналОтветить0
StablecoinArbitrageur
· 07-14 03:29
*настраивает таблицы* в соответствии с моим анализом корреляции, эффективность очистки = устойчивость сети * -0.89
Ethereum The Purge: создание долгосрочной устойчивой экосистемы Блокчейн
Возможное будущее Ethereum: чистка
Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию раздувание и сложность любого блокчейн-протокола будут увеличиваться со временем. Это происходит в двух аспектах:
Исторические данные: любые сделки и созданные счета в любое время должны постоянно храниться всеми клиентами и загружаться любым новым клиентом для полной синхронизации с сетью. Это приводит к постоянному увеличению нагрузки на клиентов и времени синхронизации, даже если емкость цепочки остается неизменной.
Функциональность протокола: добавление новых функций намного проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долгое время поддерживаться, нам необходимо оказать мощное противодействие этим двум тенденциям, снижая сложность и экспансию с течением времени. Но при этом нам нужно сохранить одну из ключевых характеристик, делающих блокчейн великим: постоянство. Вы можете разместить NFT, любовное письмо или умный контракт на сумму 1 миллион долларов в сети, зайти в пещеру на десять лет и, выйдя, обнаружить, что он все еще там, ожидая вашего чтения и взаимодействия. Чтобы DApp могли полностью доверять децентрализации и удалить ключи для обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным для них образом — особенно сам L1.
Если мы решим достичь баланса между этими двумя потребностями и минимизировать или обратить вспять громоздкость, сложность и упадок, при этом сохраняя непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют с течением времени, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы цепи Beacon хранили старые данные максимум шесть месяцев. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является высшим вызовом для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
! Виталик: возможное будущее для Ethereum, чистка
Чистка: основные цели.
Снижение требований к хранению клиентом путем уменьшения или устранения необходимости для каждого узла постоянно хранить все исторические записи, даже конечное состояние.
Снижение сложности протокола путем устранения ненужных функций.
Содержание статьи:
История истекает(исторические записи истекают) Состояние истечения(状态到期) Очистка функций(特征清理)
История истечения срока действия
Какую проблему решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиентского программного обеспечения консенсуса. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и квитанциях, большинство из которых имеют многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевая упрощенная особенность проблемы хранения истории заключается в том, что каждый блок ссылается на предыдущий блок через хэш-ссылку ( и другие структуры ), поэтому достаточно достичь консенсуса по текущему, чтобы достичь консенсуса по истории. Пока сеть достигает консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (, балансы счетов, случайные числа, код, хранилище ) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его правильность. Консенсус представляет собой модель доверия N/2-of-N, тогда как история является моделью доверия N-of-N.
Это дает нам много вариантов для хранения исторических записей. Одним из естественных выборов является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работала сеть семян в течение десятилетий: хотя сеть в целом хранила и распределяла миллионы файлов, каждый участник хранил и распределял лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если мы можем создать экономически выгодную сеть из 100,000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая единица данных будет копироваться 10,000 раз - что совершенно соответствует коэффициенту копирования сети из 10,000 узлов, где каждый узел хранит все содержимое.
Теперь Эфир начинает избавляться от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок ( связан с частью консенсуса на основе доли ), хранящейся только около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 предназначен для введения одного года хранения для исторических блоков и квитанций. Долгосрочная цель состоит в том, чтобы создать единый период (, который может составлять около 18 дней ), в течение которого каждый узел отвечает за хранение всего, а затем создать одноранговую сеть из узлов Эфира, хранящую старые данные в распределенной сети.
Коды стирания могут быть использованы для повышения надежности, одновременно сохраняя одинаковый коэффициент копирования. Фактически, Blob уже использует коды стирания для поддержки выборки доступности данных. Самое простое решение, вероятно, заключается в повторном использовании этих кодов стирания и размещении данных о выполнении и консенсусных блоках также в blob.
Какие связи существуют с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444;
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение SSZ объектов в Portal;
Как повысить лимит газа ( Paradigm ).
Что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ как минимум истории выполнения, но в конечном итоге также включает консенсус и blob. Самым простым решением является (i) простое введение существующей библиотеки torrent, а также (ii) решение на основе Ethereum, называемое сетью Portal. Как только мы введем любое из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но он действительно требует новой версии сетевого протокола. Поэтому имеет смысл одновременно включить его для всех клиентов, иначе существует риск, что клиенты потерпят неудачу из-за подключения к другим узлам с ожиданием загрузки полной истории, но на самом деле не получат ее.
Основные соображения касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение — прекратить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но ослабляет статус Эфира как места для постоянной записи. Более трудный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторического хранилища в протокол?
Экстремальный параноидальный подход к ( будет включать в себя доказательство хранения: фактически требует от каждого валидатора доказательства доли хранения определённого процента исторических данных и регулярной проверки их соответствия этому требованию в зашифрованном виде. Более мягкий подход состоит в том, чтобы установить добровольный стандарт для процента исторических данных, хранящихся каждым клиентом.
Что касается ), базовая реализация включает только уже завершённую работу на сегодня: Портал уже сохранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое соединение с процессом синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранилища или архивный узел, даже если другие архивные узлы не находятся онлайн, они смогут достичь этого через прямую синхронизацию из сети портала.
(# Как он взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов были крайне простыми, то уменьшение требований к хранению истории можно считать более важным, чем отсутствие состояния: из 1,1 ТБ, необходимых узлу, около 300 ГБ – это состояние, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно достичь видения о запуске узла Ethereum на умных часах и настройке всего за несколько минут.
Ограничение исторического хранения также делает более новыми узлы Ethereum более жизнеспособными, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранения, созданные во время DoS-атаки 2016 года, были удалены. Поскольку переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
) Срок действия
Какую проблему решает?
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении на клиенте будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает увеличиваться: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут заплатить единовременную плату, что навсегда обременит нынешних и будущих клиентов Ethereum.
Состояние сложнее "исторического" срока действия, потому что EVM изначально спроектирован на основе предположения, что как только объект состояния создан, он всегда будет существовать и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что проблема может не быть столь ужасной: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ### даже включая генерацию списков! ### могут работать без состояния. Тем не менее, существует мнение, что мы не хотим слишком сильно полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы сохранить децентрализацию Ethereum.
! Виталик: Возможное будущее Ethereum, Чистка
(# Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния, ) может происходить одним из следующих трех способов: ### i ( отправить ETH на новый аккаунт, ( ii ) создать новый аккаунт с помощью кода, ( iii ) установить ранее не затрагиваемый слот хранения (, который остается в этом состоянии навсегда. Напротив, то, что мы хотим, это чтобы объект автоматически истекал со временем. Ключевая задача заключается в том, чтобы достичь этого тремя способами:
Эффективность: не требуется大量 дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны терять доступ к ETH, ERC20, NFT, позициям CDP...
Дружелюбие к разработчикам: разработчики не должны переключаться на совершенно незнакомую им модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально функционировать.
Неудовлетворение этих целей может легко привести к решению проблемы. Например, вы можете сделать так, чтобы каждый объект состояния также хранил счетчик даты истечения ), который можно продлить с помощью сжигания ETH, что может происходить автоматически в любое время при чтении или записи ), и существует процесс обхода состояния для удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычислительные ( и даже требования к хранению ), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также трудно делать выводы о крайних случаях, связанных с хранимыми значениями, которые иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения срока действия в рамках контракта, это технически упрощает жизнь разработчикам, но затрудняет экономику: разработчики должны учитывать, как "перенести" постоянные затраты на хранение на пользователей.
Это все проблемы, которые ядро разработчиков Ethereum на протяжении многих лет пытается решить, включая предложения "аренда блокчейна" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее худших решений":
(# Частичное истечение состояния
Некоторые предложения о состоянии истекают и следуют тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", в которой блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только в том случае, если они были недавно доступны. Существует механизм "воскрешения", если данные больше не хранятся.
Основное различие между этими предложениями заключается в том, как мы определяем "недавний" ()i###) и как мы определяем "блок" ((ii))? Одно из конкретных предложений - EIP-7736, которое основано на дизайне "стебель-лист", введенном для деревьев Verkle ((), хотя оно совместимо с любой формой безстатусного состояния, например, бинарным деревом ()). В этом дизайне соседние заголовки, код и слоты хранения хранятся под одним "стеблем". Данные, хранящиеся под одним стеблем, могут составлять максимум 256 * 31 = 7,936.