Абстракція рахунку проти нативної абстракції рахунку

Простіше кажучи, абстракція облікового запису в ERC-4337 - це додаткова інфраструктура в блокчейні. Ви можете вибрати, приймати його чи ні. Після прийняття він забезпечить подібні функції до контрактних рахунків (КР), такі як мультипідпис, сплата за газ токенами ERC-20, соціальне відшкодування та інше. Багато постачальників послуг, наприклад, стекап, працюють над цією інфраструктурою. Однак ця інфраструктура не отримала широкого розповсюдження з наступних причин:

• Проблема бандлерів: у верифікації беруть участь лише бандлери, що призводить до надмірної залежності від бандлерів.
• Недостатній прибуток для бандлерів: Це головним чином пов'язано з малим масштабом, що вимагає від більшої кількості DApps обирати інфраструктуру Account Abstraction для економії плати за газ.
• Концентрація бандлерів: Пакувальники зосереджені у кількох постачальників (Alchemy, Pimlico, Stackup), що створює ризики централізації.
• Коефіцієнт утримання: За винятком аірдропів, рівень утримання користувачів у сервісах абстракції акаунтів дуже низький.

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

У цій статті згадуються деякі терміни, такі як різниця між EOA і CA (простіше кажучи, метамаска - це EOA, контракти - CA), а також бандлери (в екосистемі Account Abstraction користувачі надсилають UserOperations бандлерам для пакування і обробки в ланцюжку, замість того, щоб надсилати їх вузловим валідаторам/Mempool). Для отримання детальних пояснень ви можете перейти за посиланнями на дві статті, згадані вище, а також звернутися до раніше опублікованих статей на Gate Learn.

Що таке RIP-7560?

RIP-7560 - це пропозиція щодо покращення абстрагування рахунків (EIP-2938/ERC-4337). Впровадження нового типу транзакції "AA_TX_TYPE" включає в себе інші ролі, крім продавця пакета (будівельника блоків / валідатора вузлів) на етапах перевірки і виконання транзакції. Він більше не покладається виключно на продавця пакунків для пакування та відправлення по ланцюжку, таким чином вирішуючи проблеми централізації, про які згадувалося раніше. Крім того, RIP-7560 забезпечує стандартизований дизайн, що гарантує більшу відповідність для майбутніх користувачів. У цій статті ми детальніше розглянемо стандарти, вдосконалені пропозицією RIP-7560, і відповімо на підняті питання.

Найбільш фундаментальна зміна

Це зміна протоколу на рівні консенсусу \\.
Найперша пропозиція щодо абстракції облікових записів була фактично зроблена у вересні 2020 року EIP-2938. Врешті-решт вона була прийнята спільнотою і розгорнута на Ethereum. Причина, чому ERC-4337 було прийнято замість 2938, полягає в тому, що 4337 не вимагає змін на рівні консенсусу, що робить його відносно легшим для прийняття спільнотою.

На відміну від ERC-4337, пропозиція RIP-7560 передбачає більші зміни, зокрема на рівні протоколу рівня консенсусу (префікс RIP вказує на те, що це пропозиція нижчого рівня для покращення технології Rollup). Відповідною перевагою є можливість уникнути прямої залежності від інфраструктури рідного ланцюга L2.

Впровадження нового типу транзакцій \\ Впровадження нового типу транзакцій \\ Впровадження нового типу транзакцій
Введено новий тип транзакції: четвертий тип транзакції, також відомий як "AA_TX_TYPE" (який був запропонований в старому документі EIP-2938). Він не тільки підтримує всі функції типового CA (такі як оплата за газ та функції періодичних автоматичних платежів, згадані в статті Visa), але, на відміну від ERC-4337, він також дозволяє існуючим ЕОА надсилати транзакції. Це означає, що ця пропозиція має на меті сприяти більш широкому прийняттю.

Логіка виконання транзакцій

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

Блок-схема виконання (Джерело: GitHub документ RIP-7560)

Основні занепокоєння щодо Пропозиції

Під час обговорення на форумі Ethereum Magicians автор підняв наступні питання: RIP-7560: Абстракція нативного облікового запису

Чи обмежить це розвиток сервісів абстрагування облікових записів на основі намірів?

Очікується, що основними гравцями на ринку послуг на основі намірів стануть Uniswap V4 і UniswapX, причому UniswapX планує розвивати послуги з абстрагування облікових записів. Крім того, подібний напрямок був запропонований ERC-7521. У відповідь на обговорення спільноти один з авторів цієї пропозиції, Йоав Вайс, згадав, що поряд з RIP-7560 існує також правило перевірки абстракції облікових записів, яке називається ERC-7562. Дизайн системи намірів можна зробити сумісним лише з RIP-7560, а не з правилом верифікації. Потім можна використовувати окрему мережу вирішувача намірів, що дозволить користуватися перевагами RIP-7560, не вступаючи в конфлікт з дизайном намірів.

Ризик незворотності

Дехто в спільноті ставить під сумнів, що ця пропозиція схожа на "спробу вбудувати операційну систему в голий метал", що створює значні ризики. На це відповів Йоав Вайс: Ця пропозиція призначена для ланцюжків, які вирішили вбудувати операційну систему (наприклад, ERC-4337) в "голий метал", а саме для ланцюжків L2, які вирішили розгорнути власну абстракцію облікових записів. В екосистемі Ethereum є достатньо варіантів, і користувачі можуть обрати інші ланцюжки L2, які не використовують нативну абстракцію облікових записів.

Міркування щодо складності та вартості

Щодо занепокоєння складністю і, як наслідок, високою вартістю пропозиції, Дрор Тірош, один з авторів, відповів, що це притаманно самій абстракції бухгалтерського обліку. Абстракція облікового запису пов'язана з тим, що ми хочемо перевіряти зовнішні дані за допомогою загального EVM-коду. Усунення цієї складності зробить виробників блоків вразливими до DoS-атак або вимагатиме відмови від загального використання коду EVM, що суперечить меті розробки технології абстракції облікових записів.

Висновок

Наразі принаймні провайдери інфраструктури абстракції рахунків, такі як засновник Stackup, вітають такі зміни на рівні консенсусу, що свідчить про те, що основні проблеми, пов'язані з послугами абстракції поточних рахунків, все ще залишаються актуальними. Якщо недостатня кількість dApps прийме це рішення, щоб зменшити плату за газ і запровадити зручні для користувача функції, подібні до CA, то постачальники пакетних послуг не отримають прибутку, а показники утримання користувачів ніколи не зростуть. Однак, якщо сервіси, розроблені на основі цієї пропозиції, зможуть безперешкодно підтримувати існуючі EOA в ланцюжку, щоб підтримувати абстракцію облікових записів, ми будемо ближче до кінцевої мети (масове прийняття, метамаски, що підтримують абстракцію облікових записів тощо), а користувацький досвід взаємодії з DApps буде поступово покращуватися.