Почему говорят, что абстрагирование счета по всей цепочке - последний кусочек головоломки для EIP-4337?

Новичок3/28/2024, 9:11:18 AM
Эта статья обсуждает важность полного абстрагирования счета на цепочке в EIP-4337 и предлагает некоторые направления оптимизации. Во-первых, Biconomy предоставляет более подробный стандарт для EIP-4337 и позволяет сторонним разработчикам реализовывать модули с похожими функциями, но разными деталями. Во-вторых, она ссылается на концепцию EIP-6900 для оптимизации умных счетов более подробно, решая проблему фрагментации в экосистеме. Кроме того, в статье упоминается модульный продукт Smart Wallet-as-a-Service (Modular Smart Wallet-as-as-Service) от Particle Network, который предоставит разработчикам более гибкий и удобный способ создания мультицепных приложений и способствует широкому распространению абстрагирования счета.

TL;DR

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

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

С точки зрения абстрагирования процесса транзакции, понимание концепции "абстрагирование счета"

Что касается абстрагирования счета, Виталик неоднократно подчеркивал, что это необходимое условие для снижения порога входа для Ethereum и достижения массового принятия. Его основное видение заключается в том, чтобы позволить пользователям настраивать методы проверки подписи + наслаждаться оплатой газа и инициировать транзакции on-chain без каких-либо активов (обычно называемые транзакциями без газа). Только достигнув этих предварительных условий, можно улучшить конверсию новых пользователей в приложения Web3.

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

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

Однако, если мы посмотрим на конкретные предложения об абстрагировании счета, мы увидим, что их основное внимание не сосредоточено на самой модели счета. Например, связанные с абстрагированием счета предложения, такие как EIP-86, EIP-4337 и EIP-6900, фокусируются на абстрагировании/модуляризации всего процесса обработки транзакции от инициации до получения узлами, верификации подписи, оплаты газа и т. д., а не на самом деле сосредотачиваются на абстрагировании структуры счета. Поэтому кажется более уместным называть эти различные предложения «абстрагированием транзакции».

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

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

Сущность EIP-4337: Абстрагирование счета как локальное оптимальное решение в экосистеме Ethereum

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

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

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

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

В конце концов, появился EIP-4337.

EIP-4337 - локальное оптимальное решение, но в его рамках существует несколько аспектов, требующих срочной оптимизации.

EIP-4337 определяет полный набор стандартов интерфейса, уточняя, какие модули должен иметь смарт-кошелек, следующий протоколу 4337, и какие функции/интерфейсы должен реализовать каждый модуль, такие как Bundler, EntryPoint и Paymaster, а также какие вызываемые функции должны предоставлять эти компоненты.

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

Конечно, с точки зрения пользователя ценность, приносимая парадигмой развития модульного смарт-кошелька, пока не ясна, потому что пользователи в ближайшей перспективе могут не почувствовать больших изменений в самом кошельке с абстрагированием счета. Однако в среднесрочной и долгосрочной перспективе ценность протоколов, таких как EIP-4337, аналогична ERC-20 и ERC-721. Он заложил основу для долгосрочного развития кошельков с абстрагированием счета и является вехой эпохального значения.

Однако у EIP-4337 все еще есть множество нерешенных проблем, таких как:

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

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

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

В следующих разделах мы обсудим решения этих проблем.

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

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

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

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

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

Тем временем Biconomy также представила девиз «Модульный магазин». Активно запуская SDK модуля абстрагирования счета, Biconomy призывает разработчиков представлять свои собственные разработанные модули абстрагирования счета и инициирует «Модуль как сервис», позволяя всем проектам кошельков, соответствующим протоколу EIP-4337, напрямую принимать эти модули абстракции счета, написанные третьими лицами. Когда пользователи создают умные счета через интерфейс фронтенда, у них также будет более широкий выбор модулей для выбора.

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

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

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

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

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

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

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

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

После привлечения идей EIP-6900 белая книга Safe Core Protocol провела более детальную оптимизацию Smart Account (смарт-контрактные кошельки пользователей). Safe Core Protocol разделяет каждый вызываемый модуль смарт-контрактного кошелька на различные категории, такие как Плагины, Хуки, валидаторы подписей и обработчики функций.

Модули интеллектуального счета делаются как можно более легкими, причем контракт счета хранит только самые основные данные и функции, в то время как функции, которые могут быть вынесены за его пределы, реализуются специализированными модулями, такими как «процессоры функций» или «плагины». Это соответствует принципу бритвы Оккама: «Сущности не должны быть ненароком умножены».

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

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

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

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

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

Однако даже при вышеперечисленных решениях остается серьезная нерешенная проблема: различные цепочки и различные решения уровня 2 продвигают различные схемы реализации абстракции счета с противоречивыми формами, многие из которых конфликтуют с EIP-4337, такими как zkSync Era, Starknet, Flow и т. д. Этот фрагментация в пользовательском интерфейсе кошелька, например, делает невозможным объединение адреса смарт-кошелька пользователя на Starknet с адресом на Arbitrum.

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

Сам Виталик ранее предложил унифицированное и легко управляемое решение для умного счета на всех цепочках. Это решение использует Ethereum или высоко безопасный ZKRollup в качестве исходной цепочки, развертывает контракт хранилища Keystore для хранения глобальных ключей пользователей, после чего все умные контракты счетов на уровне 2 делят глобальные ключи, хранящиеся в контракте Keystore。

Однако эта решение приходит с крайне высокими затратами. Всякий раз, когда происходит изменение в глобальных ключах, записанных контрактом Keystore на исходной цепи, каждому счету на L2/целевой цепи необходимо синхронизировать новые ключи через взаимодействия между цепями. Однако стоимость взаимодействий между Ethereum и L2 черезвычайно высока для пользователей. Кроме того, важно отметить, что умные контрактные счета отличаются от счетов EOA. В то время как последние, благодаря своему уникальному методу генерации адресов, естественным образом унифицированы через несколько цепей (в экосистеме EVM), умные контрактные счета совершенно различны, что затрудняет пользователям получение умных контрактных счетов с тем же адресом на разных цепях.

В ответ на это Particle Network предложила свой собственный подход. Хотя общая идея совпадает с концепцией Виталика о разделении Хранилища и Кода умных счетов, Particle Network планирует использовать отдельную цепь - цепь Particle Network - в качестве полной цепи Хранилища данных для умных счетов. Через решения сторонних кросс-цепных сообщений (такие как LayerZero, CCIP, Axelar, Connext и т. д.) Particle Network намеревается синхронизировать изменения Хранилища счета с локальными счетами других цепей.

(Структура мульти-цепирующего абстрагирования счета сети Particle)

Конкретно, система абстрагирования счета Particle Network на полном блокчейне нацелена на предоставление пользователям унифицированного адреса умного контракта на разных цепях EVM. Для этого необходимо развернуть набор контрактов-деплоеров на разных цепях. Пользователям необходимо запустить создание нового счета на цепи Particle Network, после чего цепь Particle запустит все контракты-деплоеры на различных цепях, чтобы гарантировать, что умные адреса счетов, сгенерированные для пользователей на разных цепях, согласованы. В противном случае пользователи могут завершить взаимодействия на нескольких цепях через контракты на цепи Particle, не зная о других цепях, и они могут использовать Unified Gas Token в качестве унифицированного метода оплаты комиссии.

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

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

Тем не менее, синхронизацию учетных записей пользователей межцепочно можно гибко настроить с различными комбинациями Мостов сообщений, а не полагаться на единственный Мост. Например, его можно настроить с политикой 2/3, где изменения в хранилище на целевой цепочке подтверждаются только после того, как любые два из LayerZero, Axelar или Connext подтвердят изменение, что может смягчить проблему зависимости от одной точки.

Беспрепятственная совместимость как с цепочками EVM, так и с не-EVM, представляет собой еще один шаг в полном абстрагировании учетных записей по всей цепочке в экосистеме Ethereum. Несмотря на продвижения в управлении ключами и унифицированных учетных записях по цепочкам EVM, все еще есть место для оптимизации в полном абстрагировании учетных записей по всей цепочке. Цепочки, несовместимые с EVM, такие как Aptos, Solana и Sui, не могут гарантировать согласованности адресов умных контрактов, сгенерированных пользователями, с теми на цепочках EVM. Кроме того, не-EVM цепочки могут испытывать трудности в принятии концепции полного абстрагирования учетных записей, предложенной Виталиком и Particle Network, без внедрения эквивалентных решений протокола EIP-4337.

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

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

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

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

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

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

Принятие широкого распространения абстрагирования счета

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

Один из лучших продуктов для игры этой роли - продукт Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) от Particle Network:

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

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

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

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

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

Пригласить больше голосов

Содержание

Почему говорят, что абстрагирование счета по всей цепочке - последний кусочек головоломки для EIP-4337?

Новичок3/28/2024, 9:11:18 AM
Эта статья обсуждает важность полного абстрагирования счета на цепочке в EIP-4337 и предлагает некоторые направления оптимизации. Во-первых, Biconomy предоставляет более подробный стандарт для EIP-4337 и позволяет сторонним разработчикам реализовывать модули с похожими функциями, но разными деталями. Во-вторых, она ссылается на концепцию EIP-6900 для оптимизации умных счетов более подробно, решая проблему фрагментации в экосистеме. Кроме того, в статье упоминается модульный продукт Smart Wallet-as-a-Service (Modular Smart Wallet-as-as-Service) от Particle Network, который предоставит разработчикам более гибкий и удобный способ создания мультицепных приложений и способствует широкому распространению абстрагирования счета.

TL;DR

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

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

С точки зрения абстрагирования процесса транзакции, понимание концепции "абстрагирование счета"

Что касается абстрагирования счета, Виталик неоднократно подчеркивал, что это необходимое условие для снижения порога входа для Ethereum и достижения массового принятия. Его основное видение заключается в том, чтобы позволить пользователям настраивать методы проверки подписи + наслаждаться оплатой газа и инициировать транзакции on-chain без каких-либо активов (обычно называемые транзакциями без газа). Только достигнув этих предварительных условий, можно улучшить конверсию новых пользователей в приложения Web3.

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

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

Однако, если мы посмотрим на конкретные предложения об абстрагировании счета, мы увидим, что их основное внимание не сосредоточено на самой модели счета. Например, связанные с абстрагированием счета предложения, такие как EIP-86, EIP-4337 и EIP-6900, фокусируются на абстрагировании/модуляризации всего процесса обработки транзакции от инициации до получения узлами, верификации подписи, оплаты газа и т. д., а не на самом деле сосредотачиваются на абстрагировании структуры счета. Поэтому кажется более уместным называть эти различные предложения «абстрагированием транзакции».

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

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

Сущность EIP-4337: Абстрагирование счета как локальное оптимальное решение в экосистеме Ethereum

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

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

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

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

В конце концов, появился EIP-4337.

EIP-4337 - локальное оптимальное решение, но в его рамках существует несколько аспектов, требующих срочной оптимизации.

EIP-4337 определяет полный набор стандартов интерфейса, уточняя, какие модули должен иметь смарт-кошелек, следующий протоколу 4337, и какие функции/интерфейсы должен реализовать каждый модуль, такие как Bundler, EntryPoint и Paymaster, а также какие вызываемые функции должны предоставлять эти компоненты.

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

Конечно, с точки зрения пользователя ценность, приносимая парадигмой развития модульного смарт-кошелька, пока не ясна, потому что пользователи в ближайшей перспективе могут не почувствовать больших изменений в самом кошельке с абстрагированием счета. Однако в среднесрочной и долгосрочной перспективе ценность протоколов, таких как EIP-4337, аналогична ERC-20 и ERC-721. Он заложил основу для долгосрочного развития кошельков с абстрагированием счета и является вехой эпохального значения.

Однако у EIP-4337 все еще есть множество нерешенных проблем, таких как:

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

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

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

В следующих разделах мы обсудим решения этих проблем.

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

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

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

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

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

Тем временем Biconomy также представила девиз «Модульный магазин». Активно запуская SDK модуля абстрагирования счета, Biconomy призывает разработчиков представлять свои собственные разработанные модули абстрагирования счета и инициирует «Модуль как сервис», позволяя всем проектам кошельков, соответствующим протоколу EIP-4337, напрямую принимать эти модули абстракции счета, написанные третьими лицами. Когда пользователи создают умные счета через интерфейс фронтенда, у них также будет более широкий выбор модулей для выбора.

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

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

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

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

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

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

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

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

После привлечения идей EIP-6900 белая книга Safe Core Protocol провела более детальную оптимизацию Smart Account (смарт-контрактные кошельки пользователей). Safe Core Protocol разделяет каждый вызываемый модуль смарт-контрактного кошелька на различные категории, такие как Плагины, Хуки, валидаторы подписей и обработчики функций.

Модули интеллектуального счета делаются как можно более легкими, причем контракт счета хранит только самые основные данные и функции, в то время как функции, которые могут быть вынесены за его пределы, реализуются специализированными модулями, такими как «процессоры функций» или «плагины». Это соответствует принципу бритвы Оккама: «Сущности не должны быть ненароком умножены».

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

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

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

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

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

Однако даже при вышеперечисленных решениях остается серьезная нерешенная проблема: различные цепочки и различные решения уровня 2 продвигают различные схемы реализации абстракции счета с противоречивыми формами, многие из которых конфликтуют с EIP-4337, такими как zkSync Era, Starknet, Flow и т. д. Этот фрагментация в пользовательском интерфейсе кошелька, например, делает невозможным объединение адреса смарт-кошелька пользователя на Starknet с адресом на Arbitrum.

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

Сам Виталик ранее предложил унифицированное и легко управляемое решение для умного счета на всех цепочках. Это решение использует Ethereum или высоко безопасный ZKRollup в качестве исходной цепочки, развертывает контракт хранилища Keystore для хранения глобальных ключей пользователей, после чего все умные контракты счетов на уровне 2 делят глобальные ключи, хранящиеся в контракте Keystore。

Однако эта решение приходит с крайне высокими затратами. Всякий раз, когда происходит изменение в глобальных ключах, записанных контрактом Keystore на исходной цепи, каждому счету на L2/целевой цепи необходимо синхронизировать новые ключи через взаимодействия между цепями. Однако стоимость взаимодействий между Ethereum и L2 черезвычайно высока для пользователей. Кроме того, важно отметить, что умные контрактные счета отличаются от счетов EOA. В то время как последние, благодаря своему уникальному методу генерации адресов, естественным образом унифицированы через несколько цепей (в экосистеме EVM), умные контрактные счета совершенно различны, что затрудняет пользователям получение умных контрактных счетов с тем же адресом на разных цепях.

В ответ на это Particle Network предложила свой собственный подход. Хотя общая идея совпадает с концепцией Виталика о разделении Хранилища и Кода умных счетов, Particle Network планирует использовать отдельную цепь - цепь Particle Network - в качестве полной цепи Хранилища данных для умных счетов. Через решения сторонних кросс-цепных сообщений (такие как LayerZero, CCIP, Axelar, Connext и т. д.) Particle Network намеревается синхронизировать изменения Хранилища счета с локальными счетами других цепей.

(Структура мульти-цепирующего абстрагирования счета сети Particle)

Конкретно, система абстрагирования счета Particle Network на полном блокчейне нацелена на предоставление пользователям унифицированного адреса умного контракта на разных цепях EVM. Для этого необходимо развернуть набор контрактов-деплоеров на разных цепях. Пользователям необходимо запустить создание нового счета на цепи Particle Network, после чего цепь Particle запустит все контракты-деплоеры на различных цепях, чтобы гарантировать, что умные адреса счетов, сгенерированные для пользователей на разных цепях, согласованы. В противном случае пользователи могут завершить взаимодействия на нескольких цепях через контракты на цепи Particle, не зная о других цепях, и они могут использовать Unified Gas Token в качестве унифицированного метода оплаты комиссии.

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

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

Тем не менее, синхронизацию учетных записей пользователей межцепочно можно гибко настроить с различными комбинациями Мостов сообщений, а не полагаться на единственный Мост. Например, его можно настроить с политикой 2/3, где изменения в хранилище на целевой цепочке подтверждаются только после того, как любые два из LayerZero, Axelar или Connext подтвердят изменение, что может смягчить проблему зависимости от одной точки.

Беспрепятственная совместимость как с цепочками EVM, так и с не-EVM, представляет собой еще один шаг в полном абстрагировании учетных записей по всей цепочке в экосистеме Ethereum. Несмотря на продвижения в управлении ключами и унифицированных учетных записях по цепочкам EVM, все еще есть место для оптимизации в полном абстрагировании учетных записей по всей цепочке. Цепочки, несовместимые с EVM, такие как Aptos, Solana и Sui, не могут гарантировать согласованности адресов умных контрактов, сгенерированных пользователями, с теми на цепочках EVM. Кроме того, не-EVM цепочки могут испытывать трудности в принятии концепции полного абстрагирования учетных записей, предложенной Виталиком и Particle Network, без внедрения эквивалентных решений протокола EIP-4337.

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

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

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

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

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

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

Принятие широкого распространения абстрагирования счета

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

Один из лучших продуктов для игры этой роли - продукт Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) от Particle Network:

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

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

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

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

  1. Эта статья перепечатана из[Tencent website], Все авторские права принадлежат оригинальному автору [Питер Пэн, соучредитель и главный технический директор сети Particle &Faust, гик Web3]. Если есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Ворота Учитькоманда, и они оперативно разберутся с этим.
  2. Ответственность за отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.
Начните торговать сейчас
Зарегистрируйтесь сейчас и получите ваучер на
$100
!