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

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

! [Виталик о возможном будущем Ethereum (6): Трата])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.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-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 (: функция, позволяющая одной учетной записи оплачивать сборы от имени другой учетной записи, что нарушает правила, согласно которым на этапе проверки можно иметь доступ только к самой учетной записи отправителя, поэтому были введены специальные меры для обеспечения безопасности механизма платежного агента.
• Аггрегаторы): поддерживают функции агрегации подписей, такие как агрегация 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 или REMOTESTATICCALL, но это также требует, чтобы реализация абстракции аккаунтов на L2 поддерживала эти операции.

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

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