Возможное будущее протокола Ethereum(шесть): The Splurge

В дизайне протокола 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-битные STARK и криптографию на основе решеток. Сочетание EVM-MAX и SIMD делает эти два производительных расширения естественной парой.

![Виталик о возможном будущем Ethereum (Шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.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-код, который может выполнять те же задачи, что может не оказать значительного влияния на эффективность.

![Виталик о возможном будущем 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-подписанием (.

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

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

Суть абстракции аккаунта проста: позволить смарт-контрактам инициировать транзакции, а не только 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.

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

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

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

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

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

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

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

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

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

Еще одно применение, которое нам также необходимо четко рассмотреть, это аккаунты для хранения ключей, это