Виталик: возможное будущее Эфириума, The Purge

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

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

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

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

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

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

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

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

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

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

История истечения срока действия（历史记录到期）

Срок действия состояния（状态到期）

Очистка функций（特征清理）

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

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

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

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

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

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

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

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

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

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

ЭИП-4444;

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

Портальная сеть;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что решает?

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

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

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

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

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

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

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

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

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

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

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

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

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

Основное различие между этими предложениями заключается в том, как мы определяем "недавний".