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

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

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

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

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

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

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

The Purge:Основная цель.

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

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

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

Историческая запись истекла

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

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

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

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

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

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

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

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

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

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

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

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

ЭИП-4444;

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

Портал сети;

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

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

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

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

Основная работа, которая осталась, включает в себя построение и интеграцию конкретного распределенного решения для хранения истории------по крайней мере, истории выполнения, но в конечном итоге также включает консенсус и blob. Самым простым решением является (i) простое введение существующей библиотеки torrent, а также (ii), известной как нативное решение Ethereum под названием Portal Network. Как только мы введем любое из них, мы сможем открыть 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, Чистка

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