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

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

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

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

Улучшение EVM

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

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

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

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

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

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

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

Одной из более новых идей является сочетание EVM-MAX с характеристиками SIMD (один оператор, несколько данных) (, SIMD как концепция Ethereum существует уже давно, впервые предложенная Greg Colvin в 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), включая циклические и нециклические(, по крайней мере для степеней двойки. Также добавить ISZERO), что будет выводить в основной стек EVM(, что будет достаточно мощным для реализации эллиптической кривой криптографии, маломасштабной криптографии), такой как Poseidon, Circle STARKs(, традиционные хэш-функции), такие как SHA256, KECCAK, BLAKE( и криптография на основе решеток. Другие обновления EVM также могут быть реализованы, но до сих пор им уделялось меньше внимания.

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

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

В настоящее время планируется включение 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 для оплаты газа.

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

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

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

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

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

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

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

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

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

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

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

(# Оставшаяся работа и компромиссы

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

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

1. Включить EIP-4337 в качестве части протокола
2. Новый тип EOA, в котором алгоритм подписи выполняется через EVM-код.

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

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

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

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