Некоторые вещи трудно классифицировать. В проектировании протокола Ethereum многие "детали" имеют решающее значение для успеха Ethereum. Около половины содержания касается различных типов улучшений EVM, в то время как остальная часть состоит из различных нишевых тем, и в этом заключается смысл "процветания".
Превратить EVM в высокопроизводительное и стабильное "финальное состояние"
Внедрение абстракции аккаунта в Протокол, чтобы все пользователи могли наслаждаться более безопасным и удобным аккаунтом
Оптимизация торговых издержек, повышение масштабируемости при одновременном снижении рисков
Исследуйте современные криптографические технологии, чтобы значительно улучшить Ethereum в долгосрочной перспективе
Улучшение 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-битные STARK и криптографию на основе решеток. Сочетание EVM-MAX и SIMD делает эти два производительных расширения естественной парой.
! [Виталик о возможном будущем Ethereum (6): Трата])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Общий дизайн комбинации 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), включая циклические и нециклические(, по крайней мере для модулей степени 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-летнюю историю, используемая для разделения ключа на несколько частей и хранения их на нескольких устройствах, с использованием криптографических технологий для генерации подписи, без необходимости прямого объединения этих частей ключа.
![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
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 газа, а также дополнительные тысячи газа для каждой операции пользователя.
Обеспечение необходимости свойств Ethereum: например, список, созданный для обеспечения необходимости перевода на учетную запись абстрактного пользователя.
Кроме того, ERC-4337 также расширил две функции:
Платежный агент ) Paymasters (: функция, позволяющая одной учетной записи оплачивать сборы от имени другой учетной записи, что нарушает правило, согласно которому на этапе проверки можно получить доступ только к самой учетной записи отправителя, поэтому было введено специальное обращение для обеспечения безопасности механизма платежного агента.
Аггрегаторы): поддерживают функции агрегации подписи, такие как агрегация BLS или агрегация на основе SNARK. Это необходимо для достижения максимальной эффективности данных на Rollup.
(# Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунтов в Протокол. Недавно популярным предложением по записи протокола абстракции аккаунтов является EIP-7701, которое реализует абстракцию аккаунтов на основе EOF. Один аккаунт может иметь отдельную часть кода для верификации; если аккаунт настроил эту часть кода, то она будет выполняться на этапе верификации транзакций, поступающих от этого аккаунта.
Очарование этого метода заключается в том, что он явно показывает два эквивалентных взгляда на абстракцию локального аккаунта:
Включить EIP-4337 в качестве части протокола
Новый тип EOA, в котором алгоритм подписи выполняется с помощью кода EVM
Если мы начнем с строгого ограничения сложности исполняемого кода во время проверки — не допускается доступ к внешнему состоянию, и даже первоначально установленный лимит газа будет настолько низким, что станет неэффективным для приложений с квантовой устойчивостью или защитой конфиденциальности — тогда безопасность этого подхода становится весьма очевидной: просто замените проверку ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени нам нужно ослабить эти границы, поскольку разрешение работы приложений, защищающих конфиденциальность, без ретрансляции, а также квантовая устойчивость являются очень важными. Для этого нам необходимо найти более гибкие способы решения риска отказа в обслуживании )DoS###, не требуя, чтобы шаги верификации были крайне упрощены.
Основное соотношение, похоже, заключается в "быстром написании решения, которое удовлетворяет меньшее количество людей" и "ожидании более долгого времени
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
21 Лайков
Награда
21
5
Репост
Поделиться
комментарий
0/400
LonelyAnchorman
· 18ч назад
Когда же этот EVM наконец станет более удобным...
Посмотреть ОригиналОтветить0
GateUser-2fce706c
· 08-16 09:03
Пользуясь возможностями улучшения EVM, расставьте крупные фигуры... давно предвидел это направление развития.
Посмотреть ОригиналОтветить0
PoetryOnChain
· 08-16 08:50
Похоже, что это скоро закончится. Ван Шен наконец-то понял.
Перспективы протокола Ethereum: Улучшения EVM и абстрагирование счета ведут к процветанию
Будущее протокола Ethereum (шесть): Процветание
Некоторые вещи трудно классифицировать. В проектировании протокола Ethereum многие "детали" имеют решающее значение для успеха Ethereum. Около половины содержания касается различных типов улучшений EVM, в то время как остальная часть состоит из различных нишевых тем, и в этом заключается смысл "процветания".
! Виталик о возможном будущем Ethereum (6): Трата
Процветание: ключевая цель
Улучшение EVM
Какую проблему это решает?
В настоящее время EVM трудно поддается статическому анализу, что затрудняет создание эффективных реализаций, формальную проверку кода и дальнейшее расширение. Кроме того, эффективность EVM низка, что усложняет реализацию многих высокоуровневых криптографических функций, если только они не поддерживаются явно через предкомпилированные функции.
Что это такое и как это работает?
Первый шаг текущей дорожной карты улучшений EVM — это формат объекта EVM (EOF), который планируется включить в следующий хардфорк. EOF представляет собой ряд EIP, которые определяют новую версию кода EVM с множеством уникальных характеристик, наиболее заметной из которых является:
Старые контракты продолжат существовать и могут быть созданы, хотя в конечном итоге старые контракты ( могут быть постепенно выведены из эксплуатации, а возможно, даже принудительно преобразованы в код EOF ). Новые контракты получат выгоду от повышения эффективности, которое приносит EOF — сначала за счет немного уменьшенного байт-кода благодаря характеристикам подпрограмм, а затем за счет новых функций или сниженной стоимости газа, специфичных для EOF.
После введения EOF дальнейшее обновление стало проще, в настоящее время наиболее развита модульная арифметическая расширение EVM ( EVM-MAX ). EVM-MAX создает набор новых операций, специально предназначенных для модульных вычислений, и помещает их в новое пространство памяти, которое недоступно через другие коды операций, что делает возможным использование оптимизаций, таких как умножение Монгомери.
Новая идея заключается в сочетании EVM-MAX с SIMD (одиночная команда – множественные данные) (, при этом SIMD как концепция для Ethereum существует уже долгое время, впервые предложенная Greg Colvin в EIP-616. SIMD может использоваться для ускорения многих форм криптографии, включая хеш-функции, 32-битные STARK и криптографию на основе решеток. Сочетание EVM-MAX и SIMD делает эти два производительных расширения естественной парой.
! [Виталик о возможном будущем Ethereum (6): Трата])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Общий дизайн комбинации 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-летнюю историю, используемая для разделения ключа на несколько частей и хранения их на нескольких устройствах, с использованием криптографических технологий для генерации подписи, без необходимости прямого объединения этих частей ключа.
![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
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 также расширил две функции:
(# Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунтов в Протокол. Недавно популярным предложением по записи протокола абстракции аккаунтов является EIP-7701, которое реализует абстракцию аккаунтов на основе EOF. Один аккаунт может иметь отдельную часть кода для верификации; если аккаунт настроил эту часть кода, то она будет выполняться на этапе верификации транзакций, поступающих от этого аккаунта.
Очарование этого метода заключается в том, что он явно показывает два эквивалентных взгляда на абстракцию локального аккаунта:
Если мы начнем с строгого ограничения сложности исполняемого кода во время проверки — не допускается доступ к внешнему состоянию, и даже первоначально установленный лимит газа будет настолько низким, что станет неэффективным для приложений с квантовой устойчивостью или защитой конфиденциальности — тогда безопасность этого подхода становится весьма очевидной: просто замените проверку ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени нам нужно ослабить эти границы, поскольку разрешение работы приложений, защищающих конфиденциальность, без ретрансляции, а также квантовая устойчивость являются очень важными. Для этого нам необходимо найти более гибкие способы решения риска отказа в обслуживании )DoS###, не требуя, чтобы шаги верификации были крайне упрощены.
Основное соотношение, похоже, заключается в "быстром написании решения, которое удовлетворяет меньшее количество людей" и "ожидании более долгого времени