Будущее Эфириума: The Purge

Автор: Виталик Бутерин

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

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

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

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

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

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

Пurge: основные цели.

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

Снизить сложность протокола, устранив ненужные функции.

Содержание статьи:

История истечения срока действия（历史记录到期）

Состояние истечения срока действия（状态到期）

Очистка функций（特征清理）

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

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

На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиентa консенсуса. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узлов будет продолжать расти на несколько сотен ГБ каждый год.

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

Ключевая упрощенная характеристика проблемы хранения истории заключается в том, что каждый блок ссылается на предыдущий блок через хэш-ссылки (и другие структуры), поэтому достаточно достичь консенсуса по текущему состоянию, чтобы достичь консенсуса по истории. Пока сеть достигла консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (баланс аккаунта, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником, а также доказаны с помощью Merkle, и эта проверка позволяет любому другому проверить ее правильность. Консенсус - это модель доверия N/2 из N, а история - это модель доверия N из N.

Это дает нам много возможностей для хранения истории. Одним из естественных вариантов является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распределяет миллионы файлов, каждый участник хранит и распределяет лишь несколько из них. Возможно, это противоречит интуиции, но такой подход даже не обязательно снижает надежность данных. Если сделать так, чтобы работа узлов была более экономичной, мы можем создать сеть из 100,000 узлов, где каждый узел хранит случайные 10% истории, тогда каждая запись будет копироваться 10,000 раз - что абсолютно соответствует копирующему фактору сети из 10,000 узлов, где каждый узел хранит все.

Теперь Ethereum начал избавляться от модели, при которой все узлы хранят всю историю навсегда. Консенсусные блоки (то есть часть, связанная с консенсусом Proof of Stake) хранятся лишь около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 призван ввести годичный срок хранения для исторических блоков и записей. Долгосрочная цель состоит в создании единого периода (возможно, около 18 дней), в течение которого каждый узел будет отвечать за хранение всего, а затем создать одноранговую сеть, состоящую из узлов Ethereum, где старые данные будут храниться в распределенном сетевом формате.

Коды стирания могут быть использованы для повышения надежности, сохраняя при этом одинаковый коэффициент копирования. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и включение данных выполнения и блока консенсуса также в blob.

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

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

ЭИП-4444;

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

Портал сеть;

Портал сеть и EIP-4444；

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

Как повысить лимит газа (Paradigm).

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

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

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

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

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

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

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

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

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

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

Состояние истечения срока

Какую проблему решить?

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

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

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

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

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

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

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

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

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

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

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

Частичное истечение состояния

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

Основное различие между этими предложениями заключается в следующем: (i) мы как