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

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

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

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

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

Улучшение EVM

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

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

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

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

• Разделение между кодом (выполняемым, но недоступным для чтения из EVM) и данными (доступными для чтения, но не выполняемыми)
• Запретить динамические переходы, разрешить только статические переходы
• EVM код больше не может наблюдать информацию, связанную с топливом
• Добавлен новый механизм явных подпрограмм

Старые контракты будут продолжать существовать и их можно будет создавать, хотя в конечном итоге могут постепенно отказаться от старых контрактов (возможно, даже принудительно преобразовать в код EOF). Новые контракты получат выгоду от повышения эффективности, обеспечиваемого EOF.

После введения EOF дальнейшие обновления стали проще, в настоящее время наиболее развитым является арифметическое расширение модуля EVM (EVM-MAX). EVM-MAX создает набор новых операций, специально предназначенных для модульных вычислений, и помещает их в новую область памяти, недоступную через другие коды операций, что позволяет использовать такие оптимизации, как умножение Монтгомери.

Одной из более новых идей является сочетание EVM-MAX с характеристиками однокомандной многоданных (SIMD), SIMD как идея Ethereum существует уже давно, впервые предложенная Greg Colvin в EIP-616. SIMD может быть использован для ускорения многих форм криптографии, включая хэш-функции, 32-битные STARK и криптографию на основе решеток, а сочетание EVM-MAX и SIMD делает эти два производительных расширения естественной парой.

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

• 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 для оплаты газа.

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

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

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

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

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

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

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

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

Основные компромиссы, похоже, заключаются в «быстром написании решения, которое удовлетворяет меньшинству» и «долгожданном решении, которое, возможно, будет более идеальным»; идеальный подход может быть каким-то смешанным методом. Один из смешанных методов заключается в более быстром написании некоторых вариантов использования и выделении больше времени для изучения других вариантов. Другой метод — это сначала развертывание более амбициозной версии абстракции аккаунтов на L2.

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

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

EIP-1559 улучшение

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

EIP-1559 был активирован на Ethereum в 2021 году, что значительно улучшило среднее время включения блока.

Однако текущее внедрение EIP-1559 не идеально по нескольким аспектам:

1. Формула имеет некоторые недостатки: она не нацелена на 50% блоков, а ориентирована на около 50-53% полных блоков, в зависимости от дисперсии.
2. В крайних случаях корректировка происходит недостаточно быстро.

Формула для blobs (EIP-4844), представленная позже, была специально разработана для решения первой проблемы и в целом более лаконична. Тем не менее, сам EIP-1559 и EIP-4844 не пытались решить вторую проблему.

Кроме того, существуют и другие слабые места в ценообразовании ресурсов Ethereum, не связанные с EIP-1559, которые можно решить путем корректировки EIP-1559. Одной из основных проблем является различие между средним и худшим случаями: цены на ресурсы в Ethereum должны быть установлены таким образом, чтобы справляться с худшими случаями, то есть полное потребление газа одного блока занимает один ресурс, в то время как фактическое среднее использование значительно ниже, что приводит к неэффективности.

Что такое многомерный Gas и как он работает?

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

В настоящее время у нас уже есть многомерный Gas для выполнения и блоков данных; в принципе, мы можем расширить его до большего количества измерений: таких как calldata (данные транзакции), чтение / запись состояния и расширение размера состояния.

EIP-7706 вводит новое измерение газа, специально предназначенное для calldata. В то же время он упрощает многомерный механизм газа, объединив три типа газа в единую (в стиле EIP-4844) структуру, что также решает математический недостаток EIP-1559. EIP-7623 является более точным решением, которое более строго ограничивает максимальный calldata, не вводя при этом целое новое измерение, и направлено на проблемы ресурсов в среднем и худшем случаях.

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

• Часто задаваемые вопросы по EIP-1559: Часто задаваемые вопросы по EIP-1559
• Эмпирический анализ EIP-1559: Empirical analysis
• Позволяет быстро вносить изменения в предложения по улучшению: Proposed improvements
• EIP-4844 FAQ по механизму базовой платы: EIP-4844 FAQ
• EIP-7706: EIP