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

Однако EIP-4337 все еще имеет проблемы, такие как фрагментация смарт-счетов и высокая фрагментация пользовательского опыта абстракции межцепочечного счета. В данной статье исследуется, как дальше продвигать развитие области абстракции счета в рамках EIP-4337, на примере проектов, таких как Biconomy, Safe Core и Particle Network.

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

Что касается абстракции аккаунта, Виталик много раз указывал, что это необходимое условие для снижения порога пользователей Ethereum и достижения массового внедрения. Его основная идея заключается в том, чтобы позволить пользователям настраивать метод проверки подписи и получать оплату газом, а также инициировать транзакцию в блокчейне без каких-либо активов (обычно известную как безгазовая транзакция). Только реализуя эти предпосылки, приложения Web3 могут улучшить коэффициент конверсии пользователей. Несмотря на то, что предыдущие абстрактные предложения, не связанные с учетными записями, или кошельки со смарт-контрактами могут достичь аналогичного опыта, они далеки от того, чтобы быть достаточно гибкими и эффективными. Например, Gnosis Safe по-прежнему требует адрес EOA для запуска транзакций, а затраты на газ, связанные с этим, чрезвычайно высоки. Абстракция учетных записей направлена на оптимизацию базовой структуры учетных записей смарт-контрактов, прокладывая путь к следующему поколению интеллектуальных систем учетных записей. Но если мы посмотрим на реальные предложения по абстракции счета, мы обнаружим, что они сосредоточены не на самой модели счета. Например, предложения, связанные с абстракцией учетных записей, такие как EIP-86, EIP-4337 и EIP-6900, сосредоточены на абстракции/модуляризации всего процесса обработки транзакции от инициирования до получения узлами, а также на проверке подписи, оплате газа и т. д., а не на абстрагировании структуры учетной записи как таковой. Абстракция структуры счета. Поэтому представляется более уместным называть различные текущие предложения «абстракциями потока транзакций». Если мы поймем эти хорошо известные предложения по абстракции учетной записи с точки зрения абстракции потока транзакций, нам будет легче понять их основные моменты: этот вид абстракции транзакций на самом деле направлен на то, чтобы привнести пользовательский опыт входа на уровне Web2 и использования продукта в систему Ethereum. Это могут быть черные/белые списки, инициирование транзакций без подтверждения личности в течение определенного периода времени, безгазовые транзакции, платежи в фиатной валюте и т. д.

(Источник изображения: Zengo)

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

Суть EIP-4337: Локальные оптимальные решения для абстракции учетной записи в экосистеме Ethereum

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

(Image source: Springer Link)

Это аналогично ситуации до появления ERC-20 или ERC-721, когда методы реализации, функциональность и предоставленные функции/интерфейсы многих токенов были несогласованными. Такие несоответствия препятствовали развитию взаимодополняющих сторонних инфраструктур и кодовых аудитов (трудно представить, как приложения DeFi могли бы развиваться до текущего уровня без протокола ERC-20).

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

В конечном итоге EIP-4337 выделяется.

EIP-4337 - локальное оптимальное решение, но несколько аспектов в его рамках необходимо оптимизировать

EIP-4337 определяет полный набор стандартов интерфейсов, разъясняя модули, ожидаемые в смарт-кошельках, которые придерживаются протокола 4337, и функции/интерфейсы, которые должен реализовывать каждый модуль. Например, какие вызываемые функции должны предлагать внешние компоненты, такие как bundler, точки входа и paymaster. Благодаря этим рекомендациям взаимодействие между различными компонентами становится более четким, что облегчает интеграцию идей модульного дизайна в дизайн абстракции учетной записи и смарт-кошельков. Разработчики, работающие над модулями кошельков, также получают значительную выгоду. Однако, если смотреть чисто с точки зрения пользователя, ценность, приносимая парадигмой разработки модульных смарт-кошельков, может быть не сразу очевидна, поскольку изменения в самих кошельках для абстракции аккаунта могут быть неощутимы в краткосрочной перспективе. Тем не менее, если заглянуть в среднесрочную и долгосрочную перспективу, то ценность таких протоколов, как EIP-4337, напоминает ERC-20 и ERC-721. Он закладывает основу для долгосрочного развития кошельков для абстракции счетов, знаменуя собой важную веху. Тем не менее, EIP-4337 по-прежнему имеет множество нерешенных проблем, таких как:

1. Абстракция учёта недостаточно проста для интеграции, что приводит к тому, что разные разработчики ненароком «переизобретают велосипед».

2. Плохая совместимость между модулями учетной записи приводит к фрагментированной экосистеме.

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

Ниже мы рассмотрим решения для этих проблем.

Оптимизационное решение 1: Плагин абстрагирования учетной записи станет основной конфигурацией

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

(Image source: Biconomy)

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

Biconomy v2, основанная на EIP-4337 в качестве протокольной структуры, разработала более подробные стандарты и представила набор интерфейсов, не упомянутых в EIP-4337. Декларируя функциональные возможности, которыми должны обладать сборщики, кошельки смарт-контрактов, paymaster и другие модули, Biconomy позволяет сторонним разработчикам реализовывать модули с теми же функциями, но разными версиями, используя разные детали кода, при условии, что они придерживаются рекомендаций протокола, установленных Biconomy (совместимых с EIP-4337).

(Стандарты интерфейса, предложенные Biconomy, указывают, какие функции должны реализовывать разработчики сторонних модулей в своих модулях для внешних вызовов). Кроме того, Biconomy представила лозунг “Module Store”, активно продвигая запуск SDK модуля абстракции учетной записи и одновременно поощряя разработчиков представлять свои собственные разработанные модули абстракции учетной записи. Эта инициатива направлена на продвижение “модуля как сервиса”, позволяя всем проектам кошельков соблюдать протокол EIP-4337 напрямую принимать эти внешне разработанные модули абстракции учетной записи. Теперь пользователи имеют более разнообразный выбор модулей для использования при создании умных учетных записей через пользовательский интерфейс.

Модульность облегчает не только разделение труда, но также позволяет пользователям быстро переключаться или добавлять/удалять определенные функции в умном кошельке. Проще говоря, это позволяет уточнять детализацию компонентов. Biconomy указывает, что чем выше степень модульности в кошельке смарт-контракта, тем меньше изменений потребуется при его обновлении или улучшении. Нет необходимости обновлять существующий контракт кошелька смарт-контракта пользователя или использовать DelegateCall, нужно лишь обновить некоторые внешние модули, что упрощает замену определенных компонентов разным пользователям или разработчикам.

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

Решение оптимизации 2: Более детальная сегментация модуля для решения проблем фрагментации учетной записи

Относительно EIP-6900, Safe (ранее известный как Gnosis Safe) выпустил белую книгу Safe Core Protocol в августе этого года, которая в значительной степени основана на EIP-6900.

(Схема EIP-6900) EIP-6900 подчеркивает распространенную проблему в текущей модульной абстракции учетных записей, а именно «фрагментацию» учетных записей, или проблему островного отображения. Например, несмотря на то, что различные поставщики модулей абстракции учетных записей или различные DApps могут быть совместимы с EIP-4337, его уровень абстракции между различными модулями недостаточен и имеет относительно низкую степень детализации. Этот сценарий предоставляет «чрезмерную» свободу разработчикам модулей смарт-аккаунтов (смарт-аккаунт является основным компонентом, который хранит информацию о пользователе, записывает пользовательскую проверку транзакций и обрабатывает логику оплаты газа) для создания модулей с уникальными атрибутами. В результате, со временем различные проекты кошельков, как правило, разрабатывают модули смарт-аккаунтов с различными свойствами. Эта тенденция вынуждает других поставщиков модулей абстракции учетных записей отдавать приоритет совместимости с конкретными поставщиками модулей смарт-счетов, постепенно формируя фиксированные цепочки поставок «восходящий и нисходящий». Это неизбежно приводит к фрагментации и изоляции экосистемы модулей абстракции учетных записей (по аналогии с ранними днями в компьютерной индустрии, когда разработчикам операционных систем приходилось учитывать совместимость с оборудованием разных производителей). Для решения проблемы фрагментации экосистемы и повышения совместимости между модулями абстракции учетных записей, разработанными различными поставщиками, оптимальным подходом является дальнейшая абстрагация учетных записей кошельков смарт-контрактов и уточнение детализации сегментации модулей. Следуя принципам, изложенным в EIP-6900, в техническом документе Safe Core Protocol была проведена детальная оптимизация смарт-счетов (учетных записей интеллектуальных кошельков пользователей). Протокол Safe Core разбивает вызываемые модули в каждой учетной записи смарт-кошелька на различные категории, такие как плагины, хуки, валидаторы подписей, процессоры функций и многое другое. Модули смарт-аккаунтов стремятся быть как можно более легкими, храня только необходимые данные и функции, при этом делегируя перемещаемые функции «процессорам функций» или аналогичным сегментированным модулям. Этот подход согласуется с принципом бритвы Оккама – «сущности не должны умножаться без необходимости». Если смарт-аккаунты сами по себе достаточно легкие и не предполагают слишком сложных деталей, смарт-аккаунты, разработанные разными провайдерами, будут демонстрировать более тесную внутреннюю структуру и более высокую совместимость.

Протокол Safe Core также представляет собой реестр (аналогичный магазину приложений для iPhone), который содержит все утвержденные и доступные модули. Пользователи могут выбирать, какие модули активировать, и каждый раз, когда активируется новый модуль, его необходимо обработать через Менеджера.

Обычно UserOperation сначала вызовет плагин, а затем Менеджер проверит, является ли статус плагина нормальным (записан в реестре). Если статус нормальный, запрос плагина будет разрешен. При необходимости плагин вызовет некоторые функции, предоставленные Hook, или выберет не делать этого. Позже статус умного аккаунта, вовлеченного в UserOperation, будет изменен.

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

Решение оптимизации 3: Обобщение учетной записи Omnichain для единых учетных записей на разных цепях

Однако, несмотря на вышеупомянутые решения, остается существенная проблема, которую еще предстоит решить: различные цепочки и различные решения уровня 2 продвигают различные детали реализации абстракции учетной записи, многие из которых конфликтуют с EIP-4337, такие как zkSync Era, Starknet, Flow и т. д. Это фрагментирует UX кошелька для пользователей. Например, адреса смарт-кошельков на Starknet не могут быть унифицированы с адресами на Arbitrum. Кроме того, в многоцепочечной среде пользователи независимо друг от друга развернули смарт-аккаунты в разных цепочках, и соответствующие пользовательские данные часто разбросаны по этим контрактам. Если пользовательские данные, такие как ключи, необходимо обновить, транзакции должны быть инициированы повторно в нескольких цепочках, что затрудняет обеспечение согласованности смарт-счета. Ранее Виталик предложил решение для смарт-счетов, которое унифицировано по всей цепочке и легко управляется. Это решение использует Ethereum или высокозащищенный ZK-Rollup в качестве исходной цепочки и развертывает контракт Keystore для хранения глобального ключа пользователя. Затем все учетные записи смарт-контрактов на уровне 2 совместно используют глобальный ключ, хранящийся в контракте Keystore.

(Источник изображения: https://vitalik.ca/general/2023/06/20/deeperdive.html)

Однако такое решение влечет за собой значительные затраты. Всякий раз, когда глобальные ключи, записанные в контракте Keystore в исходной цепочке, изменяются, каждая учетная запись в L2/целевой цепочке должна синхронизировать новые ключи с помощью межсетевых взаимодействий. Накладные расходы на межсетевые взаимодействия между Ethereum и Layer 2 слишком высоки для пользователей. Кроме того, важно отметить, что учетные записи смарт-контрактов отличаются от EOA. Последние, благодаря своему уникальному подходу к генерации адресов, по своей сути унифицированы в нескольких цепочках EVM. Но учетные записи смарт-контрактов совершенно разные, что затрудняет пользователям получение учетных записей смарт-контрактов с одинаковыми адресами в разных цепочках. В ответ на это Particle Network предложила свой собственный метод. В то время как общая идея их метода согласуется с концепцией Виталика, сосредоточенной на разделении хранилища и кода смарт-аккаунтов, Particle Network намерена использовать независимую цепочку — Particle Network Chain — в качестве полной базы данных Storage для смарт-аккаунтов. Они планируют синхронизировать изменения в Хранилище учетной записи с локальным хранилищем учетной записи в других цепочках с помощью сторонних решений для обмена сообщениями между сетями (таких как LayerZero, CCIP, Axelar, Connext и т. д.).

(Структура мультичейнового абстрактного счета Particle Network)

В частности, система Omnichain Account Abstraction от Particle Network позволяет пользователям иметь единый адрес учетной записи смарт-контракта в разных цепочках EVM. Для этого необходимо развернуть набор контрактов Deployer в разных цепочках; пользователи должны инициировать генерацию новых учетных записей в Particle Network Chain, а затем Particle Chain активирует контракты Deployer во всех цепочках, чтобы гарантировать, что адреса учетных записей смарт-контрактов, сгенерированные для пользователей в разных цепочках, согласованы. Кроме того, пользователи могут участвовать в многоцепочечных взаимодействиях через контракты в цепочке частиц, не зная о других цепочках, и могут использовать Unified Gas Token в качестве универсального способа оплаты комиссий за транзакции.

Абстракция учетной записи Omnichain также позволяет осуществлять операции пользователей между цепями, инициируя транзакции на целевой цепи через операции пользователей и оплачивая соответствующий газ на исходной цепи. Например, это позволяет пользователям покупать NFT на Base, используя $USDC Polygon.

Однако решение Particle Network требует высокой степени сотрудничества между Контрактом Развертывания и компонентом межцепочечной передачи сообщений для достижения синхронизации мультичейн-счетов и хранения исходной цепи. Фактически это предъявляет более высокие требования к используемому оракулу или мосту межцепочечного сообщения (что, кажется, является общей проблемой для всех решений, связанных с интероперабельностью между блокчейнами). Однако синхронизацию кросс-цепочечного счета пользователя можно гибко настроить на сочетание различных мостов сообщений, а не полагаться на одиночный мост. Например, его можно настроить как стратегию 2/3, полагаясь на подтверждение любых двух из LayerZero, Axelar и Connext для подтверждения изменений хранения на целевой цепи. Это может быть потенциальным решением проблемы зависимости от одной точки.

Бесшовная межцепочная совместимость между EVM и не-EVM является дальнейшим шагом к обобщенной абстракции учетной записи в рамках экосистемы Ethereum

Несмотря на наличие управления ключами и унифицированных учетных записей в цепочках EVM, все еще есть области для оптимизации в абстракции омничейн-аккаунтов. Несовместимые с EVM цепочки, такие как Aptos, Solana, Sui и т. д., не могут гарантировать, что адреса учетных записей смарт-контрактов совпадают с адресами в цепочках EVM. Более того, цепочкам, не относящимся к EVM, будет сложно принять концепцию абстракции кроссчейн-аккаунта, предложенную в предыдущем обсуждении, если они не реализуют протокол ERC-4337 с эквивалентным решением. Кроме того, есть возможности для улучшения в проектах кошельков, совместимых с EIP-4337. Узлы Bundler, используемые большинством смарт-кошельков, официально запускаются независимо, иногда даже изолированно друг от друга, создавая различные риски (например, риски, связанные с устойчивостью к цензуре и доступностью). Создание унифицированного интерфейса, охватывающего большинство цепочек, оказывается чрезвычайно сложной задачей. Одним из возможных решений является внедрение дизайна, ориентированного на намерения, добавив дополнительный уровень поверх абстракции омничейн-аккаунта. Этот уровень включает в себя экосистему Ethereum EIP-4337 или собственные средства абстракции учетных записей других цепочек (например, zkSync) в качестве конкретных экземпляров под типом Solver/Reactor, при этом задача выбора соответствующего решателя является ответственностью верхнего уровня. Взяв в качестве примера Particle Network, он предлагает краткую и абстрактную реализацию, ориентированную на намерения. Различные проекты абстракции учетной записи являются просто экземплярами, включенными в категорию Solver в схеме намерения. Во-первых, пользовательский интерфейс преобразует запросы на естественном языке или любое взаимодействие с пользователем в конкретные программные описания, охватывающие ограничения ввода и вывода (другими словами, это условия, которые позволяют входным данным, удовлетворяющим требованиям пользователя, и выходным результатам, попадающим в определенный диапазон). Впоследствии, в сети Solver, определенные Solver (Solver) пересылают транзакции, содержащие точные входные и выходные ограничения, в контракты Solver, развернутые в цепочке (Solver охватывает не только инфраструктуру узлов, но и компоненты контрактов в сети). Контракт Solver передает директиву Intent контракту Reactor (управляющему учетными записями пользователей в блокчейне), делегируя последнему вызов других модулей для выполнения окончательного взаимодействия. Этот фреймворк позволяет первоначально обрабатывать пользовательские запросы сетью Solver, облегчая пользователям необходимость понимать лежащие в основе цепочки или различные схемы абстракции учетных записей, задача, делегированная Solver для построения конкретных решений. Тем не менее, эти концептуализации все еще являются теоретическими основами, а детали реализации ожидают дальнейшей проработки Particle Network. Очевидно, что в будущем возникнет конкурентный рынок решателей, что позволит пользователям инициировать торги, в которых несколько решателей предлагают различные решения. С помощью локально смоделированных транзакций может быть выбрано оптимальное решение и предоставлены соответствующие стимулы для решателя. Структура поощрения будет формироваться разработчиками протокола сети Solver (Particle Network стремится использовать токены PNT в качестве поощрительных токенов для своего рынка аукционов Solver). В настоящее время сущность намерения скрывает сложные детали нижних слоев и абстрагирует более высокий слой. Эта многоуровневая структура, напоминающая протокол TCP/IP, необходима для улучшения взаимодействия как с пользователем, так и с разработчиками в бесшовном взаимодействии между цепочками.

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

После оптимизации фреймворка EIP-4337 в экосистеме Ethereum с различных сторон и продвижения безшовной совместимости между экосистемами Ethereum и не Ethereum, мы считаем, что для поддержки массового принятия абстракции учетной записи нам все равно нужен продукт, охватывающий стороны предложения и спроса. Этот продукт должен уменьшить сложность для конечных пользователей, использующих различные сервисы продуктов Web3, сосредотачиваясь на снижении порогов входа для разработчиков. Одним из оптимальных продуктов, выполняющих эту роль, является модульный стек Particle Network's Modular Smart Wallet-as-a-Service:

(Архитектура Smart Wallet-as-a-Service сети Particle)

• Сервис предлагает удобный интерфейс прикладного программирования (API), позволяющий разработчикам без проблем интегрировать модульные функциональные возможности абстракции учетной записи в свои приложения.
• Разработчики могут использовать эту службу для создания и управления учетными записями omnichain, проведения взаимодействий между цепями и использования унифицированного метода оплаты комиссии.
• Такие сервисы предоставят разработчикам более гибкий и удобный способ создания многоцепочечных приложений и способствуют широкому принятию абстракции учетной записи.

В дополнение к вышеупомянутым для разработчиков функциям наиболее важным аспектом стека Modular Smart Wallet-as-a-Service от Particle Network является то, что он создал открытую экосистему для домена абстракции учетных записей на основе вычисления подписи и ориентированную на разработчиков. В дополнение к своим собственным модулям продуктов для абстракции учетных записей Particle Network интегрирует различные типы продуктов и услуг для абстракции учетных записей. Эта интеграция ускоряет принятие продуктов и услуг по всему диапазону абстракции учетных записей для разработчиков.

(Модульная конструкция Smart Wallet-as-a-Service от Particle Network)Технология Let удовлетворяет потребности пользователей. После устранения ограничений фреймворка ERC-4337 улучшение опыта разработчиков приведет к появлению большего количества продуктов с отличным пользовательским опытом, ускоряя переход Web3 из финансовой индустрии, дружественной к крипто-панку, в индустрию, дружественную к потребителям для широких масс.

Отказ от ответственности:

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