Будущее протокола Ethereum (Шесть): Процветание

В дизайне протокола Ethereum много "деталей", которые имеют ключевое значение для его успеха. Около половины содержания касается различных типов улучшений EVM, а остальная часть состоит из множества нишевых тем, вот в чем заключается "процветание".

! Виталик о возможном будущем Ethereum (6): Трата

Процветание: ключевая цель

• Превратить 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 делает эти два производительных расширения естественной парой.

Основной дизайн комбинации EIP будет начинаться с EIP-6690, а затем:

• Разрешить (i) любое нечетное число или (ii) любое степень 2, не превышающую 2768, в качестве модуля
• Для каждой операции EVM-MAX с кодом ( сложение, вычитание, умножение ) добавьте версию, которая больше не использует 3 непосредственных числа x, y, z, а вместо этого использует 7 непосредственных чисел: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. В коде Python эти коды операций действуют аналогично:

Для i в range(count): mem[z_start + z_skip * количество] = op( mem[x_start + x_skip * количество], mem[y_start + y_skip * количество] )

На практике это будет обрабатываться параллельно.

• Возможно добавить XOR, AND, OR, NOT и SHIFT(, включая циклические и нециклические), по крайней мере для степеней двойки. Также добавить ISZERO(, что выведет данные на главный стек EVM), что будет достаточно мощным для реализации криптографии на эллиптических кривых, маломасштабной криптографии(, такой как Poseidon, Circle STARKs), традиционных хеш-функций(, таких как SHA256, KECCAK, BLAKE) и криптографии на основе решеток. Другие обновления EVM также могут быть реализованы, но до сих пор им уделялось меньше внимания.

(# Остальная работа и компромиссы

В настоящее время EOF планируется включить в следующий хард-форк. Хотя всегда существует вероятность его удаления в последний момент - в предыдущих хард-форках функции временно удалялись, но это будет представлять собой большие трудности. Удаление EOF означает, что любые будущие обновления EVM должны быть выполнены без EOF, хотя это возможно, но может быть более сложно.

Основное соотношение EVM заключается в сложности L1 и сложности инфраструктуры, EOF — это большое количество кода, который необходимо добавить в реализацию EVM, статическая проверка кода также относительно сложна. Однако в обмен мы можем упростить высокоуровневые языки, упростить реализацию EVM и другие преимущества. Можно сказать, что приоритетная дорожная карта для постоянного улучшения Ethereum L1 должна включать и основываться на EOF.

Необходимой задачей является реализация функций, подобных EVM-MAX и SIMD, а также проведение бенчмаркинга потребления газа различных криптографических операций.

)# Как взаимодействовать с другими частями дорожной карты?

L1 настраивает свой EVM, чтобы L2 также мог легче вносить соответствующие изменения; если оба не будут синхронизированы, это может привести к несовместимости и негативным последствиям. Кроме того, EVM-MAX и SIMD могут снизить газовые затраты многих систем доказательств, что сделает L2 более эффективным. Это также упрощает замену большего количества предварительно скомпилированных функций кодом EVM, который может выполнять те же задачи, что, вероятно, не окажет значительного влияния на эффективность.

![Виталик о возможном будущем Ethereum (шестая часть): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.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 заключается в разделении обработки действий пользователя на два этапа: проверка и выполнение. Все проверки сначала обрабатываются, а все выполнения обрабатываются затем. В пуле памяти действия пользователя принимаются только тогда, когда этап проверки касается только его собственного аккаунта и не считывает переменные окружения. Это помогает предотвратить атаки множественного отказа. Кроме того, на этап проверки также жестко накладываются ограничения по газу.

ERC-4337 был разработан как дополнительный стандарт протокола ( ERC ), потому что в то время разработчики клиентов Ethereum сосредоточились на слиянии ( Merge ) и не имели дополнительных ресурсов для обработки других функций. Вот почему ERC-4337 использует объект, называемый пользовательскими операциями, вместо обычных транзакций. Тем не менее, недавно мы осознали необходимость записать по крайней мере часть из этого в протокол.

Две ключевые причины следующие:

1. EntryPoint как врожденная неэффективность контракта: каждый пакет имеет фиксированные затраты около 100,000 газа, а также дополнительные тысячи газа для каждой операции пользователя.
2. Обеспечение необходимости атрибутов Ethereum: например, включение списка, созданного для обеспечения необходимости перевода на аккаунт абстрактного пользователя.

Кроме того, ERC-4337 расширяет две функции:

• Платежный агент ( Paymasters ): функция, позволяющая одной учетной записи оплачивать сборы от имени другой учетной записи, что нарушает правило, согласно которому на этапе проверки можно получить доступ только к самой учетной записи отправителя, поэтому вводится специальная обработка для обеспечения безопасности механизма платежного агента.
• Агрегаторы (: поддерживают функции агрегирования подписей, такие как агрегирование BLS или агрегирование на основе SNARK. Это необходимо для достижения максимальной эффективности данных на Rollup.

![Виталик о возможном будущем Ethereum (шестая часть): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(

)# Остальная работа и компромиссы

В настоящее время основная задача заключается в том, как полностью интегрировать абстракцию аккаунта в протокол. Недавно популярный EIP для записи протокольной абстракции аккаунта - это EIP-7701, который реализует абстракцию аккаунта на основе EOF. Один аккаунт может иметь отдельную часть кода для проверки, и если этот аккаунт настроил эту часть кода, то этот код будет выполняться на этапе проверки транзакций, поступающих от данного аккаунта.

Очарование этого метода заключается в том, что он ясно показывает два эквивалентных взгляда на абстракцию локальных счетов:

1. Включить EIP-4337 в качестве части протокола
2. Новый тип EOA, в котором алгоритм подписи выполняется с помощью кода EVM.

Если мы начнем с того, чтобы установить строгие границы для сложности исполняемого кода во время валидации - не допускается доступ к внешнему состоянию, даже начальные ограничения по газу настолько низки, что они неэффективны для квантовой стойкости или приложений по защите конфиденциальности - тогда безопасность этого подхода становится очень ясной: просто заменяем валидацию ECDSA на выполнение кода EVM, требующее аналогичного времени.

Однако, с течением времени, нам необходимо ослабить эти границы, поскольку разрешение приложениям для защиты конфиденциальности работать без реле и квантовая устойчивость являются очень важными. Для этого нам нужно найти более гибкие решения для отказа в обслуживании (DoS) вет.