Будь то бычий рынок или медвежий рынок, экосистема Ethereum постоянно развивается и самооптимизируется. Среди них абстракция учетных записей (AA) добилась значительного прогресса в последние годы и проникла во все части экосистемы Ethereum, включая приложения, инфраструктуру, пользователей и разработчиков. Мы можем предвидеть, что широкомасштабное внедрение AA снизит порог использования блокчейна в целом и представит пользовательский опыт web2 в индустрии web3.
Чтобы воспользоваться возможностями потенциально многомиллиардного рынка AA, BlockPI планирует интегрировать AA в свои инфраструктурные услуги. Благодаря интеграции и инновациям в области AA BlockPI стремится предоставить пользователям AA более удобный и эффективный способ взаимодействия с учетными записями контрактного кошелька блокчейна и надеется стать лидером в этой отрасли.
В этой статье команда 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, связанные с ним, будут невозвратными.
В то же время ЭОА имеет и ограничения при выполнении некоторых линейных задач. Например, если пользователь хочет утвердить (утвердить), обменять (обменять) и не утвердить токены (unapprove token) в одной операции, необходимо выполнить три отдельные транзакции, что неэффективно и занимает много времени.
Хорошая новость заключается в том, что контрактные кошельки могут решить все вышеперечисленные проблемы. Контрактный кошелек — это, по сути, особый тип учетной записи смарт-контракта, реализующий 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. Эти UserOperations могут быть объединены в одну транзакцию и отправлены в Ethereum.
Ниже приводится подробное техническое объяснение ERC-4337 в Ethereum [официальная документация] с некоторыми полезными комментариями.
Ключевые роли ERC-4337 и их определения
UserOperation — описывает структуру транзакции, отправляемой от имени пользователя. Чтобы избежать путаницы, она не называется «транзакция» и будет отправлена в Bundler для упаковки вместе с другими пользовательскими операциями в виде Bundle. Затем Bundle отправляется по цепочке как одна транзакция.
Отправитель — учетная запись контракта, которая отправляет UserOperation. Контракт кошелька должен соответствовать стандарту ERC-4337 для настройки интерфейса IAccount.
EntryPoint - глобальный одноэлементный контракт, который выполняет пакет UserOperations. Белые списки Bundlers/Clients поддерживают EntryPoints. Контракт проверяется и утверждается для развертывания командой Infinitism, которая отвечает за обработку всех пользовательских операций и подключение контрактов с другими ролями, включая Wallet Factory, Aggregator и Paymaster. Все контракты находятся по одному и тому же адресу в цепочке, совместимой с EVM.
Bundler — узел, который упаковывает несколько пользовательских операций из мемпула и создает транзакцию EntryPoint.handleOps() (текущий узел-производитель блоков). Служба Bundler может работать независимо от узлов блокчейна и отправлять упакованные пользовательские операции через RPC.
Агрегатор — вспомогательный контракт, которому учетные записи доверяют проверку агрегированных подписей. Белые списки Bundlers/Clients поддерживают агрегаторы подписей. Агрегаторы должны настроить интерфейс IAggregator в соответствии со стандартом ERC-4337.
Paymaster — смарт-контракт, который может оплачивать газ от вашего имени. Если он вносит достаточное количество ETH в контракт EntryPoint, он может заплатить отправителю по смарт-контракту за комиссию за газ UserOperation, эффективно реализуя абстракцию газа. Paymaster должен следовать стандарту ERC-4337 для настройки интерфейса Paymaster. Казначей может заключить соглашение с Отправителем. Например, отправитель платит Paymaster в долларах США, а Paymaster использует ETH для оплаты газа за отправляемые им операции пользователя. Фактически, Paymaster может выбрать поддержку любого
Токен
, включая ERC-20
Токен
даже другие цепи
Токен
。
Wallet Factory — смарт-контракт, который может создавать контрактные кошельки для пользователей ERC-4337. Развертывание Wallet Factory не требует лицензии. Код смарт-контракта в сети открыт для публики, и каждый может его просмотреть. Широко используемый Wallet Factory должен быть полностью проверен профессионалами.
На приведенной ниже диаграмме показано, как контракт EntryPoint взаимодействует с другими участниками.
Сборщики вызывают функцию handleOps контракта EntryPoint, которая принимает UserOperation в качестве входных данных.
handleOps проверит UserOperation в цепочке, проверит, подписана ли она указанным адресом кошелька смарт-контракта, и подтвердит, достаточно ли газа в кошельке для компенсации Bundler.
Если проверка пройдена, handleOps выполнит функцию кошелька смарт-контракта в соответствии с функцией и входными параметрами, определенными в данных вызова UserOperation.
С другой стороны, когда Bundler использует EOA для запуска функции handleOps, взимается плата за газ. Кошелек смарт-контракта может оплачивать комиссию Bundlers Gas со своего баланса счета или запрашивать оплату у контракта 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], в цепочке было выполнено только 65 000+ пользовательских операций, 90% из которых поступило от Polygon. Поэтому количество выполняемых в настоящее время UserOperations все еще очень мало, большая часть из которых — тесты разработчиков, и лишь малая часть исходит от реальных пользователей. Мы отмечаем, что продукты с интегрированным AA все еще находятся на ранних стадиях. В настоящее время мы можем наблюдать, что Bundlers в целом все еще находится в состоянии убытка, и текущий убыток составляет около более 700 MATIC. В основном это вызвано тем, что некоторые Bundlers на Polygon неправильно оценивают требуемый газ, в результате чего Gas, возвращаемый EntryPoint, оказывается меньше, чем газ, потребляемый отправленным Bundle. Эта проблема должна быть решена на уровне клиента Bundler.
Помимо этого, есть несколько вопросов, которые необходимо решить. Одна из таких проблем заключается в том, как Bundlers обрабатывают сбои транзакций.
После объединения нескольких UserOperations вместе, Bundlers сначала смоделируют транзакцию, обнаружат, не произойдет ли сбой при выполнении контракта, и рассчитают, превышает ли комиссия за газ, возвращаемая отправителем или казначеем, уплаченную комиссию за газ.
Если это выгодно, Bundler отправляет этот пакет UserOperations на блок-узел как транзакцию. Тем не менее, транзакция все еще может завершиться неудачей, в результате чего Бандлер уплатит комиссию за газ, но не получит возмещение за газ от EntryPoint. Например, пользователь может отправлять действия разным сборщикам. Если есть место для прибыли и симуляция прошла успешно, Bundlers передают ее в цепочку. В этом случае, если UserOperation отправляется на блок-узел разными Bundlers одновременно, только одна транзакция будет успешной, а это означает, что только один Bundler получит комиссию за газ, возвращенную EntryPoint, а все остальные Bundler потерпят неудачу из-за к цепочке И потерять газ. Хотя можно утверждать, что такое поведение следует рассматривать как злонамеренную атаку, и утверждать, что Bundler может заблокировать адрес отправителя и отклонить любые будущие запросы с этого адреса, это неразумное решение, поскольку пользователи могут предпринять это действие непреднамеренно. Эта проблема должна быть должным образом решена в коде, возможно, через общедоступную сеть мемпула, которая находится в стадии разработки. Кроме того, Bundlers могут понести убытки из-за внезапных колебаний газа, даже если транзакция успешно отправлена, а результаты моделирования показывают, что есть место для прибыли.
Другой проблемой является максимальная извлекаемая ценность (MEV), которую можно получить от АА. В контексте Ethereum MEV обычно относится к стоимости, которую майнеры или другие обработчики транзакций извлекают, манипулируя порядком транзакций в блоке или вставляя свои собственные транзакции в блок. Можно заметить, что логика MEV применима и к AA. Это связано с тем, что в AA Bundlers могут свободно заказывать 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 с меньшим количеством пакетов — это наоборот.
Бандлеры должны установить свои собственные параметры газа транзакции, которые повлияют на приоритет производителей блоков для выполнения этой транзакции. При различных расчетных ценах на газ и условиях волатильности газа у Бандлеров могут быть разные стратегии упаковки. В то же время также необходимо учитывать стоимость локальных аппаратных вычислительных ресурсов и ресурсов узлов блокчейна для этих проверок и расчетов политик. Кроме того, сборщики также должны обеспечить хороший пользовательский интерфейс для пользователей и убедиться, что пользователи не сталкиваются с чрезмерными задержками после отправки 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 продолжает развиваться, эти усилия помогут обеспечить более эффективную, безопасную и удобную работу с блокчейном.
В настоящее время BlockPI усердно работает над достижением вышеуказанных целей. Мало того, мы связались почти со всеми клиентами Bundler и поставщиками услуг Paymaster в сообществе и будем интегрировать AA в сеть BlockPI в качестве нашей главной задачи разработки. В то же время мы также провели углубленное общение с разработчиками кошелька AA, чтобы понять потребности пользователей. Мы искренне приветствуем всех бандлеров, казначеев и кошельков для общения и сотрудничества с нами.
Цель BlockPI — создавать и развивать экосистему АА вместе с сообществом и делать все возможное для продвижения прогресса и процветания экосистемы АА. Мы надеемся, что благодаря сотрудничеству с сообществом мы внесем свой вклад во всю индустрию АА в качестве лидера отрасли и поддержим ее последующий процесс разработки, чтобы пользователи Web2 могли беспрепятственно использовать технологию блокчейна.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Как инфраструктура поддерживает миллиарды пользователей за счет абстракции учетных записей?
Будь то бычий рынок или медвежий рынок, экосистема Ethereum постоянно развивается и самооптимизируется. Среди них абстракция учетных записей (AA) добилась значительного прогресса в последние годы и проникла во все части экосистемы Ethereum, включая приложения, инфраструктуру, пользователей и разработчиков. Мы можем предвидеть, что широкомасштабное внедрение AA снизит порог использования блокчейна в целом и представит пользовательский опыт web2 в индустрии web3.
Чтобы воспользоваться возможностями потенциально многомиллиардного рынка AA, BlockPI планирует интегрировать AA в свои инфраструктурные услуги. Благодаря интеграции и инновациям в области AA BlockPI стремится предоставить пользователям AA более удобный и эффективный способ взаимодействия с учетными записями контрактного кошелька блокчейна и надеется стать лидером в этой отрасли.
В этой статье команда 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, связанные с ним, будут невозвратными.
В то же время ЭОА имеет и ограничения при выполнении некоторых линейных задач. Например, если пользователь хочет утвердить (утвердить), обменять (обменять) и не утвердить токены (unapprove token) в одной операции, необходимо выполнить три отдельные транзакции, что неэффективно и занимает много времени.
Хорошая новость заключается в том, что контрактные кошельки могут решить все вышеперечисленные проблемы. Контрактный кошелек — это, по сути, особый тип учетной записи смарт-контракта, реализующий 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. Эти UserOperations могут быть объединены в одну транзакцию и отправлены в Ethereum.
Ниже приводится подробное техническое объяснение ERC-4337 в Ethereum [официальная документация] с некоторыми полезными комментариями.
Ключевые роли ERC-4337 и их определения
UserOperation — описывает структуру транзакции, отправляемой от имени пользователя. Чтобы избежать путаницы, она не называется «транзакция» и будет отправлена в Bundler для упаковки вместе с другими пользовательскими операциями в виде Bundle. Затем Bundle отправляется по цепочке как одна транзакция.
Отправитель — учетная запись контракта, которая отправляет UserOperation. Контракт кошелька должен соответствовать стандарту ERC-4337 для настройки интерфейса IAccount.
EntryPoint - глобальный одноэлементный контракт, который выполняет пакет UserOperations. Белые списки Bundlers/Clients поддерживают EntryPoints. Контракт проверяется и утверждается для развертывания командой Infinitism, которая отвечает за обработку всех пользовательских операций и подключение контрактов с другими ролями, включая Wallet Factory, Aggregator и Paymaster. Все контракты находятся по одному и тому же адресу в цепочке, совместимой с EVM.
Bundler — узел, который упаковывает несколько пользовательских операций из мемпула и создает транзакцию EntryPoint.handleOps() (текущий узел-производитель блоков). Служба Bundler может работать независимо от узлов блокчейна и отправлять упакованные пользовательские операции через RPC.
Агрегатор — вспомогательный контракт, которому учетные записи доверяют проверку агрегированных подписей. Белые списки Bundlers/Clients поддерживают агрегаторы подписей. Агрегаторы должны настроить интерфейс IAggregator в соответствии со стандартом ERC-4337.
Paymaster — смарт-контракт, который может оплачивать газ от вашего имени. Если он вносит достаточное количество ETH в контракт EntryPoint, он может заплатить отправителю по смарт-контракту за комиссию за газ UserOperation, эффективно реализуя абстракцию газа. Paymaster должен следовать стандарту ERC-4337 для настройки интерфейса Paymaster. Казначей может заключить соглашение с Отправителем. Например, отправитель платит Paymaster в долларах США, а Paymaster использует ETH для оплаты газа за отправляемые им операции пользователя. Фактически, Paymaster может выбрать поддержку любого
Токен
, включая ERC-20
Токен
даже другие цепи
Токен
。
На приведенной ниже диаграмме показано, как контракт EntryPoint взаимодействует с другими участниками.
Сборщики вызывают функцию handleOps контракта EntryPoint, которая принимает UserOperation в качестве входных данных.
handleOps проверит UserOperation в цепочке, проверит, подписана ли она указанным адресом кошелька смарт-контракта, и подтвердит, достаточно ли газа в кошельке для компенсации Bundler.
Если проверка пройдена, handleOps выполнит функцию кошелька смарт-контракта в соответствии с функцией и входными параметрами, определенными в данных вызова UserOperation.
С другой стороны, когда Bundler использует EOA для запуска функции handleOps, взимается плата за газ. Кошелек смарт-контракта может оплачивать комиссию Bundlers Gas со своего баланса счета или запрашивать оплату у контракта 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], в цепочке было выполнено только 65 000+ пользовательских операций, 90% из которых поступило от Polygon. Поэтому количество выполняемых в настоящее время UserOperations все еще очень мало, большая часть из которых — тесты разработчиков, и лишь малая часть исходит от реальных пользователей. Мы отмечаем, что продукты с интегрированным AA все еще находятся на ранних стадиях. В настоящее время мы можем наблюдать, что Bundlers в целом все еще находится в состоянии убытка, и текущий убыток составляет около более 700 MATIC. В основном это вызвано тем, что некоторые Bundlers на Polygon неправильно оценивают требуемый газ, в результате чего Gas, возвращаемый EntryPoint, оказывается меньше, чем газ, потребляемый отправленным Bundle. Эта проблема должна быть решена на уровне клиента Bundler.
Помимо этого, есть несколько вопросов, которые необходимо решить. Одна из таких проблем заключается в том, как Bundlers обрабатывают сбои транзакций.
После объединения нескольких UserOperations вместе, Bundlers сначала смоделируют транзакцию, обнаружат, не произойдет ли сбой при выполнении контракта, и рассчитают, превышает ли комиссия за газ, возвращаемая отправителем или казначеем, уплаченную комиссию за газ.
Если это выгодно, Bundler отправляет этот пакет UserOperations на блок-узел как транзакцию. Тем не менее, транзакция все еще может завершиться неудачей, в результате чего Бандлер уплатит комиссию за газ, но не получит возмещение за газ от EntryPoint. Например, пользователь может отправлять действия разным сборщикам. Если есть место для прибыли и симуляция прошла успешно, Bundlers передают ее в цепочку. В этом случае, если UserOperation отправляется на блок-узел разными Bundlers одновременно, только одна транзакция будет успешной, а это означает, что только один Bundler получит комиссию за газ, возвращенную EntryPoint, а все остальные Bundler потерпят неудачу из-за к цепочке И потерять газ. Хотя можно утверждать, что такое поведение следует рассматривать как злонамеренную атаку, и утверждать, что Bundler может заблокировать адрес отправителя и отклонить любые будущие запросы с этого адреса, это неразумное решение, поскольку пользователи могут предпринять это действие непреднамеренно. Эта проблема должна быть должным образом решена в коде, возможно, через общедоступную сеть мемпула, которая находится в стадии разработки. Кроме того, Bundlers могут понести убытки из-за внезапных колебаний газа, даже если транзакция успешно отправлена, а результаты моделирования показывают, что есть место для прибыли.
Другой проблемой является максимальная извлекаемая ценность (MEV), которую можно получить от АА. В контексте Ethereum MEV обычно относится к стоимости, которую майнеры или другие обработчики транзакций извлекают, манипулируя порядком транзакций в блоке или вставляя свои собственные транзакции в блок. Можно заметить, что логика MEV применима и к AA. Это связано с тем, что в AA Bundlers могут свободно заказывать 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 с меньшим количеством пакетов — это наоборот.
Бандлеры должны установить свои собственные параметры газа транзакции, которые повлияют на приоритет производителей блоков для выполнения этой транзакции. При различных расчетных ценах на газ и условиях волатильности газа у Бандлеров могут быть разные стратегии упаковки. В то же время также необходимо учитывать стоимость локальных аппаратных вычислительных ресурсов и ресурсов узлов блокчейна для этих проверок и расчетов политик. Кроме того, сборщики также должны обеспечить хороший пользовательский интерфейс для пользователей и убедиться, что пользователи не сталкиваются с чрезмерными задержками после отправки 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 продолжает развиваться, эти усилия помогут обеспечить более эффективную, безопасную и удобную работу с блокчейном.
В настоящее время BlockPI усердно работает над достижением вышеуказанных целей. Мало того, мы связались почти со всеми клиентами Bundler и поставщиками услуг Paymaster в сообществе и будем интегрировать AA в сеть BlockPI в качестве нашей главной задачи разработки. В то же время мы также провели углубленное общение с разработчиками кошелька AA, чтобы понять потребности пользователей. Мы искренне приветствуем всех бандлеров, казначеев и кошельков для общения и сотрудничества с нами.
Цель BlockPI — создавать и развивать экосистему АА вместе с сообществом и делать все возможное для продвижения прогресса и процветания экосистемы АА. Мы надеемся, что благодаря сотрудничеству с сообществом мы внесем свой вклад во всю индустрию АА в качестве лидера отрасли и поддержим ее последующий процесс разработки, чтобы пользователи Web2 могли беспрепятственно использовать технологию блокчейна.