Возможное будущее Ethereum: чистка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![Виталик: возможное будущее Эфириума, The Purge])https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp(

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

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

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

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

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