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

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

Перевод: как же

Особая благодарность за отзывы и рецензирование Джастина Дрейка, Тима Бейко, Мэтта Гарнетта, Пайпера Мерриама, Мариуса ван дер Вейдена и Томаша Станчака.

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

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

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

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

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

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

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

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

ЭИП-4444;

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

Портал сети;

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

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

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

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

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

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

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

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

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

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

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

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

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

Срок действия

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

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

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

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

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

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

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

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

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

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

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

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

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

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