Виталик: возможное будущее Эфира, The Purge

Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух местах:

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

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

Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, снижая сложность и расширение с течением времени. Но в то же время мы должны сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете поместить NFT, любовное письмо в данных торгового вызова или смарт-контракт на 1 миллион долларов в цепочку, войти в пещеру на десять лет, а затем выйти и обнаружить, что он все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно L1 сам по себе.

Если мы решим найти баланс между этими двумя потребностями и одновременно минимизировать или обратить вспять избыточность, сложность и упадок, это абсолютно возможно. Биологические организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: механизм доказательства работы исчез, операция SELFDESTRUCT в значительной степени исчезла, узлы маяка хранили старые данные в течение максимум шести месяцев. Найти путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является конечной задачей долгосрочной масштабируемости, технологической устойчивости и даже безопасности Ethereum.

! Виталик: возможное будущее для 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.

! Виталик: Возможное будущее Ethereum, Чистка

с какими существующими исследованиями он связан?

ЭИП-4444;

Торренты и EIP-4444；

Портальная сеть;

Портальная сеть и EIP-4444;

Распределенное хранение и извлечение объектов SSZ в Portal;

Как увеличить лимит газа (Paradigm).

Что еще нужно сделать, что нужно взвесить?

Оставшиеся основные задачи включают в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории исполнения, но в конечном итоге также включая консенсус и blob. Самое простое решение - это (i) просто внедрить существующую библиотеку torrent, а также (ii) называемое нативным решением Ethereum Portal. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но он действительно требует новой версии сетевого протокола. Поэтому будет полезно включить его для всех клиентов одновременно, иначе существует риск, что клиенты могут потерпеть неудачу из-за подключения к другим узлам с ожиданием загрузки полной истории, но фактически не получая ее.

Основные компромиссы касаются того, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — это завтра прекратить хранить древнюю историю и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала построить и интегрировать торрент-сеть для распределенного хранения истории. Здесь "насколько мы стараемся" имеет два измерения:

Как мы стараемся гарантировать, что максимальный набор узлов действительно хранит все данные?

Насколько глубока интеграция исторического хранения в протокол?

Экстремальный параноидальный подход к (1) будет включать в себя доказательство хранения: фактически требуя, чтобы каждый валидатор Proof of Stake хранил определённый процент истории и регулярно проверял их на это в зашифрованном виде. Более умеренный подход заключается в установлении добровольного стандарта для процентного соотношения истории, хранимой каждым клиентом.

Что касается (2), базовая реализация касается только завершенной работы на сегодня: Портал уже сохранил файл ERA, содержащий всю историю Ethereum. Более полная реализация будет заключаться в фактическом подключении его к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не будут доступны онлайн, они смогут это сделать через прямую синхронизацию с сети портала.

Как это взаимодействует с другими частями дорожной карты?

Если мы хотим сделать запуск или работу узлов невероятно простым, то снижение требований к хранению истории можно считать более важным, чем безсостояние: из необходимых 1,1 ТБ для узла около 300 ГБ - это состояние, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Ethereum на смарт-часах, который можно настроить всего за несколько минут.

Ограничение исторического хранения также делает более современным внедрение узлов Ethereum, поддерживающих только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Поскольку переход на Эфир стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.

! Виталик: Возможное будущее Ethereum, Чистка

Истечение срока действия

Решает какую проблему?

Даже если мы устранили необходимость хранения истории на клиенте, потребности в хранении на клиенте будут продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: остатки на счетах и случайные числа, коды контрактов и хранилище контрактов. Пользователи могут оплатить единовременную плату, чтобы навсегда обременить текущих и будущих клиентов Ethereum.

Состояние труднее "истекать", чем история, потому что EVM изначально спроектирован с предположением, что как только объект состояния создан, он всегда будет существовать и может быть прочитан в любое время любыми транзакциями. Если мы введем безсостояние, то некоторые считают, что эта проблема не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, тогда как все остальные узлы (даже включающие генерацию списков!) могут работать без состояния. Однако есть мнение, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем пожелать истечение состояния для поддержания децентрализации Ethereum.

Что это такое и как это работает

Сегодня, когда вы создаете новый объект состояния (это может происходить одним из следующих трех способов: (i) отправив ETH на новый аккаунт, (ii) создав новый аккаунт с помощью кода, (iii) установив ранее неиспользуемый слот хранения), этот объект состояния остается в этом состоянии навсегда. Напротив, то, что мы хотим, это чтобы объект автоматически устаревал с течением времени. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:

Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.

Удобство для пользователей: если кто-то проведет пять лет в пещере и вернется, он не должен потерять доступ к позициям ETH, ERC20, NFT, CDP...

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

Неудовлетворение этих целей легко решается. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения (который может быть продлен сжиганием ETH, что может автоматически происходить в любое время при чтении или записи), и иметь цикл для обхода состояния с целью удаления объектов состояния с истекшими датами. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также трудно рассуждать о крайних случаях, в которых значения хранилищ иногда сбрасываются на ноль. Если вы установите таймер истечения в рамках контракта, это технически облегчит жизнь разработчикам, но усложнит экономику: разработчики должны учитывать, как "перенести" постоянные затраты на хранение на пользователей.

Эти проблемы являются теми, над которыми ядро сообщества разработчиков Ethereum работало на протяжении многих лет, включая предложения такие как "аренда блокчейна" и "регенерация". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих решений":

• Решение для некоторых устаревших статусов
• Рекомендации по истечению срока действия состояния на основе периода адреса.

! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)

Частичное истечение срока действия состояния

Некоторые предложения о сроках истечения статуса следуют одинаковым принципам. Мы делим статус на блоки. Каждый навсегда хранит "верхнюю карту",