Будущее протокола Ethereum ( шесть ): процветание

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

! Виталик о возможном будущем Ethereum (6): Трата

Процветание: ключевая цель

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

Улучшение EVM

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

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

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

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

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

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

![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

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

Новая идея заключается в сочетании EVM-MAX с SIMD), который является характеристикой однокомандной многоданных архитектуры. SIMD как концепция Ethereum существует уже долгое время и был впервые предложен Грегом Колвином в EIP-616. SIMD может использоваться для ускорения многих форм криптографии, включая хэш-функции, 32-битные STARKs и криптографию на основе решеток. Сочетание EVM-MAX и SIMD делает естественной пару этих двух ориентированных на производительность расширений.

Общее проектирование комбинации EIP будет начинаться с EIP-6690, а затем:

• Разрешить (i) любое нечетное число или (ii) любую степень 2, не превышающую 2768, в качестве модуля
• Для каждой операции EVM-MAX кодов ( сложения, вычитания, умножения ) добавьте версию, которая больше не использует 3 немедленных значения x, y, z, а использует 7 немедленных значений: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. В коде Python эти коды операций действуют аналогично:

питон Для i в range(count): mem[z_start + z_skip * количество] = op( mem[x_start + x_skip * количество], mem[y_start + y_skip * количество] )

На практике это будет обрабатываться параллельно.

• Возможно добавить XOR, AND, OR, NOT и SHIFT(, включая циклические и нециклические), по крайней мере для степени 2. Также добавить ISZERO( будет выводить в основной стек EVM), что будет достаточно мощным для реализации криптографии на эллиптических кривых, малом полевом шифровании(, таком как Poseidon, Circle STARKs), традиционных хеш-функций(, таких как SHA256, KECCAK, BLAKE) и криптографии на основе решеток. Другие обновления EVM также могут быть реализованы, но пока на них обращают меньше внимания.

(# Существующие исследовательские ссылки

• EOF:
• ЭВМ-МАКС:
• SIMD:

)# Остальная работа и компромиссы

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

Основная компромиссная ситуация EVM заключается в сложности L1 и сложности инфраструктуры, EOF требует добавления большого объема кода в реализацию EVM, а статический анализ кода также относительно сложен. Однако, в обмен на это, мы можем упростить высокоуровневые языки, упростить реализацию EVM и получить другие преимущества. Можно сказать, что приоритетное внимание в дорожной карте постоянного улучшения Ethereum L1 должно быть уделено EOF.

Необходимой важной работой является реализация функций, подобных EVM-MAX с SIMD, а также бенчмаркинг потребления газа для различных криптографических операций.

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

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

![Виталик о возможном будущем Ethereum (шестая часть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###

( Абстракция аккаунта

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

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

• Переключиться на квантово-устойчивую криптографию
• Замена старых ключей ### широко считается рекомендованной практикой безопасности ###
• Мультиподписной кошелек и социальный восстановительный кошелек
• Используйте один ключ для операций с низкой стоимостью, используйте другой ключ ( или набор ключей ) для операций с высокой стоимостью

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

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

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

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

Эта работа началась с EIP-3074 и в конечном итоге привела к формированию EIP-7702. EIP-7702 предоставляет "удобные функции" абстракции аккаунтов всем пользователям, включая текущие EOA( внешние управляемые аккаунты, то есть аккаунты, контролируемые подписью ECDSA ).

Хотя некоторые проблемы (, особенно проблема "удобства" ), могут быть решены с помощью прогрессивных технологий, таких как многопартийные вычисления или EIP-7702, основная цель безопасности, изначально предложенная в предложении об абстракции счетов, может быть достигнута только путем обратного анализа и решения исходной проблемы: разрешить код смарт-контракта контролировать проверку транзакций. Причина, по которой это еще не реализовано, заключается в безопасной реализации, что является вызовом.

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

Суть абстракции аккаунтов проста: разрешить смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в том, чтобы реализовать это способом, который поддерживает децентрализованную сеть и защищает от атак отказа в обслуживании.

Типичной ключевой проблемой является проблема множественных сбоев:

Если 1000 функций проверки аккаунтов зависят от одного значения S, и текущее значение S делает все транзакции в памяти действительными, то одна одиночная транзакция, изменяющая значение S, может сделать все остальные транзакции в памяти недействительными. Это позволяет атакующему с очень низкими затратами отправлять мусорные транзакции в память, тем самым блокируя ресурсы узлов сети.

После многих лет усилий, направленных на расширение функциональности при одновременном ограничении рисков отказа в обслуживании ) DoS ###, в конечном итоге было найдено решение для реализации "идеального абстракции учетной записи": ERC-4337.

Работа ERC-4337 заключается в разделении обработки действий пользователя на два этапа: проверка и выполнение. Все проверки сначала обрабатываются, затем выполняются все действия. В пуле памяти действия пользователя принимаются только тогда, когда этап проверки касается только его собственного счета и не считывает переменные среды. Это предотвращает атаки с множественными сбоями. Кроме того, к этапу проверки также строго применяются ограничения по газу.

ERC-4337 был разработан как дополнительный стандарт протокола (ERC), потому что в то время разработчики клиентов Ethereum сосредоточились на объединении (Merge) и не имели дополнительных ресурсов для обработки других функций. Вот почему ERC-4337 использует объект, называемый пользовательскими операциями, а не обычные транзакции. Однако недавно мы осознали необходимость включить как минимум часть этого в протокол.

Два ключевых причины следующие:

1. EntryPoint как врожденная неэффективность контракта: каждый пакет имеет фиксированные затраты около 100,000 gas, а также дополнительные тысячи gas на каждую операцию пользователя.
2. Обеспечение необходимости атрибутов Ethereum: например, список созданных включений гарантирует, что необходимо перевести на аккаунт абстрактного пользователя.

Кроме того, ERC-4337 также расширил две функции:

• Платежный агент ( Paymasters ): функция, позволяющая одной учетной записи оплачивать сборы от имени другой учетной записи, что нарушает правило, согласно которому на этапе проверки можно получить доступ только к учетной записи отправителя. Поэтому была введена специальная обработка для обеспечения безопасности механизма платежного агента.
• Агрегаторы(: поддерживают функции агрегирования подписей, такие как BLS-агрегирование или агрегирование на основе SNARK. Это необходимо для достижения максимальной эффективности данных на Rollup.

![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(

)# Существующие исследовательские ссылки

• Доклад об истории абстракции аккаунтов:
• ERC-4337:
• ЭИП-7702:
• Код BLSWallet ( использует агрегирующую функцию ):
• EIP-7562### запись абстракции аккаунта Протокола (:
• EIP-7701) основанный на EOF протокол абстракции учетной записи (:

)# Остальная работа и компромиссы

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

Этот метод