Будущее возможных направлений развития протокола Ethereum: Эпизод процветания

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

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

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

Улучшение 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 существует уже долгое время, впервые предложенная Грегом Колвином в EIP-616. SIMD может быть использован для ускорения многих форм криптографии, включая хэш-функции, 32-битные STARK и криптографию на основе решеток, а сочетание EVM-MAX и SIMD делает эти два ориентированных на производительность расширения естественной парой.

! [Виталик о возможном будущем Ethereum (6): Трата])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(

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

• 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, который может выполнять те же задачи, что, вероятно, не сильно повлияет на эффективность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

) EIP-1559 улучшение

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

EIP-1559 был активирован на Ethereum в 2021 году, что значительно улучшило среднее время включения блока.

Однако на текущий момент реализация EIP-1559 не идеальна в нескольких аспектах:

1. Формула имеет небольшие недостатки: она не нацелена на 50% блоков, а ориентирована на примерно 50-53% полных блоков, что зависит от дисперсии ###, это связано с тем, что математики называют "неравенством арифметико-геометрического среднего".