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

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

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

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

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

Улучшение EVM

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

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

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

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

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

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

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

![Виталик о возможном будущем Ethereum (Шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

Одной из более новых идей является сочетание EVM-MAX с многоинструкционными данными )SIMD(, SIMD как концепция Ethereum существует уже давно, впервые предложенная Greg Colvin в EIP-616. SIMD можно использовать для ускорения многих форм криптографии, включая хэш-функции, 32-битные STARKs и криптографию на основе решеток, комбинация 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 планируется включить в следующий хард-форк. Хотя всегда существует возможность удалить его в последнюю минуту — в предыдущих хард-форках функции временно удалялись, но это будет представлять собой большую сложность. Удаление 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-ec1638a809393a6ed42724fb08f534da.webp(

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

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

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

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

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

С момента предложения абстракции учетной записи в 2015 году ее цель расширилась, включая множество "удобных целей", например, учетная запись, которая не имеет ETH, но обладает некоторыми ERC20, может использовать ERC20 для оплаты газа.

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

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

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

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

![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(

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

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

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

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

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

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

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

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

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

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

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

(# Остальная работа и компромисс

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

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

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

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

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