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

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

! Виталик о возможном будущем Ethereum (6): Трата

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

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

MPC(Многосторонние вычисления) — это технология с 40-летней историей, используемая для разделения ключей на несколько частей и их хранения на нескольких устройствах, используя криптографические технологии для генерации подписи, не комбинируя напрямую эти части ключей.

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

Эта работа началась с EIP-3074 и в конечном итоге привела к EIP-7702. EIP-7702 предоставляет "удобные функции" абстракции учетных записей всем пользователям, включая сегодняшние EOA( внешние собственные аккаунты, то есть аккаунты), контролируемые подписью ECDSA.

Из графика видно, что хотя некоторые вызовы (, особенно вызов "удобства" ) могут быть решены с помощью прогрессивных технологий, таких как многопартийные вычисления или EIP-7702, основные цели безопасности, первоначально предложенные в提案 об абстракции счетов, могут быть достигнуты только путем обратного анализа и решения исходной проблемы: позволить коду смарт-контракта контролировать верификацию транзакций. Причина, по которой это еще не реализовано, заключается в сложности безопасной реализации, что является вызовом.

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

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

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

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

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

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

хозяин