Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться со временем. Это происходит в двух местах:
Исторические данные: любые транзакции, проводимые в любой момент времени в прошлом, и любые созданные учетные записи должны быть навсегда сохранены всеми клиентами и загружены любым новым клиентом для полной синхронизации с сетью. Это приведет к увеличению нагрузки на клиента и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долгое время существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, снижая сложность и рост со временем. Но в то же время нам нужно сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете поместить NFT, любовное письмо из данных торгового вызова или смарт-контракт на сумму 1 миллион долларов в цепочку, зайти в пещеру на десять лет и, выйдя, обнаружить, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли спокойно полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно L1 сам по себе.
Если мы решим сбалансировать эти две потребности и максимально сократить или обратить вспять громоздкость, сложность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареет с течением времени, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы Beacon Chain хранили старые данные не более шести месяцев. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является высшим вызовом для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
Снижение требований к хранению клиентов за счет уменьшения или устранения необходимости в том, чтобы каждый узел постоянно хранил все исторические записи или даже конечное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
История истечения
Состояние истечения срока
Очистка функций
Истечение срока действия
Какую проблему решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также несколько сотен ГБ дискового пространства для клиентского программного обеспечения консенсуса. Большую часть этого объема составляет история: данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевая упрощенная характеристика проблемы хранения истории заключается в том, что каждый блок ссылается на предыдущий блок через хэш-ссылку ( и другие структуры ), поэтому достаточно достичь консенсуса по текущему, чтобы достичь консенсуса по истории. Как только сеть достигает консенсуса по последнему блоку, любой исторический блок, транзакция или состояние ( (баланс аккаунта, случайное число, код, хранилище )) могут быть предоставлены любым отдельным участником, а также с помощью доказательства Меркла, которое позволяет любому другому проверить его правильность. Консенсус представляет собой модель доверия N/2-of-N, в то время как история является моделью доверия N-of-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;
Как увеличить лимит газа.
Что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение - это ###i( просто внедрить существующие библиотеки torrent, а также )ii( решение на основе Ethereum, называемое Portal Network. Как только мы внедрим любое из них, мы сможем открыть EIP-4444. EIP-4444 сам по себе не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл активировать его одновременно для всех клиентов, иначе существует риск сбоя клиентов, которые ожидают загрузки полной истории, подключаясь к другим узлам, но фактически не получают ее.
Основные компромиссы касаются того, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — прекратить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет позицию Эфира как места для постоянного учета. Более сложный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что максимальный набор узлов действительно хранит все данные?
На какую глубину интегрировано историческое хранилище в протокол?
Экстремальный параноидальный подход к ) будет включать в себя доказательство хранения: фактически требует, чтобы каждый валидатор на основе доли хранил определенный процент истории и регулярно проверял, делает ли он это в зашифрованном виде. Более мягкий подход - установить добровольный стандарт для процента истории, хранимой каждым клиентом.
Что касается (2), базовая реализация затрагивает только работу, которая уже завершена на сегодня: Портал уже сохранил 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, включая такие предложения, как "блокчейн-аренда" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух классах "наименее плохих известных решений":
Решение для некоторых устаревших статусов
Рекомендации по истечению состояния на основе периода адреса.
( Частичное истечение состояния
Некоторые предложения о состоянии истекают, следуя одним и тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", в которой блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только в том случае, если эти данные были недавно доступны. Существует "
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
10
Поделиться
комментарий
0/400
HashRateHermit
· 07-16 17:28
Данные цепочки нужно было давно привести в порядок.
Посмотреть ОригиналОтветить0
GasFeeCrybaby
· 07-16 10:29
Хранение данных стоило мне жизни
Посмотреть ОригиналОтветить0
FlashLoanLarry
· 07-16 03:12
честно говоря, этот чистка должна лучше оптимизировать извлечение mev, или я ухожу...
Посмотреть ОригиналОтветить0
SerLiquidated
· 07-15 18:01
Цепь собирается взорваться или как?
Посмотреть ОригиналОтветить0
NFTArtisanHQ
· 07-13 18:06
удивительно, как цифровая энтропия параллелит готовые работы Дюшана... но сделайте это web3
Посмотреть ОригиналОтветить0
GateUser-c799715c
· 07-13 18:02
Нужно похудеть.
Посмотреть ОригиналОтветить0
MeaninglessApe
· 07-13 18:02
Убрать всё, чтобы ничего не осталось.
Посмотреть ОригиналОтветить0
gas_guzzler
· 07-13 18:00
А, как долго еще сможет продержаться толстая цепь?
Посмотреть ОригиналОтветить0
SorryRugPulled
· 07-13 17:59
Виталик снова планирует будущее.
Посмотреть ОригиналОтветить0
MemeCoinSavant
· 07-13 17:58
основываясь на тезисе очистки, если быть честным... статистически бычий для технической устойчивости eth
Ethereum The Purge: исследование исторического устаревания и очистки состояния для долгосрочной устойчивости
Возможное будущее Ethereum: чистка
Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться со временем. Это происходит в двух местах:
Исторические данные: любые транзакции, проводимые в любой момент времени в прошлом, и любые созданные учетные записи должны быть навсегда сохранены всеми клиентами и загружены любым новым клиентом для полной синхронизации с сетью. Это приведет к увеличению нагрузки на клиента и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долгое время существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, снижая сложность и рост со временем. Но в то же время нам нужно сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете поместить NFT, любовное письмо из данных торгового вызова или смарт-контракт на сумму 1 миллион долларов в цепочку, зайти в пещеру на десять лет и, выйдя, обнаружить, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли спокойно полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно L1 сам по себе.
Если мы решим сбалансировать эти две потребности и максимально сократить или обратить вспять громоздкость, сложность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареет с течением времени, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы Beacon Chain хранили старые данные не более шести месяцев. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является высшим вызовом для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
! Виталик: возможное будущее для Ethereum, чистка
Чистка: основные цели.
Снижение требований к хранению клиентов за счет уменьшения или устранения необходимости в том, чтобы каждый узел постоянно хранил все исторические записи или даже конечное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
История истечения
Состояние истечения срока
Очистка функций
Истечение срока действия
Какую проблему решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также несколько сотен ГБ дискового пространства для клиентского программного обеспечения консенсуса. Большую часть этого объема составляет история: данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевая упрощенная характеристика проблемы хранения истории заключается в том, что каждый блок ссылается на предыдущий блок через хэш-ссылку ( и другие структуры ), поэтому достаточно достичь консенсуса по текущему, чтобы достичь консенсуса по истории. Как только сеть достигает консенсуса по последнему блоку, любой исторический блок, транзакция или состояние ( (баланс аккаунта, случайное число, код, хранилище )) могут быть предоставлены любым отдельным участником, а также с помощью доказательства Меркла, которое позволяет любому другому проверить его правильность. Консенсус представляет собой модель доверия N/2-of-N, в то время как история является моделью доверия N-of-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;
Как увеличить лимит газа.
Что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение - это ###i( просто внедрить существующие библиотеки torrent, а также )ii( решение на основе Ethereum, называемое Portal Network. Как только мы внедрим любое из них, мы сможем открыть EIP-4444. EIP-4444 сам по себе не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл активировать его одновременно для всех клиентов, иначе существует риск сбоя клиентов, которые ожидают загрузки полной истории, подключаясь к другим узлам, но фактически не получают ее.
Основные компромиссы касаются того, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — прекратить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет позицию Эфира как места для постоянного учета. Более сложный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что максимальный набор узлов действительно хранит все данные?
На какую глубину интегрировано историческое хранилище в протокол?
Экстремальный параноидальный подход к ) будет включать в себя доказательство хранения: фактически требует, чтобы каждый валидатор на основе доли хранил определенный процент истории и регулярно проверял, делает ли он это в зашифрованном виде. Более мягкий подход - установить добровольный стандарт для процента истории, хранимой каждым клиентом.
Что касается (2), базовая реализация затрагивает только работу, которая уже завершена на сегодня: Портал уже сохранил ERA-файл, содержащий всю историю Ethereum. Более полная реализация будет включать в себя фактическое соединение с процессом синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не находятся в сети, они смогут это сделать через прямую синхронизацию из сети портала.
( Как это взаимодействует с другими частями дорожной карты?
Если мы хотим сделать запуск или работу узлов чрезвычайно простыми, то уменьшение требований к хранению истории можно считать более важным, чем безсостояние: из 1,1 ТБ, необходимых узлу, около 300 ГБ - это состояние, остальные около 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Ethereum на умных часах и его настройке всего за несколько минут.
Ограничение исторического хранения также делает более современный узел Ethereum более жизнеспособным, поддерживая только последнюю версию протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Поскольку переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
![Виталик: Возможное будущее Эфира, Устранение])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###
Истечение срока действия
( Какую проблему решает?
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении на клиенте будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут платить одноразовую плату, тем самым навсегда обременяя текущих и будущих клиентов Ethereum.
Состояние сложнее "исторического" срока годности, потому что EVM, по сути, спроектирован на основе предположения: как только создан объект состояния, он будет существовать всегда и может быть прочитан в любой момент любыми транзакциями. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы построителей блоков должны фактически хранить состояние, в то время как все остальные узлы ), даже содержащие списки генераций! ### могут работать без состояния. Однако есть мнение, что мы не хотим чрезмерно полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы сохранить децентрализованность Ethereum.
( Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния, ) может произойти одним из трех способов: ###i ( отправить ETH на новый аккаунт, (ii ) создать новый аккаунт с помощью кода, (iii ) установить ранее не затрагиваемый слот хранилища (, этот объект состояния навсегда остается в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал со временем. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователей: если кто-то войдет в пещеру на пять лет и вернется, он не должен терять доступ к своим позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.
Неудовлетворенность этими целями легко решает проблему. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения ), который может быть продлен за счет сжигания ETH; это может происходить автоматически в любое время при чтении или записи ) и есть процесс перебора состояния для удаления объектов состояния с истекшими датами. Однако это вводит дополнительные вычисления ( и даже требования к хранению ), и это определенно не может удовлетворить требования удобства для пользователя. Разработчикам также трудно делать выводы о крайних ситуациях, в которых хранимые значения иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в пределах контракта, это технически облегчает жизнь разработчикам, но усложняет экономику: разработчики должны учитывать, как "переложить" постоянные затраты на хранение на пользователей.
! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
Эти проблемы являются предметом многолетних усилий ядра сообщества разработчиков Ethereum, включая такие предложения, как "блокчейн-аренда" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух классах "наименее плохих известных решений":
( Частичное истечение состояния
Некоторые предложения о состоянии истекают, следуя одним и тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", в которой блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только в том случае, если эти данные были недавно доступны. Существует "