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

Автор: Руі

Складено: Shenchao TechFlow

Оригінальний звіт англійською мовою, опублікований у вересні 2023 року

представити

Перехід від зовнішніх облікових записів (EOA) до облікових записів смарт-контрактів (SCA) процвітає, і його підтримують багато ентузіастів, у тому числі й сам Віталік. Незважаючи на хвилювання, впровадження SCA не було таким поширеним, як EOA. Ключові проблеми включають виклики ведмежого ринку, занепокоєння міграцією, проблеми підпису, накладні витрати на газ і, що найважливіше, інженерні проблеми.

Однією з найважливіших переваг Account Abstraction (AA) є можливість налаштовувати функціональність за допомогою коду. Однак основною інженерною проблемою є несумісність функціональних можливостей АА, і ця фрагментація перешкоджає інтеграції та відкриває двері для блокування постачальника. Крім того, забезпечення безпеки під час оновлення та одночасного поєднання функцій може бути складним.

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

AA Короткий опис

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

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

• Рівень протоколу: деякі протоколи самі забезпечують підтримку абстракції локального облікового запису. Транзакції ZKsync, від EOA чи SCA, дотримуються одного процесу, використовуючи єдиний пул пам’яті та процес транзакцій для підтримки AA, тоді як Starknet видалив EOA та всі облікові записи. Обидва є SCA , і вони мають рідні гаманці зі смарт-контрактами, такі як Argent.
• Контрактний рівень: для Ethereum і його еквівалента L2 ERC4337 представляє окремий запис транзакції для підтримки AA без зміни рівня консенсусу. Такі проекти, як Stackup, Alchemy, Etherspot, Biconomy, Candide і Plimico, створюють інфраструктуру пакетувальника, а проекти, такі як Safe, Zerodev, Etherspot і Biconomy, створюють стеки та SDK.

Дилеми прийняття SCA

Тема абстракції облікового запису (AA) обговорюється з 2015 року, і цього року її привернув ERC4337. Однак кількість розгорнутих облікових записів смарт-контрактів все ще набагато менша, ніж у EOA.

Давайте заглибимося в цю дилему:

Вплив на ведмежий ринок: Хоча АА запровадив такі переваги, як безпроблемний вхід і відбір газу, люди, які зараз відчувають ведмежий ринок, в основному складаються з освічених користувачів EOA, а не з нових користувачів, тому це не підходить для dApps і гаманців. Ні. заохочення. Незважаючи на це, деякі провідні додатки все ще поступово впроваджують AA, як-от Cyberconnect, який забезпечив близько 360 000 транзакцій UserOps (транзакцій AA) лише за один місяць, представивши свою систему AA та рішення без газу.

Перешкоди міграції: Для гаманців і програм, які накопичили користувачів і активи, безпечне та зручне переміщення активів залишається проблемою. Однак такі ініціативи, як EIP-7377, дозволяють EOA ініціювати транзакції одноразової міграції.

Проблема з підписом: Сам розумний контракт не може підписати повідомлення, оскільки він не має закритого ключа, як EOA. Зусилля, такі як ERC1271, роблять таке підписання можливим, але підписання повідомлень не працює до першої транзакції, що створює проблему для гаманців, які використовують контрфактичні розгортання. ERC-6492, запропонований Ambire, є зворотно сумісним наступником ERC-1271 і може вирішити попередні проблеми.

Накладні витрати на газ: Розгортання, моделювання та виконання SCA потребує вищих витрат, ніж стандартний EOA. Це стає перешкодою для усиновлення. Однак для зменшення цих витрат було проведено деякі тести, наприклад, відокремлення створення облікового запису від дій користувача та розгляд питання про скасування солі облікового запису та перевірки існування.

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

У цій статті ми глибше розглянемо п’яту проблему: інженерні проблеми.

Модульні смарт-контрактні облікові записи для вирішення інженерних проблем

Подальше пояснення інженерних проблем таке:

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

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

Ці терміни об’єднують загальну концепцію: побудова модульної архітектури абстракції облікового запису (Modular AA).

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

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

Модульна структура: основний рахунок і модулі

Уповноважений дзвінок і договір проксі

Зовнішні дзвінки та виклики делегатів:

Хоча delegatecall схожий на виклик, замість виконання цільового контракту у власному контексті він виконує цільовий контракт у поточному стані виклику контракту. Це означає, що будь-які зміни стану, внесені цільовим контрактом, будуть застосовані до сховища контракту виклику.

Щоб реалізувати структуру, яку можна складати та оновлювати, необхідні базові знання, які називаються «агентським контрактом».

• Агентський контракт: звичайні контракти зберігають свою логіку та статус і не можуть бути оновлені після розгортання. Проксі-контракт використовує делегат для виклику іншого контракту. Реалізація функції за посиланням, яка виконується в поточному стані контракту агента.
• Випадок використання: хоча договір проксі залишається незмінним, ви можете розгортати нові реалізації за проксі. Проксі-контракти використовуються для оновлення, їх дешевше розгортати та підтримувати в загальнодоступних блокчейнах.

Безпечна архітектура

Safe — це провідна модульна інфраструктура розумних облікових записів, розроблена для забезпечення перевіреної в боях безпеки та гнучкості, дозволяючи розробникам створювати різноманітні програми та гаманці. Варто зазначити, що багато команд створюють або надихають Safe. Biconomy запускає свій обліковий запис, розширюючи нативний мультипідпис 4337 і 1/1 на Safe. З понад 164 000 розгорнутими контрактами та заблокованою вартістю понад 30,7 мільярдів доларів, Safe, безсумнівно, є найкращим вибором у цій сфері.

Структура сейфа

• Договір безпечного облікового запису: договір основного агента (з урахуванням стану)

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

• Договір Singleton: центр інтеграції (без громадянства)

Синглтон обслуговує обліковий запис Safe та інтегрує та визначає різні інтеграції, включаючи плагіни, хуки, обробники функцій і засоби перевірки підписів.

• Контракт модуля: спеціальна логіка та функції

Модулі дуже потужні. Будучи модульним типом, плагіни можуть визначати різні функції, такі як потоки платежів, механізми відновлення та ключі сеансу, і слугувати міжланцюжковим мостом між Web2 і Web3 шляхом отримання даних поза мережею. Інші модулі, такі як Hooks, діють як охоронці, а обробники функцій реагують на будь-які інструкції.

Що відбувається, коли ми приймаємо Safe

• Контракти з можливістю оновлення:

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

• Компоновані та багаторазово використовувані модулі:

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

ERC-2535 Алмазний агент

Про ERC2535 і Diamond Agent

ERC2535 стандартизує Diamond Agent, модульну систему смарт-контрактів, яку можна оновити/розширити після розгортання та майже не має обмежень щодо розміру. Наразі цим надихалися багато команд, наприклад Zerodev’s Kernel і Soul Wallet експерименти.

**Що таке алмазна структура? **

• Diamond Contract: Контракт основного агента (Stateful) Diamond — це проксі-контракт, який викликає функції від своєї реалізації через виклики делегатів.
• Модулі/плагіни/фасетні контракти: спеціальна логіка та функціональність (без стану). Модуль або так званий фасет — це контракт без стану, який може розгортати свої функції в одному чи кількох Diamonds. Це незалежні контракти, які можуть спільно використовувати внутрішні функції, бібліотеки та змінні стану.

**Що станеться, коли ми приймемо Diamond? **

• Контракти з можливістю оновлення: Diamond забезпечує систематичний спосіб ізоляції різних плагінів і з’єднання їх разом, а також безпосереднього додавання/заміни/видалення будь-якого плагіна за допомогою функції diamondCut. Немає обмежень щодо кількості плагінів, які можна додати до Diamond з часом.
• Модульні та багаторазові плагіни: розгорнутий плагін може використовуватися будь-якою кількістю Diamonds, що значно знижує витрати на розгортання.

Різниця між Safe Smart Account і Diamond Method

Між архітектурами Safe і Diamond є багато подібностей, обидві покладаються на проксі-контракти як ядро та посилаються на логічні контракти для можливості оновлення та модульності.

Однак основна відмінність полягає в обробці логічних контрактів. Ось докладніші інструкції:

• Гнучкість: з увімкненим новим плагіном Safe потрібно повторно розгорнути свій синглтон-контракт, щоб запровадити зміни у своєму агенті. Навпаки, Diamond робить це безпосередньо через функцію diamondCut у своєму делегаті. Ця відмінність у підході означає, що Safe зберігає вищий ступінь контролю, тоді як Diamond забезпечує більшу гнучкість і модульність.
• Безпека: наразі delegatecall використовується в обох структурах, що дозволяє зовнішньому коду маніпулювати сховищем основного контракту. У безпечній архітектурі delegatecall вказує на один логічний контракт, тоді як Diamond використовує delegatecall між кількома контрактами модулів (плагінами). Таким чином, зловмисний плагін може перезаписати інший плагін, створюючи таким чином ризик конфліктів зберігання, які можуть поставити під загрозу цілісність агента.
• Вартість: Гнучкість, властива підходу Diamond, супроводжується підвищеними проблемами безпеки. Це збільшує вартість і вимагає повного аудиту кожного разу, коли додається новий плагін. Головне — забезпечити, щоб ці плагіни не заважали функціональності один одного, що може стати проблемою для малих і середніх підприємств, які намагаються підтримувати високі стандарти безпеки.

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

Порядок модулів: валідатор, виконавець і хук

Давайте розширимо наше обговорення, представивши стандарт, запропонований командою Alchemy, ERC6900, який був натхненний Diamond і спеціально адаптований для ERC-4337. Він вирішує проблему модульності в розумних облікових записах, надаючи загальний інтерфейс і координуючи роботу між розробниками плагінів і гаманців.

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

• Перевірка: переконайтеся в автентичності та авторитетності облікового запису абонента.
• Виконання: Виконайте будь-яку спеціальну логіку, дозволену обліковим записом. *Гак: як модуль, який запускається до або після іншої функції. Це може змінити стан або призвести до скасування всього виклику.

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

Виявлення та захист модулів

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

Safe{Core}Протокол

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

• Обліковий запис: у протоколі Safe{Core} концепція облікового запису є гнучкою та не обмежена певною реалізацією. Це дозволяє брати участь різним постачальникам облікових записів.
• Менеджер: Менеджер діє як координатор між обліковими записами, реєстрами та модулями. Він також відповідає за безпеку, діючи як рівень дозволів.
• Реєстр: реєстр визначає атрибути безпеки та забезпечує виконання стандартів модулів, таких як ERC6900, з метою створення відкритого середовища «магазину програм» для виявлення та безпеки.
• Модулі: модулі обробляють функціональні можливості та надаються в різних початкових типах, включаючи плагіни, хуки, засоби перевірки підпису та обробники функцій. Розробники можуть сприяти цьому, якщо вони відповідають встановленим стандартам.

Дизайн зі стразами

Процес розгортається наступним чином:

• Створення визначення схеми: схема служить попередньо визначеною структурою даних для доказу. Підприємства можуть налаштувати шаблон відповідно до конкретних випадків використання.
• Створення модуля на основі шаблону: смарт-контракт реєструється як модуль, отримує байт-код і вибирає ідентифікатор шаблону. Потім ці дані зберігаються в реєстрі.
• Отримати сертифікат модуля: перевіряльник/аудитор може надати сертифікати для модуля відповідно до схеми. Ці сертифікати можуть містити унікальні ідентифікатори (UID) і посилання на інші сертифікати для зв’язування. Їх можна поширювати в ланцюжку та перевіряти, чи досягаються певні порогові значення в цільовому ланцюжку.
• Використовуйте аналізатори для реалізації складної логіки: аналізатори необов’язково встановлюються в шаблоні. Їх можна викликати під час створення модуля, встановлення перевірки та демонтажу. Ці аналізатори дозволяють розробникам включати складну та різноманітну логіку, зберігаючи структуру доказу.
• Зручний доступ із запитами: Query надає користувачам спосіб доступу до інформації про безпеку з інтерфейсу. EIP можна знайти тут.

Незважаючи на те, що ця модель все ще перебуває на ранніх стадіях, вона має потенціал для встановлення стандарту децентралізованим і спільним способом. Їхній реєстр дозволяє розробникам реєструвати свої модулі, аудиторам — перевіряти їхню безпеку, гаманцям — інтегрувати, а користувачам — легко знаходити модулі та перевіряти інформацію про їхню атестацію. У майбутньому можуть бути наступні способи використання:

• Сертифікатор: довірені організації, такі як Safe, можуть співпрацювати з Rhinestone як сертифікатори для внутрішніх модулів. У той же час незалежні перевіряльники також можуть приєднатися.
• Розробники модулів: із формуванням відкритого ринку розробники модулів можуть комерціалізувати свою роботу через реєстр.
• Користувачі: за допомогою зручних інтерфейсів, таких як гаманці або dApps, користувачі можуть переглядати інформацію про модулі та делегувати довіру різним перевіряльникам.

Концепція «реєстру модулів» надає можливості отримання прибутку для розробників плагінів і модулів. Це також може прокласти шлях до «ринку модулів». Деякі з цих аспектів можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізовані ринкові майданчики, які запрошують усіх долучитися та забезпечити прозорий контрольний слід. Застосовуючи такий підхід, ми можемо уникнути прив’язки до постачальника та підтримати розширення EVM, забезпечуючи кращий досвід користувача, який привертає увагу ширшої аудиторії.

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

Підведіть підсумки

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

Однак модульні облікові записи смарт-контрактів (SCA) — це лише одна частина головоломки впровадження. Для повної реалізації потенціалу SCA також потрібна підтримка протокольного рівня з боку рішень другого рівня, а також потужна інфраструктура пакетування та однорангові пули пам’яті, більш економічно ефективні та здійсненні механізми підписання SCA, міжланцюгова синхронізація SCA і управління, а також розробка зручних інтерфейсів.

Ми передбачаємо майбутнє з широкою участю, що викликає кілька цікавих запитань: як тільки процес замовлення SCA стане достатньо прибутковим, як традиційні механізми майнерської видобутку (MEV) увійдуть у простір, створять пакети та отримають вартість? Коли інфраструктура розвивається, як абстракція облікового запису (AA) може стати базовим рівнем для транзакцій на основі намірів? Слідкуйте за оновленнями, оскільки ця сфера постійно розвивається.