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

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

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

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

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

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

Чистка: основная цель.

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

Снижение сложности протокола путем устранения ненужных функций.

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

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

История истечения срока (历史记录到期)

Состояние истекло（状态到期）

Уборка функций（特征清理）

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

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

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

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

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

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

Теперь Ethereum начинает отходить от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок (то есть часть, связанная с консенсусом на основе доли) хранится только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 нацелен на введение годового срока хранения для исторических блоков иReceipt. Долгосрочной целью является создание единого периода (возможно, около 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) будет использование доказательства хранения: на самом деле это требует от каждого валидатора доказательства доли хранения определенного процента исторических данных и периодической проверки их на соответствие. Более мягкий подход заключается в установлении добровольного стандарта для процента исторических данных, хранящихся каждым клиентом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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