Особая благодарность Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden и Tomasz Stanczak за обратную связь и обзор.

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

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

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

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

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

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

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

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

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

· History expiry（истекший срок истории）

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

· Очистка функций

Срок истории

Что решает эту проблему?

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

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

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

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

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

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

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

· ЭИП-4444 ;

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

· Сеть портала;

· Портальная сеть и EIP-4444 ；

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

Как повысить лимит Газа (Paradigm)?

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

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

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

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

2. Как глубоко интегрировано историческое хранилище в Протоколе?

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

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

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

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

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

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

Что решает эту проблему?

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

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

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

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

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

2. Дружественность к пользователям: если кто-то входит в пещеру на пять лет и возвращается, он не должен потерять доступ к ETH, ERC 20, NFT, позициям CDP …

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

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

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

· Частичное решение проблемы истечения срока действия

· Советы по состоянию адреса, основанные на истекающем периоде.

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

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

Основное различие между этими предложениями заключается в том, как мы определяем “недавно”, и как мы определяем “блок”. Одним из конкретных предложений является EIP-7736, который основан на дизайне “веток” для введения дерева Verkle (хотя совместим с любой формой безсостоятельного состояния, такой как двоичное дерево). В этом дизайне смежные заголовки, коды и хранилища хранятся в одной и той же “основе”. Данные, хранящиеся под этой веткой, могут быть длиной до 256 * 31 = 7, 936 байт. Во многих случаях весь заголовок и код аккаунта, а также множество хранилищ ключей будут храниться в одной и той же основе. Если данные под данной основой не были прочитаны или записаны в течение 6 месяцев, то эти данные больше не хранятся, а вместо этого хранится только 32-байтовое обещание (“стержень”). Будущие транзакции, обращающиеся к этим данным, будут требовать “возрождения” данных и предоставления доказательства на основе стержня.

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

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

Рекомендации по истечению срока состояния на основе цикла адреса

Если мы хотим полностью избежать любого постоянного роста состояния, даже 32-байтового стаба, что делать? Это проблема из-за конфликта оживления: если объект состояния удален, а затем EVM выполнит другой объект состояния на точно том же месте, но потом возвращаются люди, которые заботятся о первоначальном объекте состояния и пытаются восстановить его, что делать? «Стаб» предотвращает создание новых данных при истечении срока действия части состояния. При полном истечении срока действия состояния мы даже не сможем хранить стаб.

Одной из самых известных идей для решения этой проблемы является дизайн, основанный на адресном цикле. Мы не используем дерево состояний для хранения всего состояния, а имеем список деревьев состояний, который постоянно растет, и любое чтение или запись состояния сохраняется в последнем дереве состояний. Каждый период (например, 1 год) добавляется новое пустое дерево состояний. Старые деревья заморожены. Полный узел хранит только два последних дерева. Если объект состояния не был касаемым в течение двух периодов и попал в просроченное дерево, его все еще можно прочитать или записать, но транзакция должна доказать его Merkle-доказательство - как только это будет доказано, копия будет сохранена в последнем дереве.

Один из ключевых принципов, который делает это дружелюбным как для пользователей, так и для разработчиков, - это концепция цикла Адреса. Цикл Адреса - это числовая часть Адреса. Основное правило заключается в том, что Адрес с циклом N может быть прочитан или записан только в период N или после него (то есть, когда список состояний достигает длины N). Если вы хотите сохранить новый объект состояния (например, новый контракт или новый остаток ERC 20), и вы убедитесь, что объект состояния размещен в контракте с циклом N или N-1, то вы можете сохранить его немедленно, без необходимости предоставления доказательства о том, что раньше ничего не было. С другой стороны, любое добавление или редактирование, сделанное во время старого цикла Адреса, требует доказательства.

Этот дизайн сохраняет большую часть текущих свойств Ethereum, не требуя дополнительных вычислений, позволяя писать приложения почти так же, как сейчас (ERC 20 нужно будет переписать, чтобы убедиться, что балансы Адресов с периодом N хранятся в подконтракте, который имеет период N), решая проблему «пять лет пользователь в пещере». Однако у него есть большая проблема: Адрес должен быть расширен до более чем 20 байт, чтобы соответствовать периоду N.

Расширение пространства адресов Адрес空间扩展

Один из предложений - ввести новый формат 32 байт для Адреса, включающий номер версии, номер цикла Адреса и расширенный хэш.

0x01 (красный) 0000 (оранжевый) 000001 (зеленый) 57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF (синий)。

Красное - это номер версии. Здесь четыре нуля оранжевого цвета предназначены для пустого пространства, которое может вместить номер Шардинга. Зеленый - это номер цикла Адреса. Синий - это хеш-значение из 26 байтов.

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

Сжатие адресного пространства

Другой способ - пойти в обратном направлении: мы сразу запрещаем некоторый диапазон под-адресов размером 2^128 (например, все адреса, начинающиеся с 0xffffffff), а затем вводим в этот диапазон адрес с циклическим периодом и хеш-значением длиной 14 байт.

0xffffffff000169125 d5dFcb7B8C2659029395bdF

Основной жертвой этого метода является введение риска безопасности обратных фактов: у Адрес есть активы или разрешения, но его код еще не был опубликован в сети. Риск заключается в том, что кто-то создаст Адрес, который утверждает, что у него есть отрывок кода (который еще не был опубликован), но также есть другой действительный код, хэш которого совпадает с хэшем того же Адреса. По сегодняшним меркам для вычисления такого столкновения требуется 2^80 хешей; сжатие пространства Адресов сократит это число до более доступных 2^56 хешей.

Важные области риска, то есть фактические адреса Кошелек, не принадлежащие одному владельцу, на сегодняшний день являются редкостью, но с появлением мира L2 они могут стать более распространенными. Единственное решение - просто принять этот риск, но необходимо определить все распространенные случаи, где могут возникнуть проблемы, и предложить эффективные решения.

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

Раннее предложение

Блокчейн чистый;

Восстановление;

Теория управления размером состояния Ethereum;

Некоторые возможные пути отсутствия состояния и истечения срока действия состояния;

Предложение об истечении срока некоторых состояний

ЭИП-7736 ;

Документ по расширению адресного пространства

Исходное предложение;

Ipsilon отзыв;

Комментарии к статье в блоге;

Если мы потеряем сопротивление столкновения, что будет разрушено.

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

Я считаю, что в будущем существует четыре возможных пути:

· Мы достигаем состояния без состояния и никогда не вводим истекшее состояние. Состояние постоянно растет (хотя и медленно: мы можем не видеть его более 8 ТБ десятилетий), но это требуется только от относительно специфической категории пользователей: даже валидаторам PoS не нужно состояние.

Одной из функций, включающих генерацию списка, является функция доступа к части состояния, но мы можем выполнить эту операцию децентрализованно: каждый пользователь отвечает за поддержание части состояния дерева, содержащей его собственную учетную запись. При передаче транзакции они широковещательно передают транзакцию и прикрепляют доказательство состояния, к которому они обращались во время проверки (это относится к учетным записям EOA и ERC-4337). Затем безсостояний проверяющий может объединить эти доказательства в одно доказательство, содержащее список.

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

· Мы используем расширение пространства Адресов для устаревания состояния. Этот процесс займет несколько лет, чтобы гарантировать, что методы преобразования формата Адреса будут эффективными и безопасными, включая существующие приложения.

· Мы проводим сжатие пространства адресов для истечения срока действия состояния. Это будет длительный процесс, чтобы обеспечить обработку всех возникающих рисков безопасности, связанных с конфликтами адресов (включая случаи взаимодействия кросс-чейн).

Важным моментом является то, что в конечном итоге необходимо решить проблемы расширения и сжатия пространства Адрес, независимо от того, будет ли реализован план завершения состояния, зависящий от изменений формата. В настоящее время для генерации конфликтов Адреса требуется около 2 80 хешей, что для участников с изобилием ресурсов уже является выполнимой вычислительной нагрузкой: GPU может вычислить приблизительно 2 27 хешей, поэтому за год можно вычислить 2 52, таким образом, все примерно 230 GPU в мире могут найти столкновение примерно за 1/4 года, а FPGA и ASIC могут дополнительно ускорить этот процесс. В будущем такие атаки станут доступны все большему числу людей. Поэтому реальные затраты на полное завершение состояния могут быть не такими высокими, как кажется, потому что в любом случае нам нужно решить эту очень сложную проблему Адреса.

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

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

Очистка функций

Что оно решает?

Одним из ключевых предпосылок безопасности, доступности и нейтральности является простота. Если протокол является эстетичным и простым, это снижает вероятность ошибок. Это увеличивает возможность вовлечения новых разработчиков в любую его часть. Он более справедливый и легче устойчив к специфическим интересам. К сожалению, протокол, как и любая социальная система, по умолчанию становится все сложнее со временем. Если мы не хотим, чтобы Ethereum попал в воронку все возрастающей сложности, нам нужно сделать одно из двух: (i) прекратить вносить изменения и заморозить протокол, (ii) иметь возможность фактически удалять функции и падение сложности. Также возможен промежуточный путь, который заключается в внесении меньшего количества изменений в протокол и постепенном устранении хотя бы некоторой сложности со временем. В этом разделе будет обсуждаться, как снизить или устранить сложность.

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

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

Пример, который находится в большой степени завершен, - это удаление операции SELFDESTRUCT и может служить моделью для обработки других примеров. Операция SELFDESTRUCT - это единственная операция, которая может изменять неограниченное количество слотов хранения внутри одного блока, что требует от клиента реализации значительно большей сложности для предотвращения атаки DoS. Исходная цель этой операции заключалась в реализации добровольной ликвидации состояния, что позволяет уменьшать размер состояния со временем. На самом деле, ею редко кто-то пользуется. Операция была ослаблена, и теперь она позволяет создавать самоуничтожающиеся счета только в рамках одной транзакции, созданной в одном и том же блоке Dencun хардфорка. Это решает проблему DoS и может значительно упростить клиентский код. В будущем полное удаление операции может иметь смысл.

До сих пор некоторые ключевые примеры упрощения возможности протокола включают следующее. Во-первых, некоторые примеры за пределами EVM; они относительно неинвазивны, поэтому их легче достичь соглашения и реализовать за более короткий период времени.

· Преобразование RLP в SSZ: изначально объекты Ethereum использовали кодирование с использованием RLP для сериализации. RLP является без типовым и излишне сложным. В настоящее время блокчейн-маяк использует SSZ, который во многих отношениях намного лучше, поскольку он поддерживает не только сериализацию, но и хеширование. В конечном итоге мы надеемся полностью избавиться от RLP и перенести все типы данных в структуру SSZ, что в свою очередь сделает обновление более простым. Текущие EIP включают [ 1 ] [ 2 ] [ 3 ].

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

· РЕФОРМА ЖУРНАЛА: Создание блум-фильтра и другой логики увеличивает сложность протокола, но на самом деле не используется клиентом, потому что это слишком медленно. Мы можем удалить эти функции и сосредоточиться на альтернативных решениях, таких как инструмент чтения журнала с использованием современных технологий, таких как SNARK, для децентрализованного доступа к протоколу.

· Конечное удаление механизма синхронизации блокчейн-маяк: Механизм синхронизации был изначально введен для обеспечения проверки легкого клиента ETH на основе утверждений. Однако он значительно увеличивает сложность протокола. В конечном итоге мы сможем непосредственно использовать проверку SNARK на уровне соглашения ETH, что устранит необходимость в специализированной проверке легкого клиента для протокола. Потенциально изменения в соглашении могут позволить нам раньше удалить синхронизацию комитета путем создания более «естественного» протокола легкого клиента, который включает в себя подписи случайного подмножества валидаторов соглашения ETH.

· Единый формат данных: В настоящее время состояние выполнения хранится в дереве Merkle Patricia, состояние соглашения хранится в дереве SSZ, и блобы передаются с использованием обязательств KZG. В будущем имеет смысл иметь единый формат данных для блоков и единый формат данных для состояния. Эти форматы будут удовлетворять всем основным требованиям: (i) простому доказательству для клиента без состояния, (ii) сериализации и кодированию с использованием стирания данных, (iii) нормализованным структурам данных.

· Удалить комитет блокчейн-маяк: Этот механизм изначально был введен для поддержки выполнения Шардинга в определенной версии. Вместо этого мы в конечном итоге используем L2 и блоб для Шардинга. Поэтому комитет не нужен и принимаются меры по его удалению.

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

Сейчас некоторые примеры в EVM:

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

· Удаление предварительной компиляции: многие предварительные компиляции, которыми в настоящее время обладает ETH坊, являются излишне сложными, относительно неиспользуемыми и составляют значительную часть Соглашение-провалов практически без каких-либо применений. Два способа решения этой проблемы: (i) удаление только предварительной компиляции и (ii) замена ее на участок (неизбежно более дорогого) кода EVM, реализующий ту же логику. Черновик этого EIP предлагает выполнить эту операцию только для предварительной компиляции личности; позже RIPEMD 160, MODEXP и BLAKE могут стать кандидатами на удаление.

· Удаление Газ Наблюдаемость: Это делает EVM исполнение не видит, сколько Газ остается. Это разрушит некоторые приложения (наиболее очевидное - спонсируемые транзакции), но в будущем будет легче обновить (например, для более продвинутой версии газа). Спецификация EOF уже делает Газ невидимым, но для упрощения Протокола EOF должен стать обязательным.

· Улучшение статического анализа: в настоящее время статический анализ кода EVM затруднен, особенно из-за возможности динамических переходов. Это также делает более сложным оптимизацию реализации EVM (предкомпиляция кода EVM в другие языки). Мы можем решить эту проблему, удалив динамические переходы (или делая их более дорогими, например, линейными по отношению к количеству JUMPDEST в контракте). Здесь идея заключается в том, чтобы принудительно применять EOF, хотя для получения преимуществ от упрощения протокола необходимо его обязательное применение.

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

· Шаги по очистке;

· Самоуничтожение

· SSZ преобразование EIPS: [1] [2] [3];

· Бесстатусный Газ изменение стоимости；

· Линейное ценообразование памяти;

· Удаление предварительной компиляции;

· блум-фильтр移除；

· Метод обеспечения безопасного поиска журналов с использованием приращенных верифицируемых вычислений (читается: рекурсивный STARK) вне блокчейна;

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

Основным компромиссом при упрощении этой функции являются (i) степень и скорость нашего упрощения и (ii) обратная совместимость. Ценность Ethereum как цепи происходит от того, что она является платформой, на которой можно развертывать приложения, и уверенность в том, что она будет работать еще много лет. В то же время этот идеал может быть слишком далеким, как сказал Уильям Дженнингс Брайан, «приковать Ethereum к кресту обратной совместимости». Если во всей сети Ethereum есть только два приложения, использующих определенную функцию, и одно из приложений не имеет пользователей уже много лет, а другое приложение почти не используется и имеет общую стоимость в 57 долларов, мы должны удалить эту функцию и, если нужно, возместить пострадавшему 57 долларов.

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

1. Начните говорить об удалении функции X;

2. Проведение анализа для определения воздействия удаления X на приложение зависит от конкретных результатов: (i) отказ от этой идеи, (ii) продолжение в соответствии с планом или (iii) определение минимально разрушительного способа удаления X и продолжения.

3. Разработать официальный EIP для отмены X. Убедитесь, что популярные инфраструктуры более высокого уровня (например, языки программирования, Кошелек) уважают это и прекращают использование этой функции.

4. В конце концов, фактически удалите X;

Между шагами 1 и 4 должен быть долговременный процесс, четко определяющий, какие проекты находятся на каком шаге. На данный момент необходимо найти баланс между энергией и скоростью процесса удаления функций и более консервативным подходом, который требует больше ресурсов для развития Протокола в других областях, но мы все еще далеки от пограничной точки Парето.

Конец файла

Одним из основных изменений, предложенных для EVM, является формат объекта EVM (EOF). EOF вносит много изменений, таких как запрет на наблюдаемость Газа, наблюдаемость кода (т.е. отсутствие CODECOPY) и только статический переход. Цель заключается в том, чтобы разрешить EVM выполнять больше обновлений с более сильными свойствами, сохраняя при этом обратную совместимость (поскольку EVM до EOF все еще существует).

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

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

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

· Переключение на конечность одного слота дает нам возможность отменить комитет, пересмотреть экономику и упростить другие аспекты, связанные с аттестацией.

· Полная реализация абстрагирования счета может позволить нам удалить значительное количество существующей логики обработки транзакций и переместить ее в “по умолчанию счет EVM кода”, который может быть заменен всеми EOA.

· Если мы перенесем состояние Ethereum в двоичное дерево хешей, это может быть согласовано с новой версией SSZ, чтобы все структуры данных Ethereum могли обрабатываться хешем одинаковым образом.

Более радикальный метод: преобразовать большую часть содержания Протокола в код контракта

Более радикальная стратегия упрощения ETH заключается в том, чтобы оставить Протокол неизменным, но перенести большую часть его функций из Протокола в код контракта.

Самая экстремальная версия заключается в том, чтобы сделать L1 ETH фактически только блокчейн-маяком и ввести минимальную Виртуальную машину (например, RISC-V, Каиро или даже более минимальную, которая специально предназначена для системы подтверждения), чтобы позволить другим создавать свои сборки. Затем EVM станет первым в этих сборках. Ирония заключается в том, что это полностью совпадает с результатом предложения о выполнении среды за 2019-20 годы, хотя благодаря SNARK это становится более выполнимым на практике.

Более мягким способом является сохранение связи между блокчейн-маяком и текущей средой выполнения ETH, но с непосредственной заменой EVM. Мы можем выбрать RISC-V, Cairo или другую ВМ в качестве новой «официальной ВМ ETH», а затем принудительно преобразовать все EVM контракты в новый код ВМ, который интерпретирует исходную логику кода (через компиляцию или интерпретацию). В теории, это даже может быть завершено путем создания новой «целевой Виртуальной машины» в качестве версии EOF.

ссылка на оригинал текста