Некоторые вещи трудно отнести к одной категории. В дизайне протокола Ethereum много "деталей", которые очень важны для успеха Ethereum. На самом деле, около половины содержания касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем, и в этом заключается смысл "процветания".
Процветание: ключевая цель
Превратить EVM в высокопроизводительное и стабильное "конечное состояние"
Введение абстракции аккаунтов в Протокол, позволяющее всем пользователям наслаждаться более безопасным и удобным аккаунтом
Оптимизация торговых издержек, повышение масштабируемости при одновременном снижении рисков
Исследование передовой криптографии, чтобы Эфир значительно улучшился в долгосрочной перспективе
Улучшение EVM
Что было решено?
В настоящее время EVM трудно поддается статическому анализу, что затрудняет создание эффективных реализаций, формальную верификацию кода и дальнейшее расширение. Кроме того, эффективность EVM низка, и трудно реализовать многие формы продвинутой криптографии, если это не поддерживается явно через предкомпиляцию.
Что это такое и как это работает?
Текущий первый шаг в дорожной карте улучшения EVM — это формат объекта EVM (EOF), который планируется включить в следующий хард-форк. EOF — это ряд EIP, который определяет новую версию кода EVM с множеством уникальных характеристик, наиболее заметными из которых являются:
Код ( может быть выполнен, но нельзя прочитать отделение между ) из 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) любую степень 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, который может выполнять те же задачи, что, возможно, не окажет значительного влияния на эффективность.
Абстракция аккаунта
Что было решено?
В настоящее время транзакции могут быть проверены только одним способом: подписью 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 использует объекты, называемые пользовательскими операциями, а не обычные транзакции. Однако недавно мы осознали необходимость записать по крайней мере часть из этого в протокол.
Две ключевые причины следующие:
EntryPoint как неотъемлемая неэффективность контракта: каждый пакет имеет фиксированные затраты около 100 000 gas, а также дополнительные тысячи gas для каждой операции пользователя.
Обеспечение необходимости атрибутов Ethereum: например, включенные в список гарантии, которые необходимо перевести на абстрактный счет пользователя.
Кроме того, ERC-4337 также расширяет две функции:
Платежный агент ( Paymasters ): функция, позволяющая одной учетной записи платить сборы от имени другой учетной записи, что нарушает правило, согласно которому на этапе проверки можно получать доступ только к самой учетной записи отправителя, поэтому было введено специальное обращение для обеспечения безопасности механизма платежного агента.
Агрегаторы(: поддерживают функции агрегации подписей, такие как агрегация BLS или агрегация на основе SNARK. Это необходимо для достижения максимальной эффективности данных на Rollup.
![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Оставшаяся работа и компромиссы
В настоящее время основной задачей является полное внедрение абстракции аккаунтов в протокол. Недавно популярное предложение по записи протокола абстракции аккаунтов EIP — это EIP-7701, которое реализует абстракцию аккаунтов на основе EOF. Один аккаунт может иметь отдельную часть кода для верификации; если аккаунт настроен на использование этой части кода, то этот код будет выполняться на этапе верификации транзакций, исходящих от этого аккаунта.
Очарование этого метода заключается в том, что он ясно показывает два эквивалентных аспекта абстракции локальных учетных записей:
Включить EIP-4337 как часть Протокола
Новый тип EOA, в котором алгоритм подписи выполняется с помощью кода EVM
Если мы начнем с жесткого ограничения сложности исполняемого кода верификации ------ не позволяя доступ к внешнему состоянию, даже первоначально установленный лимит газов будет слишком низким для квантово-устойчивых или защищающих конфиденциальность приложений ------ тогда безопасность этого подхода становится весьма очевидной: просто заменяем верификацию ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако со временем нам нужно ослабить эти ограничения, так как разрешение на использование приложений для защиты конфиденциальности без посредников...
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Будущее протокола Ethereum: новые возможности, открывающиеся благодаря обновлению EVM и абстрагированию счета
Будущее Эфирного Протокола ( шесть ): Процветание
Автор: Виталик Бутерин
Некоторые вещи трудно отнести к одной категории. В дизайне протокола Ethereum много "деталей", которые очень важны для успеха Ethereum. На самом деле, около половины содержания касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем, и в этом заключается смысл "процветания".
Процветание: ключевая цель
Улучшение EVM
Что было решено?
В настоящее время EVM трудно поддается статическому анализу, что затрудняет создание эффективных реализаций, формальную верификацию кода и дальнейшее расширение. Кроме того, эффективность EVM низка, и трудно реализовать многие формы продвинутой криптографии, если это не поддерживается явно через предкомпиляцию.
Что это такое и как это работает?
Текущий первый шаг в дорожной карте улучшения EVM — это формат объекта EVM (EOF), который планируется включить в следующий хард-форк. EOF — это ряд EIP, который определяет новую версию кода 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 в range(count): mem[z_start + z_skip * количество] = op( mem[x_start + x_skip * количество], mem[y_start + y_skip * количество] )
На практике это будет обрабатываться параллельно.
Оставшаяся работа и компромиссы
В настоящее время планируется включить 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 использует объекты, называемые пользовательскими операциями, а не обычные транзакции. Однако недавно мы осознали необходимость записать по крайней мере часть из этого в протокол.
Две ключевые причины следующие:
Кроме того, ERC-4337 также расширяет две функции:
![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Оставшаяся работа и компромиссы
В настоящее время основной задачей является полное внедрение абстракции аккаунтов в протокол. Недавно популярное предложение по записи протокола абстракции аккаунтов EIP — это EIP-7701, которое реализует абстракцию аккаунтов на основе EOF. Один аккаунт может иметь отдельную часть кода для верификации; если аккаунт настроен на использование этой части кода, то этот код будет выполняться на этапе верификации транзакций, исходящих от этого аккаунта.
Очарование этого метода заключается в том, что он ясно показывает два эквивалентных аспекта абстракции локальных учетных записей:
Если мы начнем с жесткого ограничения сложности исполняемого кода верификации ------ не позволяя доступ к внешнему состоянию, даже первоначально установленный лимит газов будет слишком низким для квантово-устойчивых или защищающих конфиденциальность приложений ------ тогда безопасность этого подхода становится весьма очевидной: просто заменяем верификацию ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако со временем нам нужно ослабить эти ограничения, так как разрешение на использование приложений для защиты конфиденциальности без посредников...