Новая статья Виталика: Возможное будущее Ethereum (V) — The Purge

Оригинальное название: Возможное будущее протокола Ethereum, часть 5: Чистка

Оригинальная статья Виталика Бутерина

Оригинальный перевод: Odaily Planet Daily Husband How

Начиная с 14 октября основатель Ethereum Виталик Бутерин последовательно публиковал обсуждения возможного будущего Ethereum. Слияние , Всплеск , Бич , Грань к последней версии Чистка , все они подчеркивают видение Виталиком будущего развития основной сети Ethereum и пути решения текущих проблем. Решения.

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

The Surge: изучает различные стратегии масштабирования Ethereum, особенно дорожную карту, ориентированную на Rollup, а также ее проблемы и решения с точки зрения масштабируемости, децентрализации и безопасности.

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

The Verge: исследует проблемы и решения верификации без сохранения состояния в Ethereum, уделяя особое внимание тому, как такие технологии, как деревья Веркла и STARK, могут повысить децентрализацию и эффективность блокчейна.

26 октября Виталик Бутерин опубликовал статью о The Purge, в которой обсуждалась проблема, с которой сталкивается Ethereum, — как снизить сложность и требования к хранению в долгосрочной перспективе, сохраняя при этом долговечность и децентрализацию цепочки. Ключевые меры включают снижение нагрузки на хранилище клиента за счет истечения срока истории и состояния, а также упрощение протокола за счет очистки функций для обеспечения устойчивости и масштабируемости сети.

Ниже представлен оригинальный контент, переведенный Odaily Planet Daily.

Особая благодарность Джастину Дрейку, Тиму Бейко, Мэтту Гарнетту, Пайпер Мерриам, Мариусу ван дер Вейдену и Томашу Станчаку за их отзывы и рецензии.

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

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

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

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

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

Чистка: Основная цель.

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

• Уменьшите сложность протокола, исключив ненужные функции.

Каталог статей:

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

• Истечение срока действия государственного документа

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

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

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

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

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

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

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

Сегодня Ethereum начал отходить от модели, в которой все узлы хранят всю историю постоянно. Консенсусные блоки (т. е. часть, связанная с консенсусом proof-of-stake) хранятся только около 6 месяцев. Blob-ы хранятся только около 18 дней. ЭИП-4444 направлен на введение годичного периода хранения исторических блоков и квитанций. Долгосрочная цель — установить единый период (вероятно, около 18 дней), в течение которого каждый узел отвечает за хранение всего, а затем создать одноранговую сеть узлов Ethereum, которые хранят старые данные в распределенной сетевой манере.

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

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

• ЭИП-4444 ;

• Торренты и EIP-4444 ;

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

• Сеть порталов и EIP-4444 ;

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

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

Что еще необходимо сделать и на какие компромиссы следует пойти?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Решение проблемы частичного истечения срока действия статуса

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

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

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

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

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

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

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

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

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

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

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

Расширение адресного пространства

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

0x 01 (красный) 0000 (оранжевый) 000001 (зеленый) 57 аЕ 408398 дФ 7 Э 5 ф 4552091 А 69125 д5 ФВф 7 Б 8 С 2659029395 bdF (синий).

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

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

Уменьшение адресного пространства

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

0x фффффффф 000169125 д5 ФВф 7 Б 8 C2659029395bdF

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

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

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

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

• Очистка блокчейна ;

• регенерация ;

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

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

Предложение о частичном истечении срока действия статуса

• ЭИП-7736 ;

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

• Первоначальное предложение ;

• Обзор Ипсилона ;

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

• Что сломается, если мы потеряем устойчивость к столкновению .

Что еще необходимо сделать и на какие компромиссы следует пойти?

Я вижу четыре возможных пути развития событий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Реформа LOG: Фильтры Блума для создания журнала и другая логика добавляют сложности протоколу, но фактически не используются клиентами, поскольку они слишком медленные. Мы можем удалить эти функции и работа над альтернативами, такими как децентрализованные инструменты чтения журналов вне протокола с использованием современных технологий, таких как SNARKs.

• В конечном итоге удалите механизм Комитета по синхронизации цепочки маяков: Механизм Синхронного Комитета Первоначально был введен для обеспечения легкой верификации клиента для Ethereum. Однако он значительно увеличивает сложность протокола. В конце концов, мы сможем проверить уровень консенсуса Ethereum напрямую с помощью SNARKs , что устранит необходимость в специальном протоколе проверки легкого клиента. Потенциально изменение консенсуса может позволить нам удалить Комитет синхронизации раньше, создав более нативный протокол легкого клиента, который включает проверку подписей из случайного подмножества валидаторов консенсуса Ethereum.

• Унификация формата данных: Сегодня состояние выполнения хранится в деревьях Merkle Patricia, состояние консенсуса хранится в Деревья ССЗ , и капли фиксируются через Обязательства КЗГ . В будущем имело бы смысл иметь единый унифицированный формат для блочных данных и единый унифицированный формат для состояния. Эти форматы удовлетворяли бы всем важным требованиям: (i) простые доказательства для клиентов без состояния, (ii) сериализация и кодирование стирания данных, и (iii) стандартизированные структуры данных.

• Упразднение комитета Beacon Chain: этот механизм изначально был введен для поддержки конкретная версия сегментирования выполнения . Вместо этого мы закончили шардингом через L2 и BLOB-объекты . Таким образом, комитет не нужен, поэтому предпринимаются шаги по его устранению .

• Удалить смешанный порядок байтов: EVM — big endian, консенсусный слой — little endian. Может иметь смысл согласовать и сделать все так или иначе (вероятно big endian, так как EVM сложнее изменить)

Теперь несколько примеров в EVM:

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

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

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

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

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

• Дальнейшие шаги по удалению ;

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

• EIPS на основе SSZ: [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 можно было хешировать одинаковым образом.

Более радикальный подход: преобразование больших частей протокола в код контракта

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

Самым экстремальным вариантом было бы иметь Ethereum L1 «технически» только как цепочку маяков и ввести минимальную виртуальную машину (например, RISC-V , Каир , или что-то еще более минимальное специально для систем доказательств), что позволяет другим создавать свои собственные накопитель. EVM тогда станет первым из этих накопителей. По иронии судьбы, это точно такой же результат, как предложение по среде исполнения на 2019-20 гг. , хотя SNARKs делают его более осуществимым на практике.

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

Эта статья взята из интернета: Новая статья Виталика: Возможное будущее Ethereum (V) — The Purge