Предисловие

Статья разделена на два основных раздела:

В первой части начнется с первого предложения AA с 2015 года, систематически организуя основное содержание предложений EIP на сегодняшний день. Целью является исследование исторического развития предложений AA и комплексная оценка сильных и слабых сторон каждого предложения.

Во второй части будет сосредоточено на сравнении реакции рынка после введения EIP-4337, а затем будет введен анализ EIP-7702, который предполагается включить в следующее обновление Ethereum. После слияния данного предложения ожидается значительное изменение характера онлайн-приложений.

EIP-7702 обещает революционные изменения, и мы обсудим их подробно.

1. Фон счета абстракции

1.1 Значение абстрагирования учетной записи

В конце 2023 года основатель Ethereum Виталик Бутерин еще раз обновил дорожную карту развития ETH. Однако положения, связанные с Абстракцией счета, остались неизменными. Текущая основная модель продолжает эволюционировать от EIP-4337 к следующей фазе: Добровольное преобразование EOA (самостоятельное преобразование учетных записей EOA).

https://x.com/VitalikButerin/status/1741190491578810445

С момента выпуска EIP-4337 более года назад (1 марта 2023 года на WalletCon в Денвере разработчики Ethereum Foundation объявили, что основные контракты ERC-4337 прошли аудит OpenZeppelin, отметив исторический рубеж для его официального запуска), он получил широкое признание пользователей, но не увидел широкого принятия. Эта парадоксальная рыночная среда ускорила прогресс EIP-7702, который теперь подтвержден для включения в следующее обновление.

1.2 Текущий рыночный статус абстракции учетной записи

Без лишних слов давайте посмотрим на данные.

После полуторагодичной разработки EIP-4337 набрал только 12 миллионов адресов в основных цепных учетах. Особенно удивительно, что на основной сети Ethereum всего 6 764 активных адреса. Возможно, есть проблемы с статистическими измерениями, но это число все равно значительно отличается от количества адресов для EOAs и CAs. Для контекста количество уникальных адресов в основной сети Ethereum достигло 270 миллионов (источник: https://etherscan.io/chart/address).

Можно сказать, что EIP-4337 не сделал существенного прогресса на основной сети.

(Источник диаграммы: https://dune.com/niftytable/account-abstraction)

Однако это не умаляет врожденной ценности абстракции учетной записи (AA). С самого начала проектирование EIP-4337 было обречено на серьезные проблемы с обратной совместимостью на основной сети. В результате различные цепи Layer 2, интегрирующие собственную AA, EIP-4337 заметно вырос в количестве адресов на Layer 2. Например, в июле количество активных пользователей на цепях Base и Polygon достигло 1 миллиона и 3 миллиона соответственно, что довольно впечатляюще.

Поэтому проблема не в том, что дизайн EIP-4337 ошибочен; у него есть много преимуществ, которые мы систематически суммируем. Текущая ситуация возникает из различий между основной сетью и Layer 2, требующими индивидуальных решений.

2. Что такое Абстракция учетной записи?

Абстракция учетной записи может показаться сложной, но в основном она решает проблему разделения собственности.

В архитектуре виртуальной машины Ethereum (EVM) существуют два типа учетных записей: учетные записи с внешним владением (EOA) и контрактные учетные записи. В учетных записях EOA владение и право подписи принадлежат одному и тому же субъекту. Человек с закрытым ключом не только владеет учетной записью, но и имеет право подписывать и переводить все ее активы.

Эта настройка определяется структурой транзакций по счету Ethereum. В стандартной транзакции Ethereum прямой адрес отправителя не отображается. Когда происходит перевод средств, фактический адрес, с которого тратятся средства, определяется с помощью параметров VRS (т.е. подписи пользователя).

Это включает в себя такие концепции, как асимметричное шифрование ECDSA и односторонние пороговые функции, но мы не будем углубляться в эти детали здесь. В основном, криптография обеспечивает безопасность, что приводит к текущей ситуации, когда собственность и право подписи объединены в EOAs.

Основной эффект EIP-4337 заключается в добавлении поля адреса отправителя к транзакции, что позволяет отделить приватный ключ и адрес операции.

Так почему так важно разделять собственность?

Поскольку дизайн Внешних Собственных Счетов (EOA) приводит к нескольким проблемам:

Защита частного ключа: потеря частного ключа (из-за утери, взлома или криптографической компрометации) означает потерю всех активов.

Ограниченные алгоритмы подписи**: Встроенный протокол поддерживает только ECDSA для подписи и верификации.

Высокий Авторитет Подписи: Без поддержки множественных подписей на уровне языка (которую можно достичь только через смарт-контракты), одна подпись может выполнить любую операцию.

Комиссии за транзакции: Комиссии могут быть оплачены только в ETH, который не поддерживает высокий объем транзакций.

Конфиденциальность транзакций: Однозначные транзакции облегчают анализ личной информации владельца учетной записи.

Эти ограничения затрудняют использование Ethereum обычными пользователями:

Для использования любого приложения на Ethereum пользователи должны держать ETH (и нести риск флуктуаций цены ETH).

Пользователям нужно иметь дело с сложной логикой комиссий, такой как цена газа, лимит газа и блокировка транзакций (порядок nonce), что может быть слишком сложным.

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

Решение заключается в реализации абстракции учетной записи, которая разделяет владение (Владелец) и право на подписание (Подписант), чтобы решить эти проблемы. Исторически возникло много решений, в конечном итоге сходящихся к двум основным подходам.

3. Исторический обзор предложений по абстракции учетной записи

Хотя может показаться, что существует много предложений EIP, решающих проблему, по сути, есть всего два основных подхода. Проблемы, рассматриваемые в прошлых предложениях, которые не были утверждены, в конечном итоге сошлись в текущие решения.

3.1 Первый маршрут - превратить адрес EOA в адрес CA

15 ноября 2015 года Виталик Бутерин предложил новую структуру учетной записи вокруг EIP-101, которая включала использование контрактов в качестве учетных записей. Это преобразовало бы адреса в сущности только с кодом и местом для хранения, изменило бы поддержку платы на оплату через токены ERC20 и использовало бы предварительно скомпилированные контракты для преобразования внутренних токенов в токены ERC20 для хранения баланса (с функциями, такими как делегированная авторизация). Поля транзакции упростились и теперь включают только to, startgas, data и code)

Оглядываясь назад, это было революционное изменение, которое радикально изменит базовый дизайн, давая каждому адресу учетной записи его собственную "кодовую" логику, что в сущности и является целью EIP-7702 сегодня. Такой подход также может обеспечить дополнительные функции, такие как:

Разрешение транзакциям использовать больше криптографических алгоритмов, указанных во внутреннем коде каждого адреса для верификации и аутентификации.

Обеспечение квантовой стойкости благодаря возможности обновления кода.

Наделяя Эфир теми же функциональными характеристиками, что и у контрактов ERC20, с функциями, такими как делегированная авторизация, устраняя необходимость в расходе местной монеты.

Улучшение настройки учетной записи, поддержка социального восстановления, SBT (жетоны, привязанные к душе), и восстановление ключа.

Причина, по которой этот проект не был продвинут, была проста: шаги были слишком амбициозными. Проблемы, такие как столкновения хэшей транзакций и проблемы безопасности, не были полностью решены, что привело к его отсрочке. Тем не менее, многие из его преимуществ стали основными чертами в последующих EIP, включая EIP-4337 и EIP-7702.

Несколько EIP позже попытались уточнить эту логику:

EIP-859: Account Abstraction on Mainnet (30 января 2018 года) aimed at addressing code deployment issues. Его основная функция была использовать кодпараметр, прикрепленный к транзакциям для развертывания контрактных кошельков, если контракт не был развернут. Также был введен новый опкод PAYGAS для разделения частей верификации и выполнения транзакции.

Хотя на тот момент это не продвинулось, этот логический компонент стал основной частью EIP-7702, который позволяет адресам EOA обладать возможностями контракта через специальные транзакционные структуры, которые могут включать код.

EIP-7702: Установка кода учетной записи EOA (7 мая 2024 года) - это ключевой EIP, обсуждаемый здесь. Виталик предложил EIP-7702 в качестве альтернативы EIP-3074. В результате EIP-3074 был заброшен, а EIP-7702 предполагается включить в предстоящий хардфорк ETH Prague/Electra (Pectra). Дополнительные подробности будут обсуждены ниже.

3.2 Второй подход заключается в том, чтобы позволить адресам EOA управлять адресами CA.

EIP-3074: Добавление операций AUTH и AUTHCALL (15 октября 2020)

Этот EIP вводит два новых операционных кода, AUTH и AUTHCALL, в EVM, позволяя EOAs авторизовать контракты на замену их идентичности и вызов других контрактов. По сути, EOA может отправить подписанное сообщение (транзакцию) доверенному контракту (называемому Invoker). Контракт Invoker затем может использовать операционные коды AUTH и AUTHCALL для отправки транзакции от имени EOA.

EIP-4337: Внедрение абстракции учетной записи через пулы транзакций (29 сентября 2021 года)

Вдохновленный MEV, основная ценность этого EIP заключается в том, что он избегает изменений в протоколе уровня консенсуса. EIP-4337 вводит новый объект транзакции, UserOperation, который пользователи отправляют в пул памяти. Затем бандлеры пакетируют и доставляют эти транзакции для выполнения контракта, эффективно перемещая операции с транзакциями и счетами на более низкий уровень на уровень контракта.

EIP-5189: Абстрактные операции счета через эндорсеров (29 июня 2022)

Этот EIP оптимизирует EIP-4337, решая потенциальные проблемы с злонамеренными пакетами. Он вводит механизм фондов, поддерживаемых эндорсером, для предотвращения атак типа DoS путем наказания плохих актеров.

3.3 Другие предложения в поддержку абстракции учетной записи

EIP-2718: Новый тип транзакции Envelope (13 июня 2020 г.)

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

EIP-3607: Предотвращение развертывания контрактов с адресов EOA (10 июня 2021 года)

Этот дополнительный предложение решает проблему конфликта адресов развертывания контракта с адресами EOA. Оно контролирует методы создания контракта, предотвращая развертывание кода на адресах, уже используемых EOA. Риск минимален из-за длины 160 бит адресов Ethereum, хотя теоретически возможен через коллизии ключей, это потребует значительных вычислительных усилий.

3.4 Понимание развития абстракции учетной записи

Для понимания ценности перехода к CA-адресам важно осознать практические эффекты EIP-4337, которые могут достигнуть…

Однако основным недостатком EIP-4337 является то, что она нарушает принцип человеческих стимулов. Хотя кажется, что она предлагает улучшения, она попадает в тупик рыночного развития. Многие Dapps до сих пор не совместимы с ней, что заставляет пользователей неохотно использовать CA-адреса. Кроме того, использование CA может привести к увеличению затрат на транзакции (например, комиссии за транзакции могут удвоиться в обычных сценариях перевода), что сильно зависит от совместимости Dapps.

В результате это до сих пор не стало широко распространенным на основной сети Ethereum на сегодняшний день. Стоимость - самый важный фактор для пользователей, и ее необходимо снизить. Чтобы действительно снизить затраты на GAS, сам Ethereum должен был бы выполнить мягкое обновление, чтобы изменить расчеты GAS или изменить потребление GAS опкодов. Учитывая необходимость мягкого форка, почему бы не рассмотреть прямо EIP-7702?

4. Комплексный анализ EIP-7702

4.1 Что такое EIP-7702

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

Это позволяет пользователям получать большую часть возможностей AA без развертывания смарт-контрактов и даже предоставлять третьей стороне возможность инициировать транзакции от имени пользователей. Для этого не требуется предоставлять пользовательские приватные ключи, достаточно только подписать авторизованную информацию.

4.2 Структура данных

Он определил новый тип транзакции 0x04. TransactionPayload этого типа транзакции - это сериализованный результат кодирования RLP следующего содержимого

rlp([

chain_id, //Идентификатор цепи, используемый для предотвращения повторных атак.

nonce, // Счетчик транзакций для обеспечения уникальности транзакции.

max_priority_fee_per_gas, //1559 комиссия за транзакцию

max_fee_per_gas, //1559 комиссия за транзакцию

лимит_газа,

destination, //Адрес целевой транзакции

значение,

данные,

access_list, //Список доступа, используемый для оптимизации газа в EIP-2929.

список авторизации,

signature_y_parity, // 3 параметра подписи, используемые для проверки подписи транзакции.

signature_r,

подпись

])

Важно, чтобы объект authorization_list добавлялся для хранения кода, который подписывающий хочет выполнить в своем EOA. Когда пользователь подписывает транзакцию, он также подписывает код контракта на выполнение. Он существует в виде двумерного списка, указывая на то, что в пакетах можно хранить множественную информацию об операциях и выполнять их пакетными операциями.

authorization_list = [[chain_id, адрес, nonce, y_паритет, r, s], …]

4.3 Жизненный цикл транзакции

4.3.1 Фаза проверки

В начале фазы выполнения транзакции, для каждой [chain_id, address, nonce, y_parity, r, s]кортеж всписок авторизации:

Используйте ecrecoverфункция для восстановления адреса подписанта из подписи(r, s)Обратите внимание, что здесь используется существующий механизм Ethereum, поэтому алгоритм подписи остается неизменным в этом EIP. Адрес восстанавливается с использованием: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s). Это похоже на то, как изадрес происходит от подписей, но применяется к конкретному списку подписи.

Проверьте идентификатор цепи, чтобы предотвратить ретрансляцию атак на различные цепи.

Проверьте, если властьКод подписанта либо пуст, либо делегирован (для подтверждения, является ли транзакция действительной транзакцией EIP-7702, обработка выполнения которой осуществляется с помощью механизмов делегирования).

Проверьте властьnonce подписывающего для предотвращения повторных атак на подписи.

Установитеавторитеткод подписанта на 0xef0100 || адрес (для обхода стратегий предотвращения коллизий EIP-3607).

Увеличить властьnonce подписчика (для предотвращения локального повтора подписи).

Добавить авторитетдобавить учетную запись подписчика в список доступа (для перехода к горячему хранению, сокращая газовые расходы на доступ).

4.3.2 Фаза выполнения

Где выполняется код контракта и операционные инструкции?

Новая версия изменяет способ развертывания кода контракта. Вместо того, чтобы устанавливать код учетной записи напрямую, она извлекает код из список авторизацииадрес и устанавливает его в качестве кода учетной записи.

При выполнении авторизованного кода загружайте код с указанного адреса в список авторизацийи выполнять его в контексте учетной записи подписанта. Это означает, что код контракта пользователя хранится по определенному адресу на блокчейне, а не непосредственно включается в транзакцию.

Операционные инструкции и связанные параметры хранятся в данныеполе полезной нагрузки транзакции.

4.4 Каково значение EIP-7702?

EIP-7702 вносит значительную ценность, поскольку фундаментально изменяет весь процесс транзакций для кошельков Web3, что приводит к радикальным изменениям в пользовательском опыте. Обычные транзакции, инициированные EOA (Внешне Управляемый Счет), теперь могут выполнять несколько логик, аналогичных выполнению смарт-контрактов, таких как пакетные переводы. Это также влияет на сценарии CeFi, затрагивая идентификацию транзакций и комиссии за вывод и консолидацию.

EIP-7702 нарушает многие долгосрочные предположения: это нарушает инвариант, что баланс счета может уменьшаться только из-за транзакций, исходящих от этого счета. Это нарушает инвариант, что счетчик EOA увеличивается на 1 после начала выполнения транзакции (теперь он может увеличиваться одновременно на несколько значений). Это нарушает защитную логику, которая полагается на сравнениеtx.originиmsg.sender, вводя потенциальные риски для многих существующих контрактов. Также нарушается тот факт, что сам EOA не может генерировать события, что может повлиять на идентификацию и мониторинг определенных on-chain событий. Наконец, нарушается предположение о том, что адрес EOA всегда успешно получит ERC20, 721, 1155 и другие активы (так как это может не удалиться из-за механизма обратного вызова).

4.5 Сравнение между EIP-7702 и EIP-4337

1.Преимущества EIP-7702

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

По сравнению с EIP-4337, EIP-7702 также поддерживает делегированное выполнение кода и предлагает два типа делегирования:

Полная Делегация: Это означает делегирование полного контроля над определенной операцией определенному адресу. Например, пользователь может делегировать управление всеми токенами ERC-20 адресу смарт-контракта, позволяя контракту выполнять все связанные операции от имени пользователя.

Защищенная делегирование: это включает добавление ограничений и мер безопасности во время делегирования, чтобы обеспечить безопасность и управляемость делегированных операций. Например, пользователь может делегировать только частичные права управления токенами ERC-20 смарт-контракту или установить условия (например, тратить не более 1% от общего баланса в день).

2. Недостатки EIP-7702

Основной недостаток EIP-7702 заключается в том, что он включает в себя обновление софтфорка, требующее консенсуса сообщества для продвижения вперед. Его изменения существенны и могут оказать широкое влияние на ончейн-экосистему. На основе первоначальной оценки, проведенной Шиси Цзюнем, было выявлено несколько проблем, но эти проблемы также могут представлять рыночные возможности:

Высокая степень свободы делает аудит сложным, что приводит к требованиям пользователей к более надежным кошелькам для обеспечения защиты безопасности.

Изменения в исходной архитектуре значительны. Хотя можно выделить различные типы транзакций, многие фундаментальные инфраструктуры, особенно неизменные контракты on-chain, могут быть непосредственно несовместимы.

Хотя EIP-7702 предоставляет возможности контракта для адресов EOA, соответствующее пространство хранения не может быть сохранено.

Стоимость отдельных транзакций немного выше из-за значительного увеличения раздела Calldata. Предполагаемая общая стоимость вызова составит 16 (газ)15 (байт) = 240 (газ) для затрат на calldata, плюс стоимость EIP-3860 в размере 215 = 30, и примерно 150 на затраты на выполнение. Поэтому даже подготовка учетной записи без операций увеличит затраты на газ примерно на 500.

«Если получатель подписывает код, в котором отсутствует функция получения, отправитель может столкнуться с DoS при попытке отправки активов». См. случай. Эта проблема возникает, когда EOA A подписывает то, что не следовало бы — файл, подлежащий повторению, с неправильной реализацией (не имеющий получить()).

Логика консолидации и вывода на цепочке может быть несогласованной. Например, при передаче токенов ERC-20, если у учетной записи получателя есть код, контракт токена вызовет onERC20Receivedна счет получателя. ЕслиonERC20Receivedесли функция возвращает неправильное значение, передача токена отменится.

Кроме того, если EOA может генерировать события, могут ли возникнуть какие-либо проблемы? Некоторым инфраструктурам может потребоваться обратить на это внимание.

Это всего лишь некоторые из недостатков, суммированные Шиши Цзюн на основе текущего предложения EIP-7702 и обсуждений на официальном форуме. Полный анализ потребует изучения кода окончательной реализации.

5. Summary

Статья может показаться обширной, но в ней содержится всего около 6 000 слов. Множество ссылок на прошлые интерпретации EIP приведены в тексте для дальнейшего изучения, поэтому здесь я не буду вдаваться в них.

В настоящее время кажется, что абстракция учётной записи может быть размещена только в шестом модуле, который является завершающим этапом исправления всего перед тем, как продвигаться вперёд. Ускоренный прогресс EIP-7702 в основном представляет собой вызовы для безопасности системы. Предполагается, что он в конечном итоге будет реализован. В конце концов, слияние Ethereum, которое включало крупномасштабную переработку алгоритма консенсуса, уже произошло. Новый тип транзакции относительно незначителен по сравнению.

Однако на этот раз изменения довольно революционные, нарушая несколько ранее «невозможных» правил on-chain и изменяя логику большинства DApps. Однако EIP-7702 твердо удерживает самую важную точку: значительно снижает затраты пользователей. В отличие от этого, EIP-4337 почти удваивает транзакционные издержки.

Пользователи остаются адресами EOA (внешнеуправляемого счета), но вызывают и используют логику CA (счета контракта) только при необходимости, тем самым снижая затраты на хранение. Нет необходимости сначала преобразовывать в идентификатор CA на цепи блоков перед выполнением действий, что означает, что пользователям не нужно регистрироваться.

Пользователи могут легко выполнять несколько транзакций параллельно, используя свои EOA, такие как объединение авторизации на удержание и выполнение удержаний. Это по своей сути снижает транзакционные издержки для пользователей. Для DApps, особенно проектов, требующих управления на уровне предприятия в цепи, таких как биржи, эта оптимизация является революционной. Если пакетная консолидация будет реализована нативно, основные операционные издержки для бирж могут быть снижены более чем наполовину, в конечном итоге принося пользу пользователям.

Поэтому, хотя EIP-7702 вносит много изменений, его влияние на стоимость одного лишь делает его достойным изучения и адаптации для всех DApps. В этот раз пользователи, безусловно, на стороне EIP-7702.

Disclaimer：

1. Эта статья перепечатана из [PANews]. Все авторские права принадлежат оригинальному автору [Четырнадцатый Лорд]. Если есть возражения против этого повторного издания, пожалуйста, свяжитесь сGate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционной рекомендацией.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.