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

Автор: Виталик Бутерин

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

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

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

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

Улучшение 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 делает эти два производительных расширения естественной парой.

Общее проектирование комбинации 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 (включая циклические и нециклические), как минимум для степеней двойки. Также добавление ISZERO (который будет выводить на основной стек EVM), что будет достаточно мощным для реализации эллиптической кривой криптографии, маломасштабной криптографии (таких как Poseidon, Circle STARKs), традиционных хэш-функций (таких как SHA256, KECCAK, BLAKE) и криптографии на основе решеток. Другие обновления EVM также могут быть реализованы, но до сих пор им уделялось меньше внимания.

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

• EOF:
• EVM-MAX:
• SIMD:

Остальная работа и взвешивание

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

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

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

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

Суть абстракции аккаунта проста: разрешить смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в том, чтобы реализовать это таким образом, чтобы поддерживать децентрализованную сеть и предотвращать атаки отказа в обслуживании.

Одной из типичных ключевых проблем является проблема множественных сбоев:

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

После многолетних усилий, направленных на расширение функциональности и ограничение рисков отказа в обслуживании (DoS), в конечном итоге был найден вариант реализации "идеальной абстракции аккаунта": ERC-4337.

Работа ERC-4337 заключается в разделении обработки пользовательских операций на два этапа: верификация и выполнение. Сначала обрабатывается вся верификация, а затем выполняются все операции. В пуле памяти пользовательские операции принимаются только в том случае, если этап верификации касается только их собственного аккаунта и не считывает переменные окружения. Это помогает предотвратить атаки с множественным сбоем. Кроме того, на этап верификации также накладываются строгие ограничения по gas.

ERC-4337 был разработан как дополнительный стандарт протокола (ERC), поскольку разработчики клиентов Ethereum в то время сосредоточились на слиянии (Merge) и не имели дополнительной энергии для обработки других функций. Именно поэтому ERC-4337 использует объекты, называемые пользовательскими операциями, вместо обычных транзакций. Тем не менее, недавно мы осознали необходимость записать по крайней мере часть этого в протокол.

Две ключевые причины следующие:

1. EntryPoint как врожденная неэффективность контракта: каждый пакет имеет фиксированные затраты около 100,000 gas, а также дополнительные тысячи gas за каждую операцию пользователя.
2. Обеспечение необходимости свойств Ethereum: например, включение списка, созданного для гарантии, необходимо перевести на аккаунт абстрактного пользователя.

Кроме того, ERC-4337 расширил две функции:

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

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

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