Будущее возможного развития протокола Ethereum: Эпизод процветания
В дизайне протокола Ethereum есть множество важных "деталей", которые имеют решающее значение для его успеха. Около половины содержимого касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем, в этом и заключается смысл "процветания".
Процветание: ключевая цель
Превратить EVM в высокопроизводительное и стабильное "конечное состояние"
Внедрение абстракции аккаунтов в протокол, позволяющее всем пользователям наслаждаться более безопасными и удобными аккаунтами
Оптимизация экономии на торговых издержках, повышение масштабируемости при одновременном снижении рисков
Исследование современных криптографических технологий, чтобы Эфир значительно улучшился в долгосрочной перспективе.
Улучшение EVM
Решило какую проблему?
В настоящее время EVM сложно подвергать статическому анализу, что затрудняет создание эффективных реализаций, официальную верификацию кода и его дальнейшее расширение. Кроме того, эффективность EVM низка, и сложно реализовать многие формы высокоуровневой криптографии, если это не поддерживается явно через предварительную компиляцию.
Что это такое и как это работает?
Текущий первый шаг дорожной карты улучшения EVM заключается в формате объекта EVM (EOF), который планируется включить в следующий хард-форк. EOF представляет собой серию EIP, которые определяют новую версию кода EVM с множеством уникальных характеристик, наиболее заметной из которых является:
Код ( может выполняться, но не может быть прочитан из EVM. ) и данные ( могут быть прочитаны, но не могут быть выполнены между разделением ).
Запрещены динамические переходы, разрешены только статические переходы
Код EVM больше не может наблюдать за информацией, связанной с топливом.
Добавлен новый механизм явных подсистем
Структура кода EOF включает в себя сегмент кода, сегмент данных и сегмент информации о типах.
После введения EOF дальнейшие обновления стали значительно проще. В настоящее время наиболее развита арифметическая расширяемость модуля EVM ( EVM-MAX ). EVM-MAX создает набор новых операций, специально предназначенных для модульной арифметики, и размещает их в новой области памяти, доступ к которой невозможно осуществить с помощью других кодов операций, что позволяет использовать такие оптимизации, как умножение Монтгомери.
Новая идея заключается в сочетании EVM-MAX с особенностями SIMD (одноинструкционная многоданные) (. SIMD может использоваться для ускорения многих форм криптографии, включая хэш-функции, 32-битные STARK и криптографию на основе решеток. Сочетание EVM-MAX и SIMD делает эти два производительных расширения естественной парой.
) Существующие исследовательские ссылки
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-8930b556d169a2bc7168ddc2e611d3df.webp(
Абстракция счета
) Решило какую проблему?
На данный момент транзакции могут быть проверены только одним способом: подписью ECDSA. Изначально абстракция аккаунта была задумана для преодоления этого ограничения, позволяя логике проверки аккаунта быть произвольным EVM-кодом. Это может активировать ряд приложений:
Переключиться на квантовую криптографию
Замена старых ключей ### широко считается рекомендуемой безопасной практикой (
Мультиподписные кошельки и социальные восстановительные кошельки
Используйте один ключ для операций с низкой стоимостью, используйте другой ключ ) или набор ключей ( для операций с высокой стоимостью
Позволяет протоколу конфиденциальности работать без реле, значительно снижая его сложность и устраняя ключевую центральную зависимость.
С тех пор как в 2015 году была предложена абстракция учетной записи, ее цель расширилась, чтобы включить множество "удобных целей", например, учетная запись, которая не имеет ETH, но располагает некоторыми ERC20, может использовать ERC20 для оплаты газа.
![Виталик о возможном будущем Эфира (Шесть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Что это такое и как это работает?
Суть абстракции аккаунта проста: разрешить смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в том, чтобы реализовать это в способе, благоприятном для поддержки децентрализованной сети, и предотвратить атаки отказа в обслуживании.
Типичной ключевой проблемой является проблема множественных сбоев: если функции проверки 1000 аккаунтов зависят от одного единственного значения S, и текущее значение S делает все транзакции в пуле памяти действительными, то одна единственная транзакция, изменяющая значение S, может сделать недействительными все другие транзакции в пуле памяти. Это позволяет злоумышленникам с очень низкими затратами отправлять мусорные транзакции в пул памяти, тем самым блокируя ресурсы узлов сети.
После многих лет усилий, направленных на расширение функциональности при одновременном ограничении рисков отказа в обслуживании ### DoS (, в конечном итоге было найдено решение для реализации "идеального абстрактного счета": ERC-4337.
Работа ERC-4337 заключается в разделении обработки операций пользователя на два этапа: верификация и выполнение. Все верификации сначала обрабатываются, а все выполнения обрабатываются позже. В пуле памяти операции пользователя принимаются только тогда, когда этап верификации касается только его собственного аккаунта и не читает переменные окружения. Это может предотвратить атаки с множественными сбоями. Кроме того, строгие ограничения на газ также применяются к этапу верификации.
![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Существующие исследовательские ссылки
Доклад об истории абстракции аккаунта:
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 и любом совместимом L2. Эффективная реализация этого может потребовать, чтобы L2 поддерживал такие операции, как L1SLOAD или REMOTESTATICCALL, но это также требует, чтобы реализация абстракции учетных записей на L2 поддерживала эти операции.
) Как это взаимодействует с другими частями дорожной карты?
Список включения должен поддерживать транзакции с абстракцией учетных записей. На практике потребность в списке включения на самом деле очень похожа на потребность в децентрализованном пуле памяти, хотя для списка включения гибкость немного больше. Кроме того, реализация абстракции учетной записи должна по возможности координироваться между L1 и L2. Если в будущем мы ожидаем, что большинство пользователей будут использовать Rollup с хранением ключей, дизайн абстракции учетной записи должен основываться на этом.
![Виталик о возможном будущем Эфира (шесть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Улучшение EIP-1559
) Какую проблему это решает?
EIP-1559 был активирован в 2021 году на Ethereum, что значительно улучшило среднее время включения блока. Тем не менее, текущее внедрение EIP-1559 не идеально в нескольких аспектах:
Формула имеет некоторые недостатки: она не нацелена на 50% блоков, а на полные блоки примерно на 50-53%, в зависимости от вариации ###, что связано с тем, что математики называют "неравенством арифметико-геометрического среднего" (.
В крайних случаях регулировка недостаточно быстрая.
Формула ) для blobs EIP-4844 была специально разработана для решения первой проблемы и в целом более лаконична. Однако EIP-1559 сам по себе и EIP-4844 не пытались решить вторую проблему. Таким образом, текущее состояние является хаотичным промежуточным состоянием, вовлекающим две разные механики, и существует мнение, что со временем обе нуждаются в доработке.
Кроме того, существуют и другие слабые места в ценообразовании ресурсов Ethereum, не связанные с EIP-1559, которые можно решить путем корректировки EIP-1559. Одной из основных проблем является разница между средним и худшим случаями: цена ресурсов в Ethereum должна быть установлена так, чтобы справляться с худшим случаем, то есть все газовые затраты одного блока занимают один ресурс, но фактическое среднее использование значительно ниже, что приводит к неэффективности.
( Что такое многомерный Gas и как он работает?
Решение этих неэффективных проблем — это многомерный Gas: установление различных цен и ограничений для различных ресурсов. Эта концепция технически независима от EIP-1559, но EIP-1
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
7
Поделиться
комментарий
0/400
MissedAirdropBro
· 07-26 03:16
Почему снова абстрагирование счета!
Посмотреть ОригиналОтветить0
BrokenDAO
· 07-25 06:25
Еще одна амбициозная дорожная карта, в конечном итоге, скорее всего, повторит судьбу Casper.
Посмотреть ОригиналОтветить0
GasGuru
· 07-24 20:52
Звучит довольно надежно, да.
Посмотреть ОригиналОтветить0
SigmaBrain
· 07-24 20:51
Что за версия, что её нужно еще менять?
Посмотреть ОригиналОтветить0
OPsychology
· 07-24 20:45
Когда это обновление будет запущено?
Посмотреть ОригиналОтветить0
WalletWhisperer
· 07-24 20:31
поведенческие паттерны указывают на то, что evm2.0 вызовет массовые миграции кошельков... статистически неизбежно
Посмотреть ОригиналОтветить0
Whale_Whisperer
· 07-24 20:29
Обновление EVM давно должно было быть предложено, эти Газ fees действительно невыносимы.
Будущее Эфира: обновление EVM, абстрагирование счета и оптимизация затрат
Будущее возможного развития протокола Ethereum: Эпизод процветания
В дизайне протокола Ethereum есть множество важных "деталей", которые имеют решающее значение для его успеха. Около половины содержимого касается различных типов улучшений EVM, а остальная часть состоит из различных нишевых тем, в этом и заключается смысл "процветания".
Процветание: ключевая цель
Улучшение EVM
Решило какую проблему?
В настоящее время EVM сложно подвергать статическому анализу, что затрудняет создание эффективных реализаций, официальную верификацию кода и его дальнейшее расширение. Кроме того, эффективность EVM низка, и сложно реализовать многие формы высокоуровневой криптографии, если это не поддерживается явно через предварительную компиляцию.
Что это такое и как это работает?
Текущий первый шаг дорожной карты улучшения EVM заключается в формате объекта EVM (EOF), который планируется включить в следующий хард-форк. EOF представляет собой серию EIP, которые определяют новую версию кода EVM с множеством уникальных характеристик, наиболее заметной из которых является:
Структура кода EOF включает в себя сегмент кода, сегмент данных и сегмент информации о типах.
После введения EOF дальнейшие обновления стали значительно проще. В настоящее время наиболее развита арифметическая расширяемость модуля EVM ( EVM-MAX ). EVM-MAX создает набор новых операций, специально предназначенных для модульной арифметики, и размещает их в новой области памяти, доступ к которой невозможно осуществить с помощью других кодов операций, что позволяет использовать такие оптимизации, как умножение Монтгомери.
Новая идея заключается в сочетании EVM-MAX с особенностями SIMD (одноинструкционная многоданные) (. 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-код, который может выполнять те же задачи, что не должно существенно повлиять на эффективность.
![Виталика о возможном будущем Ethereum (шестая часть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Абстракция счета
) Решило какую проблему?
На данный момент транзакции могут быть проверены только одним способом: подписью ECDSA. Изначально абстракция аккаунта была задумана для преодоления этого ограничения, позволяя логике проверки аккаунта быть произвольным EVM-кодом. Это может активировать ряд приложений:
Позволяет протоколу конфиденциальности работать без реле, значительно снижая его сложность и устраняя ключевую центральную зависимость.
С тех пор как в 2015 году была предложена абстракция учетной записи, ее цель расширилась, чтобы включить множество "удобных целей", например, учетная запись, которая не имеет ETH, но располагает некоторыми ERC20, может использовать ERC20 для оплаты газа.
![Виталик о возможном будущем Эфира (Шесть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Что это такое и как это работает?
Суть абстракции аккаунта проста: разрешить смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в том, чтобы реализовать это в способе, благоприятном для поддержки децентрализованной сети, и предотвратить атаки отказа в обслуживании.
Типичной ключевой проблемой является проблема множественных сбоев: если функции проверки 1000 аккаунтов зависят от одного единственного значения S, и текущее значение S делает все транзакции в пуле памяти действительными, то одна единственная транзакция, изменяющая значение S, может сделать недействительными все другие транзакции в пуле памяти. Это позволяет злоумышленникам с очень низкими затратами отправлять мусорные транзакции в пул памяти, тем самым блокируя ресурсы узлов сети.
После многих лет усилий, направленных на расширение функциональности при одновременном ограничении рисков отказа в обслуживании ### DoS (, в конечном итоге было найдено решение для реализации "идеального абстрактного счета": ERC-4337.
Работа ERC-4337 заключается в разделении обработки операций пользователя на два этапа: верификация и выполнение. Все верификации сначала обрабатываются, а все выполнения обрабатываются позже. В пуле памяти операции пользователя принимаются только тогда, когда этап верификации касается только его собственного аккаунта и не читает переменные окружения. Это может предотвратить атаки с множественными сбоями. Кроме того, строгие ограничения на газ также применяются к этапу верификации.
![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Существующие исследовательские ссылки
) Остальная работа и компромиссы
В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунта в протокол. Недавно популярным стал EIP абстракции аккаунта, который записывает протокол EIP-7701; это предложение реализует абстракцию аккаунта на EOF. Один аккаунт может иметь отдельную часть кода для верификации; если аккаунт настроил эту часть кода, то она будет выполняться на этапе верификации транзакций, приходящих от этого аккаунта.
Очарование этого метода заключается в том, что он четко показывает два эквивалентных взгляда на абстракцию локальных учетных записей:
Если мы начнем с того, чтобы установить строгие границы для сложности исполняемого кода во время верификации, то безопасность этого подхода становится очень ясной: просто замените верификацию ECDSA на выполнение кода EVM, требующее аналогичного времени.
Однако, с течением времени, нам необходимо ослабить эти границы, поскольку разрешение приложениям для защиты конфиденциальности работать без ретрансляторов и наличие квантовой устойчивости являются очень важными. Для этого нам нужно найти более гибкие способы решения рисков отказа в обслуживании ###DoS(, не требуя, чтобы шаги проверки были крайне упрощены.
Основная дилемма, кажется, заключается в "быстром написании решения, которое удовлетворяет меньшее количество людей" и "ожидании более длительного времени для получения более идеального решения"; идеальным подходом может быть некий смешанный метод. Один из смешанных подходов заключается в более быстром написании некоторых случаев использования и выделении большего времени для изучения других случаев использования. Другой подход заключается в первоначальном развертывании более амбициозной версии абстракции аккаунтов на L2. Однако с этим связаны вызовы: команде L2 необходимо быть уверенной в том, что работа по принятию предложений будет успешной, чтобы она была готова к реализации, особенно чтобы гарантировать, что L1 и/или другие L2 смогут в будущем принять совместимые решения.
Еще одно приложение, которое нам также нужно четко рассмотреть, это учетные записи хранения ключей. Эти учетные записи хранят состояние, связанное с учетной записью, на L1 или специализированном L2, но могут использоваться на L1 и любом совместимом L2. Эффективная реализация этого может потребовать, чтобы L2 поддерживал такие операции, как L1SLOAD или REMOTESTATICCALL, но это также требует, чтобы реализация абстракции учетных записей на L2 поддерживала эти операции.
) Как это взаимодействует с другими частями дорожной карты?
Список включения должен поддерживать транзакции с абстракцией учетных записей. На практике потребность в списке включения на самом деле очень похожа на потребность в децентрализованном пуле памяти, хотя для списка включения гибкость немного больше. Кроме того, реализация абстракции учетной записи должна по возможности координироваться между L1 и L2. Если в будущем мы ожидаем, что большинство пользователей будут использовать Rollup с хранением ключей, дизайн абстракции учетной записи должен основываться на этом.
![Виталик о возможном будущем Эфира (шесть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Улучшение EIP-1559
) Какую проблему это решает?
EIP-1559 был активирован в 2021 году на Ethereum, что значительно улучшило среднее время включения блока. Тем не менее, текущее внедрение EIP-1559 не идеально в нескольких аспектах:
Формула ) для blobs EIP-4844 была специально разработана для решения первой проблемы и в целом более лаконична. Однако EIP-1559 сам по себе и EIP-4844 не пытались решить вторую проблему. Таким образом, текущее состояние является хаотичным промежуточным состоянием, вовлекающим две разные механики, и существует мнение, что со временем обе нуждаются в доработке.
Кроме того, существуют и другие слабые места в ценообразовании ресурсов Ethereum, не связанные с EIP-1559, которые можно решить путем корректировки EIP-1559. Одной из основных проблем является разница между средним и худшим случаями: цена ресурсов в Ethereum должна быть установлена так, чтобы справляться с худшим случаем, то есть все газовые затраты одного блока занимают один ресурс, но фактическое среднее использование значительно ниже, что приводит к неэффективности.
( Что такое многомерный Gas и как он работает?
Решение этих неэффективных проблем — это многомерный Gas: установление различных цен и ограничений для различных ресурсов. Эта концепция технически независима от EIP-1559, но EIP-1