作者:Пітер Пен, співзасновник і технічний директор Particle Network &Faust,极客Web3
З 2022 року абстракція облікових записів є широко обговорюваною темою, і структура абстракції облікових записів з EIP-4337 як ядром, здається, стала загальним консенсусом у галузі. Популярність концепції наміру спонукала приділяти більше уваги таким низькопороговим компонентам взаємодії з користувачем.
Однак EIP-4337 все ще має больові точки фрагментації облікових записів Smart Account і дуже фрагментований абстрактний користувацький досвід крос-чейн облікових записів. **У цій статті використовуються такі проекти, як Biconomy, Safe Core і Particle Network, як приклади, щоб дослідити, як ще більше просунути сферу абстракції облікових записів у рамках EIP-4337. **
Розуміти концепцію "абстракції облікового запису" з точки зору абстракції транзакційного процесу
Що стосується абстракції облікового запису, Віталік неодноразово вказував, що це необхідна умова для зниження порогу користувачів Ethereum і досягнення масового прийняття, а його основне бачення полягає в тому, щоб дозволити користувачам налаштовувати метод перевірки підпису + насолоджуватися оплатою газу та ініціювати транзакції в ланцюжку без будь-яких активів (широко відомі як транзакції без газу). Тільки реалізувавши ці передумови, ми зможемо підвищити коефіцієнт конверсії нових користувачів Web3-додатків.
У минулому абстрактні пропозиції без облікового запису або гаманці смарт-контрактів, хоча вони можуть досягти подібного досвіду, далеко не гнучкі та ефективні, наприклад, Gnosis Safe все ще вимагає адрес EOA для ініціювання транзакцій, а вартість газу надзвичайно висока.
Абстракція облікових записів має намір оптимізувати з нижнього рівня структури рахунків смарт-контрактів, щоб прокласти шлях для наступного покоління інтелектуальних систем облікових записів.
Але з фактичної пропозиції абстракції рахунку ми побачимо, що вони зосереджені не на самій моделі рахунку. Наприклад, EIP-86, EIP-4337, EIP-6900 та інші пропозиції, пов'язані з абстракцією рахунків, фокусуються на абстракції/модульності всього процесу обробки транзакції від ініціації до отримання вузлом, перевірки підпису, оплати газу тощо, не особливо звертають увагу на абстракцію структури рахунку. Тому видається більш доречним називати нинішні пропозиції «транзакційними абстракціями».
Якщо ми зрозуміємо ці відомі абстрактні пропозиції облікових записів з точки зору «абстракції процесу обробки транзакцій», нам буде легше зрозуміти їхні основні моменти: ця абстракція транзакцій насправді хоче привнести досвід користувачів рівня Web2, які вводять і використовують продукти в системі Ethereum, такі як чорний список/білий список, відсутність перевірки особи для ініціювання транзакцій протягом певного періоду часу, відсутність транзакцій з газом, комісії за оплату фіатною валютою тощо.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/a966728c2d42bc95cc4199e63f9b6ae7.png)
Але деякі люди запитають: чи не могли ці речі бути реалізовані в гаманцях смарт-контрактів у минулому? У чому цінність абстрактних схем типу EIP-4337?
Суть EIP-4337: локальне оптимальне рішення абстракції облікового запису в екосистемі Ethereum
Як згадувалося в наведеному вище питанні, хоча розумні гаманці в минулому могли виконувати функції, згадані вище, методи реалізації, як правило, грубі і часто покладаються на високоцентралізовані сторонні засоби. Наприклад, у минулому схема оплати газу полягала у впровадженні стороннього вузла Relayer (EIP-2771). Крім того, відсутність єдиних стандартів між різними розумними гаманцями не сприяє розробці та розгортанню допоміжних компонентів. **
Основна привабливість EIP, пов'язана з різними абстракціями облікових записів, полягає в тому, щоб усунути ці дефекти в різних проектах гаманців за допомогою стандартизованої структури, розробленої для гаманців смарт-контрактів, і просунути структуру облікового запису в екосистемі Ethereum з базової функціональної структури в інтелектуальну структуру з більш високою стелею.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/cbe5faeb45fe0855ca3707430ce2e7d7.png)
Наприклад, до появи 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 все ще має багато невирішених проблем: ** Наприклад:
Функція абстракції облікового запису недостатньо вбудована, і різним розробникам легко винайти велосипед;
Сумісність модуля обліку погана, і вся облікова система демонструє тенденцію до фрагментації екології;
Екологія абстракції облікового запису між різними ланцюжками сильно фрагментована, що ускладнює надання уніфікованого та якісного досвіду для кінцевих користувачів та розробників та досягнення кращого UX.
Нижче ми розглянемо шляхи вирішення цих проблем.
Напрямок оптимізації 1: Функція плагіна абстракції облікового запису стане базовою конфігурацією
**Можна сказати, що одним з основних питань обговорення, пов'язаних з абстракцією облікового запису, зараз є те, як краще реалізувати модульність абстрактного гаманця облікового запису та скоротити деталізацію кожного модуля до більшої деталізації. **
Наприклад, Biconomy пропонує наратив, заснований на EIP-4337 (EIP-6900 з більш дрібною деталізацією буде представлений в майбутньому) для подальшого сприяння модульному розвитку екології абстракції облікового запису.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/48172bf745d6ba99c4709aa3b10697ed.png)
Так званий плагін функції абстракції облікового запису насправді полягає в тому, щоб за допомогою набору протоколів з'ясувати, які ключові модулі беруть участь у гаманці смарт-контрактів, які інтерфейси/функції ці модулі повинні реалізовувати, а також як ці інтерфейси називаються і як їх викликати. Потім сторонні розробники розробляють компоненти з різними деталями відповідно до власних уявлень, але ці компоненти відповідатимуть вимогам, викладеним в угоді.
Версія Biconomy V2, з EIP-4337 в якості основи протоколу, розробила більш детальні стандарти і додала ряд інтерфейсів, не згаданих в 4337. Вказуючи, які функції повинні мати такі модулі, як Bundler, Smart Contract Wallet і Paymaster, Biconomy дозволяє стороннім розробникам реалізовувати модулі з однаковими характеристиками та різними версіями з різними деталями коду, якщо вони дотримуються деталей протоколу, заздалегідь зазначених Biconomy (сумісні з EIP-4337).
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/70a918d3c0fa189323edbf381b630a84.png)
У той же час Biconomy також висунула слоган «Module Store», при особистому запуску абстрактного модуля облікового запису SDK більшості розробників пропонується представити власні розроблені абстрактні модулі облікового запису, розширити «Модуль як послуга», ** щоб всі проекти гаманців, які дотримуються протоколу EIP-4337, могли безпосередньо прийняти ці абстрактні модулі облікового запису, написані сторонніми особами. Коли користувачі створюють розумний обліковий запис через зовнішню сторінку, вони також мають більш різноманітний вибір того, які модулі використовувати.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/f96ee55f5dd8dcdaf0a1a5442fe0281a.png)
У той час як модульність зручна для розподілу праці, користувачам також зручно швидко перемикатися або додавати і видаляти певні функції в смарт-гаманці (простіше кажучи, це розділити деталізацію на більш дрібні шматочки).
У Biconomy зазначили, що чим більш модульним є гаманець смарт-контрактів, тим менше змін йому потрібно вносити при оновленні або оновленні (не потрібно оновлювати існуючі контракти гаманця смарт-контрактів користувачів або використовувати DelegateCall, лише деякі зовнішні модулі), що полегшує заміну певних компонентів різним користувачам або розробникам.
У майбутній новій абстракції облікового запису Biconomy він також стосуватиметься пропозиції EIP-6900, яка є більш модульною, ніж EIP-4337.
Напрямок оптимізації 2: Більш тонка сегментація модулів для вирішення проблеми фрагментації облікового запису
Що стосується пропозиції EIP-6900, ** Safe (раніше Gnosis Safe) фактично випустила відповідний технічний документ Safe Core Protocol у серпні цього року, і найбільш запозиченим є EIP-6900. **
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/c61f4b7e5a49dc219a785276a95cf071.png)
** EIP-6900 вказує на те, що однією з проблем нинішньої абстракції модульних рахунків є «фрагментація» рахунків, або проблема розрізненості. Наприклад, незважаючи на те, що різні постачальники модулів абстракції облікових записів або різні програми DAPP будуть сумісні з EIP-4337, EIP-4337 недостатньо високий для різних модулів, а деталізація відносно груба, залишаючи «занадто високий» ступінь свободи для розробників модулів Smart Account (розумний обліковий запис є основною частиною зберігання інформації про користувачів і запису користувацької перевірки транзакцій і логіки оплати газу).
Таким чином, різні учасники проекту гаманців, як правило, розробляють модулі розумних облікових записів з унікальними властивостями. **У довгостроковій перспективі інші постачальники модулів абстракції облікових записів повинні визначати пріоритети, які надають сумісні модулі Smart Account, і повільно створювати фіксований ланцюжок поставок вище та нижче, що неминуче призведе до фрагментації та відокремлення екології модуля абстракції облікового запису. ** (Це схоже на те, що на зорі комп'ютерної індустрії розробники операційних систем повинні були враховувати, з яким виробником комп'ютерного обладнання сумісний.)
Щоб вирішити проблему екологічної фрагментації та покращити сумісність модулів абстракції облікових записів, розроблених різними постачальниками, найкращим способом є подальше абстрагування облікових записів гаманців смарт-контрактів і підвищення деталізації модулів.
Після запозичення ідей EIP-6900 у технічному документі протоколу **Safe Core зроблено більш детальну оптимізацію Smart Account (облікового запису смарт-гаманця користувача). Протокол Safe Core розбиває модулі, які можуть бути викликані кожним обліковим записом смарт-гаманця, на плагіни, хуки, верифікатори підпису, функціональні процесори та інші категорії. **
Модуль розумного облікового запису максимально простий, контракт облікового запису зберігає лише найосновніші дані та функції, а всі функції, які можна перемістити назовні, перекидаються в модуль підрозділу «функціональний процесор» або «плагін» для реалізації. Це перегукується з так званим принципом бритви Оккама – «не додавайте сутності без необхідності».
Якщо смарт-аккаунт сам по собі досить легкий і не передбачає занадто громіздких деталей, розроблений різними виробниками смарт-аккаунт буде ближче за внутрішньою структурою і більш сумісний.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/09f83d13d3ab4398881f144c2c17aa58.png)
Протокол Safe Core також вводить реєстр, подібний до магазину додатків iPhone, який містить усі затверджені доступні модулі. Користувач може вибрати, які модулі активувати, і кожен раз, коли активується новий модуль, він обробляється через контракт Minger.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/bd45f12927186dd3b98dbd955a08c962.png)
Загалом, UserOperation спочатку запустить плагін плагіна, а потім контракт Manger перевірить, чи є статус плагіна нормальним (є запис у реєстрі), і якщо він нормальний, він дозволить запит плагіна. При необхідності, плагіни викликають деякі функції, що надаються хуком, або ні. Потім вносяться зміни до стану смарт-облікового запису, який бере участь у UserOperation.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/fd639d5a6f150f1cfcfe67cc77a79e44.png)
За допомогою вищезгаданого тонкого методу шардингу модулів і процесу планування, Safe Core Protocol намагається реалізувати набір протоколу інтероперабельності абстрактних модулів облікового запису з відкритим вихідним кодом, основна ідея якого полягає в тому, щоб зробити Smart Account легким, таким же простим, як обліковий запис EOA, щоб покращити сумісність модулів Smart Account, покращених різними постачальниками.
Напрямок оптимізації 3: Повна абстракція облікового запису, для досягнення уніфікованих облікових записів у різних мережах
Але навіть з вищезгаданим рішенням все ще існує велика проблема, яка не вирішена: різні ланцюжки та різні Layer2 просувають абстракції облікових записів з різними деталями, і багато хто використовує форми, які конфліктують з EIP-4337, такі як zkSync Era, Starknet, Flow тощо. Це призвело до фрагментації UX гаманця, наприклад, адреса смарт-гаманця користувача на Starknet і адреса розумного гаманця на Arbitrum взагалі не можуть бути уніфіковані.
Більш того, в мультичейн середовищі користувачі самостійно розгорнули Smart Accounts в різних ланцюгах, і відповідні дані користувачів часто розкидані в цих контрактах. Якщо потрібно оновити дані користувача, такі як ключі, необхідно багаторазово ініціювати транзакції в декількох ланцюжках, і важко забезпечити узгодженість Smart Account.
Сам Віталік раніше запропонував набір повноланцюгових уніфікованих і простих в управлінні схем смарт-рахунків, ** ця схема використовує Ethereum або високозахищений ZKRollup в якості вихідного ланцюжка, розгортає контракт Keystore, зберігає глобальний ключ користувача, а потім всі облікові записи смарт-контрактів користувача на L2 діляться глобальним ключем, що зберігається в контракті Keystore.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/6dbc43d45760d49029da132dab099e17.png)
Однак це рішення є надзвичайно дорогим, тобто щоразу, коли глобальний ключ, записаний у контракті Keystore у вихідному ланцюжку, змінюється, кожен обліковий запис у ланцюжку L2/target повинен синхронізувати новий ключ за допомогою крос-чейн взаємодії. Кросчейн взаємодія між Ethereum і L2 занадто дорога для користувачів, щоб дозволити собі це. І слід зазначити, що облікові записи смарт-контрактів відрізняються від облікових записів EOA, які за своєю суттю є мультичейн уніфікованими (уніфікованими між ланцюгами EVM) своїми унікальними методами генерації адрес, але облікові записи смарт-контрактів абсолютно різні, і користувачам складно отримати облікові записи смарт-контрактів з однаковою адресою в різних ланцюгах.
Particle Network придумала свій підхід до цього. Хоча загальна ідея збігається з ідеєю Віталіка, яка також полягає в тому, щоб відокремити сховище та код смарт-облікового запису, Particle Network має намір використовувати незалежний ланцюг, Particle Network Chain, як повноланцюгову базу даних зберігання смарт-облікового запису, за допомогою сторонніх крос-чейн рішень для обміну повідомленнями (LayerZero, CCIP, Axelar, Connext). і т.д.) Синхронізувати зміни користувача в сховищі облікового запису з локальним обліковим записом в інших мережах.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/083c776894d73db5ee207dc727214b5b.png)
(Абстракція мультичейн-акаунту Particle Network)
Зокрема, система абстракції облікових записів повного ланцюга Particle Network вимагає, щоб користувачі мали єдину адресу облікового запису смарт-контракту в різних ланцюжках EVM, що вимагає розгортання набору контрактів розгортання в різних ланцюгах;
Користувачі повинні ініціювати генерацію нових облікових записів у ланцюжку Particle Network Chain, після чого Particle Chain запустить контракт розгортача на всіх ланцюгах, гарантуючи, що адреси облікових записів смарт-контрактів, згенеровані для користувачів у різних ланцюгах, є однаковими, або користувачі можуть завершити процес багатоланцюгової взаємодії за допомогою контракту на Particle Chain, не знаючи про інші ланцюги, і можуть використовувати Unified Gas Токен як єдиний спосіб оплати комісії.
Абстракція облікового запису повного ланцюга також робить можливою операцію користувача Cross-Chain, ініціюючи транзакцію цільового ланцюга через User Operation вихідного ланцюга та відповідний платіж Gas, наприклад, використання USDC Polygon для покупки NFT на базі.
Однак рішення Particle Network вимагає високого ступеня співпраці між контрактом розгортача та компонентом крос-чейн обміну повідомленнями для досягнення синхронізації багатоланцюгового облікового запису та сховища вихідного ланцюга, яке насправді має високі вимоги до оракула або крос-чейн мосту повідомлень, який він використовує (ця проблема, здається, існує у всіх схемах, пов'язаних із взаємодією повного ланцюга).
Однак синхронізація кросчейн-акаунтів користувача може гнучко налаштувати комбінацію різних мостів повідомлень, а не покладатися лише на певний міст, наприклад, стратегію, яку можна налаштувати як 2/3, покладаючись на підтвердження будь-яких двох LayerZero, Axelar і Connext для підтвердження зміни сховища в цільовому ланцюжку, що може приблизно вирішити цю проблему одноточкової залежності.
Бездоганна сумісність повного ланцюга між EVM та іншими EVM є кроком вперед в абстракції повноланцюгових облікових записів в екосистемі Ethereum
Незважаючи на те, що в ланцюжку EVM є управління ключами та уніфіковані облікові записи, все ще є місце для оптимізації в абстракції облікового запису повного ланцюга: ланцюжки, несумісні з EVM, такі як Aptos, Solana, Sui тощо, не можуть гарантувати, що адреса облікового запису смарт-контракту, створена користувачем, відповідає ланцюжку EVM; У той же час, якщо ланцюжок, що не належить до EVM, не реалізує протокол EIP-4337 з еквівалентною схемою, важко слідувати абстрактній концепції повного ланцюгового рахунку, запропонованої вище Віталіком і Particle Network.
Крім того, сам проект гаманця, сумісного з EIP-4337, має куди вдосконалюватися. Більшість вузлів-бандлерів, які використовуються смарт-гаманцями, офіційно запускаються незалежно і навіть не спілкуються один з одним, а багато проектів смарт-гаманців фактично формують власний ланцюжок, що несе в собі багато ризиків (стійкість до цензури, зручність використання). Створення єдиного інтерфейсу для більшості мереж може бути дуже складним. Одне з рішень полягає в тому, щоб запровадити дизайн, орієнтований на наміри, додати шар поверх абстракції облікового запису повного ланцюга та розглядати екосистему EIP-4337 Ethereum або нативні засоби абстракції облікових записів іншої мережі (наприклад, zkSync) як конкретні екземпляри під типом Solver/Reactor, а як вибрати правильний Solver є завданням вищого рівня. **
Беручи за приклад Particle Network, він пропонує стислу реалізацію абстракції-наміру, в той час як різні абстракції облікового запису є просто класом екземплярів рішень Intent, які включені в Solver.
По-перше, інтерфейс користувача відповідатиме за перетворення запитів природної мови або довільних взаємодій з користувачем у конкретні програмні описи, включаючи вхідні та вихідні обмеження (простіше кажучи, саме умови введення та інтервали вихідних результатів відповідають вимогам користувача), а потім один або кілька розв'язувачів у мережі Solver міститимуть специфічні вхідні та вихідні обмеження транзакцій. Контракти Forward to Solver, розгорнуті в ланцюжку (Solver має не тільки вузлові можливості, але й ончейн-контрактні частини). Контракт Solver передасть інструкцію наміру контракту Reactor (який керує обліковим записом користувача в ланцюжку), який викличе інші модулі для завершення остаточної взаємодії.
Запит користувача спочатку відомий мережі Solver, так що користувачеві не потрібно сприймати базовий ланцюжок або побудову різних абстракцій облікового запису, і ця частина залишається Solver для побудови конкретного рішення.
Звичайно, ці ідеї все ще є лише теоретичною основою, а деталі реалізації, що стоять за ними, ще не були офіційно викладені Particle Network.
В даний час ясно, що в майбутньому з'явиться конкурентний ринок Solver, і користувачі можуть ініціювати аукціони, щоб дозволити кільком Solver запропонувати різні рішення, і за допомогою локальної імітації торгівлі можна вибрати найкраще рішення і заохотити відповідний Solver. Форма заохочення залежить від розробників протоколу Solver Network (Particle Network має намір використовувати токени PNT як заохочувальні токени для свого ринку аукціонів Solver).
** Поточний намір по суті приховує складні деталі нижнього шару та абстрагує їх у вищий рівень, ** такий багаторівневий дизайн з характером протоколу TCP/IP необхідний для взаємодії користувача та досвіду розробників при бездоганній сумісності всього ланцюжка.
Прийміть масове впровадження абстракцій облікового запису
Коли ми оптимізуємо фреймворк 4337 в екосистемі Ethereum з усіх боків, а також сприяємо бездоганній сумісності між екосистемами Ethereum і інших країн, щоб підтримати широкомасштабне впровадження абстракції облікових записів, ми відчуваємо, що нам все ще потрібен продукт, який охоплює сторону пропозиції та попит. Це може зменшити використання різних продуктів і послуг Web3 кінцевими користувачами, зосередившись при цьому на розробниках послуг і знизивши поріг для розробників. **
Одним із найкращих продуктів для цієї ролі є модульний смарт-гаманець як послуга від Particle Network:
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/5c72565a4e66f037765f4870ebf1c26b.jpeg)
Сервіс надає простий у використанні набір API, які дозволяють розробникам легко інтегрувати функціонал модульної абстракції облікових записів у свої програми;
Розробники можуть використовувати сервіс для створення та управління повноланцюговими обліковими записами, ведення крос-чейн взаємодії та використання єдиного методу оплати комісії;
Такий сервіс надасть розробникам більш гнучкий і зручний спосіб створення мультичейн додатків і сприятиме широкому впровадженню абстракцій облікових записів.
На додаток до вищевказаних функцій, зручних для розробників, найважливішою особливістю є те, що модульний смарт-гаманець як послуга від Particle Network створює відкриту екологію на основі сигнатурних обчислень і орієнтований на поле абстракції облікових записів розробників, на додаток до надання самостійно розроблених абстрактних модулів продуктів облікового запису, інтеграції різних типів абстрактних продуктів і послуг облікового запису. Він може швидко сприяти прийняттю продуктів і послуг різних розробників у всій сфері абстракції облікового запису.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/9ffc21bfacc35413e4711eb656564a80.png)
Нехай технології служать попиту, після вирішення обмежень усіх ракурсів фреймворку ERC-4337, покращення досвіду розробників сприятиме просуванню більшої кількості продуктів із відмінним користувацьким досвідом, прискорюючи індустрію Web3 від фінансової індустрії, дружньої до криптопанку, до індустрії масового споживання.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Чому повна абстракція облікового запису є останньою частиною головоломки EIP-4337?
作者:Пітер Пен, співзасновник і технічний директор Particle Network &Faust,极客Web3
З 2022 року абстракція облікових записів є широко обговорюваною темою, і структура абстракції облікових записів з EIP-4337 як ядром, здається, стала загальним консенсусом у галузі. Популярність концепції наміру спонукала приділяти більше уваги таким низькопороговим компонентам взаємодії з користувачем.
Однак EIP-4337 все ще має больові точки фрагментації облікових записів Smart Account і дуже фрагментований абстрактний користувацький досвід крос-чейн облікових записів. **У цій статті використовуються такі проекти, як Biconomy, Safe Core і Particle Network, як приклади, щоб дослідити, як ще більше просунути сферу абстракції облікових записів у рамках EIP-4337. **
Розуміти концепцію "абстракції облікового запису" з точки зору абстракції транзакційного процесу
Що стосується абстракції облікового запису, Віталік неодноразово вказував, що це необхідна умова для зниження порогу користувачів Ethereum і досягнення масового прийняття, а його основне бачення полягає в тому, щоб дозволити користувачам налаштовувати метод перевірки підпису + насолоджуватися оплатою газу та ініціювати транзакції в ланцюжку без будь-яких активів (широко відомі як транзакції без газу). Тільки реалізувавши ці передумови, ми зможемо підвищити коефіцієнт конверсії нових користувачів Web3-додатків.
У минулому абстрактні пропозиції без облікового запису або гаманці смарт-контрактів, хоча вони можуть досягти подібного досвіду, далеко не гнучкі та ефективні, наприклад, Gnosis Safe все ще вимагає адрес EOA для ініціювання транзакцій, а вартість газу надзвичайно висока.
Абстракція облікових записів має намір оптимізувати з нижнього рівня структури рахунків смарт-контрактів, щоб прокласти шлях для наступного покоління інтелектуальних систем облікових записів.
Але з фактичної пропозиції абстракції рахунку ми побачимо, що вони зосереджені не на самій моделі рахунку. Наприклад, EIP-86, EIP-4337, EIP-6900 та інші пропозиції, пов'язані з абстракцією рахунків, фокусуються на абстракції/модульності всього процесу обробки транзакції від ініціації до отримання вузлом, перевірки підпису, оплати газу тощо, не особливо звертають увагу на абстракцію структури рахунку. Тому видається більш доречним називати нинішні пропозиції «транзакційними абстракціями».
Якщо ми зрозуміємо ці відомі абстрактні пропозиції облікових записів з точки зору «абстракції процесу обробки транзакцій», нам буде легше зрозуміти їхні основні моменти: ця абстракція транзакцій насправді хоче привнести досвід користувачів рівня Web2, які вводять і використовують продукти в системі Ethereum, такі як чорний список/білий список, відсутність перевірки особи для ініціювання транзакцій протягом певного періоду часу, відсутність транзакцій з газом, комісії за оплату фіатною валютою тощо.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/a966728c2d42bc95cc4199e63f9b6ae7.png)
Але деякі люди запитають: чи не могли ці речі бути реалізовані в гаманцях смарт-контрактів у минулому? У чому цінність абстрактних схем типу EIP-4337?
Суть EIP-4337: локальне оптимальне рішення абстракції облікового запису в екосистемі Ethereum
Як згадувалося в наведеному вище питанні, хоча розумні гаманці в минулому могли виконувати функції, згадані вище, методи реалізації, як правило, грубі і часто покладаються на високоцентралізовані сторонні засоби. Наприклад, у минулому схема оплати газу полягала у впровадженні стороннього вузла Relayer (EIP-2771). Крім того, відсутність єдиних стандартів між різними розумними гаманцями не сприяє розробці та розгортанню допоміжних компонентів. **
Основна привабливість EIP, пов'язана з різними абстракціями облікових записів, полягає в тому, щоб усунути ці дефекти в різних проектах гаманців за допомогою стандартизованої структури, розробленої для гаманців смарт-контрактів, і просунути структуру облікового запису в екосистемі Ethereum з базової функціональної структури в інтелектуальну структуру з більш високою стелею.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/cbe5faeb45fe0855ca3707430ce2e7d7.png)
Наприклад, до появи 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 все ще має багато невирішених проблем: ** Наприклад:
Функція абстракції облікового запису недостатньо вбудована, і різним розробникам легко винайти велосипед;
Сумісність модуля обліку погана, і вся облікова система демонструє тенденцію до фрагментації екології;
Екологія абстракції облікового запису між різними ланцюжками сильно фрагментована, що ускладнює надання уніфікованого та якісного досвіду для кінцевих користувачів та розробників та досягнення кращого UX.
Нижче ми розглянемо шляхи вирішення цих проблем.
Напрямок оптимізації 1: Функція плагіна абстракції облікового запису стане базовою конфігурацією
**Можна сказати, що одним з основних питань обговорення, пов'язаних з абстракцією облікового запису, зараз є те, як краще реалізувати модульність абстрактного гаманця облікового запису та скоротити деталізацію кожного модуля до більшої деталізації. **
Наприклад, Biconomy пропонує наратив, заснований на EIP-4337 (EIP-6900 з більш дрібною деталізацією буде представлений в майбутньому) для подальшого сприяння модульному розвитку екології абстракції облікового запису.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/48172bf745d6ba99c4709aa3b10697ed.png)
Так званий плагін функції абстракції облікового запису насправді полягає в тому, щоб за допомогою набору протоколів з'ясувати, які ключові модулі беруть участь у гаманці смарт-контрактів, які інтерфейси/функції ці модулі повинні реалізовувати, а також як ці інтерфейси називаються і як їх викликати. Потім сторонні розробники розробляють компоненти з різними деталями відповідно до власних уявлень, але ці компоненти відповідатимуть вимогам, викладеним в угоді.
Версія Biconomy V2, з EIP-4337 в якості основи протоколу, розробила більш детальні стандарти і додала ряд інтерфейсів, не згаданих в 4337. Вказуючи, які функції повинні мати такі модулі, як Bundler, Smart Contract Wallet і Paymaster, Biconomy дозволяє стороннім розробникам реалізовувати модулі з однаковими характеристиками та різними версіями з різними деталями коду, якщо вони дотримуються деталей протоколу, заздалегідь зазначених Biconomy (сумісні з EIP-4337).
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/70a918d3c0fa189323edbf381b630a84.png)
У той же час Biconomy також висунула слоган «Module Store», при особистому запуску абстрактного модуля облікового запису SDK більшості розробників пропонується представити власні розроблені абстрактні модулі облікового запису, розширити «Модуль як послуга», ** щоб всі проекти гаманців, які дотримуються протоколу EIP-4337, могли безпосередньо прийняти ці абстрактні модулі облікового запису, написані сторонніми особами. Коли користувачі створюють розумний обліковий запис через зовнішню сторінку, вони також мають більш різноманітний вибір того, які модулі використовувати.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/f96ee55f5dd8dcdaf0a1a5442fe0281a.png)
У той час як модульність зручна для розподілу праці, користувачам також зручно швидко перемикатися або додавати і видаляти певні функції в смарт-гаманці (простіше кажучи, це розділити деталізацію на більш дрібні шматочки).
У Biconomy зазначили, що чим більш модульним є гаманець смарт-контрактів, тим менше змін йому потрібно вносити при оновленні або оновленні (не потрібно оновлювати існуючі контракти гаманця смарт-контрактів користувачів або використовувати DelegateCall, лише деякі зовнішні модулі), що полегшує заміну певних компонентів різним користувачам або розробникам.
У майбутній новій абстракції облікового запису Biconomy він також стосуватиметься пропозиції EIP-6900, яка є більш модульною, ніж EIP-4337.
Напрямок оптимізації 2: Більш тонка сегментація модулів для вирішення проблеми фрагментації облікового запису
Що стосується пропозиції EIP-6900, ** Safe (раніше Gnosis Safe) фактично випустила відповідний технічний документ Safe Core Protocol у серпні цього року, і найбільш запозиченим є EIP-6900. **
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/c61f4b7e5a49dc219a785276a95cf071.png)
** EIP-6900 вказує на те, що однією з проблем нинішньої абстракції модульних рахунків є «фрагментація» рахунків, або проблема розрізненості. Наприклад, незважаючи на те, що різні постачальники модулів абстракції облікових записів або різні програми DAPP будуть сумісні з EIP-4337, EIP-4337 недостатньо високий для різних модулів, а деталізація відносно груба, залишаючи «занадто високий» ступінь свободи для розробників модулів Smart Account (розумний обліковий запис є основною частиною зберігання інформації про користувачів і запису користувацької перевірки транзакцій і логіки оплати газу).
Таким чином, різні учасники проекту гаманців, як правило, розробляють модулі розумних облікових записів з унікальними властивостями. **У довгостроковій перспективі інші постачальники модулів абстракції облікових записів повинні визначати пріоритети, які надають сумісні модулі Smart Account, і повільно створювати фіксований ланцюжок поставок вище та нижче, що неминуче призведе до фрагментації та відокремлення екології модуля абстракції облікового запису. ** (Це схоже на те, що на зорі комп'ютерної індустрії розробники операційних систем повинні були враховувати, з яким виробником комп'ютерного обладнання сумісний.)
Щоб вирішити проблему екологічної фрагментації та покращити сумісність модулів абстракції облікових записів, розроблених різними постачальниками, найкращим способом є подальше абстрагування облікових записів гаманців смарт-контрактів і підвищення деталізації модулів.
Після запозичення ідей EIP-6900 у технічному документі протоколу **Safe Core зроблено більш детальну оптимізацію Smart Account (облікового запису смарт-гаманця користувача). Протокол Safe Core розбиває модулі, які можуть бути викликані кожним обліковим записом смарт-гаманця, на плагіни, хуки, верифікатори підпису, функціональні процесори та інші категорії. **
Модуль розумного облікового запису максимально простий, контракт облікового запису зберігає лише найосновніші дані та функції, а всі функції, які можна перемістити назовні, перекидаються в модуль підрозділу «функціональний процесор» або «плагін» для реалізації. Це перегукується з так званим принципом бритви Оккама – «не додавайте сутності без необхідності».
Якщо смарт-аккаунт сам по собі досить легкий і не передбачає занадто громіздких деталей, розроблений різними виробниками смарт-аккаунт буде ближче за внутрішньою структурою і більш сумісний.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/09f83d13d3ab4398881f144c2c17aa58.png)
Протокол Safe Core також вводить реєстр, подібний до магазину додатків iPhone, який містить усі затверджені доступні модулі. Користувач може вибрати, які модулі активувати, і кожен раз, коли активується новий модуль, він обробляється через контракт Minger.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/bd45f12927186dd3b98dbd955a08c962.png)
Загалом, UserOperation спочатку запустить плагін плагіна, а потім контракт Manger перевірить, чи є статус плагіна нормальним (є запис у реєстрі), і якщо він нормальний, він дозволить запит плагіна. При необхідності, плагіни викликають деякі функції, що надаються хуком, або ні. Потім вносяться зміни до стану смарт-облікового запису, який бере участь у UserOperation.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/fd639d5a6f150f1cfcfe67cc77a79e44.png)
За допомогою вищезгаданого тонкого методу шардингу модулів і процесу планування, Safe Core Protocol намагається реалізувати набір протоколу інтероперабельності абстрактних модулів облікового запису з відкритим вихідним кодом, основна ідея якого полягає в тому, щоб зробити Smart Account легким, таким же простим, як обліковий запис EOA, щоб покращити сумісність модулів Smart Account, покращених різними постачальниками.
Напрямок оптимізації 3: Повна абстракція облікового запису, для досягнення уніфікованих облікових записів у різних мережах
Але навіть з вищезгаданим рішенням все ще існує велика проблема, яка не вирішена: різні ланцюжки та різні Layer2 просувають абстракції облікових записів з різними деталями, і багато хто використовує форми, які конфліктують з EIP-4337, такі як zkSync Era, Starknet, Flow тощо. Це призвело до фрагментації UX гаманця, наприклад, адреса смарт-гаманця користувача на Starknet і адреса розумного гаманця на Arbitrum взагалі не можуть бути уніфіковані.
Більш того, в мультичейн середовищі користувачі самостійно розгорнули Smart Accounts в різних ланцюгах, і відповідні дані користувачів часто розкидані в цих контрактах. Якщо потрібно оновити дані користувача, такі як ключі, необхідно багаторазово ініціювати транзакції в декількох ланцюжках, і важко забезпечити узгодженість Smart Account.
Сам Віталік раніше запропонував набір повноланцюгових уніфікованих і простих в управлінні схем смарт-рахунків, ** ця схема використовує Ethereum або високозахищений ZKRollup в якості вихідного ланцюжка, розгортає контракт Keystore, зберігає глобальний ключ користувача, а потім всі облікові записи смарт-контрактів користувача на L2 діляться глобальним ключем, що зберігається в контракті Keystore.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/6dbc43d45760d49029da132dab099e17.png)
Однак це рішення є надзвичайно дорогим, тобто щоразу, коли глобальний ключ, записаний у контракті Keystore у вихідному ланцюжку, змінюється, кожен обліковий запис у ланцюжку L2/target повинен синхронізувати новий ключ за допомогою крос-чейн взаємодії. Кросчейн взаємодія між Ethereum і L2 занадто дорога для користувачів, щоб дозволити собі це. І слід зазначити, що облікові записи смарт-контрактів відрізняються від облікових записів EOA, які за своєю суттю є мультичейн уніфікованими (уніфікованими між ланцюгами EVM) своїми унікальними методами генерації адрес, але облікові записи смарт-контрактів абсолютно різні, і користувачам складно отримати облікові записи смарт-контрактів з однаковою адресою в різних ланцюгах.
Particle Network придумала свій підхід до цього. Хоча загальна ідея збігається з ідеєю Віталіка, яка також полягає в тому, щоб відокремити сховище та код смарт-облікового запису, Particle Network має намір використовувати незалежний ланцюг, Particle Network Chain, як повноланцюгову базу даних зберігання смарт-облікового запису, за допомогою сторонніх крос-чейн рішень для обміну повідомленнями (LayerZero, CCIP, Axelar, Connext). і т.д.) Синхронізувати зміни користувача в сховищі облікового запису з локальним обліковим записом в інших мережах.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/083c776894d73db5ee207dc727214b5b.png)
(Абстракція мультичейн-акаунту Particle Network)
Зокрема, система абстракції облікових записів повного ланцюга Particle Network вимагає, щоб користувачі мали єдину адресу облікового запису смарт-контракту в різних ланцюжках EVM, що вимагає розгортання набору контрактів розгортання в різних ланцюгах;
Користувачі повинні ініціювати генерацію нових облікових записів у ланцюжку Particle Network Chain, після чого Particle Chain запустить контракт розгортача на всіх ланцюгах, гарантуючи, що адреси облікових записів смарт-контрактів, згенеровані для користувачів у різних ланцюгах, є однаковими, або користувачі можуть завершити процес багатоланцюгової взаємодії за допомогою контракту на Particle Chain, не знаючи про інші ланцюги, і можуть використовувати Unified Gas Токен як єдиний спосіб оплати комісії.
Абстракція облікового запису повного ланцюга також робить можливою операцію користувача Cross-Chain, ініціюючи транзакцію цільового ланцюга через User Operation вихідного ланцюга та відповідний платіж Gas, наприклад, використання USDC Polygon для покупки NFT на базі.
Однак рішення Particle Network вимагає високого ступеня співпраці між контрактом розгортача та компонентом крос-чейн обміну повідомленнями для досягнення синхронізації багатоланцюгового облікового запису та сховища вихідного ланцюга, яке насправді має високі вимоги до оракула або крос-чейн мосту повідомлень, який він використовує (ця проблема, здається, існує у всіх схемах, пов'язаних із взаємодією повного ланцюга).
Однак синхронізація кросчейн-акаунтів користувача може гнучко налаштувати комбінацію різних мостів повідомлень, а не покладатися лише на певний міст, наприклад, стратегію, яку можна налаштувати як 2/3, покладаючись на підтвердження будь-яких двох LayerZero, Axelar і Connext для підтвердження зміни сховища в цільовому ланцюжку, що може приблизно вирішити цю проблему одноточкової залежності.
Бездоганна сумісність повного ланцюга між EVM та іншими EVM є кроком вперед в абстракції повноланцюгових облікових записів в екосистемі Ethereum
Незважаючи на те, що в ланцюжку EVM є управління ключами та уніфіковані облікові записи, все ще є місце для оптимізації в абстракції облікового запису повного ланцюга: ланцюжки, несумісні з EVM, такі як Aptos, Solana, Sui тощо, не можуть гарантувати, що адреса облікового запису смарт-контракту, створена користувачем, відповідає ланцюжку EVM; У той же час, якщо ланцюжок, що не належить до EVM, не реалізує протокол EIP-4337 з еквівалентною схемою, важко слідувати абстрактній концепції повного ланцюгового рахунку, запропонованої вище Віталіком і Particle Network.
Крім того, сам проект гаманця, сумісного з EIP-4337, має куди вдосконалюватися. Більшість вузлів-бандлерів, які використовуються смарт-гаманцями, офіційно запускаються незалежно і навіть не спілкуються один з одним, а багато проектів смарт-гаманців фактично формують власний ланцюжок, що несе в собі багато ризиків (стійкість до цензури, зручність використання). Створення єдиного інтерфейсу для більшості мереж може бути дуже складним. Одне з рішень полягає в тому, щоб запровадити дизайн, орієнтований на наміри, додати шар поверх абстракції облікового запису повного ланцюга та розглядати екосистему EIP-4337 Ethereum або нативні засоби абстракції облікових записів іншої мережі (наприклад, zkSync) як конкретні екземпляри під типом Solver/Reactor, а як вибрати правильний Solver є завданням вищого рівня. **
Беручи за приклад Particle Network, він пропонує стислу реалізацію абстракції-наміру, в той час як різні абстракції облікового запису є просто класом екземплярів рішень Intent, які включені в Solver.
По-перше, інтерфейс користувача відповідатиме за перетворення запитів природної мови або довільних взаємодій з користувачем у конкретні програмні описи, включаючи вхідні та вихідні обмеження (простіше кажучи, саме умови введення та інтервали вихідних результатів відповідають вимогам користувача), а потім один або кілька розв'язувачів у мережі Solver міститимуть специфічні вхідні та вихідні обмеження транзакцій. Контракти Forward to Solver, розгорнуті в ланцюжку (Solver має не тільки вузлові можливості, але й ончейн-контрактні частини). Контракт Solver передасть інструкцію наміру контракту Reactor (який керує обліковим записом користувача в ланцюжку), який викличе інші модулі для завершення остаточної взаємодії.
Запит користувача спочатку відомий мережі Solver, так що користувачеві не потрібно сприймати базовий ланцюжок або побудову різних абстракцій облікового запису, і ця частина залишається Solver для побудови конкретного рішення.
Звичайно, ці ідеї все ще є лише теоретичною основою, а деталі реалізації, що стоять за ними, ще не були офіційно викладені Particle Network.
В даний час ясно, що в майбутньому з'явиться конкурентний ринок Solver, і користувачі можуть ініціювати аукціони, щоб дозволити кільком Solver запропонувати різні рішення, і за допомогою локальної імітації торгівлі можна вибрати найкраще рішення і заохотити відповідний Solver. Форма заохочення залежить від розробників протоколу Solver Network (Particle Network має намір використовувати токени PNT як заохочувальні токени для свого ринку аукціонів Solver).
** Поточний намір по суті приховує складні деталі нижнього шару та абстрагує їх у вищий рівень, ** такий багаторівневий дизайн з характером протоколу TCP/IP необхідний для взаємодії користувача та досвіду розробників при бездоганній сумісності всього ланцюжка.
Прийміть масове впровадження абстракцій облікового запису
Коли ми оптимізуємо фреймворк 4337 в екосистемі Ethereum з усіх боків, а також сприяємо бездоганній сумісності між екосистемами Ethereum і інших країн, щоб підтримати широкомасштабне впровадження абстракції облікових записів, ми відчуваємо, що нам все ще потрібен продукт, який охоплює сторону пропозиції та попит. Це може зменшити використання різних продуктів і послуг Web3 кінцевими користувачами, зосередившись при цьому на розробниках послуг і знизивши поріг для розробників. **
Одним із найкращих продуктів для цієї ролі є модульний смарт-гаманець як послуга від Particle Network:
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/5c72565a4e66f037765f4870ebf1c26b.jpeg)
На додаток до вищевказаних функцій, зручних для розробників, найважливішою особливістю є те, що модульний смарт-гаманець як послуга від Particle Network створює відкриту екологію на основі сигнатурних обчислень і орієнтований на поле абстракції облікових записів розробників, на додаток до надання самостійно розроблених абстрактних модулів продуктів облікового запису, інтеграції різних типів абстрактних продуктів і послуг облікового запису. Він може швидко сприяти прийняттю продуктів і послуг різних розробників у всій сфері абстракції облікового запису.
! [Чому абстракція облікового запису повного ланцюга є останньою частиною головоломки для EIP-4337?] ](https://cdn-img.panewslab.com//panews/2022/10/26/images/9ffc21bfacc35413e4711eb656564a80.png)
Нехай технології служать попиту, після вирішення обмежень усіх ракурсів фреймворку ERC-4337, покращення досвіду розробників сприятиме просуванню більшої кількості продуктів із відмінним користувацьким досвідом, прискорюючи індустрію Web3 від фінансової індустрії, дружньої до криптопанку, до індустрії масового споживання.