Возможное будущее протокола 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 (один инструкция - множество данных) ), причем SIMD как концепция Ethereum существует уже долгое время, впервые предложенная Greg Colvin в 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 также могут быть реализованы, но до сих пор их внимание было ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунта в Протокол. Недавно популярным стал 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 для этих операций.

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

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

![Виталик о возможном будущем Ethereum（