Модулярізація облікового запису смарт-контрактів: вирішення проблеми складного впровадження та уможливлення широкомасштабного впровадження Web3

Автор: Rui S (SevenX Ventures)

Упорядник: Deep Wave TechFlow

представити

Перехід від зовнішніх облікових записів (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.

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

Вплив ведмежого ринку:

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

)

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

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

Архітектура безпеки

)

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

Безпечна структура

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

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

Одноразовий договір: Інтеграційний центр (без громадянства)

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

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

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

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

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

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

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

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

ERC-2535 Diamond Agent

)

Про ERC2535 і Diamond Agent

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

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

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

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

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

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

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

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

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

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

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

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

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

)

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

)

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

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

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

Safe{Core}Protocol

)

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

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

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

)

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

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

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

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

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

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

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

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

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

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