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

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

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

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

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

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

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

Уборка: основные цели.

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

• Уменьшение сложности протокола за счет устранения ненужных функций.

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

• Срок действия истории (历史记录到期)
• Состояние истечения срока действия（状态到期）
• Удаление функций（特征清理）

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

Что решает?

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

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

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

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

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

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

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

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

• ЭИП-4444;
• Торренты и EIP-4444；
• Портальная сеть;
• Портальная сеть и EIP-4444;
• Распределенное хранение и извлечение объектов SSZ в Portal;
• Как увеличить лимит газа (Paradigm).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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