Возможности будущего протокола Ethereum: процветание
В дизайне протокола Ethereum много "деталей", которые имеют решающее значение для его успеха. Около половины содержания касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем, именно в этом и заключается "процветание".
Процветание: ключевая цель
Превратить EVM в высокопроизводительное и стабильное "конечное состояние"
Внедрение абстракции аккаунта в Протокол, позволяющее всем пользователям наслаждаться более безопасным и удобным аккаунтом
Оптимизация экономии торговых сборов, повышение масштабируемости при одновременном снижении рисков
Исследуйте современные криптографические технологии, чтобы Эфир значительно улучшился в долгосрочной перспективе.
Улучшение 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-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(
)# Существующие исследовательские ссылки
EOF:
ЭВМ-МАКС:
SIMD:
Оставшаяся работа и взвешивание
В настоящее время планируется включение 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-e607936b4195e92945aa6ebd5f969276.webp(
) Абстракция аккаунтов
Какую проблему это решает?
В настоящее время транзакции могут быть проверены только одним способом: подписью ECDSA. Изначально абстракция аккаунтов призвана выйти за рамки этого, позволяя логике проверки учетных записей быть произвольным кодом EVM. Это может открыть ряд приложений:
Переключиться на квантово-устойчивую криптографию
Замена старого ключа ### широко считается рекомендуемой безопасной практикой (
Мультиподписной кошелек и социальный восстановительный кошелек
Используйте один ключ для операций с низкой стоимостью, используйте другой ключ ) или набор ключей ( для операций с высокой стоимостью
Позволяет протоколу конфиденциальности работать без ретрансляторов, значительно снижая его сложность и устраняя одну из ключевых центральных зависимостей.
С тех пор как концепция абстракции аккаунтов была предложена в 2015 году, её цели также расширились, включая множество "удобных целей", например, аккаунт, который не имеет ETH, но имеет некоторые ERC20, может использовать ERC20 для оплаты газа.
MPC) многосторонние вычисления( — это технология с 40-летней историей, используемая для разделения ключа на несколько частей и хранения их на нескольких устройствах, с использованием криптографических технологий для генерации подписи, не требуя непосредственного объединения этих частей ключа.
EIP-7702 — это предложение, запланированное для внедрения в следующем хардфорке. EIP-7702 является результатом растущего осознания необходимости предоставления удобства абстракции аккаунтов для всех пользователей ), включая пользователей EOA (, с целью улучшения опыта всех пользователей в краткосрочной перспективе и избежания раскола на две экосистемы.
Эта работа началась с EIP-3074 и в конечном итоге привела к EIP-7702. EIP-7702 предоставляет "удобные функции" абстракции аккаунта всем пользователям, включая сегодняшние EOA) внешние управляемые аккаунты, то есть аккаунты, контролируемые подписью ECDSA(.
Хотя некоторые проблемы ), особенно проблема "удобства" (, могут быть решены с помощью прогрессивных технологий, таких как многопартитные вычисления или EIP-7702, основная цель безопасности, изначально предложенная в предложении по абстракции аккаунтов, может быть достигнута только путем обратной работы и решения исходной проблемы: позволить коду смарт-контрактов контролировать проверку транзакций. Причина, по которой это до сих пор не реализовано, заключается в сложностях безопасной реализации, что является вызовом.
![Виталик о возможном будущем Эфириума (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Что это такое и как это работает?
Суть абстракции аккаунта проста: разрешить смарт-контрактам инициировать транзакции, а не только 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.
(# Существующие ссылки на исследования
Доклад об истории абстракции аккаунтов:
ERC-4337:
ЭИП-7702:
Код BLSWallet ) использует функцию агрегации ###:
EIP-7562( запись абстракции аккаунта протокола ):
EIP-7701( Протокол записи на основе EOF учётной записи абстракции ):
(# Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунтов в протокол. Недавно популярный EIP для записи протокольной абстракции аккаунтов — это EIP-7701, который реализует абстракцию аккаунтов на основе EOF. Один аккаунт может иметь отдельную часть кода для верификации, и если аккаунт настроил эту часть кода, то она будет выполняться на этапе верификации транзакций, исходящих от данного аккаунта.
Очарование этого метода заключается в том, что он ясно показывает два эквивалентных аспекта абстракции локального аккаунта:
Включить EIP-4337 как часть Протокола
Новый тип EOA, в котором алгоритм подписи выполняется через EVM код
Если мы начнем с установления строгих границ для сложности исполняемого кода в период проверки --- не допускается доступ к внешнему состоянию, и даже первоначально установленный лимит газа настолько низок, что становится неэффективным для квантовой устойчивости или приложений для защиты конфиденциальности --- тогда безопасность этого подхода становится совершенно ясной: просто заменяем верификацию ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени нам необходимо ослабить эти границы, потому что разрешение на работу приложений с защитой конфиденциальности без реле, а также квантовая устойчивость являются очень важными. Для этого нам нужно найти более гибкие способы решения риска отказа в обслуживании )DoS###, не требуя, чтобы этапы проверки были крайне упрощенными.
Основное соотношение, похоже, заключается в "быстрой записи решения, которое удовлетворяет меньшее количество людей" и "ожидании более длительного времени для получения более идеального решения"; идеальным подходом может быть некий смешанный метод. Один из смешанных методов заключается в том, чтобы быстрее записать некоторые случаи использования и выделить больше времени для исследования других случаев использования. Другой подход заключается в том, чтобы сначала развернуть более амбициозную версию абстракции аккаунта на L2. Однако с этим связана проблема: командам L2 нужно быть уверенными в том, что работа по принятию предложений будет успешной, чтобы они были готовы к реализации, особенно необходимо убедиться, что L1 и/или другие L2 в будущем смогут принять совместимые решения.
Еще одно приложение, которое нам также необходимо четко рассмотреть, — это счета для хранения ключей, которые хранят связанные с аккаунтом состояния на L1 или специализированном L2, но могут работать на L1 и任.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Дорожная карта процветания Ethereum: обновление EVM, абстрагирование счета и оптимизация EIP-1559
Возможности будущего протокола Ethereum: процветание
В дизайне протокола Ethereum много "деталей", которые имеют решающее значение для его успеха. Около половины содержания касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем, именно в этом и заключается "процветание".
Процветание: ключевая цель
Улучшение 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-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(
)# Существующие исследовательские ссылки
Оставшаяся работа и взвешивание
В настоящее время планируется включение 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-e607936b4195e92945aa6ebd5f969276.webp(
) Абстракция аккаунтов
Какую проблему это решает?
В настоящее время транзакции могут быть проверены только одним способом: подписью ECDSA. Изначально абстракция аккаунтов призвана выйти за рамки этого, позволяя логике проверки учетных записей быть произвольным кодом EVM. Это может открыть ряд приложений:
Позволяет протоколу конфиденциальности работать без ретрансляторов, значительно снижая его сложность и устраняя одну из ключевых центральных зависимостей.
С тех пор как концепция абстракции аккаунтов была предложена в 2015 году, её цели также расширились, включая множество "удобных целей", например, аккаунт, который не имеет ETH, но имеет некоторые ERC20, может использовать ERC20 для оплаты газа.
MPC) многосторонние вычисления( — это технология с 40-летней историей, используемая для разделения ключа на несколько частей и хранения их на нескольких устройствах, с использованием криптографических технологий для генерации подписи, не требуя непосредственного объединения этих частей ключа.
EIP-7702 — это предложение, запланированное для внедрения в следующем хардфорке. EIP-7702 является результатом растущего осознания необходимости предоставления удобства абстракции аккаунтов для всех пользователей ), включая пользователей EOA (, с целью улучшения опыта всех пользователей в краткосрочной перспективе и избежания раскола на две экосистемы.
Эта работа началась с EIP-3074 и в конечном итоге привела к EIP-7702. EIP-7702 предоставляет "удобные функции" абстракции аккаунта всем пользователям, включая сегодняшние EOA) внешние управляемые аккаунты, то есть аккаунты, контролируемые подписью ECDSA(.
Хотя некоторые проблемы ), особенно проблема "удобства" (, могут быть решены с помощью прогрессивных технологий, таких как многопартитные вычисления или EIP-7702, основная цель безопасности, изначально предложенная в предложении по абстракции аккаунтов, может быть достигнута только путем обратной работы и решения исходной проблемы: позволить коду смарт-контрактов контролировать проверку транзакций. Причина, по которой это до сих пор не реализовано, заключается в сложностях безопасной реализации, что является вызовом.
![Виталик о возможном будущем Эфириума (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Что это такое и как это работает?
Суть абстракции аккаунта проста: разрешить смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в реализации этого способа, который был бы дружелюбен к поддержанию децентрализованной сети и защищал бы от атак типа "отказ в обслуживании".
Типичной ключевой проблемой является проблема множественных отказов:
Если функция проверки 1000 аккаунтов зависит от одного единственного значения S, и текущее значение S делает все транзакции в мемпуле действительными, то одна единственная транзакция, изменяющая значение S, может сделать все остальные транзакции в мемпуле недействительными. Это позволяет злоумышленникам отправлять мусорные транзакции в мемпул с очень низкими затратами, тем самым блокируя ресурсы узлов сети.
После многолетних усилий, направленных на расширение функциональности при ограничении рисков отказа в обслуживании ###DoS(, в конечном итоге была разработана реализация "идеального абстрактного аккаунта": ERC-4337.
Работа ERC-4337 заключается в разделении обработки операций пользователя на два этапа: проверка и выполнение. Все проверки сначала обрабатываются, а все выполнения обрабатываются позже. В пуле памяти операции пользователя принимаются только в том случае, если этап проверки касается только его собственного счета и не считывает переменные окружения. Это может предотвратить атаки множественной неудачи. Кроме того, для этапа проверки также строго применяются ограничения по газу.
ERC-4337 был разработан как дополнительный стандарт протокола ) ERC (, потому что в то время разработчики клиентов Ethereum сосредоточились на слиянии ) Merge ( и не имели дополнительных ресурсов для обработки других функций. Вот почему ERC-4337 использует объекты, называемые пользовательскими операциями, вместо обычных транзакций. Однако недавно мы осознали необходимость записать хотя бы часть этого в протокол.
Две ключевые причины следующие:
Кроме того, ERC-4337 расширяет две функции:
(# Существующие ссылки на исследования
(# Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунтов в протокол. Недавно популярный EIP для записи протокольной абстракции аккаунтов — это EIP-7701, который реализует абстракцию аккаунтов на основе EOF. Один аккаунт может иметь отдельную часть кода для верификации, и если аккаунт настроил эту часть кода, то она будет выполняться на этапе верификации транзакций, исходящих от данного аккаунта.
Очарование этого метода заключается в том, что он ясно показывает два эквивалентных аспекта абстракции локального аккаунта:
Если мы начнем с установления строгих границ для сложности исполняемого кода в период проверки --- не допускается доступ к внешнему состоянию, и даже первоначально установленный лимит газа настолько низок, что становится неэффективным для квантовой устойчивости или приложений для защиты конфиденциальности --- тогда безопасность этого подхода становится совершенно ясной: просто заменяем верификацию ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени нам необходимо ослабить эти границы, потому что разрешение на работу приложений с защитой конфиденциальности без реле, а также квантовая устойчивость являются очень важными. Для этого нам нужно найти более гибкие способы решения риска отказа в обслуживании )DoS###, не требуя, чтобы этапы проверки были крайне упрощенными.
Основное соотношение, похоже, заключается в "быстрой записи решения, которое удовлетворяет меньшее количество людей" и "ожидании более длительного времени для получения более идеального решения"; идеальным подходом может быть некий смешанный метод. Один из смешанных методов заключается в том, чтобы быстрее записать некоторые случаи использования и выделить больше времени для исследования других случаев использования. Другой подход заключается в том, чтобы сначала развернуть более амбициозную версию абстракции аккаунта на L2. Однако с этим связана проблема: командам L2 нужно быть уверенными в том, что работа по принятию предложений будет успешной, чтобы они были готовы к реализации, особенно необходимо убедиться, что L1 и/или другие L2 в будущем смогут принять совместимые решения.
Еще одно приложение, которое нам также необходимо четко рассмотреть, — это счета для хранения ключей, которые хранят связанные с аккаунтом состояния на L1 или специализированном L2, но могут работать на L1 и任.