Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем будут расти. Это происходит в двух местах:
Исторические данные: любые транзакции и созданные учетные записи, проведенные в любой момент времени в прошлом, должны храниться всеми клиентами навсегда и загружаться любым новым клиентом для полной синхронизации с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, снижая сложность и расширение с течением времени. Но в то же время нам нужно сохранить одну из ключевых характеристик, делающих блокчейн великим: долговечность. Вы можете разместить NFT, письмо любви в данных торгового вызова или смарт-контракт на 1 миллион долларов в блокчейне, зайти в пещеру на десять лет, а когда выйдете, обнаружите, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли без опасений полностью децентрализоваться и удалить ключи обновления, им нужно быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно сам L1.
Если мы решим добиться баланса между этими двумя потребностями и при этом максимально уменьшить или обратить вспять избыточность, сложность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, большинство операций SELFDESTRUCT исчезло, а узлы цепи Beacon хранили старые данные максимум шесть месяцев. Найти путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату - это конечная задача для долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
The Purge: Основная цель.
Снизить требования к хранилищу клиента, уменьшая или исключая необходимость каждого узла постоянно хранить всю историю или даже окончательное состояние.
Снижение сложности протокола путем устранения ненужных функций.
Содержание статьи:
История истечения(исторические записи истекли)
Состояние истечения(状态到期)
Очистка функций ( 特征清理 )
Истечение истории
Какую проблему это решает?
На момент написания этой статьи полностью синхронизированным узлам Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также сотни ГБ дискового пространства для клиентской части консенсуса. При этом подавляющее большинство данных является историческими: это данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если ограничение Gas вообще не увеличится, размер узла будет продолжать расти на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевой упрощенной особенностью проблемы хранения истории является то, что поскольку каждый блок связан с предыдущим блоком через хэш ( и другие структуры ), для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Пока сеть достигнет консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (, такие как баланс счетов, случайные числа, код, хранилище ) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его правильность. Консенсус — это модель доверия N/2-of-N, а история — это модель доверия N-of-N.
Это дает нам множество вариантов хранения исторических записей. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распространяет миллионы файлов, каждый участник хранит и распространяет лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если мы можем создать экономически эффективную сеть из 100,000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая запись будет скопирована 10,000 раз - что совершенно идентично фактору копирования в сети из 10,000 узлов, где каждый узел хранит все данные.
Теперь Эфир начинает отходить от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок ( связан с частью консенсуса на основе доли ), которая хранится всего около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 предназначен для введения годичного срока хранения для исторических блоков и квитанций. Долгосрочная цель - создать единый период, который может составлять около 18 дней (, в течение которого каждый узел отвечает за хранение всего, а затем создать пиринговую сеть из узлов Эфира, которая будет хранить старые данные в распределенной сети.
![Vitalik: Возможное будущее Эфира, The Purge])ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(
Коды стирания могут быть использованы для повышения устойчивости, при этом сохраняя одинаковый коэффициент репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных выполнения и консенсусных блоков также в blob.
) с какими существующими исследованиями связан?
ЭИП-4444;
Торренты и EIP-4444;
Портал сети;
Портальная сеть и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как увеличить лимит газа ### Paradigm (.
) Что еще нужно сделать, что нужно взвесить?
Оставшиеся основные задачи включают в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение - это ###i( просто ввести существующую библиотеку торрент, а также )ii( решение на основе Эфира, называемое сетью Portal. Как только мы введем одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но он действительно требует новой версии сетевого протокола. Следовательно, включение его для всех клиентов одновременно имеет значение, иначе существует риск, что клиенты могут выйти из строя из-за ожидания загрузки полной истории, подключаясь к другим узлам, но на самом деле не получая её.
Основные компромиссы касаются того, как мы стремимся предоставить "древние" исторические данные. Самым простым решением было бы завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для репликации. Это легко, но это подрывает статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь заключается в том, чтобы сначала построить и интегрировать торрент-сеть для распределенного хранения истории. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторического хранилища в протокол?
Крайний параноидальный подход к )1( будет включать в себя доказательство хранения: фактически требуя от каждого валидатора с доказательством доли хранить определённый процент исторических данных и регулярно проверять их наличие в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента истории, хранимого каждым клиентом.
Что касается )2(, базовая реализация связана только с работой, которая уже завершена на сегодня: Портал уже хранил файл ERA, содержащий всю историю Эфира. Более полная реализация будет включать в себя фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не онлайн, они смогут это сделать через прямую синхронизацию с сети Портала.
) Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов были чрезвычайно простыми, то уменьшение требований к хранению истории можно считать более важным, чем безсостояние: из необходимых 1,1 ТБ на состояние уходит примерно 300 ГБ, а оставшиеся около 800 ГБ стали историей. Только достижение безсостояния и EIP-4444 позволит реализовать видение, согласно которому узлы Ethereum могут работать на смарт-часах и на их настройку потребуется всего несколько минут.
Ограничение исторического хранения также делает новые узлы Ethereum более жизнеспособными, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Поскольку переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
Даже если мы устраним необходимость хранения истории на клиенте, потребность в хранилище на клиенте будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает увеличиваться: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут оплатить одноразовую плату, тем самым навсегда обременив нынешних и будущих клиентов Ethereum.
Состояние сложнее «исторического» «истечения срока», потому что EVM по своей сути спроектирован на основе предположения, что как только объект состояния создан, он будет существовать всегда и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не такой уж плохой: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ###, даже содержащие генерацию списков! ( могут работать без состояния. Однако существует точка зрения, что мы не хотим слишком полагаться на безсостояние, в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы поддерживать децентрализацию Ethereum.
) Что это такое и как это работает?
Сегодня, когда вы создаете новый объект состояния, ### может произойти одним из следующих трех способов: (i ( отправить ETH на новую учетную запись, )ii ( создать новую учетную запись с помощью кода, )iii ( установить ранее неиспользуемый слот для хранения ), этот объект состояния навсегда останется в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал со временем. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется大量 дополнительных вычислений для запуска процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.
Неудовлетворение этих целей делает решение проблем очень простым. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения ), который может быть продлен сжиганием ETH; это может происходить автоматически в любое время при чтении или записи ( и имеет процесс обхода состояния для удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычислительные ) и даже требования к хранению (, и это определенно не может соответствовать требованиям удобства для пользователя. Разработчикам также трудно делать выводы о крайних случаях, когда значения хранилища иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в пределах контракта, это технически упростит жизнь разработчикам, но усложнит экономику: разработчики должны учитывать, как "перекладывать" постоянные затраты на хранение на пользователей.
Эти проблемы являются теми, над которыми ядро разработчиков Ethereum работало на протяжении многих лет, включая такие предложения, как "блокчейн-аренда" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
Решение для устаревших статусов
Рекомендации по истечению состояния на основе цикла адреса.
) Частичное истечение состояния
Некоторые предложения о состоянии истекают по одним и тем же принципам. Мы разбиваем состояние на блоки. Каждый постоянно хранит "верхнюю карту", в которой блоки могут быть пустыми или непустыми. Данные хранятся в каждом блоке только если они были недавно доступны. Существует механизм "воскрешения", который срабатывает, если данные больше не хранятся.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
7
Поделиться
комментарий
0/400
MidnightGenesis
· 9ч назад
в блокчейне мониторинг действительно показывает интересный код снижение нагрузки не терпит отлагательств
Посмотреть ОригиналОтветить0
SignatureVerifier
· 08-04 19:47
технически говоря, довольно обеспокоен недостаточными проверками в этом механизме очистки... требует тщательного аудита безопасности, если честно
Посмотреть ОригиналОтветить0
UnluckyLemur
· 08-03 10:23
Чеканка 100 токенов достаточно.
Посмотреть ОригиналОтветить0
DegenApeSurfer
· 08-03 10:22
Снижение нагрузки действительно слишком сложно.
Посмотреть ОригиналОтветить0
OldLeekNewSickle
· 08-03 10:20
Сокращение данных цепочки, или будут играть для лохов данные? Старый неудачник говорит, что не понимает.
Посмотреть ОригиналОтветить0
NonFungibleDegen
· 08-03 10:18
ngmi с этим вздутием сер... очистить или мы все в плохом состоянии fr fr
Ethereum The Purge план: Падение требований к хранилищу и упрощение сложности Протокола
Будущее Эфириума: Очистка
Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем будут расти. Это происходит в двух местах:
Исторические данные: любые транзакции и созданные учетные записи, проведенные в любой момент времени в прошлом, должны храниться всеми клиентами навсегда и загружаться любым новым клиентом для полной синхронизации с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, снижая сложность и расширение с течением времени. Но в то же время нам нужно сохранить одну из ключевых характеристик, делающих блокчейн великим: долговечность. Вы можете разместить NFT, письмо любви в данных торгового вызова или смарт-контракт на 1 миллион долларов в блокчейне, зайти в пещеру на десять лет, а когда выйдете, обнаружите, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли без опасений полностью децентрализоваться и удалить ключи обновления, им нужно быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно сам L1.
Если мы решим добиться баланса между этими двумя потребностями и при этом максимально уменьшить или обратить вспять избыточность, сложность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, большинство операций SELFDESTRUCT исчезло, а узлы цепи Beacon хранили старые данные максимум шесть месяцев. Найти путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату - это конечная задача для долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
The Purge: Основная цель.
Снизить требования к хранилищу клиента, уменьшая или исключая необходимость каждого узла постоянно хранить всю историю или даже окончательное состояние.
Снижение сложности протокола путем устранения ненужных функций.
Содержание статьи:
История истечения(исторические записи истекли)
Состояние истечения(状态到期)
Очистка функций ( 特征清理 )
Истечение истории
Какую проблему это решает?
На момент написания этой статьи полностью синхронизированным узлам Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также сотни ГБ дискового пространства для клиентской части консенсуса. При этом подавляющее большинство данных является историческими: это данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если ограничение Gas вообще не увеличится, размер узла будет продолжать расти на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевой упрощенной особенностью проблемы хранения истории является то, что поскольку каждый блок связан с предыдущим блоком через хэш ( и другие структуры ), для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Пока сеть достигнет консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (, такие как баланс счетов, случайные числа, код, хранилище ) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его правильность. Консенсус — это модель доверия N/2-of-N, а история — это модель доверия N-of-N.
Это дает нам множество вариантов хранения исторических записей. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распространяет миллионы файлов, каждый участник хранит и распространяет лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если мы можем создать экономически эффективную сеть из 100,000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая запись будет скопирована 10,000 раз - что совершенно идентично фактору копирования в сети из 10,000 узлов, где каждый узел хранит все данные.
Теперь Эфир начинает отходить от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок ( связан с частью консенсуса на основе доли ), которая хранится всего около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 предназначен для введения годичного срока хранения для исторических блоков и квитанций. Долгосрочная цель - создать единый период, который может составлять около 18 дней (, в течение которого каждый узел отвечает за хранение всего, а затем создать пиринговую сеть из узлов Эфира, которая будет хранить старые данные в распределенной сети.
![Vitalik: Возможное будущее Эфира, The Purge])ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(
Коды стирания могут быть использованы для повышения устойчивости, при этом сохраняя одинаковый коэффициент репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных выполнения и консенсусных блоков также в blob.
) с какими существующими исследованиями связан?
ЭИП-4444;
Торренты и EIP-4444;
Портал сети;
Портальная сеть и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как увеличить лимит газа ### Paradigm (.
) Что еще нужно сделать, что нужно взвесить?
Оставшиеся основные задачи включают в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение - это ###i( просто ввести существующую библиотеку торрент, а также )ii( решение на основе Эфира, называемое сетью Portal. Как только мы введем одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но он действительно требует новой версии сетевого протокола. Следовательно, включение его для всех клиентов одновременно имеет значение, иначе существует риск, что клиенты могут выйти из строя из-за ожидания загрузки полной истории, подключаясь к другим узлам, но на самом деле не получая её.
Основные компромиссы касаются того, как мы стремимся предоставить "древние" исторические данные. Самым простым решением было бы завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для репликации. Это легко, но это подрывает статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь заключается в том, чтобы сначала построить и интегрировать торрент-сеть для распределенного хранения истории. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторического хранилища в протокол?
Крайний параноидальный подход к )1( будет включать в себя доказательство хранения: фактически требуя от каждого валидатора с доказательством доли хранить определённый процент исторических данных и регулярно проверять их наличие в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента истории, хранимого каждым клиентом.
Что касается )2(, базовая реализация связана только с работой, которая уже завершена на сегодня: Портал уже хранил файл ERA, содержащий всю историю Эфира. Более полная реализация будет включать в себя фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не онлайн, они смогут это сделать через прямую синхронизацию с сети Портала.
) Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов были чрезвычайно простыми, то уменьшение требований к хранению истории можно считать более важным, чем безсостояние: из необходимых 1,1 ТБ на состояние уходит примерно 300 ГБ, а оставшиеся около 800 ГБ стали историей. Только достижение безсостояния и EIP-4444 позволит реализовать видение, согласно которому узлы Ethereum могут работать на смарт-часах и на их настройку потребуется всего несколько минут.
Ограничение исторического хранения также делает новые узлы Ethereum более жизнеспособными, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Поскольку переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
! [Виталик: возможное будущее Ethereum, чистка] ###ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg(
Истечение срока действия
) Какую проблему решает?
Даже если мы устраним необходимость хранения истории на клиенте, потребность в хранилище на клиенте будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает увеличиваться: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут оплатить одноразовую плату, тем самым навсегда обременив нынешних и будущих клиентов Ethereum.
Состояние сложнее «исторического» «истечения срока», потому что EVM по своей сути спроектирован на основе предположения, что как только объект состояния создан, он будет существовать всегда и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не такой уж плохой: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ###, даже содержащие генерацию списков! ( могут работать без состояния. Однако существует точка зрения, что мы не хотим слишком полагаться на безсостояние, в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы поддерживать децентрализацию Ethereum.
) Что это такое и как это работает?
Сегодня, когда вы создаете новый объект состояния, ### может произойти одним из следующих трех способов: (i ( отправить ETH на новую учетную запись, )ii ( создать новую учетную запись с помощью кода, )iii ( установить ранее неиспользуемый слот для хранения ), этот объект состояния навсегда останется в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал со временем. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется大量 дополнительных вычислений для запуска процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.
Неудовлетворение этих целей делает решение проблем очень простым. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения ), который может быть продлен сжиганием ETH; это может происходить автоматически в любое время при чтении или записи ( и имеет процесс обхода состояния для удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычислительные ) и даже требования к хранению (, и это определенно не может соответствовать требованиям удобства для пользователя. Разработчикам также трудно делать выводы о крайних случаях, когда значения хранилища иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в пределах контракта, это технически упростит жизнь разработчикам, но усложнит экономику: разработчики должны учитывать, как "перекладывать" постоянные затраты на хранение на пользователей.
Эти проблемы являются теми, над которыми ядро разработчиков Ethereum работало на протяжении многих лет, включая такие предложения, как "блокчейн-аренда" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
) Частичное истечение состояния
Некоторые предложения о состоянии истекают по одним и тем же принципам. Мы разбиваем состояние на блоки. Каждый постоянно хранит "верхнюю карту", в которой блоки могут быть пустыми или непустыми. Данные хранятся в каждом блоке только если они были недавно доступны. Существует механизм "воскрешения", который срабатывает, если данные больше не хранятся.
![Виталик: Будущее Эфира, The Purge]###