Автор: 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 ERC 4337 представляє окремий запис транзакцій для підтримки AA без зміни рівня консенсусу. Такі проекти, як Stackup, Alchemy, Etherspot, Biconomy, Candide і Plimico, створюють інфраструктуру пакетувальника, а проекти, такі як Safe, Zerodev, Etherspot і Biconomy, створюють стеки та SDK.
Дилеми прийняття SCA
Тема абстракції облікового запису (AA) обговорюється з 2015 року і була привернута до уваги цього року ERC 4337. Однак кількість розгорнутих облікових записів смарт-контрактів все ще набагато менша, ніж у EOA.
Давайте заглибимося в цю дилему:
Вплив ведмежого ринку:
Незважаючи на те, що AA запровадив такі переваги, як безперебійний вхід і відбір газу, люди, які зараз відчувають ведмежий ринок, в основному складаються з освічених користувачів EOA, а не з нових користувачів, тому немає стимулу для dApps і гаманців. Незважаючи на це, деякі провідні додатки поступово впроваджують АА, як-от Cyberconnect, який забезпечив близько 360 000 транзакцій UserOps (транзакцій АА) лише за один місяць, представивши свою систему АА та безгазове рішення.
Перешкоди для міграції:
Для гаманців і програм, які накопичили користувачів і активи, безпечне та зручне переміщення активів залишається проблемою. Однак такі ініціативи, як EIP-7377, дозволяють EOA ініціювати транзакції одноразової міграції.
*Проблема підпису:
Сам розумний контракт не може підписувати повідомлення, оскільки він не має закритого ключа, як EOA. Зусилля, такі як ERC 1271, роблять таке підписання можливим, але підписання повідомлень не працює до першої транзакції, що створює проблему для гаманців, які використовують контрфактичні розгортання. 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 Алмазний агент
Про ERC 2535 і Diamond Agent
ERC 2535 стандартизує Diamond Agent, модульну систему смарт-контрактів, яку можна оновити/розширити після розгортання та практично не має обмежень щодо розміру. Наразі цим надихалися багато команд, наприклад Zerodev's Kernel і Soul Wallet експерименти.
Яка структура алмазу?
Diamond Contract: Контракт основного агента (Stateful) Diamond — це проксі-контракт, який викликає функції від своєї реалізації через виклики делегатів.
Модулі/плагіни/фасетні контракти: спеціальна логіка та функціональність (без стану). Модуль або так званий аспект — це контракт без статусу, який може розгортати свої функції в одному або кількох Diamonds. Це незалежні контракти, які можуть спільно використовувати внутрішні функції, бібліотеки та змінні стану.
Що відбувається, коли ми використовуємо Diamond
Контракти з можливістю оновлення: Diamond забезпечує систематичний спосіб ізоляції та з’єднання різних плагінів, а також додавання/заміни/видалення будь-якого плагіна безпосередньо за допомогою функції diamondCut. Немає обмежень щодо кількості плагінів, які можна додати до Diamond з часом.
Модульні та багаторазові плагіни: розгорнутий плагін може використовуватися будь-якою кількістю Diamonds, що значно знижує витрати на розгортання.
Різниця між безпечним розумним обліковим записом і алмазним методом
Між архітектурами Safe і Diamond є багато подібностей, обидві покладаються на проксі-контракти як ядро та посилаються на логічні контракти для можливості оновлення та модульності.
Однак основна відмінність полягає в обробці логічних контрактів. Ось докладніші інструкції:
Гнучкість: із увімкненням нових плагінів Safe потрібно повторно розгорнути свій синглтон-контракт, щоб запровадити зміни у своєму агенті. Навпаки, Diamond робить це безпосередньо через функцію diamondCut у своєму делегаті. Ця відмінність у підході означає, що Safe зберігає вищий ступінь контролю, тоді як Diamond забезпечує більшу гнучкість і модульність.
Безпека: наразі delegatecall використовується в обох структурах, що дозволяє зовнішньому коду маніпулювати сховищем основного контракту. У безпечній архітектурі delegatecall вказує на один логічний контракт, тоді як Diamond використовує delegatecall між кількома контрактами модулів (плагінами). Таким чином, зловмисний плагін може перезаписати інший плагін, створюючи таким чином ризик конфліктів зберігання, які можуть поставити під загрозу цілісність агента.
Вартість: гнучкість, притаманна підходу Diamond, супроводжується підвищеними проблемами безпеки. Це збільшує вартість і вимагає повного аудиту кожного разу, коли додається новий плагін. Головне — забезпечити, щоб ці плагіни не заважали функціональності один одного, що може стати проблемою для малих і середніх підприємств, які намагаються підтримувати високі стандарти безпеки.
«Метод безпечного розумного облікового запису» та «Метод алмазу» є прикладами різних структур із залученням агентів і модулів. Те, як збалансувати гнучкість і безпеку, має вирішальне значення, і ці два підходи, ймовірно, доповнюватимуть один одного в майбутньому.
Порядок модулів: валідатор, виконавець і хук
Давайте розширимо наше обговорення, представивши стандарт, запропонований командою Alchemy, ERC 6900, який був натхненний Diamond і спеціально адаптований для ERC-4337. Він вирішує проблему модульності в розумних облікових записах, надаючи загальний інтерфейс і координуючи роботу між розробниками плагінів і гаманців.
Коли йдеться про процес транзакцій АА, існує три основні процеси: перевірка, виконання та перехоплення. Як ми обговорювали раніше, цими кроками можна керувати, викликавши модуль за допомогою облікового запису проксі. Хоча різні проекти можуть використовувати різні назви, важливо вловити схожу базову логіку.
Перевірка: переконайтеся в автентичності та авторитетності облікового запису абонента.
Виконання: Виконайте будь-яку спеціальну логіку, дозволену обліковим записом.
*Гак: як модуль, який запускається до або після іншої функції. Це може змінити стан або призвести до скасування всього виклику.
Розділення модулів на основі різної логіки має вирішальне значення. Стандартизований підхід має визначати, як мають бути написані функції перевірки облікового запису смарт-контракту, виконання та підключення. Незалежно від того, чи це Safe чи ERC 6900, стандартизація допомагає зменшити потребу в унікальних зусиллях щодо розробки для конкретної реалізації чи екосистеми та запобігає блокуванню постачальника.
Виявлення та захист модулів
Одне з рішень, яке процвітає, передбачає створення місця, яке дозволяє користувачам знаходити верифіковані модулі, те, що ми можемо назвати «реєстром». Цей реєстр схожий на «магазин додатків», призначений для створення спрощеного, але процвітаючого модульного ринку.
Safe{Core}Протокол
Safe{Core} Protocol — це протокол облікового запису смарт-контракту з відкритим вихідним кодом, сумісний із можливістю взаємодії, розроблений для підвищення доступності для різноманітних постачальників і розробників за допомогою чітко визначених стандартів і правил, зберігаючи при цьому високий рівень безпеки.
Обліковий запис: у протоколі Safe{Core} концепція облікового запису є гнучкою та не обмежена певною реалізацією. Це дозволяє брати участь різним постачальникам облікових записів.
Менеджер: Менеджер діє як координатор між обліковими записами, реєстрами та модулями. Він також відповідає за безпеку, діючи як рівень дозволів.
Реєстр: реєстр визначає атрибути безпеки та забезпечує виконання стандартів модулів, таких як ERC 6900, з метою створення відкритого середовища «магазину програм» для виявлення та безпеки.
Модулі: модулі обробляють функціональні можливості та надаються в різних початкових типах, включаючи плагіни, хуки, засоби перевірки підпису та обробники функцій. Розробники можуть сприяти цьому, якщо вони відповідають встановленим стандартам.
Дизайн зі стразами
Процес розгортається наступним чином:
Створення визначення схеми: схема служить попередньо визначеною структурою даних для доказу. Підприємства можуть налаштувати шаблон відповідно до конкретних випадків використання.
Створення модуля на основі шаблону: смарт-контракт реєструється як модуль, отримує байт-код і вибирає ідентифікатор шаблону. Потім ці дані зберігаються в реєстрі.
Отримати докази модулів: сертифікатори/аудитори можуть надати докази для модулів на основі схеми. Ці сертифікати можуть містити унікальні ідентифікатори (UID) і посилання на інші сертифікати для зв’язування. Їх можна поширювати в ланцюжку та перевіряти, чи досягаються певні порогові значення в цільовому ланцюжку.
Використовуйте аналізатори для реалізації складної логіки: аналізатори необов'язково встановлюються в шаблоні. Їх можна викликати під час створення модуля, встановлення перевірки та демонтажу. Ці аналізатори дозволяють розробникам включати складну та різноманітну логіку, зберігаючи структуру доказу.
Зручний доступ із запитами: Query надає користувачам спосіб доступу до інформації про безпеку з інтерфейсу. EIP можна знайти тут.
Незважаючи на те, що ця модель все ще перебуває на ранніх стадіях, вона має потенціал для встановлення стандарту децентралізованим і спільним способом. Їхній реєстр дозволяє розробникам реєструвати свої модулі, аудиторам — перевіряти їхню безпеку, гаманцям — інтегрувати, а користувачам — легко знаходити модулі та перевіряти інформацію про їхню атестацію. У майбутньому можуть бути наступні способи використання:
Сертифікатор: довірені організації, такі як Safe, можуть співпрацювати з Rhinestone як сертифікатори для внутрішніх модулів. У той же час незалежні перевіряльники також можуть приєднатися.
Розробники модулів: із формуванням відкритого ринку розробники модулів можуть комерціалізувати свою роботу через реєстр.
Користувачі: за допомогою зручних інтерфейсів, таких як гаманці або dApps, користувачі можуть переглядати інформацію про модулі та делегувати довіру різним перевіряльникам.
Концепція «реєстру модулів» надає вигідні можливості для розробників плагінів і модулів. Це також може прокласти шлях до «ринку модулів». Деякі з цих аспектів можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізовані ринкові майданчики, які запрошують усіх долучитися та забезпечити прозорий контрольний слід. Застосовуючи такий підхід, ми можемо уникнути прив’язки до постачальника та підтримати розширення EVM, забезпечуючи кращий досвід користувача, який привертає увагу ширшої аудиторії.
Хоча ці методи забезпечують безпеку окремих модулів, загальна безпека облікових записів смарт-контрактів не є абсолютно надійною. Поєднання законних модулів і доведення того, що вони не мають конфліктів зберігання, може бути складним завданням, підкреслюючи важливість гаманців або інфраструктури АА у вирішенні таких проблем.
Підведіть підсумки
Використовуючи модульний стек облікових записів смарт-контрактів, постачальники гаманців і dApps можуть уникнути складності технічного обслуговування. У той же час зовнішні розробники модулів мають можливість надавати професійні послуги з урахуванням індивідуальних потреб. Однак проблеми, які необхідно вирішити, включають досягнення балансу між гнучкістю та безпекою, стимулювання розвитку модульних стандартів і впровадження стандартизованих інтерфейсів, які дозволяють користувачам легко оновлювати та змінювати свої розумні облікові записи.
Однак модульні облікові записи смарт-контрактів (SCA) — це лише одна частина головоломки впровадження. Щоб повністю реалізувати потенціал SCA, також потрібна підтримка протокольного рівня з боку рішень другого рівня, а також потужна інфраструктура пакетування та однорангові пули пам’яті, більш економічно ефективні та здійсненні механізми підписання SCA, міжланцюгова синхронізація SCA і управління, а також розробка зручних інтерфейсів.
Ми уявляємо майбутнє з широкою участю, що викликає кілька цікавих запитань: як тільки процес замовлення SCA стане досить прибутковим, як традиційні механізми майнерів, що витягуються (MEV), увійдуть у простір, створять пакети та отримають вартість? Коли інфраструктура розвивається, як може абстракція облікового запису (AA) стати базовим рівнем для транзакцій на основі намірів? Слідкуйте за оновленнями, оскільки ця сфера постійно розвивається.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Поглиблене обговорення модульного дизайну облікового запису смарт-контрактів: вирішення технічних проблем у реалізації
Автор: Rui S, SevenX Ventures; Упорядник: Deep Wave TechFlow
представити
Перехід від зовнішніх облікових записів (EOA) до облікових записів смарт-контрактів (SCA) процвітає, і його підтримують багато ентузіастів, у тому числі й сам Віталік. Незважаючи на хвилювання, впровадження SCA не було таким поширеним, як EOA. Ключові проблеми включають виклики ведмежого ринку, занепокоєння міграцією, проблеми підпису, накладні витрати на газ і, що найважливіше, інженерні проблеми.
Однією з найважливіших переваг Account Abstraction (AA) є можливість налаштовувати функціональність за допомогою коду. Однак основною інженерною проблемою є несумісність функціональних можливостей АА, і ця фрагментація перешкоджає інтеграції та відкриває двері для блокування постачальника. Крім того, забезпечення безпеки під час оновлення та одночасного поєднання функцій може бути складним.
Модульна абстракція облікових записів виникла як частина ширшого руху АА, інноваційного підходу до відокремлення розумних облікових записів від їхніх спеціальних функцій. Мета полягає в тому, щоб створити модульну структуру для розробки безпечних, бездоганно інтегрованих гаманців із різноманітною функціональністю. У майбутньому він може запровадити безкоштовний смарт-контрактний обліковий запис «магазин додатків», щоб гаманці та dApp більше не зосереджувалися на створенні функцій, а зосереджувалися на взаємодії з користувачем.
AA Короткий опис
Традиційний EOA представляє багато проблем, таких як вихідні фрази, газ, крос-ланцюги та численні транзакції. Ми ніколи не збиралися вводити складність, але реальність така, що блокчейн не є простою грою для мас.
Абстракція облікового запису використовує облікові записи смарт-контрактів, дозволяючи програмовану перевірку та виконання, дозволяючи користувачам затверджувати низку транзакцій одночасно, замість того, щоб підписувати та транслювати кожну транзакцію, і надає більше функцій. Це приносить переваги взаємодії з користувачем (наприклад, відбір газу та ключі сеансу), вартості (наприклад, пакетні транзакції) та безпеці (наприклад, соціальне відновлення, мультипідпис). Наразі існує два способи впровадження абстракції облікового запису:
Дилеми прийняття SCA
Тема абстракції облікового запису (AA) обговорюється з 2015 року і була привернута до уваги цього року ERC 4337. Однак кількість розгорнутих облікових записів смарт-контрактів все ще набагато менша, ніж у EOA.
Давайте заглибимося в цю дилему:
Незважаючи на те, що AA запровадив такі переваги, як безперебійний вхід і відбір газу, люди, які зараз відчувають ведмежий ринок, в основному складаються з освічених користувачів EOA, а не з нових користувачів, тому немає стимулу для dApps і гаманців. Незважаючи на це, деякі провідні додатки поступово впроваджують АА, як-от Cyberconnect, який забезпечив близько 360 000 транзакцій UserOps (транзакцій АА) лише за один місяць, представивши свою систему АА та безгазове рішення.
Для гаманців і програм, які накопичили користувачів і активи, безпечне та зручне переміщення активів залишається проблемою. Однак такі ініціативи, як EIP-7377, дозволяють EOA ініціювати транзакції одноразової міграції.
*Проблема підпису:
Сам розумний контракт не може підписувати повідомлення, оскільки він не має закритого ключа, як EOA. Зусилля, такі як ERC 1271, роблять таке підписання можливим, але підписання повідомлень не працює до першої транзакції, що створює проблему для гаманців, які використовують контрфактичні розгортання. ERC-6492, запропонований Ambire, є зворотно сумісним наступником ERC-1271 і може вирішити попередні проблеми.
*Витрати газу:
Розгортання, моделювання та виконання SCA потребує вищих витрат, ніж стандартний EOA. Це стає перешкодою для усиновлення. Однак для зменшення цих витрат було проведено деякі тести, наприклад, відокремлення створення облікового запису від дій користувача та розгляд питання про скасування солі облікового запису та перевірки існування.
Команда ERC-4337 створила репозиторій eth-infinitiism, щоб надати розробникам базові реалізації. Однак, оскільки ми розгалужуємося на більш детальну або специфічну функціональність у різних випадках використання, інтеграція та декодування стають складними.
У цій статті ми глибше розглянемо п’яту проблему: інженерні проблеми.
Модульні смарт-контрактні облікові записи для вирішення інженерних проблем
Подальше пояснення інженерних проблем таке:
Щоб вирішити ці проблеми, нам потрібні контракти, які можна оновлювати, щоб забезпечити безпечні та ефективні оновлення, багаторазові ядра для підвищення загальної ефективності розробки та стандартизовані інтерфейси, щоб забезпечити плавний перехід облікових записів контрактів між різними інтерфейсами.
Ці терміни об’єднують загальну концепцію: побудова модульної архітектури абстракції облікового запису (Modular AA).
Модульний AA — це ніша в рамках ширшого руху AA, який передбачає модульне створення смарт-облікових записів, щоб адаптувати послуги для користувачів і дозволити розробникам плавно покращувати функціональність з мінімальними обмеженнями.
Проте встановлення та просування нових стандартів є величезним викликом у будь-якій галузі. Багато різних рішень може з’явитися на початкових етапах, перш ніж усі приймуть основне рішення. Однак надихає те, що і 4337 SDK, і розробники гаманців, інфраструктурні групи та розробники протоколів працюють разом, щоб прискорити цей процес.
Модульна структура: основний рахунок і модулі
Уповноважений дзвінок і договір проксі
Зовнішні дзвінки та виклики делегатів:
Хоча delegatecall схожий на виклик, замість виконання цільового контракту у власному контексті він виконує цільовий контракт у поточному стані виклику контракту. Це означає, що будь-які зміни стану, внесені цільовим контрактом, будуть застосовані до сховища контракту виклику.
Щоб реалізувати складові та оновлювані структури, необхідні базові знання, які називаються «агентськими контрактами».
Архітектура безпеки
Safe — це провідна модульна інфраструктура розумних облікових записів, розроблена для забезпечення перевіреної в боях безпеки та гнучкості, дозволяючи розробникам створювати різноманітні програми та гаманці. Варто зазначити, що багато команд створюють або надихають Safe. Biconomy запускає свій обліковий запис, розширюючи нативний мультипідпис 4337 і 1/1 на Safe. З понад 164 000 розгорнутими контрактами та заблокованою вартістю понад 30,7 мільярдів доларів, Safe, безсумнівно, є найкращим вибором у цій сфері.
Безпечна структура
Обліковий запис Safe є проксі-контрактом, оскільки він делегатом викликає єдиний контракт. Безпечний обліковий запис містить власника, поріг і адресу реалізації, які встановлюються як змінні для агента, таким чином визначаючи його стан.
Синглтон обслуговує обліковий запис Safe та інтегрує та визначає різні інтеграції, включаючи плагіни, хуки, обробники функцій і засоби перевірки підписів.
Модулі дуже потужні. Будучи модульним типом, плагіни можуть визначати різні функції, такі як потоки платежів, механізми відновлення та ключі сеансу, і слугувати міжланцюжковим мостом між Web2 і Web3 шляхом отримання даних поза мережею. Інші модулі, такі як Hooks, діють як охоронці, а обробники функцій реагують на будь-які інструкції.
Що відбувається, коли ми приймаємо Safe
Щоразу, коли вводиться новий плагін, потрібно розгортати новий синглтон. Користувачі зберігають автономію для оновлення Safe до потрібної однокомпонентної версії відповідно до своїх уподобань і вимог.
Модульний характер плагінів дозволяє розробникам створювати функціональність незалежно. Потім вони можуть вільно вибирати та комбінувати ці плагіни відповідно до власних випадків використання, сприяючи підходу, який можна налаштовувати.
ERC-2535 Алмазний агент
Про ERC 2535 і Diamond Agent
ERC 2535 стандартизує Diamond Agent, модульну систему смарт-контрактів, яку можна оновити/розширити після розгортання та практично не має обмежень щодо розміру. Наразі цим надихалися багато команд, наприклад Zerodev's Kernel і Soul Wallet експерименти.
Яка структура алмазу?
Що відбувається, коли ми використовуємо Diamond
Різниця між безпечним розумним обліковим записом і алмазним методом
Між архітектурами Safe і Diamond є багато подібностей, обидві покладаються на проксі-контракти як ядро та посилаються на логічні контракти для можливості оновлення та модульності.
Однак основна відмінність полягає в обробці логічних контрактів. Ось докладніші інструкції:
«Метод безпечного розумного облікового запису» та «Метод алмазу» є прикладами різних структур із залученням агентів і модулів. Те, як збалансувати гнучкість і безпеку, має вирішальне значення, і ці два підходи, ймовірно, доповнюватимуть один одного в майбутньому.
Порядок модулів: валідатор, виконавець і хук
Давайте розширимо наше обговорення, представивши стандарт, запропонований командою Alchemy, ERC 6900, який був натхненний Diamond і спеціально адаптований для ERC-4337. Він вирішує проблему модульності в розумних облікових записах, надаючи загальний інтерфейс і координуючи роботу між розробниками плагінів і гаманців.
Коли йдеться про процес транзакцій АА, існує три основні процеси: перевірка, виконання та перехоплення. Як ми обговорювали раніше, цими кроками можна керувати, викликавши модуль за допомогою облікового запису проксі. Хоча різні проекти можуть використовувати різні назви, важливо вловити схожу базову логіку.
Розділення модулів на основі різної логіки має вирішальне значення. Стандартизований підхід має визначати, як мають бути написані функції перевірки облікового запису смарт-контракту, виконання та підключення. Незалежно від того, чи це Safe чи ERC 6900, стандартизація допомагає зменшити потребу в унікальних зусиллях щодо розробки для конкретної реалізації чи екосистеми та запобігає блокуванню постачальника.
Виявлення та захист модулів
Одне з рішень, яке процвітає, передбачає створення місця, яке дозволяє користувачам знаходити верифіковані модулі, те, що ми можемо назвати «реєстром». Цей реєстр схожий на «магазин додатків», призначений для створення спрощеного, але процвітаючого модульного ринку.
Safe{Core}Протокол
Safe{Core} Protocol — це протокол облікового запису смарт-контракту з відкритим вихідним кодом, сумісний із можливістю взаємодії, розроблений для підвищення доступності для різноманітних постачальників і розробників за допомогою чітко визначених стандартів і правил, зберігаючи при цьому високий рівень безпеки.
Дизайн зі стразами
Процес розгортається наступним чином:
Незважаючи на те, що ця модель все ще перебуває на ранніх стадіях, вона має потенціал для встановлення стандарту децентралізованим і спільним способом. Їхній реєстр дозволяє розробникам реєструвати свої модулі, аудиторам — перевіряти їхню безпеку, гаманцям — інтегрувати, а користувачам — легко знаходити модулі та перевіряти інформацію про їхню атестацію. У майбутньому можуть бути наступні способи використання:
Концепція «реєстру модулів» надає вигідні можливості для розробників плагінів і модулів. Це також може прокласти шлях до «ринку модулів». Деякі з цих аспектів можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізовані ринкові майданчики, які запрошують усіх долучитися та забезпечити прозорий контрольний слід. Застосовуючи такий підхід, ми можемо уникнути прив’язки до постачальника та підтримати розширення EVM, забезпечуючи кращий досвід користувача, який привертає увагу ширшої аудиторії.
Хоча ці методи забезпечують безпеку окремих модулів, загальна безпека облікових записів смарт-контрактів не є абсолютно надійною. Поєднання законних модулів і доведення того, що вони не мають конфліктів зберігання, може бути складним завданням, підкреслюючи важливість гаманців або інфраструктури АА у вирішенні таких проблем.
Підведіть підсумки
Використовуючи модульний стек облікових записів смарт-контрактів, постачальники гаманців і dApps можуть уникнути складності технічного обслуговування. У той же час зовнішні розробники модулів мають можливість надавати професійні послуги з урахуванням індивідуальних потреб. Однак проблеми, які необхідно вирішити, включають досягнення балансу між гнучкістю та безпекою, стимулювання розвитку модульних стандартів і впровадження стандартизованих інтерфейсів, які дозволяють користувачам легко оновлювати та змінювати свої розумні облікові записи.
Однак модульні облікові записи смарт-контрактів (SCA) — це лише одна частина головоломки впровадження. Щоб повністю реалізувати потенціал SCA, також потрібна підтримка протокольного рівня з боку рішень другого рівня, а також потужна інфраструктура пакетування та однорангові пули пам’яті, більш економічно ефективні та здійсненні механізми підписання SCA, міжланцюгова синхронізація SCA і управління, а також розробка зручних інтерфейсів.
Ми уявляємо майбутнє з широкою участю, що викликає кілька цікавих запитань: як тільки процес замовлення SCA стане досить прибутковим, як традиційні механізми майнерів, що витягуються (MEV), увійдуть у простір, створять пакети та отримають вартість? Коли інфраструктура розвивається, як може абстракція облікового запису (AA) стати базовим рівнем для транзакцій на основі намірів? Слідкуйте за оновленнями, оскільки ця сфера постійно розвивається.