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.

У наступних розділах ми обговоримо рішення цих проблем.

Напрям оптимізації один: Модуляризація функціональності Plug-and-play рахунків стане базовою конфігурацією абстрагування

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

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

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

Версія V2 Biconomy, заснована на EIP-4337 як протокольному каркасі, встановила більш детальні стандарти та додала партію інтерфейсів, не згаданих у 4337. Специфікуючи функціональні можливості, якими повинні бути Bundler, Smart Contract Wallet, Paymaster та інші модулі, Biconomy дозволяє стороннім розробникам реалізувати модулі з різними деталями коду, але з схожими функціями та різними версіями, якщо вони відповідають передбаченим заздалегідь протокольним правилам Biconomy (сумісними з EIP-4337).

Тим часом Biconomy також ввів гасло "Module Store". Паралельно з активним запуском модуля 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 розбиває кожний викликаємий модуль облікового запису розумного контракту на різні категорії, такі як Плагіни, Гачки, валідатори підписів та функціональні обробники.

Модулі розумного облікового запису робляться якомога легшими, причому контракт облікового запису зберігає лише найбільш базові дані та функції, тоді як функції, які можуть бути переміщені за межі, реалізовані спеціалізованими модулями, такими як "процесори функцій" або "Плагіни". Це дотримується принципу Бритви Оккама: "Сутності не повинні бути множені непотрібно".

Якщо розумний рахунок сам по собі є досить легким і не включає занадто багато витончених деталей, розумні рахунки, розроблені різними виробниками, будуть більш схожі за внутрішньою структурою, а сумісність також буде вищою.

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

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

Через вищезгаданий процес сегментації та планування дрібнозернистих модулів Протокол безпеки ядра намагається сприяти протоколу взаємодії модулів абстракції рахунку з відкритим вихідним кодом. Його основна ідея полягає в тому, щоб зробити легкими Розумні Рахунки настільки, наскільки це можливо, роблячи їх такими простими, як рахунки EOA, щоб покращити сумісність між модулями Розумних Рахунків, розробленими різними виробниками.

Оптимізація напрямку Три: Єдина абстракція рахунку по всіх ланцюгах, досягнення однорідних рахунків на різних ланцюгах

Проте, навіть з урахуванням вищезгаданих рішень, існує ще одне серйозне невирішене питання: різні ланцюжки та різні рішення другого рівня розвивають різні схеми реалізації абстрагування рахунку з конфліктними формами, багато з яких суперечать EIP-4337, такі як zkSync Era, Starknet, Flow і т. д. Ця фрагментація в UX гаманців, наприклад, унеможливлює об’єднання адреси розумного гаманця користувача на Starknet з адресою на Arbitrum.

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

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

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

У відповідь на це, мережа Particle запропонувала власний підхід. Хоча загальна ідея узгоджується з концепцією Віталіка щодо розділення Сховища та Коду розумних рахунків, мережа Particle планує використовувати окремий ланцюг - Ланцюг мережі Particle - як повний ланцюговий Сховище бази даних для розумних рахунків. За допомогою рішень про спільне пересилання міжланцюжкових повідомлень від сторонніх постачальників (таких як LayerZero, CCIP, Axelar, Connext тощо), мережа Particle має намір синхронізувати зміни в Сховищі рахунку з місцевими Рахунками інших ланцюгів.

(Багатоланкова структура абстрагування рахунку Particle Network)

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

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

Проте рішення Particle Network потребує високоорганізованих зусиль між контрактами Deployer та компонентами міжланцюжкового обміну повідомленнями для синхронізації облікових записів на багатьох ланцюгах та джерело-ланцюжкового сховища. Це ставить високі вимоги до використаного оракула або моста міжланцюжкового обміну повідомленнями (виклик, що, схоже, існує в усіх рішеннях, пов'язаних з повною міжланцюжковою взаємодією).

Однак синхронізацію облікових записів користувачів між ланцюжками можна гнучко налаштувати з різними комбінаціями Посланців повідомлень, а не покладатися лише на одного Посланця. Наприклад, її можна налаштувати з політикою 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 всередині схеми намірів.

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

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

Звісно, ці ідеї наразі лише теоретична концепція, а деталі реалізації все ще очікують на офіційне впровадження з боку мережі Particle. Очевидно, що у майбутньому обов'язково з'явиться конкурентний ринок рішень, де користувачі зможуть ініціювати аукціони для кількох Рішень, щоб запропонувати різні рішення. Шляхом місцевих симульованих транзакцій може бути вибрано оптимальне рішення, і відповідному Рішенню може бути винагороджено. Щодо форми стимулів, це залежить від уваги протоколу дизайнерів мережі Рішень (мережа Particle намір використовувати токени PNT як стимули для свого аукціонного ринку Рішень).

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

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

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

Одним з найкращих продуктів для виконання цієї ролі є продукт Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) від Particle Network:

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

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

Алігнувавши технологію з попитом і вирішивши обмеження рамки ERC-4337 з усіх сторін, покращення досвіду розробника каталізує появу більшої кількості продуктів з видатними користувацькими враженнями. Це прискорить перехід відраслі Web3 від крипто-ентузіастів-орієнтованої на фінанси до споживачоорієнтованої та масової.

Disclaimer：

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