Будь то бычий рынок или медвежий рынок, экосистема Ethereum постоянно развивается и самооптимизируется. Среди них абстракция учетных записей (AA) добилась значительного прогресса в последние годы и проникла во все части экосистемы Ethereum, включая приложения, инфраструктуру, пользователей и разработчиков. Мы можем предвидеть, что широкомасштабное внедрение AA снизит порог использования блокчейна в целом и представит пользовательский опыт web2 в индустрии web3.
В этой статье команда BlockPI углубится в свое понимание AA и поделится своим мнением с точки зрения поставщика инфраструктурных услуг.
EOA и контрактный кошелек
Концепция AA проистекает из ограничений счетов EOA. Учетная запись EOA (внешняя учетная запись) — это учетная запись пользователя в Ethereum, представленная открытым ключом (адресом блокчейна) и доступная через закрытый ключ. Это основной компонент экосистемы Ethereum, позволяющий пользователям переводить деньги в блокчейн или взаимодействовать со смарт-контрактами. Однако для многих людей использование EOA само по себе может быть сложной задачей. Более того, текущая учетная запись EOA по-прежнему имеет некоторые неудобства в использовании, что сказывается на пользовательском опыте.
Во-первых, это плата за газ. Каждая транзакция будет стоить пользователю значительную сумму ETH в качестве платы за газ (взяв в качестве примера цену газа в 25 Gwei, плата за газ для простого перевода ETH составляет около 0,5 долларов США, и это будет дороже для взаимодействия по контракту. или когда цена на газ выше). Это делает небольшие транзакции очень дорогими, особенно в периоды сильной перегрузки сети. Кроме того, газ можно оплачивать только ETH, а это означает, что пользователи должны хранить ETH в своих кошельках, что представляет собой высокий барьер для входа для многих пользователей.
Во-вторых, для некоторых сложных операций, которые хотят реализовать пользователи, EOA должен полагаться на другие смарт-контракты. Например, если пользователь хочет установить периодическую передачу по времени, ему необходимо перевести ETH в смарт-контракт с помощью этой функции для выполнения этой операции.
Третья проблема с EOA — алгоритм шифрования с фиксированной подписью. Сеть Ethereum использует алгоритм цифровой подписи под названием secp256k1 для обеспечения подлинности и безопасности транзакций. Этот алгоритм жестко запрограммирован в системе, и пользователи не могут использовать другие алгоритмы шифрования.
В дополнение к вышеупомянутым трем проблемам, связывающая связь между открытым ключом EOA и закрытым ключом также является проблемой. Закрытый ключ — это единственный способ для пользователей получить доступ к EOA. Если закрытый ключ утерян, он не будет восстановлен. Это также означает, что все активы в рамках EOA, связанные с ним, будут невозвратными.
В то же время ЭОА имеет и ограничения при выполнении некоторых линейных задач. Например, если пользователь хочет утвердить, поменять местами и не утвердить токены за одну операцию, необходимо выполнить три отдельные транзакции, что неэффективно и занимает много времени.
Хорошая новость заключается в том, что контрактные кошельки могут решить все вышеперечисленные проблемы. Контрактный кошелек — это, по сути, особый тип учетной записи смарт-контракта, реализующий AA, который можно использовать в качестве кошелька пользователя в Ethereum. И это может предоставить пользователям более гибкий и персонализированный способ управления средствами. Пока это логика, которая может быть реализована смарт-контрактом Ethereum, контрактный кошелек может реализовать и предоставить соответствующие функции.
В частности, несколько операций с контрактным кошельком могут быть объединены в транзакцию по цепочке, и эти операции могут разделить стоимость газа этой транзакции. Если третья сторона готова оплатить комиссию за газ, нет необходимости платить газ за пользователей, использующих контрактный кошелек. Контрактные кошельки также могут выполнять несколько линейных задач одновременно. Кроме того, контрактный кошелек также поддерживает алгоритм шифрования пользовательских подписей, устанавливает функцию восстановления кошелька и так далее.
Поскольку обсуждение преимуществ контрактных кошельков продолжается, сообщество Ethereum фактически провело долгосрочное исследование контрактных кошельков. Хотя многие EIP исследовали проблемы, связанные с абстрагированием учетной записи, по состоянию на 2021 год единый стандарт не установлен. Ниже приведены несколько репрезентативных EIP.
ЭИП-86
Первоначально предложено Виталиком Бутериным в 2017 году. Схема реализует ряд изменений с общей целью «абстрагирования» проверки подписи и проверки одноразового номера, тем самым позволяя пользователям создавать «контракты учетных записей», которые выполняют произвольную проверку подписи/одноразового номера.
ЭИП-2938
Представлен в 2020 году. Название этого EIP — «Абстракция учетной записи». Концепция AA хорошо описана в этом EIP. Он вводит новый тип транзакции, транзакцию AA. Транзакция инициируется адресом точки входа (EntryPoint address) и обращается к кошельку контракта AA. EIP-2938 предоставляет унифицированную спецификацию и официально вводит абстракцию учетной записи AA в консенсус Ethereum. В частности, он вводит два новых кода операции, три глобальные переменные и другую структуру полезной нагрузки для консенсуса Ethereum.
ЭИП-3074
Представлен в 2020 году. В этом EIP представлены две инструкции EVM: AUTH и AUTHCALL. AUTH устанавливает переменную среды в соответствии с полномочиями подписи ECDSA. AUTHCALL отправляет вызов как авторизованная учетная запись. Это позволяет смарт-контрактам отправлять транзакции от имени EOA. Но это все еще не идеальное решение для АА. В процессе транзакции авторизации EIP-3074 имеет определенные ограничения на передачу исходного значения. И если пользователь потеряет доступ к EOA, у него все равно не будет возможности восстановить свои активы. В случае утечки закрытого ключа пользователю необходимо перевести все активы в новую учетную запись.
Ни одно из вышеперечисленных предложений не было официально включено в протокол Ethereum из-за необходимости изменений на уровне консенсуса или из-за того, что предложения не были достаточно исчерпывающими. Поэтому сообщество Ethereum продолжило изучать, как внедрить AA в протокол Ethereum без изменения консенсуса, и, наконец, предложило EIP4337.
ERC-4337
EIP-4337 был первоначально предложен в сентябре 2021 года и авторизован как ERC-4337 в марте 2023 года. Среди его авторов Виталик Бутерин, Йоав Вайс, Кристоф Газсо, Намра Патель, Дрор Тирош, Шахаф Наксон и Тьяден Хесс.
EIP-4337 — это прорывное предложение, которое может ввести AA без изменения основного протокола Ethereum. EIP-4337 в конечном итоге стал стандартом ERC-4337, который разработчики могут использовать для реализации своих собственных кошельков смарт-контрактов. В то же время стандарт также вводит некоторую дополнительную инфраструктуру, включая «связчики» и «мемпул UserOperation». Таким образом, он фактически копирует мемпул Ethereum с аналогичными функциями на верхнем уровне системы блокчейна. То, что отправляет пользователь, больше не является отдельной транзакцией, а является UserOperation. Несколько пользовательских операций могут быть объединены в одну транзакцию и отправлены в Ethereum.
Ниже приводится подробное техническое объяснение ERC-4337 в Ethereum [официальная документация](, а также некоторые полезные комментарии.
Ключевые роли и определения ERC-4337
UserOperation — описывает структуру транзакции, отправляемой от имени пользователя. Чтобы избежать путаницы, она не называется «транзакция» и будет отправлена в Bundler для упаковки в Bundle с другими UserOperations. Затем Bundle отправляется по цепочке как одна транзакция.
Sender — учетная запись контракта, которая отправляет UserOperation. Контракт кошелька должен соответствовать стандарту ERC-4337 для настройки интерфейса IAccount.
EntryPoint — глобальный одноэлементный контракт, который выполняет пакет UserOperations. Белые списки бандлеров/клиентов поддерживают EntryPoints. Контракт проверяется и утверждается для развертывания командой Infinitism, которая отвечает за обработку всех пользовательских операций и подключение контрактов с другими ролями, включая Wallet Factory, Aggregator и Paymaster. Все контракты находятся по одному и тому же адресу в цепочке, совместимой с EVM.
Bundler — узел, который упаковывает несколько UserOperations из мемпула и создает транзакцию EntryPoint.handleOps() (текущий производитель блоков). Служба Bundler может работать независимо от узлов блокчейна и отправлять упакованные пользовательские операции через RPC.
Агрегатор — вспомогательный контракт, которому учетные записи доверяют проверку агрегированных подписей. Белый список Bundlers/Clients поддерживает агрегаторы подписей. Агрегатор должен следовать стандарту ERC-4337 для настройки интерфейса IAggregator.
Paymaster — смарт-контракт, который может оплачивать газ от вашего имени. Если он вносит достаточно ETH в контракт EntryPoint, он может оплатить комиссию за газ для UserOperation для отправителя, эффективно реализуя абстракцию газа. Paymaster должен следовать стандарту ERC-4337 для настройки интерфейса Paymaster. Казначей может заключить договор с Отправителем. Например, отправитель платит Paymaster в долларах США, а Paymaster использует ETH для оплаты газа за отправляемые им операции пользователя. Фактически, Paymaster может выбрать поддержку любого токена, включая токены ERC-20 и даже токены других цепей.
Wallet Factory — смарт-контракт, который может создавать контрактные кошельки для пользователей ERC-4337. Развертывание Wallet Factory не требует разрешения. Как сетевой смарт-контракт, его код открыт для публики, и любой может просмотреть его. Широко используемая фабрика кошельков должна быть полностью проверена профессионалами.
На приведенной ниже диаграмме показано, как контракт EntryPoint взаимодействует с другими участниками.
Сборщики вызывают функцию handleOps контракта EntryPoint, которая принимает UserOperation в качестве входных данных.
handleOps проверит UserOperation в цепочке, проверит, подписана ли она указанным адресом кошелька смарт-контракта, и подтвердит, достаточно ли газа в кошельке для компенсации Bundler.
Если проверка пройдена, handleOps выполнит функцию кошелька смарт-контракта в соответствии с функцией и входными параметрами, определенными в данных вызова UserOperation.
С другой стороны, когда Bundler использует EOA для запуска функции handleOps, взимается плата за газ. Кошелек со смарт-контрактом может оплачивать сборы за газ для Bundlers со своего собственного баланса счета или запрашивать оплату у контракта Paymaster. UserOperations не может пройти этап проверки вне сети без достаточного количества газа, то есть происходит сбой до выполнения транзакции в цепочке. Даже если газа достаточно, UserOperations все равно может выйти из строя из-за таких причин, как ошибки времени выполнения во время выполнения. Для UserOperation, независимо от того, было ли выполнение контракта успешным или нет, контракт EntryPoint будет платить комиссию за газ Bundler, который запускает функцию handleOps.
(Выдержка из официальной документации:
После вступления в силу ERC-4337 пользователи теперь могут инициировать транзакции в блокчейне двумя способами. Один из них — традиционный, то есть EOA напрямую инициирует транзакцию. Другой — использовать стандарт ERC-4337 для инициации UserOperation через Bundler, а затем Bundler упакует ее с другими UserOperations и отправит в цепочку. Блок-схема ниже иллюстрирует разницу между обычной транзакцией отправки EOA и отправкой UserOperation контрактного кошелька ERC-4337.
Дорога заасфальтирована, но пешеходов пока мало
ERC-4337 предоставляет пользователям и разработчикам мощную основу для использования и создания AA на Ethereum. Хотя эта структура является важным достижением, все еще существуют некоторые проблемы и неопределенности, которые необходимо рассмотреть и решить.
Принятие АА все еще находится в зачаточном состоянии. Согласно аналитической панели Dune ERC-4337 (*[ERC-4337 Account Abstraction](от @niftytable), в цепочке было выполнено только 65 000+ пользовательских операций, 90 % из которых поступило от Polygon. Таким образом, количество выполняемых в настоящее время пользовательских операций по-прежнему очень мал, и большинство из них Часть из них является тестом разработчиков, и лишь небольшая часть исходит от реальных пользователей.Мы заметили, что продукты, в которые интегрировано AA, все еще находятся на ранней стадии.В настоящее время мы можем наблюдать, что Бандлеры в целом все еще находятся в состоянии убытков, а текущие потери составляют более 700 MATIC. Это в основном вызвано тем, что некоторые бандлеры на полигоне неправильно оценивают требуемый газ, в результате чего газ, возвращаемый EntryPoint, меньше, чем потребляемый газ. отправленным Bundle.Эта проблема должна быть решена на уровне клиента Bundler.
Помимо этого, есть несколько вопросов, которые необходимо решить. Одна из проблем заключается в том, как Bundlers обрабатывают сбои транзакций.
После объединения нескольких UserOperations вместе, Bundlers сначала смоделируют транзакцию, обнаружат, не произойдет ли сбой при выполнении контракта, и рассчитают, превышает ли комиссия за газ, возвращаемая отправителем или казначеем, уплаченную комиссию за газ.
Если это выгодно, Bundler отправляет этот пакет UserOperations как транзакцию на узел блока. Тем не менее, транзакция все еще может завершиться неудачей, в результате чего Бандлер уплатит комиссию за газ, но не получит возмещение за газ от EntryPoint. Например, пользователь может отправлять действия разным сборщикам. Если есть прибыль и симуляция прошла успешно, Bundlers передаст ее в цепочку. В этом случае, если UserOperation отправляется узлу, производящему блок, разными Bundlers одновременно, только одна транзакция будет успешной, что означает, что только один Bundler получит комиссию за газ, возвращенную EntryPoint, а все остальные Bundlers потерпят неудачу. из-за привязки И потерять газ. Хотя можно утверждать, что такое поведение следует рассматривать как злонамеренную атаку, и утверждать, что Bundler может заблокировать адрес отправителя и отклонить любые будущие запросы с этого адреса, это не является разумным решением, поскольку пользователи могут предпринять это действие непреднамеренно. Эта проблема должна быть должным образом решена в коде, возможно, через общедоступный мемпул, который находится в стадии разработки. Кроме того, Bundlers могут понести убытки из-за внезапных колебаний газа, даже если транзакция успешно отправлена, а результаты моделирования показывают, что есть место для прибыли.
Другой проблемой является максимальная извлекаемая ценность (MEV), которую можно получить от АА. В контексте Ethereum MEV обычно относится к стоимости, которую майнеры или другие обработчики транзакций извлекают, манипулируя порядком транзакций в блоке или вставляя свои собственные транзакции в блок. Можно заметить, что логика MEV применима и к AA. Это связано с тем, что в AA упаковщики могут свободно секвенировать UserOps, что дает им возможность приобретать MEV. Однако то, сможет ли Bundler извлекать MEV, зависит от того, может ли быть объединено достаточно пользовательских операций. Сейчас весь рынок АА пока находится в зачаточном состоянии, поэтому Bundler MEV тоже можно считать в зачаточном состоянии. Видно, что MEV AA может развиваться в двух направлениях: одно похоже на основную сеть Ethereum, с участием таких участников, как Flashbots, Ultra Sound и BloXroute; другое направление — формирование консенсуса Bundler для реализации справедливой сортировки. А последнее полностью исключило бы возможность извлечения МЭВ в АА.
будущее развитие
публичный мемпул
Хотя экосистема AA уже работает, предстоит еще много работы по развитию. Глядя на всю экосистему АА, самая большая недостающая часть сейчас — это публичный мемпул. Команда Etherspot, разработчики клиента Skandha Bundler, в настоящее время разрабатывают p2p-сеть с общедоступным мемпулом. Ожидается, что p2p-сеть публичных мемпулов будет запущена в августе этого года.
Алгоритм связки
Попутно Ethereum Foundation профинансировал несколько выдающихся команд разработчиков AA. На данный момент разработано и доступно несколько клиентов Bundler. Среди них есть очень зрелые. Это Candide (Voltaire Bundler, написанный на Python), Pimlico (Alto Bundler, написанный на Type), Etherspot (Skandha Bundler, написанный на Type), Stackup (Stackup-Bundler, написанный на Go) и т. д.
Здесь возникает вопрос стратегии упаковки. В настоящее время из-за небольшого количества пользовательских операций Bundler могут использовать простую логику упаковки, такую как фиксированный интервал времени или определенное количество пользовательских операций в каждом Bundle. Однако по мере увеличения количества пользовательских операций, особенно после введения общедоступного мемпула, стратегия выбора и упаковки пользовательских операций становится более сложной. Причина проста: в экосистеме АА нет механизма, аналогичного консенсусному протоколу блокчейна, а группа Bundler превратилась в темный лес: каждый Bundler расставляет приоритеты в задачах в соответствии со своими интересами и конкурирует друг с другом. В отличие от публичных мемпулов, приватные мемпулы могут появиться раньше. Поскольку упаковка UserOperations из общедоступного мемпула невыгодна, по-прежнему можно упаковать UserOperations в приватный мемпул. В этом случае упаковщик более конкурентоспособен, чем другие упаковщики.
Кроме того, с постепенной популяризацией публичного мемпула пользовательские операции в нем имеют различные характеристики, такие как разные ожидания прибыли от газа и сложность выполнения в сети. Сборщики будут проводить моделирование вне сети, чтобы оценить прибыльность различных комбинаций пользовательских операций, чтобы установить свои соответствующие стратегии объединения. Упаковка большего количества UserOperations может принести более высокую прибыль, но также увеличивает риск сбоев проверки. Даже если проверка пройдена, риск сбоя исполнения в цепочке все равно существует. Напротив, менее упакованные UserOperations делают противоположное. Бандлерам необходимо установить свои собственные параметры газа транзакции, которые повлияют на приоритет производителей блоков для выполнения этой транзакции. При различных расчетных ценах на газ и условиях волатильности газа у Бандлеров могут быть разные стратегии упаковки. В то же время также необходимо учитывать стоимость локальных аппаратных вычислительных ресурсов и ресурсов узлов блокчейна для этих проверок и расчетов политик. Кроме того, сборщики также должны усердно работать, чтобы предоставить пользователям хороший пользовательский опыт и убедиться, что пользователи не сталкиваются с чрезмерными задержками после отправки UserOperations.
Хотя пути решения этих задач пока неясны, можно с уверенностью сказать, что развитие индустрии АА и совместные усилия разработчиков в конечном итоге решат эти проблемы. Как строитель инфраструктуры, BlockPI надеется сыграть роль в решении проблем в развитии индустрии AA, будь то в качестве разработчика или предоставления инфраструктуры, дружественной к AA, для других разработчиков.
Инфраструктура должна адаптироваться к AA
AA абстрагирует различные роли, участвующие в транзакциях в сети, включая отправителя, сборщиков, плательщиков газа, контрактных кошельков и подписантов, чтобы пользователи имели более высокую степень свободы при использовании блокчейна. В то же время поставщики инфраструктуры могут самостоятельно развертывать эти услуги в соответствии со своим мнением о рынке.
Чтобы адаптироваться к широкомасштабному внедрению AA, поставщикам инфраструктуры сначала необходимо предоставить как минимум две основные услуги: услугу Bundler и услугу Paymaster.
В службах Bundler поставщикам инфраструктуры может потребоваться разработать частные мемпулы с Bundlers, чтобы обеспечить хорошее взаимодействие с пользователем. В частности, поставщикам инфраструктуры необходимо интегрировать несколько клиентов Bundler, чтобы обеспечить стабильность услуг Bundler. Эти клиенты Bundler в настоящее время предоставляют пользователям несколько стандартных методов JSON RPC, предоставляемых основной группой разработчиков ERC-4337. Ожидается, что в будущем пользователям будет доступно больше методов RPC. Поставщики инфраструктурных услуг должны своевременно обновлять поддержку этих методов в ходе этого процесса.
Кроме того, очень важно оптимизировать API-интерфейс Bundler и клиентский RPC исходного узла. Текущие клиенты узлов не оптимизированы для AA. Некоторые методы Bundler API требуют, чтобы узел предоставил индекс данных для AA. Например, когда текущий клиент ищет UserOperation по хешу, ему необходимо просмотреть журналы контрактов EntryPoint во всех блоках. Если нет индекса данных, потребление аппаратных ресурсов для этого одного запроса будет довольно большим, и время возврата запроса также станет очень большим.
Кроме того, чтобы предоставить пользователям безгазовый пользовательский интерфейс и разнообразные услуги, поставщики инфраструктуры должны сотрудничать с различными поставщиками услуг Paymaster для интеграции различных услуг Paymaster. В то же время, в соответствии с рыночным спросом, поставщики инфраструктуры также могут разрабатывать более удобные интегрированные решения на основе существующих услуг Paymaster. Другие сервисы, такие как агрегированные подписи, фабрики кошельков и т. д., также являются потенциальными направлениями будущего развития и интеграции инфраструктуры.
Короче говоря, чтобы адаптироваться к крупномасштабному применению AA, поставщикам инфраструктуры необходимо постоянно улучшать и расширять свои услуги. Это включает в себя оптимизацию услуг Bundler, сотрудничество с различными поставщиками услуг Paymaster, интеграцию различных интерфейсов API и разработку других потенциальных услуг. Поскольку индустрия AA продолжает развиваться, эти усилия помогут обеспечить более эффективную, безопасную и удобную работу с блокчейном.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Как инфраструктура поддерживает миллиарды пользователей за счет абстракции учетных записей
Будь то бычий рынок или медвежий рынок, экосистема Ethereum постоянно развивается и самооптимизируется. Среди них абстракция учетных записей (AA) добилась значительного прогресса в последние годы и проникла во все части экосистемы Ethereum, включая приложения, инфраструктуру, пользователей и разработчиков. Мы можем предвидеть, что широкомасштабное внедрение AA снизит порог использования блокчейна в целом и представит пользовательский опыт web2 в индустрии web3.
В этой статье команда BlockPI углубится в свое понимание AA и поделится своим мнением с точки зрения поставщика инфраструктурных услуг.
EOA и контрактный кошелек
Концепция AA проистекает из ограничений счетов EOA. Учетная запись EOA (внешняя учетная запись) — это учетная запись пользователя в Ethereum, представленная открытым ключом (адресом блокчейна) и доступная через закрытый ключ. Это основной компонент экосистемы Ethereum, позволяющий пользователям переводить деньги в блокчейн или взаимодействовать со смарт-контрактами. Однако для многих людей использование EOA само по себе может быть сложной задачей. Более того, текущая учетная запись EOA по-прежнему имеет некоторые неудобства в использовании, что сказывается на пользовательском опыте.
Во-первых, это плата за газ. Каждая транзакция будет стоить пользователю значительную сумму ETH в качестве платы за газ (взяв в качестве примера цену газа в 25 Gwei, плата за газ для простого перевода ETH составляет около 0,5 долларов США, и это будет дороже для взаимодействия по контракту. или когда цена на газ выше). Это делает небольшие транзакции очень дорогими, особенно в периоды сильной перегрузки сети. Кроме того, газ можно оплачивать только ETH, а это означает, что пользователи должны хранить ETH в своих кошельках, что представляет собой высокий барьер для входа для многих пользователей.
Во-вторых, для некоторых сложных операций, которые хотят реализовать пользователи, EOA должен полагаться на другие смарт-контракты. Например, если пользователь хочет установить периодическую передачу по времени, ему необходимо перевести ETH в смарт-контракт с помощью этой функции для выполнения этой операции.
Третья проблема с EOA — алгоритм шифрования с фиксированной подписью. Сеть Ethereum использует алгоритм цифровой подписи под названием secp256k1 для обеспечения подлинности и безопасности транзакций. Этот алгоритм жестко запрограммирован в системе, и пользователи не могут использовать другие алгоритмы шифрования.
В дополнение к вышеупомянутым трем проблемам, связывающая связь между открытым ключом EOA и закрытым ключом также является проблемой. Закрытый ключ — это единственный способ для пользователей получить доступ к EOA. Если закрытый ключ утерян, он не будет восстановлен. Это также означает, что все активы в рамках EOA, связанные с ним, будут невозвратными.
В то же время ЭОА имеет и ограничения при выполнении некоторых линейных задач. Например, если пользователь хочет утвердить, поменять местами и не утвердить токены за одну операцию, необходимо выполнить три отдельные транзакции, что неэффективно и занимает много времени.
Хорошая новость заключается в том, что контрактные кошельки могут решить все вышеперечисленные проблемы. Контрактный кошелек — это, по сути, особый тип учетной записи смарт-контракта, реализующий AA, который можно использовать в качестве кошелька пользователя в Ethereum. И это может предоставить пользователям более гибкий и персонализированный способ управления средствами. Пока это логика, которая может быть реализована смарт-контрактом Ethereum, контрактный кошелек может реализовать и предоставить соответствующие функции.
В частности, несколько операций с контрактным кошельком могут быть объединены в транзакцию по цепочке, и эти операции могут разделить стоимость газа этой транзакции. Если третья сторона готова оплатить комиссию за газ, нет необходимости платить газ за пользователей, использующих контрактный кошелек. Контрактные кошельки также могут выполнять несколько линейных задач одновременно. Кроме того, контрактный кошелек также поддерживает алгоритм шифрования пользовательских подписей, устанавливает функцию восстановления кошелька и так далее.
Поскольку обсуждение преимуществ контрактных кошельков продолжается, сообщество Ethereum фактически провело долгосрочное исследование контрактных кошельков. Хотя многие EIP исследовали проблемы, связанные с абстрагированием учетной записи, по состоянию на 2021 год единый стандарт не установлен. Ниже приведены несколько репрезентативных EIP.
ЭИП-86
Первоначально предложено Виталиком Бутериным в 2017 году. Схема реализует ряд изменений с общей целью «абстрагирования» проверки подписи и проверки одноразового номера, тем самым позволяя пользователям создавать «контракты учетных записей», которые выполняют произвольную проверку подписи/одноразового номера.
ЭИП-2938
Представлен в 2020 году. Название этого EIP — «Абстракция учетной записи». Концепция AA хорошо описана в этом EIP. Он вводит новый тип транзакции, транзакцию AA. Транзакция инициируется адресом точки входа (EntryPoint address) и обращается к кошельку контракта AA. EIP-2938 предоставляет унифицированную спецификацию и официально вводит абстракцию учетной записи AA в консенсус Ethereum. В частности, он вводит два новых кода операции, три глобальные переменные и другую структуру полезной нагрузки для консенсуса Ethereum.
ЭИП-3074
Представлен в 2020 году. В этом EIP представлены две инструкции EVM: AUTH и AUTHCALL. AUTH устанавливает переменную среды в соответствии с полномочиями подписи ECDSA. AUTHCALL отправляет вызов как авторизованная учетная запись. Это позволяет смарт-контрактам отправлять транзакции от имени EOA. Но это все еще не идеальное решение для АА. В процессе транзакции авторизации EIP-3074 имеет определенные ограничения на передачу исходного значения. И если пользователь потеряет доступ к EOA, у него все равно не будет возможности восстановить свои активы. В случае утечки закрытого ключа пользователю необходимо перевести все активы в новую учетную запись.
Ни одно из вышеперечисленных предложений не было официально включено в протокол Ethereum из-за необходимости изменений на уровне консенсуса или из-за того, что предложения не были достаточно исчерпывающими. Поэтому сообщество Ethereum продолжило изучать, как внедрить AA в протокол Ethereum без изменения консенсуса, и, наконец, предложило EIP4337.
ERC-4337
EIP-4337 был первоначально предложен в сентябре 2021 года и авторизован как ERC-4337 в марте 2023 года. Среди его авторов Виталик Бутерин, Йоав Вайс, Кристоф Газсо, Намра Патель, Дрор Тирош, Шахаф Наксон и Тьяден Хесс.
EIP-4337 — это прорывное предложение, которое может ввести AA без изменения основного протокола Ethereum. EIP-4337 в конечном итоге стал стандартом ERC-4337, который разработчики могут использовать для реализации своих собственных кошельков смарт-контрактов. В то же время стандарт также вводит некоторую дополнительную инфраструктуру, включая «связчики» и «мемпул UserOperation». Таким образом, он фактически копирует мемпул Ethereum с аналогичными функциями на верхнем уровне системы блокчейна. То, что отправляет пользователь, больше не является отдельной транзакцией, а является UserOperation. Несколько пользовательских операций могут быть объединены в одну транзакцию и отправлены в Ethereum.
Ниже приводится подробное техническое объяснение ERC-4337 в Ethereum [официальная документация](, а также некоторые полезные комментарии.
Ключевые роли и определения ERC-4337
UserOperation — описывает структуру транзакции, отправляемой от имени пользователя. Чтобы избежать путаницы, она не называется «транзакция» и будет отправлена в Bundler для упаковки в Bundle с другими UserOperations. Затем Bundle отправляется по цепочке как одна транзакция.
Sender — учетная запись контракта, которая отправляет UserOperation. Контракт кошелька должен соответствовать стандарту ERC-4337 для настройки интерфейса IAccount.
EntryPoint — глобальный одноэлементный контракт, который выполняет пакет UserOperations. Белые списки бандлеров/клиентов поддерживают EntryPoints. Контракт проверяется и утверждается для развертывания командой Infinitism, которая отвечает за обработку всех пользовательских операций и подключение контрактов с другими ролями, включая Wallet Factory, Aggregator и Paymaster. Все контракты находятся по одному и тому же адресу в цепочке, совместимой с EVM.
Bundler — узел, который упаковывает несколько UserOperations из мемпула и создает транзакцию EntryPoint.handleOps() (текущий производитель блоков). Служба Bundler может работать независимо от узлов блокчейна и отправлять упакованные пользовательские операции через RPC.
Агрегатор — вспомогательный контракт, которому учетные записи доверяют проверку агрегированных подписей. Белый список Bundlers/Clients поддерживает агрегаторы подписей. Агрегатор должен следовать стандарту ERC-4337 для настройки интерфейса IAggregator.
Paymaster — смарт-контракт, который может оплачивать газ от вашего имени. Если он вносит достаточно ETH в контракт EntryPoint, он может оплатить комиссию за газ для UserOperation для отправителя, эффективно реализуя абстракцию газа. Paymaster должен следовать стандарту ERC-4337 для настройки интерфейса Paymaster. Казначей может заключить договор с Отправителем. Например, отправитель платит Paymaster в долларах США, а Paymaster использует ETH для оплаты газа за отправляемые им операции пользователя. Фактически, Paymaster может выбрать поддержку любого токена, включая токены ERC-20 и даже токены других цепей.
Wallet Factory — смарт-контракт, который может создавать контрактные кошельки для пользователей ERC-4337. Развертывание Wallet Factory не требует разрешения. Как сетевой смарт-контракт, его код открыт для публики, и любой может просмотреть его. Широко используемая фабрика кошельков должна быть полностью проверена профессионалами.
На приведенной ниже диаграмме показано, как контракт EntryPoint взаимодействует с другими участниками.
Сборщики вызывают функцию handleOps контракта EntryPoint, которая принимает UserOperation в качестве входных данных.
handleOps проверит UserOperation в цепочке, проверит, подписана ли она указанным адресом кошелька смарт-контракта, и подтвердит, достаточно ли газа в кошельке для компенсации Bundler.
Если проверка пройдена, handleOps выполнит функцию кошелька смарт-контракта в соответствии с функцией и входными параметрами, определенными в данных вызова UserOperation.
С другой стороны, когда Bundler использует EOA для запуска функции handleOps, взимается плата за газ. Кошелек со смарт-контрактом может оплачивать сборы за газ для Bundlers со своего собственного баланса счета или запрашивать оплату у контракта Paymaster. UserOperations не может пройти этап проверки вне сети без достаточного количества газа, то есть происходит сбой до выполнения транзакции в цепочке. Даже если газа достаточно, UserOperations все равно может выйти из строя из-за таких причин, как ошибки времени выполнения во время выполнения. Для UserOperation, независимо от того, было ли выполнение контракта успешным или нет, контракт EntryPoint будет платить комиссию за газ Bundler, который запускает функцию handleOps.
(Выдержка из официальной документации:
После вступления в силу ERC-4337 пользователи теперь могут инициировать транзакции в блокчейне двумя способами. Один из них — традиционный, то есть EOA напрямую инициирует транзакцию. Другой — использовать стандарт ERC-4337 для инициации UserOperation через Bundler, а затем Bundler упакует ее с другими UserOperations и отправит в цепочку. Блок-схема ниже иллюстрирует разницу между обычной транзакцией отправки EOA и отправкой UserOperation контрактного кошелька ERC-4337.
Дорога заасфальтирована, но пешеходов пока мало
ERC-4337 предоставляет пользователям и разработчикам мощную основу для использования и создания AA на Ethereum. Хотя эта структура является важным достижением, все еще существуют некоторые проблемы и неопределенности, которые необходимо рассмотреть и решить.
Принятие АА все еще находится в зачаточном состоянии. Согласно аналитической панели Dune ERC-4337 (*[ERC-4337 Account Abstraction](от @niftytable), в цепочке было выполнено только 65 000+ пользовательских операций, 90 % из которых поступило от Polygon. Таким образом, количество выполняемых в настоящее время пользовательских операций по-прежнему очень мал, и большинство из них Часть из них является тестом разработчиков, и лишь небольшая часть исходит от реальных пользователей.Мы заметили, что продукты, в которые интегрировано AA, все еще находятся на ранней стадии.В настоящее время мы можем наблюдать, что Бандлеры в целом все еще находятся в состоянии убытков, а текущие потери составляют более 700 MATIC. Это в основном вызвано тем, что некоторые бандлеры на полигоне неправильно оценивают требуемый газ, в результате чего газ, возвращаемый EntryPoint, меньше, чем потребляемый газ. отправленным Bundle.Эта проблема должна быть решена на уровне клиента Bundler.
Помимо этого, есть несколько вопросов, которые необходимо решить. Одна из проблем заключается в том, как Bundlers обрабатывают сбои транзакций.
После объединения нескольких UserOperations вместе, Bundlers сначала смоделируют транзакцию, обнаружат, не произойдет ли сбой при выполнении контракта, и рассчитают, превышает ли комиссия за газ, возвращаемая отправителем или казначеем, уплаченную комиссию за газ.
Если это выгодно, Bundler отправляет этот пакет UserOperations как транзакцию на узел блока. Тем не менее, транзакция все еще может завершиться неудачей, в результате чего Бандлер уплатит комиссию за газ, но не получит возмещение за газ от EntryPoint. Например, пользователь может отправлять действия разным сборщикам. Если есть прибыль и симуляция прошла успешно, Bundlers передаст ее в цепочку. В этом случае, если UserOperation отправляется узлу, производящему блок, разными Bundlers одновременно, только одна транзакция будет успешной, что означает, что только один Bundler получит комиссию за газ, возвращенную EntryPoint, а все остальные Bundlers потерпят неудачу. из-за привязки И потерять газ. Хотя можно утверждать, что такое поведение следует рассматривать как злонамеренную атаку, и утверждать, что Bundler может заблокировать адрес отправителя и отклонить любые будущие запросы с этого адреса, это не является разумным решением, поскольку пользователи могут предпринять это действие непреднамеренно. Эта проблема должна быть должным образом решена в коде, возможно, через общедоступный мемпул, который находится в стадии разработки. Кроме того, Bundlers могут понести убытки из-за внезапных колебаний газа, даже если транзакция успешно отправлена, а результаты моделирования показывают, что есть место для прибыли.
Другой проблемой является максимальная извлекаемая ценность (MEV), которую можно получить от АА. В контексте Ethereum MEV обычно относится к стоимости, которую майнеры или другие обработчики транзакций извлекают, манипулируя порядком транзакций в блоке или вставляя свои собственные транзакции в блок. Можно заметить, что логика MEV применима и к AA. Это связано с тем, что в AA упаковщики могут свободно секвенировать UserOps, что дает им возможность приобретать MEV. Однако то, сможет ли Bundler извлекать MEV, зависит от того, может ли быть объединено достаточно пользовательских операций. Сейчас весь рынок АА пока находится в зачаточном состоянии, поэтому Bundler MEV тоже можно считать в зачаточном состоянии. Видно, что MEV AA может развиваться в двух направлениях: одно похоже на основную сеть Ethereum, с участием таких участников, как Flashbots, Ultra Sound и BloXroute; другое направление — формирование консенсуса Bundler для реализации справедливой сортировки. А последнее полностью исключило бы возможность извлечения МЭВ в АА.
будущее развитие
публичный мемпул
Хотя экосистема AA уже работает, предстоит еще много работы по развитию. Глядя на всю экосистему АА, самая большая недостающая часть сейчас — это публичный мемпул. Команда Etherspot, разработчики клиента Skandha Bundler, в настоящее время разрабатывают p2p-сеть с общедоступным мемпулом. Ожидается, что p2p-сеть публичных мемпулов будет запущена в августе этого года.
Алгоритм связки
Попутно Ethereum Foundation профинансировал несколько выдающихся команд разработчиков AA. На данный момент разработано и доступно несколько клиентов Bundler. Среди них есть очень зрелые. Это Candide (Voltaire Bundler, написанный на Python), Pimlico (Alto Bundler, написанный на Type), Etherspot (Skandha Bundler, написанный на Type), Stackup (Stackup-Bundler, написанный на Go) и т. д.
Здесь возникает вопрос стратегии упаковки. В настоящее время из-за небольшого количества пользовательских операций Bundler могут использовать простую логику упаковки, такую как фиксированный интервал времени или определенное количество пользовательских операций в каждом Bundle. Однако по мере увеличения количества пользовательских операций, особенно после введения общедоступного мемпула, стратегия выбора и упаковки пользовательских операций становится более сложной. Причина проста: в экосистеме АА нет механизма, аналогичного консенсусному протоколу блокчейна, а группа Bundler превратилась в темный лес: каждый Bundler расставляет приоритеты в задачах в соответствии со своими интересами и конкурирует друг с другом. В отличие от публичных мемпулов, приватные мемпулы могут появиться раньше. Поскольку упаковка UserOperations из общедоступного мемпула невыгодна, по-прежнему можно упаковать UserOperations в приватный мемпул. В этом случае упаковщик более конкурентоспособен, чем другие упаковщики.
Кроме того, с постепенной популяризацией публичного мемпула пользовательские операции в нем имеют различные характеристики, такие как разные ожидания прибыли от газа и сложность выполнения в сети. Сборщики будут проводить моделирование вне сети, чтобы оценить прибыльность различных комбинаций пользовательских операций, чтобы установить свои соответствующие стратегии объединения. Упаковка большего количества UserOperations может принести более высокую прибыль, но также увеличивает риск сбоев проверки. Даже если проверка пройдена, риск сбоя исполнения в цепочке все равно существует. Напротив, менее упакованные UserOperations делают противоположное. Бандлерам необходимо установить свои собственные параметры газа транзакции, которые повлияют на приоритет производителей блоков для выполнения этой транзакции. При различных расчетных ценах на газ и условиях волатильности газа у Бандлеров могут быть разные стратегии упаковки. В то же время также необходимо учитывать стоимость локальных аппаратных вычислительных ресурсов и ресурсов узлов блокчейна для этих проверок и расчетов политик. Кроме того, сборщики также должны усердно работать, чтобы предоставить пользователям хороший пользовательский опыт и убедиться, что пользователи не сталкиваются с чрезмерными задержками после отправки UserOperations.
Хотя пути решения этих задач пока неясны, можно с уверенностью сказать, что развитие индустрии АА и совместные усилия разработчиков в конечном итоге решат эти проблемы. Как строитель инфраструктуры, BlockPI надеется сыграть роль в решении проблем в развитии индустрии AA, будь то в качестве разработчика или предоставления инфраструктуры, дружественной к AA, для других разработчиков.
Инфраструктура должна адаптироваться к AA
AA абстрагирует различные роли, участвующие в транзакциях в сети, включая отправителя, сборщиков, плательщиков газа, контрактных кошельков и подписантов, чтобы пользователи имели более высокую степень свободы при использовании блокчейна. В то же время поставщики инфраструктуры могут самостоятельно развертывать эти услуги в соответствии со своим мнением о рынке.
Чтобы адаптироваться к широкомасштабному внедрению AA, поставщикам инфраструктуры сначала необходимо предоставить как минимум две основные услуги: услугу Bundler и услугу Paymaster.
В службах Bundler поставщикам инфраструктуры может потребоваться разработать частные мемпулы с Bundlers, чтобы обеспечить хорошее взаимодействие с пользователем. В частности, поставщикам инфраструктуры необходимо интегрировать несколько клиентов Bundler, чтобы обеспечить стабильность услуг Bundler. Эти клиенты Bundler в настоящее время предоставляют пользователям несколько стандартных методов JSON RPC, предоставляемых основной группой разработчиков ERC-4337. Ожидается, что в будущем пользователям будет доступно больше методов RPC. Поставщики инфраструктурных услуг должны своевременно обновлять поддержку этих методов в ходе этого процесса.
Кроме того, очень важно оптимизировать API-интерфейс Bundler и клиентский RPC исходного узла. Текущие клиенты узлов не оптимизированы для AA. Некоторые методы Bundler API требуют, чтобы узел предоставил индекс данных для AA. Например, когда текущий клиент ищет UserOperation по хешу, ему необходимо просмотреть журналы контрактов EntryPoint во всех блоках. Если нет индекса данных, потребление аппаратных ресурсов для этого одного запроса будет довольно большим, и время возврата запроса также станет очень большим.
Кроме того, чтобы предоставить пользователям безгазовый пользовательский интерфейс и разнообразные услуги, поставщики инфраструктуры должны сотрудничать с различными поставщиками услуг Paymaster для интеграции различных услуг Paymaster. В то же время, в соответствии с рыночным спросом, поставщики инфраструктуры также могут разрабатывать более удобные интегрированные решения на основе существующих услуг Paymaster. Другие сервисы, такие как агрегированные подписи, фабрики кошельков и т. д., также являются потенциальными направлениями будущего развития и интеграции инфраструктуры.
Короче говоря, чтобы адаптироваться к крупномасштабному применению AA, поставщикам инфраструктуры необходимо постоянно улучшать и расширять свои услуги. Это включает в себя оптимизацию услуг Bundler, сотрудничество с различными поставщиками услуг Paymaster, интеграцию различных интерфейсов API и разработку других потенциальных услуг. Поскольку индустрия AA продолжает развиваться, эти усилия помогут обеспечить более эффективную, безопасную и удобную работу с блокчейном.