Будущее Протокола 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-битные STARKs и криптографию на основе решеток. Объединение 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(, включая циклические и нециклические), по крайней мере для степеней 2. Также добавить ISZERO(, который будет выводить результаты на основной стек EVM), что будет достаточно мощным для реализации эллиптической кривой криптографии, маломасштабной криптографии(, такой как Poseidon, Circle STARKs), традиционных хеш-функций(, таких как SHA256, KECCAK, BLAKE) и криптографии на основе решеток. Другие обновления EVM также могут быть реализованы, но пока что они не привлекли большого внимания.

Существующие исследовательские ссылки

• 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-код, который может выполнять те же задачи, что, вероятно, не окажет значительного влияния на эффективность.

Абстракция аккаунта

Что решает?

В настоящее время транзакции можно проверять только одним способом: подписью 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-c0f722db75e53f4ff37ef40f5547dfc4.webp(

) Что это такое и как это работает?

Суть абстракции аккаунта проста: позволяет смарт-контрактам инициировать транзакции, а не только EOA. Вся сложность заключается в том, чтобы реализовать это таким образом, который является дружелюбным к поддержанию децентрализованной сети и предотвращает атаки отказа в обслуживании.

Одним из типичных ключевых вызовов является проблема множественных сбоев:

Если валидационная функция для 1000 аккаунтов зависит от одного единственного значения S, и текущее значение S делает все транзакции в пуле памяти действительными, то одна единственная транзакция, меняющая значение S, может сделать все остальные транзакции в пуле памяти недействительными. Это позволяет злоумышленнику с очень низкими затратами отправлять мусорные транзакции в пул памяти, тем самым блокируя ресурсы узлов сети.

После многих лет усилий, направленных на расширение функциональности и ограничение рисков отказа в обслуживании ###DoS(, в конечном итоге был найден способ реализации "идеального абстракции учетной записи": ERC-4337.

Работа ERC-4337 заключается в разделении обработки пользовательских операций на два этапа: верификация и выполнение. Сначала обрабатываются все верификации, а затем все выполнения. В мемпуле принимаются только те пользовательские операции, этап верификации которых касается только их собственного аккаунта и не считывает переменные окружения. Это позволяет предотвратить атаки с множественными сбоями. Кроме того, для этапа верификации также строго применяются ограничения по газу.

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

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

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

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

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

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

( Существующие ссылки на исследования

• Доклад о истории абстракции аккаунта:
• ERC-4337:
• ЭИП-7702:
• Код BLSWallet ) использует агрегирующую функцию ###:
• EIP-7562( записанный в Протокол абстракции аккаунтов ):
• EIP-7701( Протокол записи абстракции аккаунтов на основе EOF ):

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

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