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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

( Что решает?

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

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

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

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

• Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
• Удобство для пользователей: если кто-то войдет в пещеру на пять лет и вернется, они не должны потерять доступ к ETH, ERC20, NFT, CDP позициям...
• Дружественность к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.

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

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

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

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

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

Основное различие между этими предложениями заключается в следующем: )i### как мы определяем "недавний", и (ii) как мы определяем "блок"? Конкретное предложение - это EIP-7736, которое основано на дизайне "ветви и листа", введенном для Verkle деревьев (, хотя оно совместимо с любой формой безсостояния, например, двоичными деревьями ). В этом дизайне соседние заголовки, коды и хранилища данных хранятся под одним "стеблем". Данные, хранящиеся под одним стеблем, могут составлять не более чем 256 * 31 = 7936 байт. Во многих случаях весь заголовок и код аккаунта, а также множество хранилищ ключей будут храниться под одним и тем же стеблем. Если данные под заданным стеблем не были прочитаны или записаны в течение 6 месяцев, то эти данные больше не будут храниться, а будет храниться только 32-байтовое обязательство ("подпись" ). Транзакции, которые в будущем будут пытаться получить доступ к этим данным, должны будут "возродить" данные и предоставить доказательства проверки в соответствии с подписью.

Есть и другие способы реализовать похожие идеи. Например, если уровень детализации на уровне аккаунта недостаточен, мы можем разработать схему, в которой каждая 1/232 часть дерева контролируется подобным механизмом стебля и листьев.

Из-за стимулов это становится более сложным: злоумышленники могут "обновлять дерево", помещая большое количество данных в одно поддерево и отправляя одну транзакцию в год, тем самым заставляя клиента постоянно хранить большое количество состояния. Если вы сделаете стоимость продления пропорциональной размеру дерева ( или обратно пропорциональной продолжительности продления ), то кто-то может навредить другим пользователям, поместив большое количество данных в то же поддерево, что и они. Люди могут попытаться ограничить эти две проблемы, динамически изменяя тонкость в зависимости от размера поддерева: например, каждые 216= 65536 объектов состояния могут считаться "группой". Тем не менее, эти идеи более сложные; метод, основанный на стебле, прост, и стимулы могут быть скорректированы, поскольку обычно под стеблем.