В дизайне протокола Ethereum множество "деталей" имеют решающее значение для его успеха. Около половины содержания связано с различными типами улучшений EVM, а остальная часть состоит из различных нишевых тем, что и означает "процветание".
Процветание: ключевая цель
Превратить EVM в высокопроизводительное и стабильное "конечное состояние"
Внедрение абстракции аккаунтов в протокол, чтобы все пользователи могли наслаждаться более безопасными и удобными учетными записями
Оптимизация торговых издержек, повышение масштабируемости при одновременном снижении рисков
Исследование современных криптографий для долгосрительного значительного улучшения Ethereum
В настоящее время 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 делает эти два производительных расширения естественной парой.
На практике это будет обрабатываться параллельно.
)# Остальная работа и компромиссы
В настоящее время планируется включение EOF в следующем хард-форке. Хотя всегда существует вероятность его удаления в последний момент — в предыдущих хард-форках некоторые функции временно удалялись, но это будет представлять собой большие сложности. Удаление EOF означает, что любое будущее обновление EVM должно будет проводиться без EOF, хотя это и возможно, но может быть более сложным.
Основное соотношение между EVM заключается в сложности L1 и сложности инфраструктуры, EOF требует добавления большого количества кода в реализацию EVM, статический анализ кода также относительно сложен. Однако, в обмен на это, мы можем упростить высокоуровневые языки, упростить реализацию EVM и получить другие преимущества. Можно сказать, что приоритетное внимание в дорожной карте постоянного улучшения Ethereum L1 должно включать и основываться на EOF.
Необходимой важной задачей является реализация функций, аналогичных EVM-MAX с SIMD, а также проведение бенчмарков по расходу газа для различных криптографических операций.
Как взаимодействовать с другими частями дорожной карты?
L1 настраивает свой EVM, чтобы L2 также мог легче производить соответствующие настройки. Если обе стороны не будут синхронизированы, это может привести к несовместимости и негативным последствиям. Кроме того, EVM-MAX и SIMD могут снизить газовые затраты многих систем доказательств, что делает L2 более эффективным. Это также упрощает замену большего количества предкомпилированных функций кодом EVM, выполняющим те же задачи, что может не сильно повлиять на эффективность.
![Виталик о возможном будущем Эфира (шестая часть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) Абстракция аккаунта
Какую проблему это решает?
В настоящее время транзакции могут быть проверены только одним способом: подписью 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 заключается в разделении обработки пользовательских операций на два этапа: верификация и выполнение. Все проверки обрабатываются в первую очередь, а все выполнения обрабатываются позже. В пуле памяти операции пользователя принимаются только в том случае, если этап верификации касается только его собственного счета и не считывает переменные окружения. Это помогает предотвратить атаки с множественными сбоями. Кроме того, к шагу верификации также применяется строгий лимит газа.
![Виталик о возможном будущем Эфира (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 был разработан как дополнительный стандарт Протокол )ERC(, потому что в то время разработчики клиентов Ethereum сосредоточились на слиянии )Merge( и не имели дополнительных ресурсов для работы с другими функциями. Вот почему ERC-4337 использует объект, называемый пользовательским действием, а не обычные транзакции. Однако недавно мы осознали необходимость записать по крайней мере часть этого в Протокол.
Две ключевые причины следующие:
EntryPoint как врожденная неэффективность контракта: каждый пакет имеет фиксированные затраты около 100 000 газ, а также дополнительные тысячи газ для каждой операции пользователя.
Обеспечение необходимости атрибутов Ethereum: например, включение списков, созданных для гарантирования, требует перевода на абстрактный пользовательский аккаунт.
Кроме того, ERC-4337 также расширяет две функции:
Платежный агент ) Paymasters (: функция, позволяющая одной учетной записи оплачивать сборы от имени другой учетной записи, нарушает правило, согласно которому на этапе проверки можно получить доступ только к самой учетной записи отправителя, поэтому были введены специальные меры для обеспечения безопасности механизма платежного агента.
Агрегаторы): поддержка функции агрегирования подписей, такой как BLS-агрегирование или агрегирование на основе SNARK. Это необходимо для достижения максимальной эффективности данных на Rollup.
(# Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию учетных записей в протокол. Недавно популярный EIP по абстракции учетных записей, EIP-7701, реализует абстракцию учетных записей на основе EOF. Учетная запись может иметь отдельную часть кода для проверки; если учетная запись настроила эту часть кода, то данный код будет выполняться на этапе проверки транзакций от этой учетной записи.
Очарование этого подхода заключается в том, что он ясно показывает два эквивалентных аспекта абстракции локальных счетов:
Включить EIP-4337 в качестве части Протокола
Новый тип EOA, где алгоритм подписи является выполнением кода EVM
Если мы начнем с жестких границ сложности исполняемого кода во время проверки — не допускается доступ к внешнему состоянию, даже первоначально установленный лимит газа настолько низок, что становится неэффективным для квантовой устойчивости или приложений по защите конфиденциальности — тогда безопасность этого подхода становится совершенно ясной: просто замените проверку ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени, нам необходимо ослабить эти границы, поскольку разрешение на работу приложений с защитой конфиденциальности без реле и квантовая устойчивость являются крайне важными. Для этого нам нужно найти более гибкие способы решения рисков отказа в обслуживании )DoS###, не требуя, чтобы шаги проверки были исключительно упрощенными.
Основные компромиссы, похоже, заключаются в "быстром внедрении решения, которое удовлетворит меньшее число людей" и "ожидании более длительного времени, чтобы, возможно, получить более идеальное решение"; идеальный подход может быть неким смешанным методом. Один из смешанных методов заключается в более быстром внедрении некоторых случаев использования и выделении большего времени для исследования других случаев использования. Другой подход заключается в том, чтобы сначала развернуть более амбициозную версию абстракции аккаунтов на L2. Однако с этим связаны трудности: командам L2 необходимо быть уверенными в работе предложений по принятию, чтобы они были готовы к реализации, особенно чтобы убедиться, что L1 и/или другие L2 в будущем смогут принять совместимое решение.
Еще одно применение, которое нам нужно четко рассмотреть, — это учетные записи для хранения ключей, которые хранят связанные с учетной записью состояния на L1 или специализированном L2, но могут использоваться на L1 и любом совместимом L2. Эффективное выполнение этого может потребовать от L2 поддержки операций, таких как L1SLOAD или REMOTESTATICCALL, но это также требует, чтобы реализация абстракции учетной записи на L2 поддерживала эти операции.
(# Как это взаимодействует с другими частями дорожной карты?
Список включения должен поддерживать абстрактные транзакции аккаунтов. На практике потребность в списке включения на самом деле очень похожа на потребность в децентрализованном пуле памяти, хотя для списка включения гибкость чуть выше. Кроме того, реализация абстракции аккаунтов должна стремиться к координации между L1 и L2. Если в будущем мы ожидаем, что большинство пользователей будут использовать хранение ключей Rollup, дизайн абстракции аккаунтов должен
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
7
Репост
Поделиться
комментарий
0/400
UnluckyMiner
· 08-06 21:50
еще и бык EVM
Посмотреть ОригиналОтветить0
AirdropLicker
· 08-06 03:35
Прощайте, насос Gas пришёл
Посмотреть ОригиналОтветить0
ChainWanderingPoet
· 08-05 23:23
Расходы снова нужно оптимизировать, даже с BTC не справиться.
Посмотреть ОригиналОтветить0
LeverageAddict
· 08-03 22:13
шиткоин уже работает на EVM, а Эфир все еще тормозит.
Посмотреть ОригиналОтветить0
FrogInTheWell
· 08-03 22:10
Все действительно хотят немного оптимизировать EVM.
Посмотреть ОригиналОтветить0
Ser_This_Is_A_Casino
· 08-03 22:09
Резко оптимизировать, давно пора было заняться этим.
Перспективы протокола Ethereum: обновление EVM, абстрагирование счета и оптимизация комиссии за транзакцию
Возможное будущее протокола 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 делает эти два производительных расширения естественной парой.
На практике это будет обрабатываться параллельно.
)# Остальная работа и компромиссы
В настоящее время планируется включение EOF в следующем хард-форке. Хотя всегда существует вероятность его удаления в последний момент — в предыдущих хард-форках некоторые функции временно удалялись, но это будет представлять собой большие сложности. Удаление EOF означает, что любое будущее обновление EVM должно будет проводиться без EOF, хотя это и возможно, но может быть более сложным.
Основное соотношение между EVM заключается в сложности L1 и сложности инфраструктуры, EOF требует добавления большого количества кода в реализацию EVM, статический анализ кода также относительно сложен. Однако, в обмен на это, мы можем упростить высокоуровневые языки, упростить реализацию EVM и получить другие преимущества. Можно сказать, что приоритетное внимание в дорожной карте постоянного улучшения Ethereum L1 должно включать и основываться на EOF.
Необходимой важной задачей является реализация функций, аналогичных EVM-MAX с SIMD, а также проведение бенчмарков по расходу газа для различных криптографических операций.
Как взаимодействовать с другими частями дорожной карты?
L1 настраивает свой EVM, чтобы L2 также мог легче производить соответствующие настройки. Если обе стороны не будут синхронизированы, это может привести к несовместимости и негативным последствиям. Кроме того, EVM-MAX и SIMD могут снизить газовые затраты многих систем доказательств, что делает L2 более эффективным. Это также упрощает замену большего количества предкомпилированных функций кодом EVM, выполняющим те же задачи, что может не сильно повлиять на эффективность.
![Виталик о возможном будущем Эфира (шестая часть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) Абстракция аккаунта
Какую проблему это решает?
В настоящее время транзакции могут быть проверены только одним способом: подписью 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 заключается в разделении обработки пользовательских операций на два этапа: верификация и выполнение. Все проверки обрабатываются в первую очередь, а все выполнения обрабатываются позже. В пуле памяти операции пользователя принимаются только в том случае, если этап верификации касается только его собственного счета и не считывает переменные окружения. Это помогает предотвратить атаки с множественными сбоями. Кроме того, к шагу верификации также применяется строгий лимит газа.
![Виталик о возможном будущем Эфира (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 был разработан как дополнительный стандарт Протокол )ERC(, потому что в то время разработчики клиентов Ethereum сосредоточились на слиянии )Merge( и не имели дополнительных ресурсов для работы с другими функциями. Вот почему ERC-4337 использует объект, называемый пользовательским действием, а не обычные транзакции. Однако недавно мы осознали необходимость записать по крайней мере часть этого в Протокол.
Две ключевые причины следующие:
Кроме того, ERC-4337 также расширяет две функции:
(# Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию учетных записей в протокол. Недавно популярный EIP по абстракции учетных записей, EIP-7701, реализует абстракцию учетных записей на основе EOF. Учетная запись может иметь отдельную часть кода для проверки; если учетная запись настроила эту часть кода, то данный код будет выполняться на этапе проверки транзакций от этой учетной записи.
Очарование этого подхода заключается в том, что он ясно показывает два эквивалентных аспекта абстракции локальных счетов:
Если мы начнем с жестких границ сложности исполняемого кода во время проверки — не допускается доступ к внешнему состоянию, даже первоначально установленный лимит газа настолько низок, что становится неэффективным для квантовой устойчивости или приложений по защите конфиденциальности — тогда безопасность этого подхода становится совершенно ясной: просто замените проверку ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени, нам необходимо ослабить эти границы, поскольку разрешение на работу приложений с защитой конфиденциальности без реле и квантовая устойчивость являются крайне важными. Для этого нам нужно найти более гибкие способы решения рисков отказа в обслуживании )DoS###, не требуя, чтобы шаги проверки были исключительно упрощенными.
Основные компромиссы, похоже, заключаются в "быстром внедрении решения, которое удовлетворит меньшее число людей" и "ожидании более длительного времени, чтобы, возможно, получить более идеальное решение"; идеальный подход может быть неким смешанным методом. Один из смешанных методов заключается в более быстром внедрении некоторых случаев использования и выделении большего времени для исследования других случаев использования. Другой подход заключается в том, чтобы сначала развернуть более амбициозную версию абстракции аккаунтов на L2. Однако с этим связаны трудности: командам L2 необходимо быть уверенными в работе предложений по принятию, чтобы они были готовы к реализации, особенно чтобы убедиться, что L1 и/или другие L2 в будущем смогут принять совместимое решение.
Еще одно применение, которое нам нужно четко рассмотреть, — это учетные записи для хранения ключей, которые хранят связанные с учетной записью состояния на L1 или специализированном L2, но могут использоваться на L1 и любом совместимом L2. Эффективное выполнение этого может потребовать от L2 поддержки операций, таких как L1SLOAD или REMOTESTATICCALL, но это также требует, чтобы реализация абстракции учетной записи на L2 поддерживала эти операции.
(# Как это взаимодействует с другими частями дорожной карты?
Список включения должен поддерживать абстрактные транзакции аккаунтов. На практике потребность в списке включения на самом деле очень похожа на потребность в децентрализованном пуле памяти, хотя для списка включения гибкость чуть выше. Кроме того, реализация абстракции аккаунтов должна стремиться к координации между L1 и L2. Если в будущем мы ожидаем, что большинство пользователей будут использовать хранение ключей Rollup, дизайн абстракции аккаунтов должен