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

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

Розуміння концепції абстракції облікового запису з погляду абстракції потоку транзакцій

Що стосується абстракції облікового запису, Віталік неодноразово вказував, що це необхідна умова для зниження порогу користувачів Ethereum і досягнення масового прийняття. Його основне бачення полягає в тому, щоб дозволити користувачам налаштувати метод перевірки підпису та насолоджуватися оплатою газу, а також ініціювати транзакцію в мережі без будь-яких активів (широко відома як безгазова транзакція). Лише усвідомлюючи ці передумови, Web3-додатки можуть покращити коефіцієнт конверсії користувачів. Хоча попередні абстрактні пропозиції, не пов'язані з обліковим записом, або гаманці смарт-контрактів можуть досягти подібного досвіду, вони далеко не достатньо гнучкі та ефективні. Наприклад, Gnosis Safe все ще вимагає EOA-адресу для ініціювання транзакцій, а витрати на газ, пов'язані з цим, надзвичайно високі. Абстракція облікового запису спрямована на оптимізацію базової структури облікових записів смарт-контрактів, прокладаючи шлях для наступного покоління інтелектуальних систем облікових записів. Але якщо ми подивимося на фактичні пропозиції абстракції рахунку, то виявимо, що вони зосереджені не на самій моделі рахунку. Наприклад, пропозиції, пов'язані з абстракцією облікового запису, такі як EIP-86, EIP-4337 і EIP-6900, зосереджені на абстракції/модульності всього процесу обробки транзакції від ініціації до отримання вузлами, а також на перевірці підпису, оплаті газу тощо, а не зосереджуються на абстракції структури рахунку як такої. Абстракція структури рахунку. Тому представляється більш доречним називати різні поточні пропозиції «абстракціями трансакційного потоку». Якщо ми зрозуміємо ці добре відомі пропозиції щодо абстракції облікового запису з точки зору абстракції потоку транзакцій, нам буде легше зрозуміти їхні основні моменти: цей вид абстракції транзакцій насправді спрямований на те, щоб перенести користувацький досвід входу на рівень Web2 та використання продукту в систему Ethereum. Це може відбуватися у формі чорних/білих списків, ініціювання трасакцій без підтвердження особи протягом певного періоду часу, безгазових транзакцій, платежів у фіатній валюті тощо.

(Джерело зображення: Zengo)

Проте деякі можуть запитати: Чи не можна було досягти цих речей існуючими гаманцями для розумних контрактів у минулому? Яка цінність рішень з абстракції облікового запису, таких як EIP-4337?

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

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

(Джерело зображення: Springer Link)

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

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

У кінці кінців, EIP-4337 виділяється.

EIP-4337 є місцевим оптимальним рішенням, але кілька перспектив всередині його рамок потребують оптимізації

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

1. Абстракція облікового запису не настільки проста для інтеграції, що призводить до того, що різні розробники ненавмисно «винаходять велосипед».

2. Погана сумісність між модулями облікових записів, що призводить до фрагментації екосистеми.

3. Висока фрагментація екосистеми абстракції облікового запису на різних ланцюгах ускладнює надання єдиної високоякісної ​​досвіду для кінцевих користувачів та розробників.

Нижче ми дослідимо рішення для цих проблем.

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

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

(Джерело зображення: Biconomy)

Так званий плагін абстракції облікового запису фактично призначений для створення протоколу, який явно визначає ключові модулі, що беруть участь у гаманці для управління смарт-контрактами, виокремлюючи інтерфейси/функції, які ці модулі повинні виконувати, і вказуючи назви та методи виклику цих інтерфейсів. Сторонні розробники потім створюватимуть компоненти з різними деталями на основі своїх ідей, забезпечуючи відповідність цих компонентів вимогам, викладеним у протоколі.

Biconomy’s v2, розроблений на основі EIP-4337 як протокольного каркасу, розробив більш детальні стандарти та ввів набір інтерфейсів, не згаданих в EIP-4337. Під час оголошення функціональності, якою повинні володіти зв'язувальники, розумні контрактні гаманці, платника та інші модулі, Biconomy дозволяє стороннім розробникам реалізувати модулі з такими ж функціями, але різними версіями, використовуючи різні деталі коду, поки вони дотримуються установлених Biconomy протокольних керівництв (сумісних з EIP-4337).

(Стандарти інтерфейсу, запропоновані Biconomy, вказують, які функції повинні реалізувати розробники сторонніх модулів у своїх модулях для зовнішніх викликів). Крім того, Biconomy ввів гасло «Module Store», активно пропагуючи запуск модуля SDK абстракції акаунту, одночасно закликаючи розробників надсилати свої власні розроблені модулі абстракції облікового запису. Ця ініціатива спрямована на просування «модуля як сервісу», що дозволяє всім проектам гаманців дотримуватися протоколу EIP-4337 безпосередньо приймати ці зовні розроблені модулі абстракції облікового запису. Користувачі тепер мають більше різноманітних варіантів щодо вибору модулів для використання при створенні розумних облікових записів через фронтенд.

Модульність дозволяє не лише сприяти поділу праці, але й дозволяє користувачам швидко перемикати або додавати/видаляти певні функції в розумному гаманці. Щоб висловитися прямо, це дозволяє вдосконалити дрібність компонентів. Biconomy вказує, що чим вищий рівень модульності в розумному контрактному гаманці, тим менше змін потрібно буде вносити при оновленні або модернізації. Не потрібно оновлювати існуючий контракт гаманця користувача або використовувати DelegateCall, лише деякі зовнішні модулі потрібно оновити, що дозволяє зручно заміняти певні компоненти для різних користувачів або розробників.

У майбутній оновленій схемі абстракції облікових записів компанії Biconomy вони також розглянуть EIP-6900, який сприяє модуляризації більше, ніж EIP-4337.

Оптимізація рішення 2: Додаткова дрібничкова сегментація модуля для вирішення проблем фрагментації облікових записів

Стосовно EIP-6900, Safe (раніше Gnosis Safe) випустила білу книгу Safe Core Protocol в серпні цього року, яка в значній мірі позичена з EIP-6900.

(Схема EIP-6900) EIP-6900 висвітлює поширену проблему в поточній модульній абстракції рахунків, тобто «фрагментацію» рахунків, або проблему острова. Наприклад, хоча різні постачальники модулів абстракції облікових записів або різні DApps можуть бути сумісні з EIP-4337, його рівень абстракції в різних модулях є недостатнім, з відносно низькою деталізацією. Цей сценарій надає «надмірну» свободу розробникам модулів смарт-акаунтів (смарт-обліковий запис є основним компонентом, який зберігає інформацію про користувачів, записує користувацьку перевірку транзакцій і обробляє логіку оплати газу) створювати модулі з унікальними атрибутами. Як наслідок, з часом різні проекти гаманців, як правило, розробляють модулі розумних облікових записів з різними властивостями. Ця тенденція змушує інших постачальників модулів абстракції облікових записів надавати пріоритет сумісності з конкретними постачальниками модулів інтелектуальних облікових записів, поступово формуючи фіксовані ланцюжки поставок up-downstream. Це неминуче призводить до фрагментації та ізоляції екосистеми модулів абстракції облікових записів (подібно до ранніх днів у комп'ютерній індустрії, де розробникам операційних систем доводилося враховувати сумісність з апаратним забезпеченням різних виробників). Для вирішення проблеми фрагментації екосистеми та підвищення сумісності між модулями абстракції облікових записів, розробленими різними постачальниками, оптимальним підходом є подальше абстрагування облікових записів гаманців смарт-контрактів та уточнення деталізації сегментації модулів. Дотримуючись принципів, викладених у EIP-6900, у технічному документі Safe Core Protocol було проведено детальну оптимізацію смарт-облікових записів (інтелектуальних облікових записів гаманців користувачів). Протокол Safe Core розбиває модулі, які можна викликати, у кожному обліковому записі смарт-гаманця на різні категорії, такі як плагіни, хуки, валідатори підписів, функціональні процесори тощо. Модулі інтелектуальних облікових записів мають бути максимально легкими, зберігаючи лише важливі дані та функції, делегуючи рухомі функції «функціональним процесорам» або подібним сегментованим модулям. Такий підхід узгоджується з принципом бритви Оккама – «сутності не повинні множитися без потреби». Якщо розумні облікові записи самі по собі досить легкі і не передбачають занадто складних деталей, розумні облікові записи, розроблені різними провайдерами, будуть демонструвати більш тісну внутрішню структуру і більш високу сумісність.

Протокол безпечного ядра також вводить реєстр (схожий на магазин додатків для iPhone), який містить всі затверджені та доступні модулі. Користувачі можуть вибирати, які модулі активувати, і кожного разу, коли активується новий модуль, він повинен бути оброблений через Manger.

Зазвичай UserOperation спочатку спрацює плагін, а потім Менеджер перевірить, чи статус плагіна є нормальним (записаний в реєстрі). Якщо все нормально, буде дозволено запит плагіна. При необхідності плагін викличе деякі функції, надані Hook, або може вибрати не викликати їх. Пізніше буде змінено статус розумного облікового запису, залученого в UserOperation.

За допомогою вищенаведеного методу дрібнозернової сегментації модулів та процесу планування Safe Core Protocol намагається реалізувати набір протоколів взаємодії модулів абстрагування облікового запису з відкритим кодом. Основна ідея полягає в тому, щоб зробити розумний обліковий запис легким та таким же простим, як обліковий запис EOA, для підвищення сумісності між розумними обліковими записами модулів від різних постачальників.

Оптимізація рішення 3: Omnichain Account Abstraction для об'єднаних облікових записів на різних ланцюгах

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

(Джерело зображення: https://vitalik.ca/general/2023/06/20/deeperdive.html)

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

(Багатоланкова структура абстракції облікового запису мережі часток)

Зокрема, система уніфікованого облікового запису Omnichain мережі Particle Network дозволяє користувачам мати єдину адресу облікового запису розумного контракту на різних EVM ланцюгах. Це передбачає розгортання набору контрактів Deployer на різних ланцюгах; користувачам потрібно спровокувати генерацію нових облікових записів на ланцюгу Particle Network, і потім ланцюг Particle буде спровоковувати контракти Deployer на всіх ланцюгах, щоб забезпечити належність адрес рахунків розумних контрактів, згенерованих для користувачів на різних ланцюгах. З альтернативи, користувачі можуть взаємодіяти з кількома ланцюгами через контракти на ланцюзі Particle, не знаючи про інші ланцюги, і можуть використовувати Unified Gas Token як універсальний метод оплати комісій за транзакції.

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

Однак рішення Particle Network вимагає високого ступеня співпраці між контрактом розгортача та компонентом крос-чейн обміну повідомленнями для досягнення синхронізації багатоланцюгових облікових записів та сховища вихідного ланцюга. Це фактично висуває вищі вимоги до використовуваного оракула або крос-чейн мосту повідомлень (що, здається, є загальною проблемою у всіх рішеннях, пов'язаних із сумісністю омнічейну). Однак синхронізація кросчейн-акаунтів користувача може гнучко налаштувати комбінацію різних мостів повідомлень замість того, щоб покладатися на один міст. Наприклад, його можна налаштувати як стратегію 2/3, покладаючись на підтвердження будь-яких двох LayerZero, Axelar і Connext для підтвердження змін сховища в цільовому ланцюжку. Це може бути потенційним вирішенням проблеми одноточкової залежності.

Безшовна взаємодія між ланцюгами через EVM та не-EVM - це ще один крок у напрямку абстракції облікового запису в межах екосистеми Ethereum

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

Прийняття масового використання абстракції рахунку

Після оптимізації каркасу EIP-4337 в екосистемі Ethereum з різних аспектів та просування безшовної взаємодії між екосистемами Ethereum та не-Ethereum, ми вважаємо, що для підтримки масового прийняття абстракції облікового запису нам все ще потрібен продукт, який охоплює сфери подання та попиту. Цей продукт повинен зменшувати складність для кінцевих користувачів, які використовують різноманітні послуги продуктів Web3, одночасно зосереджуючись на зниженні бар'єрів для вступу розробника. Один з оптимальних продуктів, які виконують цю роль, - це Модульний Стек Смарт-Гаманця-як-Сервісу мережі Particle:

(Архітектура Смарт-Гаманця-як-Сервіс Мережі Particle)

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

Крім вищезазначених функцій, спрямованих на розробників, найважливішим аспектом стеку Modular Smart Wallet-as-a-Service мережі Particle Network є те, що він побудував відкриту екосистему для домену абстракції рахунку, засновану на обчисленні підпису і орієнтовану на розробників. Паралельно з їхніми внутрішніми модулями продуктів абстракції рахунку, мережа Particle Network інтегрує різні типи продуктів та послуг з абстракції рахунку. Ця інтеграція прискорює прийняття продуктів та послуг по всьому домену абстракції рахунку для розробників.

(Модульна конструкція смарт-гаманця Particle Network як послуга)Дозвольте технології задовольняти потреби користувачів. Після вирішення обмежень фреймворку ERC-4337 покращення досвіду розробників призведе до появи більшої кількості продуктів із чудовим користувацьким досвідом, прискоривши перехід Web3 від фінансової індустрії, дружньої до криптопанку, до індустрії, дружньої до споживачів для широких мас.

Disclaimer：

1. Ця стаття передрукована з [Web3 гік]. Усі авторські права належать оригінальному автору [Пітер Пен, співзасновник та головний технічний директор Particle Network & Faust, 极客Web3]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони вирішать це негайно.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення чи плагіат перекладених статей заборонені.