*Примітка редактора: Облікові записи смарт-контрактів (SCA) набирають обертів і підтримуються багатьма основними підприємцями, включаючи Віталіка, але все ще існує багато проблем із прийняттям SCA. Перевага Account Abstraction (AA) полягає в тому, що вона використовує кастомізацію коду, але її несумісність створює проблеми з інтеграцією та прив'язкою до постачальника. Модульна абстракція облікового запису має на меті створити модульну структуру для розробки гаманців, які є універсальними, безпечними та бездоганно інтегрованими. *
Руї, інвестор SevenX Ventures >, визначив п'ять основних проблем для впровадження SCA — вплив ведмежого ринку, труднощі міграції, проблеми з характером, високі витрати на газ та інженерні проблеми — і обговорив їх далі. Крім того, аналіз архітектури модульних облікових записів смарт-контрактів вказує на те, що модульний SCA є лише невеликою частиною проблем впровадження.
Щоб реалізувати весь потенціал SCA, необхідні рішення рівня 2, які забезпечують додаткову підтримку протокольного рівня, надійну інфраструктуру бандлерів і однорангові пули пам'яті, більш економічно ефективний і життєздатний механізм підпису SCA, крос-чейн синхронізацію та управління SCA, а також розробку зручних інтерфейсів.
Що буде далі в майбутньому, коли поточні проблеми будуть вирішені, і все більше людей приймуть SCA? Руї також ставить кілька цікавих запитань. BlockBeats скомпілювали оригінальний текст наступним чином:
Перехід від рахунків із зовнішнім володінням (EOA) до рахунків смарт-контрактів (SCA) набирає обертів і вже підтримується багатьма основними підприємцями, включаючи Віталіка. Незважаючи на це, прийняття SCA не було настільки поширеним, як EOA. Ключові проблеми включають вплив ведмежого ринку, складність міграції EOA на SCA, проблеми з підписами, високі витрати на газ і, що найважливіше, проблеми розвитку.
Найважливішою перевагою Account Abstraction (AA) є можливість налаштування функціоналу за допомогою коду. Однак несумісність функцій АА є серйозною проблемою, оскільки ця фрагментація перешкоджає інтеграції АА та посилює прив'язку до постачальника. Крім того, також важливим завданням є забезпечення безпеки, будучи при цьому можливістю модернізації та компонування.
Поява модульної абстракції облікових записів є нішею в тренді АА, інноваційного підходу, який відокремлює смарт-рахунки від їх кастомних функцій. Мета полягала в тому, щоб створити модульну структуру для розробки гаманців з безліччю функцій, безпекою та безперебійною інтеграцією. У майбутньому модульна абстракція облікового запису дозволить створити безкоштовний обліковий запис смарт-контракту «магазин додатків», що дозволить гаманцям і dApps зосередитися на покращенні користувацького досвіду, а не витрачати занадто багато зусиль на створення функцій.
Коротка абстракція розповіді (АА)
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
Традиційний EOA приносить багато викликів, пов'язаних із впливом блокчейну, таких як початкові фрази, плата за газ, крос-чейн операції та численні транзакції.
Абстракція облікового запису використовує облікові записи смарт-контрактів, щоб забезпечити програмовану перевірку та перевірку. Це означає, що користувачі зможуть схвалювати серію транзакцій одночасно, замість того, щоб підписувати та транслювати кожну транзакцію. Абстракція облікового запису також може забезпечити більше функцій, таких як покращений користувацький досвід (наприклад, абстракція газу та ключі сеансу), зниження витрат (наприклад, масові транзакції) та покращена безпека (наприклад, соціальне відновлення, мультипідпис). В даний час існує два способи абстрагування рахунків:
· Рівень протоколу: Деякі протоколи за замовчуванням забезпечують вбудовану підтримку абстракції облікових записів, транзакції ZKSync використовують єдиний мемпул і потік транзакцій для підтримки AA, як від EOA, так і від SCA дотримуються одного і того ж процесу, в той час як Starknet видалив EOA, всі облікові записи є SCA, і вони мають власні гаманці смарт-контрактів, такі як Argent.
· Контрактний рівень: для Ethereum та подібних L2 ERC4337 представили окремий мемпул для підтримки AA без зміни рівня консенсусу. Такі місця, як Stackup, Alchemy, Etherspot, Biconomy, Candide і Plimico, створюють інфраструктуру бандлерів, тоді як такі речі, як Safe, Zerodev, Etherspot і Biconomy, створюють бандлери та SDK.
Дилема прийняття SCA
Тема абстракції облікового запису (АА) обговорюється з 2015 року, а цього року вона була висунута в центр уваги ERC 4337. Однак кількість розгорнутих облікових записів смарт-контрактів все ще далеко не така низька, як EOA.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Давайте розберемося в цій дилемі:
Вплив ведмежого ринку
Незважаючи на такі переваги АА, як безшовний вхід і абстракція газу, на нинішньому ведмежому ринку, де всі користувачі є освіченими користувачами EOA і не так багато нових користувачів, у dApps і гаманців немає стимулу впроваджувати SCA. Незважаючи на це, деякі з провідних dApps поступово впроваджують AA, такі як Cyberconnect, який забезпечив близько 360 000 транзакцій UserOps (AA) лише за один місяць, представивши свою систему AA та безгазове рішення.
Міграційні перешкоди
Для гаманців і додатків, які вже накопичили користувачів і активи, залишається проблемою безпечного та зручного перенесення активів. Однак така схема, як EIP-7377, дозволяє EOA ініціювати одноразову транзакцію міграції.
Проблеми з підписом
Сам смарт-контракт не може підписувати повідомлення, оскільки не має приватного ключа, такого як EOA. Такі спроби ERC1271 роблять це можливим, але підпис повідомлень не працює до першої транзакції, що, в свою чергу, створює проблему для гаманців, розгорнутих з контрфактами. ERC-6492, запропонований Ambire, є зворотно сумісним наступником ERC-1271 і, можливо, зможе вирішити попередню проблему.
Вартість газу
Вища вартість розгортання, моделювання та виконання SCA порівняно зі стандартним EOA також є перешкодою для прийняття. Однак були проведені деякі тести, такі як відокремлення створення облікового запису від дій користувача, усунення «солі», пов'язаної з обліковим записом, тощо.
Інженерні проблеми
Команда ERC-4337 створила репозиторій eth-infinitism, який забезпечує базову реалізацію для розробників. Однак у міру того, як розробники масштабуються до більш детальних і специфічних функцій для різних випадків використання, інтеграція та декодування стикаються з більшими проблемами. У цій статті ми зануримося в інженерні проблеми.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Вирішуйте інженерні завдання за допомогою модульних облікових записів смарт-контрактів
Інженерні проблеми можуть бути додатково деталізовані до трьох аспектів: фрагментація, безпека та можливість модернізації.
· Фрагментація: Функції тепер можна вмикати різними способами, як через певну SCA, так і через окрему систему плагінів. Кожна платформа та постачальник послуг дотримуються власних стандартів, що спонукає розробників вирішувати, які платформи та постачальників послуг підтримувати. Це може призвести до потенційної прив'язки платформи (постачальника) або до зайвої роботи.
· Безпека: Хоча відокремлення облікових записів і функцій дає перевагу гнучкості, воно також може зробити проблеми безпеки більш серйозними. Оскільки всі функції можуть перевірятися разом, відсутність незалежної оцінки може збільшити ризик вразливостей облікового запису.
· Можливість оновлення: у міру зростання вашого облікового запису важливо зберігати можливість додавати, замінювати або видаляти функції, і кожне оновлення, яке повторно розгортає наявні функції, ускладнює ситуацію.
Щоб вирішити ці проблеми, нам потрібні контракти з можливістю оновлення, щоб забезпечити безпечні та ефективні оновлення, багаторазові ядра для підвищення загальної ефективності розробки, а також стандартизовані інтерфейси для забезпечення плавного переходу між різними інтерфейсами.
Ці терміни сходяться на загальній концепції: побудова модульної архітектури абстракції облікового запису (Modular AA).
Модульна абстракція облікових записів є підрозділом більш широкої розробки АА, яка передбачає модульність смарт-облікових записів для надання індивідуальних послуг користувачам і надання розробникам можливості безперешкодно розширювати функціональність з мінімальними обмеженнями.
Однак встановлення та просування нових стандартів у будь-якій галузі є величезним викликом. Поки всі не приймуть один і той же стандарт, на початковому етапі може з'явитися багато різних рішень. Приємно бачити, що ті, хто працює над удосконаленням і просуванням абстракції облікових записів, будь то 4337 SDK, гаманці, команди інфраструктури або розробники протокольного рівня, працюють разом, щоб прискорити цей процес.
Модульна структура: майстер-акаунти та модулі
Як обліковий запис викликає модуль для реалізації функції
Делегувати дзвінок і проксі-контракт
Зовнішні та делеговані дзвінки:
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
Про виклики делегатів
Хоча "делегований виклик" схожий на "виклик", він виконується не в контексті цільового контракту, а в контексті поточного стану контракту, що викликає. Це означає, що будь-яка зміна стану, внесена цільовим контрактом, змінить сховище контракту, що викликає.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Проксі-контракти та виклики делегатів
** Для досягнення структури, яку можна компонувати та модернізувати, необхідно ввести базове поняття «агентський контракт». **
Проксі-контракт: звичайний контракт зберігає свою логіку та стан і не може бути оновлений після розгортання. Проксі-контракт розгортається на інший контракт за допомогою виклику делегата. Реалізуйте функцію за посиланням, щоб виконати її в поточному стані проксі-контракту.
Приклад використання: Поки проксі-контракт залишається незмінним, ви можете розгорнути нову реалізацію за брокером. Проксі-контракти можна оновлювати та дешевше розгортати та підтримувати на публічних блокчейнах.
Безпечна архітектура! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Безпечна архітектура
Що таке Safe: Safe — це провідна модульна інфраструктура розумних облікових записів, розроблена для забезпечення перевіреної в боях безпеки та гнучкості, а також дозволяє розробникам створювати різноманітні програми та гаманці. Багато команд створюють додатки на основі Safe (або натхненні ним). Наприклад, Biconomy розширила Safe нативним 4337 і мультипідписом 1/1, коли запустила свій обліковий запис смарт-контракту. Ставши свідком розгортання понад 164 000 контрактів і зафіксувавши вартість понад 30,7 мільярда доларів, Safe, безсумнівно, є лідером у своїй галузі.
Структура Safe включає контракт захищеного рахунку, контракт на одиночний рахунок і модульний контракт.
Проксі-контракт: Stateful
Захищений обліковий запис є проксі-контрактом, оскільки делегований виклик є контрактом singleton. Обліковий запис безпеки містить змінні, де власник, поріг і адреса реалізації встановлюються як агенти, а їх стан визначається на їх основі.
单例合约(singleton contract):Integration Hub(无状态)
Контракт singleton обслуговує безпечні облікові записи та визначає різні інтеграції контрактів модулів, включаючи плагін, хук, обробник функцій та валідатор підпису.
Модулі: Користувацька логіка та функціональність
Модульні контракти мають велику потужність. Плагіни як модульні типи можуть визначати різні функції, такі як платіжні потоки, механізми відновлення та сесійні ключі, і можуть діяти як міст між Web2 та Web3, отримуючи дані поза мережею. Інші модулі, такі як хуки та обробники функцій як охоронці, можуть реагувати на будь-яку команду.
Зміни, які змінилися після впровадження Safe:
Контракти, які можна оновити: Кожного разу, коли з'являється новий плагін, потрібно розгорнути новий синглтон. Користувач зберігає автономію для оновлення Safe до бажаної версії singleton.
Багаторазово використовувані модулі: Модульний характер плагінів дозволяє розробникам розробляти функції самостійно. Вони вільні вибирати та комбінувати ці плагіни відповідно до їх сценарію використання, що призводить до підходу, який легко налаштовується.
ERC-2535 Діамант 代理
**! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
Про ERC2535, Diamond Agent:
ERC2535 стандартизована модель Diamond, модульна система смарт-контрактів, яку можна модернізувати/масштабувати після розгортання практично без обмежень за розміром. В даний час багато команд, таких як Kernel від Zerodev і експерименти Soul Wallet, були натхненні структурою Diamond.
Що таке алмазна структура:**
Diamond Contract: Первинний проксі-контракт (Stateful) Diamond — це проксі-контракт, який використовує метод делегованого виклику для виклику функції з його реалізації.
Модуль/Плагін/Фасетний контракт: Користувацька логіка та функціональність (Stateless) Модуль або так званий Facet — це контракт без стану, який може розгортати свою функціональність для одного або кількох Diamonds. Це окремі, незалежні контракти, які можуть мати спільні внутрішні функції, бібліотеки та змінні стану.
Зміни з Diamond:
Контракти, що оновлюються: Diamond надає систематичний спосіб ізолювати різні плагіни та з'єднувати їх разом, обмінюватися даними між ними, а також додавати/замінювати/видаляти будь-який плагін безпосередньо за допомогою функції diamondCut. З часом кількість плагінів, які можна додати в Diamond, не буде обмежена.
Модульні та багаторазові плагіни: розгорнуті плагіни можуть використовуватися будь-якою кількістю Diamonds, що значно знижує витрати на розгортання.
Різниця між безпечним смарт-рахунком і діамантовим методом:
Існує багато спільного між архітектурами Safe і Diamond, обидві з яких покладаються на свої основні проксі-контракти та еталонні логічні контракти для можливості оновлення та модульності.
Основна відмінність між ними полягає в обробці логічних контрактів. Специфічно:
· Гнучкість: З увімкненням нового плагіна Safe потрібно перерозгорнути свій контракт singleton, щоб впровадити зміни у своєму проксі-сервері. На противагу цьому, Diamond досягає цього безпосередньо за допомогою функції diamondCut у своєму проксі-контракті. Різниця в підході означає, що Safe зберігає вищий ступінь контролю, тоді як Diamond забезпечує підвищену гнучкість і модульність.
· Безпечний: наразі використовується в обох структурах, дозволяє зовнішньому коду маніпулювати сховищем основного контракту. В архітектурі Safe виклики делегатів вказують на єдиний логічний контракт, в той час як Diamond використовує виклики делегатів для декількох контрактів-плагінів модулів. Як наслідок, шкідливий плагін може перезаписати інший плагін, що створює ризик конфліктів сховища та ставить під загрозу цілісність проксі-сервера.
· Вартість: У підході Diamond гнучкість і безпека поєднуються. Це збільшує вартість, і кожного разу, коли додається новий плагін, його потрібно повністю перевіряти. Ключ полягає в тому, щоб гарантувати, що ці плагіни не заважають функціональності один одного, що є складним завданням, особливо для малого та середнього бізнесу, який намагається підтримувати високі стандарти безпеки.
«Метод безпечного смарт-рахунку» та «Діамантовий метод» є прикладами різних структур, що включають агентів та модулі. Баланс між гнучкістю та безпекою має вирішальне значення, і ці два підходи продовжуватимуть розвиватися та доповнювати один одного в майбутньому.
Порядок модулів: валідатор, виконавець та хук
Давайте обговоримо це далі, представивши ERC6900, стандарт, натхненний діамантами, від команди Alchemy, розроблений спеціально для ERC-4337. Він вирішує проблеми модульності розумних облікових записів, надаючи загальний інтерфейс і координуючи роботу між розробниками плагінів і гаманців.
Коли справа доходить до процесу транзакції АА, існує три основні процеси: валідація, виконання та прив'язка. Як ми обговорювали раніше, усіма цими кроками можна керувати за допомогою модуля виклику проксі-облікового запису. Хоча різні проекти можуть використовувати різні назви, важливо зрозуміти логіку подібності, що лежить в основі.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
Назва функції в різних конструкціях
Валідатор: забезпечує автентичність і дозволи абонента облікового запису.
Виконання (UTOR): виконання будь-якої користувацької логіки, яку дозволяє обліковий запис.
Hook: діє як модуль, який запускається до або після іншої функції. Він може змінити стан або скасувати весь виклик.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Важливо розділяти модулі за різною логікою. Стандартизований підхід повинен визначати, як писати функції перевірки, виконання та прив'язки для облікових записів смарт-контрактів. Незалежно від того, чи це Safe чи ERC6900, стандартизація допомагає зменшити потребу в унікальних зусиллях з розробки, специфічних для певних реалізацій або екосистем, і запобігає прив'язці до постачальника.
Виявлення модулів та безпека
Як знаходити та перевіряти модулі відкритим способом: Одне з рішень, яке розробляється, передбачає створення області, яка дозволяє користувачам виявляти модулі, які можна перевірити, що можна назвати «реєстром». Реєстр функціонує як «магазин додатків» і має на меті сприяти спрощеному, але процвітаючому модульному ринку.
Safe{Core} 协议
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
Протокол Safe{Core} — це сумісний протокол із відкритим вихідним кодом для облікових записів смарт-контрактів, призначений для підвищення доступності для широкого кола постачальників і розробників, зберігаючи при цьому надійну безпеку за допомогою чітко визначених стандартів і правил.
· Облікові записи: У протоколі Safe{Core} концепція облікових записів є гнучкою та не прив'язана до конкретної реалізації. Це дозволяє різним постачальникам послуг облікових записів брати участь.
· Менеджер: Менеджер виконує роль координатора між обліковими записами, реєстрами та модулями. Він також дбає про безпеку як рівень ліцензування.
· Реєстр: Реєстр визначає атрибути безпеки та застосовує стандарти модулів, такі як ERC6900, щоб створити відкрите середовище «магазину додатків» для видимості та безпеки.
· Модулі: модулі обробляють функціональність і мають різноманітні початкові типи, включаючи плагіни, хуки, валідатори підпису та обробники функцій. Розробники можуть брати участь, якщо вони відповідають встановленим критеріям.
Стрази 设计
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
Процес розгортається наступним чином:
· Створення схеми: схема надає попередньо визначену структуру даних. Люди можуть адаптувати його відповідно до свого конкретного випадку використання.
· Створення модулів на основі схеми: смарт-контракт, зареєстрований як модуль, отримує байт-код і вибирає ідентифікатор схеми, а дані зберігаються в реєстрі.
· Отримати атестацію модуля: Перевіряючи/аудитор може надати доказ модуля на основі архітектури. Ці атестації можуть містити унікальний ідентифікатор (UID) і посилання на інші атестації, використані для посилання. Вони можуть поширюватися між ланцюгами та перевіряти, чи цільовий ланцюг відповідає певним пороговим значенням.
· Реалізація складної логіки за допомогою резольвера: У гру вступає синтаксичний аналізатор (необов'язково). Вони можуть бути викликані під час створення модулів, встановлення атестації та відкликання. Ці аналізатори дозволяють розробникам інтегрувати складну та різноманітну логіку, зберігаючи структури доказів.
Зручний доступ до запитів: Query надає користувачам можливість доступу до інформації про безпеку з інтерфейсу.
Хоча модель все ще перебуває на ранніх стадіях, вона має потенціал для встановлення стандартів децентралізованим і спільним способом. Реєстр дозволяє розробникам реєструвати свої модулі, аудиторам перевіряти їхню безпеку, гаманцям інтегрувати, а користувачам легко знаходити модулі та перевіряти інформацію про атестацію. У майбутньому можна використовувати кілька варіантів:
· Атестатор: Довірена організація, така як Safe, може працювати з Rhinestone як постачальник внутрішніх модулів. При цьому можуть приєднатися і незалежні сертифікатори.
· Розробник модулів: З формуванням відкритого маркетплейсу розробники модулів можуть монетизувати свою роботу через реєстр.
· Користувачі: Участь через зручний інтерфейс, такий як гаманець або dApp, дозволяє користувачам перевіряти інформацію про модулі та делегувати довіру різним доказам.
Концепція «реєстру модулів» відкриває шляхи для монетизації розробників плагінів і модулів. Це може ще більше прокласти шлях до «ринку модулів». Деякі аспекти можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізований ринок, який запрошує всіх зробити свій внесок і забезпечує прозорий контрольний журнал. Це дозволяє уникнути прив'язки до постачальника та підтримує розширення EVM, додаючи покращений користувацький досвід, який приваблює ширшу аудиторію.
Хоча ці методи гарантують безпеку окремих модулів, облікові записи смарт-контрактів не є надійними, коли справа доходить до ширшої безпеки. Може бути складно об'єднати модулі відповідності та довести, що вони не мають конфліктів зберігання, що підкреслює важливість гаманців або інфраструктури АА у вирішенні таких проблем.
Підсумки
Використовуючи модульний стек облікових записів смарт-контрактів, постачальники гаманців і dApps можуть звільнитися від складнощів технічного обслуговування. При цьому зовнішні розробники модулів мають можливість надавати персоналізовані професійні послуги. Однак проблеми, які необхідно вирішити, включають пошук балансу між гнучкістю та безпекою, просування модульних стандартів і впровадження стандартизованих інтерфейсів, які дозволяють користувачам легко оновлювати та змінювати свої смарт-облікові записи.
Крім того, модульні облікові записи смарт-контрактів (SCA) — це лише невелика частина головоломки впровадження. Щоб реалізувати весь потенціал SCA, необхідні рішення рівня 2, які забезпечують додаткову підтримку протокольного рівня, такі як надійна інфраструктура бандлерів і однорангові пули пам'яті, більш економічно ефективний і життєздатний механізм підпису SCA, крос-чейн механізми синхронізації та управління SCA, а також розробка зручних інтерфейсів.
У майбутньому буде більше впроваджуватися SCA, але це також порушить деякі цікаві питання: як традиційні механізми видобутку цінності майнерів (MEV) увійдуть у простір для створення бандерів та отримання цінності, коли потік ордерів SCA стане достатньо прибутковим, і як абстракція облікового запису (AA) слугуватиме базовим рівнем для транзакцій на основі намірів, коли інфраструктура дозріє?
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Поглиблений огляд архітектури та проблем модульних облікових записів смарт-контрактів
作者:Rui,інвестор SevenX Ventures
编译:Luccy,Joyce,BlockBeats
Руї, інвестор SevenX Ventures >, визначив п'ять основних проблем для впровадження SCA — вплив ведмежого ринку, труднощі міграції, проблеми з характером, високі витрати на газ та інженерні проблеми — і обговорив їх далі. Крім того, аналіз архітектури модульних облікових записів смарт-контрактів вказує на те, що модульний SCA є лише невеликою частиною проблем впровадження.
Перехід від рахунків із зовнішнім володінням (EOA) до рахунків смарт-контрактів (SCA) набирає обертів і вже підтримується багатьма основними підприємцями, включаючи Віталіка. Незважаючи на це, прийняття SCA не було настільки поширеним, як EOA. Ключові проблеми включають вплив ведмежого ринку, складність міграції EOA на SCA, проблеми з підписами, високі витрати на газ і, що найважливіше, проблеми розвитку.
Найважливішою перевагою Account Abstraction (AA) є можливість налаштування функціоналу за допомогою коду. Однак несумісність функцій АА є серйозною проблемою, оскільки ця фрагментація перешкоджає інтеграції АА та посилює прив'язку до постачальника. Крім того, також важливим завданням є забезпечення безпеки, будучи при цьому можливістю модернізації та компонування.
Поява модульної абстракції облікових записів є нішею в тренді АА, інноваційного підходу, який відокремлює смарт-рахунки від їх кастомних функцій. Мета полягала в тому, щоб створити модульну структуру для розробки гаманців з безліччю функцій, безпекою та безперебійною інтеграцією. У майбутньому модульна абстракція облікового запису дозволить створити безкоштовний обліковий запис смарт-контракту «магазин додатків», що дозволить гаманцям і dApps зосередитися на покращенні користувацького досвіду, а не витрачати занадто багато зусиль на створення функцій.
Коротка абстракція розповіді (АА)
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
Традиційний EOA приносить багато викликів, пов'язаних із впливом блокчейну, таких як початкові фрази, плата за газ, крос-чейн операції та численні транзакції.
Абстракція облікового запису використовує облікові записи смарт-контрактів, щоб забезпечити програмовану перевірку та перевірку. Це означає, що користувачі зможуть схвалювати серію транзакцій одночасно, замість того, щоб підписувати та транслювати кожну транзакцію. Абстракція облікового запису також може забезпечити більше функцій, таких як покращений користувацький досвід (наприклад, абстракція газу та ключі сеансу), зниження витрат (наприклад, масові транзакції) та покращена безпека (наприклад, соціальне відновлення, мультипідпис). В даний час існує два способи абстрагування рахунків:
· Рівень протоколу: Деякі протоколи за замовчуванням забезпечують вбудовану підтримку абстракції облікових записів, транзакції ZKSync використовують єдиний мемпул і потік транзакцій для підтримки AA, як від EOA, так і від SCA дотримуються одного і того ж процесу, в той час як Starknet видалив EOA, всі облікові записи є SCA, і вони мають власні гаманці смарт-контрактів, такі як Argent.
· Контрактний рівень: для Ethereum та подібних L2 ERC4337 представили окремий мемпул для підтримки AA без зміни рівня консенсусу. Такі місця, як Stackup, Alchemy, Etherspot, Biconomy, Candide і Plimico, створюють інфраструктуру бандлерів, тоді як такі речі, як Safe, Zerodev, Etherspot і Biconomy, створюють бандлери та SDK.
Дилема прийняття SCA
Тема абстракції облікового запису (АА) обговорюється з 2015 року, а цього року вона була висунута в центр уваги ERC 4337. Однак кількість розгорнутих облікових записів смарт-контрактів все ще далеко не така низька, як EOA.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Давайте розберемося в цій дилемі:
Незважаючи на такі переваги АА, як безшовний вхід і абстракція газу, на нинішньому ведмежому ринку, де всі користувачі є освіченими користувачами EOA і не так багато нових користувачів, у dApps і гаманців немає стимулу впроваджувати SCA. Незважаючи на це, деякі з провідних dApps поступово впроваджують AA, такі як Cyberconnect, який забезпечив близько 360 000 транзакцій UserOps (AA) лише за один місяць, представивши свою систему AA та безгазове рішення.
Для гаманців і додатків, які вже накопичили користувачів і активи, залишається проблемою безпечного та зручного перенесення активів. Однак така схема, як EIP-7377, дозволяє EOA ініціювати одноразову транзакцію міграції.
Сам смарт-контракт не може підписувати повідомлення, оскільки не має приватного ключа, такого як EOA. Такі спроби ERC1271 роблять це можливим, але підпис повідомлень не працює до першої транзакції, що, в свою чергу, створює проблему для гаманців, розгорнутих з контрфактами. ERC-6492, запропонований Ambire, є зворотно сумісним наступником ERC-1271 і, можливо, зможе вирішити попередню проблему.
Вища вартість розгортання, моделювання та виконання SCA порівняно зі стандартним EOA також є перешкодою для прийняття. Однак були проведені деякі тести, такі як відокремлення створення облікового запису від дій користувача, усунення «солі», пов'язаної з обліковим записом, тощо.
Команда ERC-4337 створила репозиторій eth-infinitism, який забезпечує базову реалізацію для розробників. Однак у міру того, як розробники масштабуються до більш детальних і специфічних функцій для різних випадків використання, інтеграція та декодування стикаються з більшими проблемами. У цій статті ми зануримося в інженерні проблеми.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Вирішуйте інженерні завдання за допомогою модульних облікових записів смарт-контрактів
Інженерні проблеми можуть бути додатково деталізовані до трьох аспектів: фрагментація, безпека та можливість модернізації.
· Фрагментація: Функції тепер можна вмикати різними способами, як через певну SCA, так і через окрему систему плагінів. Кожна платформа та постачальник послуг дотримуються власних стандартів, що спонукає розробників вирішувати, які платформи та постачальників послуг підтримувати. Це може призвести до потенційної прив'язки платформи (постачальника) або до зайвої роботи.
· Безпека: Хоча відокремлення облікових записів і функцій дає перевагу гнучкості, воно також може зробити проблеми безпеки більш серйозними. Оскільки всі функції можуть перевірятися разом, відсутність незалежної оцінки може збільшити ризик вразливостей облікового запису.
· Можливість оновлення: у міру зростання вашого облікового запису важливо зберігати можливість додавати, замінювати або видаляти функції, і кожне оновлення, яке повторно розгортає наявні функції, ускладнює ситуацію.
Щоб вирішити ці проблеми, нам потрібні контракти з можливістю оновлення, щоб забезпечити безпечні та ефективні оновлення, багаторазові ядра для підвищення загальної ефективності розробки, а також стандартизовані інтерфейси для забезпечення плавного переходу між різними інтерфейсами.
Ці терміни сходяться на загальній концепції: побудова модульної архітектури абстракції облікового запису (Modular AA).
Модульна абстракція облікових записів є підрозділом більш широкої розробки АА, яка передбачає модульність смарт-облікових записів для надання індивідуальних послуг користувачам і надання розробникам можливості безперешкодно розширювати функціональність з мінімальними обмеженнями.
Однак встановлення та просування нових стандартів у будь-якій галузі є величезним викликом. Поки всі не приймуть один і той же стандарт, на початковому етапі може з'явитися багато різних рішень. Приємно бачити, що ті, хто працює над удосконаленням і просуванням абстракції облікових записів, будь то 4337 SDK, гаманці, команди інфраструктури або розробники протокольного рівня, працюють разом, щоб прискорити цей процес.
Модульна структура: майстер-акаунти та модулі
Як обліковий запис викликає модуль для реалізації функції
Делегувати дзвінок і проксі-контракт
Зовнішні та делеговані дзвінки:
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
Про виклики делегатів
Хоча "делегований виклик" схожий на "виклик", він виконується не в контексті цільового контракту, а в контексті поточного стану контракту, що викликає. Це означає, що будь-яка зміна стану, внесена цільовим контрактом, змінить сховище контракту, що викликає.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Проксі-контракти та виклики делегатів
** Для досягнення структури, яку можна компонувати та модернізувати, необхідно ввести базове поняття «агентський контракт». **
Проксі-контракт: звичайний контракт зберігає свою логіку та стан і не може бути оновлений після розгортання. Проксі-контракт розгортається на інший контракт за допомогою виклику делегата. Реалізуйте функцію за посиланням, щоб виконати її в поточному стані проксі-контракту.
Приклад використання: Поки проксі-контракт залишається незмінним, ви можете розгорнути нову реалізацію за брокером. Проксі-контракти можна оновлювати та дешевше розгортати та підтримувати на публічних блокчейнах.
Безпечна архітектура! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Безпечна архітектура
Що таке Safe: Safe — це провідна модульна інфраструктура розумних облікових записів, розроблена для забезпечення перевіреної в боях безпеки та гнучкості, а також дозволяє розробникам створювати різноманітні програми та гаманці. Багато команд створюють додатки на основі Safe (або натхненні ним). Наприклад, Biconomy розширила Safe нативним 4337 і мультипідписом 1/1, коли запустила свій обліковий запис смарт-контракту. Ставши свідком розгортання понад 164 000 контрактів і зафіксувавши вартість понад 30,7 мільярда доларів, Safe, безсумнівно, є лідером у своїй галузі.
Структура Safe включає контракт захищеного рахунку, контракт на одиночний рахунок і модульний контракт.
Проксі-контракт: Stateful
Захищений обліковий запис є проксі-контрактом, оскільки делегований виклик є контрактом singleton. Обліковий запис безпеки містить змінні, де власник, поріг і адреса реалізації встановлюються як агенти, а їх стан визначається на їх основі.
单例合约(singleton contract):Integration Hub(无状态)
Контракт singleton обслуговує безпечні облікові записи та визначає різні інтеграції контрактів модулів, включаючи плагін, хук, обробник функцій та валідатор підпису.
Модулі: Користувацька логіка та функціональність
Модульні контракти мають велику потужність. Плагіни як модульні типи можуть визначати різні функції, такі як платіжні потоки, механізми відновлення та сесійні ключі, і можуть діяти як міст між Web2 та Web3, отримуючи дані поза мережею. Інші модулі, такі як хуки та обробники функцій як охоронці, можуть реагувати на будь-яку команду.
Зміни, які змінилися після впровадження Safe:
Контракти, які можна оновити: Кожного разу, коли з'являється новий плагін, потрібно розгорнути новий синглтон. Користувач зберігає автономію для оновлення Safe до бажаної версії singleton.
Багаторазово використовувані модулі: Модульний характер плагінів дозволяє розробникам розробляти функції самостійно. Вони вільні вибирати та комбінувати ці плагіни відповідно до їх сценарію використання, що призводить до підходу, який легко налаштовується.
ERC-2535 Діамант 代理
**! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
Про ERC2535, Diamond Agent:
ERC2535 стандартизована модель Diamond, модульна система смарт-контрактів, яку можна модернізувати/масштабувати після розгортання практично без обмежень за розміром. В даний час багато команд, таких як Kernel від Zerodev і експерименти Soul Wallet, були натхненні структурою Diamond.
Що таке алмазна структура:**
Diamond Contract: Первинний проксі-контракт (Stateful) Diamond — це проксі-контракт, який використовує метод делегованого виклику для виклику функції з його реалізації.
Модуль/Плагін/Фасетний контракт: Користувацька логіка та функціональність (Stateless) Модуль або так званий Facet — це контракт без стану, який може розгортати свою функціональність для одного або кількох Diamonds. Це окремі, незалежні контракти, які можуть мати спільні внутрішні функції, бібліотеки та змінні стану.
Зміни з Diamond:
Контракти, що оновлюються: Diamond надає систематичний спосіб ізолювати різні плагіни та з'єднувати їх разом, обмінюватися даними між ними, а також додавати/замінювати/видаляти будь-який плагін безпосередньо за допомогою функції diamondCut. З часом кількість плагінів, які можна додати в Diamond, не буде обмежена.
Модульні та багаторазові плагіни: розгорнуті плагіни можуть використовуватися будь-якою кількістю Diamonds, що значно знижує витрати на розгортання.
Різниця між безпечним смарт-рахунком і діамантовим методом:
Існує багато спільного між архітектурами Safe і Diamond, обидві з яких покладаються на свої основні проксі-контракти та еталонні логічні контракти для можливості оновлення та модульності.
Основна відмінність між ними полягає в обробці логічних контрактів. Специфічно:
· Гнучкість: З увімкненням нового плагіна Safe потрібно перерозгорнути свій контракт singleton, щоб впровадити зміни у своєму проксі-сервері. На противагу цьому, Diamond досягає цього безпосередньо за допомогою функції diamondCut у своєму проксі-контракті. Різниця в підході означає, що Safe зберігає вищий ступінь контролю, тоді як Diamond забезпечує підвищену гнучкість і модульність.
· Безпечний: наразі використовується в обох структурах, дозволяє зовнішньому коду маніпулювати сховищем основного контракту. В архітектурі Safe виклики делегатів вказують на єдиний логічний контракт, в той час як Diamond використовує виклики делегатів для декількох контрактів-плагінів модулів. Як наслідок, шкідливий плагін може перезаписати інший плагін, що створює ризик конфліктів сховища та ставить під загрозу цілісність проксі-сервера.
· Вартість: У підході Diamond гнучкість і безпека поєднуються. Це збільшує вартість, і кожного разу, коли додається новий плагін, його потрібно повністю перевіряти. Ключ полягає в тому, щоб гарантувати, що ці плагіни не заважають функціональності один одного, що є складним завданням, особливо для малого та середнього бізнесу, який намагається підтримувати високі стандарти безпеки.
«Метод безпечного смарт-рахунку» та «Діамантовий метод» є прикладами різних структур, що включають агентів та модулі. Баланс між гнучкістю та безпекою має вирішальне значення, і ці два підходи продовжуватимуть розвиватися та доповнювати один одного в майбутньому.
Порядок модулів: валідатор, виконавець та хук
Давайте обговоримо це далі, представивши ERC6900, стандарт, натхненний діамантами, від команди Alchemy, розроблений спеціально для ERC-4337. Він вирішує проблеми модульності розумних облікових записів, надаючи загальний інтерфейс і координуючи роботу між розробниками плагінів і гаманців.
Коли справа доходить до процесу транзакції АА, існує три основні процеси: валідація, виконання та прив'язка. Як ми обговорювали раніше, усіма цими кроками можна керувати за допомогою модуля виклику проксі-облікового запису. Хоча різні проекти можуть використовувати різні назви, важливо зрозуміти логіку подібності, що лежить в основі.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
Назва функції в різних конструкціях
Валідатор: забезпечує автентичність і дозволи абонента облікового запису.
Виконання (UTOR): виконання будь-якої користувацької логіки, яку дозволяє обліковий запис.
Hook: діє як модуль, який запускається до або після іншої функції. Він може змінити стан або скасувати весь виклик.
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Важливо розділяти модулі за різною логікою. Стандартизований підхід повинен визначати, як писати функції перевірки, виконання та прив'язки для облікових записів смарт-контрактів. Незалежно від того, чи це Safe чи ERC6900, стандартизація допомагає зменшити потребу в унікальних зусиллях з розробки, специфічних для певних реалізацій або екосистем, і запобігає прив'язці до постачальника.
Виявлення модулів та безпека
Як знаходити та перевіряти модулі відкритим способом: Одне з рішень, яке розробляється, передбачає створення області, яка дозволяє користувачам виявляти модулі, які можна перевірити, що можна назвати «реєстром». Реєстр функціонує як «магазин додатків» і має на меті сприяти спрощеному, але процвітаючому модульному ринку.
Safe{Core} 协议
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
Протокол Safe{Core} — це сумісний протокол із відкритим вихідним кодом для облікових записів смарт-контрактів, призначений для підвищення доступності для широкого кола постачальників і розробників, зберігаючи при цьому надійну безпеку за допомогою чітко визначених стандартів і правил.
· Облікові записи: У протоколі Safe{Core} концепція облікових записів є гнучкою та не прив'язана до конкретної реалізації. Це дозволяє різним постачальникам послуг облікових записів брати участь.
· Менеджер: Менеджер виконує роль координатора між обліковими записами, реєстрами та модулями. Він також дбає про безпеку як рівень ліцензування.
· Реєстр: Реєстр визначає атрибути безпеки та застосовує стандарти модулів, такі як ERC6900, щоб створити відкрите середовище «магазину додатків» для видимості та безпеки.
· Модулі: модулі обробляють функціональність і мають різноманітні початкові типи, включаючи плагіни, хуки, валідатори підпису та обробники функцій. Розробники можуть брати участь, якщо вони відповідають встановленим критеріям.
Стрази 设计
! [Поглиблений огляд архітектури та проблем модульного облікового запису смарт-контрактів] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
Процес розгортається наступним чином:
· Створення схеми: схема надає попередньо визначену структуру даних. Люди можуть адаптувати його відповідно до свого конкретного випадку використання.
· Створення модулів на основі схеми: смарт-контракт, зареєстрований як модуль, отримує байт-код і вибирає ідентифікатор схеми, а дані зберігаються в реєстрі.
· Отримати атестацію модуля: Перевіряючи/аудитор може надати доказ модуля на основі архітектури. Ці атестації можуть містити унікальний ідентифікатор (UID) і посилання на інші атестації, використані для посилання. Вони можуть поширюватися між ланцюгами та перевіряти, чи цільовий ланцюг відповідає певним пороговим значенням.
· Реалізація складної логіки за допомогою резольвера: У гру вступає синтаксичний аналізатор (необов'язково). Вони можуть бути викликані під час створення модулів, встановлення атестації та відкликання. Ці аналізатори дозволяють розробникам інтегрувати складну та різноманітну логіку, зберігаючи структури доказів.
Зручний доступ до запитів: Query надає користувачам можливість доступу до інформації про безпеку з інтерфейсу.
Хоча модель все ще перебуває на ранніх стадіях, вона має потенціал для встановлення стандартів децентралізованим і спільним способом. Реєстр дозволяє розробникам реєструвати свої модулі, аудиторам перевіряти їхню безпеку, гаманцям інтегрувати, а користувачам легко знаходити модулі та перевіряти інформацію про атестацію. У майбутньому можна використовувати кілька варіантів:
· Атестатор: Довірена організація, така як Safe, може працювати з Rhinestone як постачальник внутрішніх модулів. При цьому можуть приєднатися і незалежні сертифікатори.
· Розробник модулів: З формуванням відкритого маркетплейсу розробники модулів можуть монетизувати свою роботу через реєстр.
· Користувачі: Участь через зручний інтерфейс, такий як гаманець або dApp, дозволяє користувачам перевіряти інформацію про модулі та делегувати довіру різним доказам.
Концепція «реєстру модулів» відкриває шляхи для монетизації розробників плагінів і модулів. Це може ще більше прокласти шлях до «ринку модулів». Деякі аспекти можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізований ринок, який запрошує всіх зробити свій внесок і забезпечує прозорий контрольний журнал. Це дозволяє уникнути прив'язки до постачальника та підтримує розширення EVM, додаючи покращений користувацький досвід, який приваблює ширшу аудиторію.
Хоча ці методи гарантують безпеку окремих модулів, облікові записи смарт-контрактів не є надійними, коли справа доходить до ширшої безпеки. Може бути складно об'єднати модулі відповідності та довести, що вони не мають конфліктів зберігання, що підкреслює важливість гаманців або інфраструктури АА у вирішенні таких проблем.
Підсумки
Використовуючи модульний стек облікових записів смарт-контрактів, постачальники гаманців і dApps можуть звільнитися від складнощів технічного обслуговування. При цьому зовнішні розробники модулів мають можливість надавати персоналізовані професійні послуги. Однак проблеми, які необхідно вирішити, включають пошук балансу між гнучкістю та безпекою, просування модульних стандартів і впровадження стандартизованих інтерфейсів, які дозволяють користувачам легко оновлювати та змінювати свої смарт-облікові записи.
Крім того, модульні облікові записи смарт-контрактів (SCA) — це лише невелика частина головоломки впровадження. Щоб реалізувати весь потенціал SCA, необхідні рішення рівня 2, які забезпечують додаткову підтримку протокольного рівня, такі як надійна інфраструктура бандлерів і однорангові пули пам'яті, більш економічно ефективний і життєздатний механізм підпису SCA, крос-чейн механізми синхронізації та управління SCA, а також розробка зручних інтерфейсів.
У майбутньому буде більше впроваджуватися SCA, але це також порушить деякі цікаві питання: як традиційні механізми видобутку цінності майнерів (MEV) увійдуть у простір для створення бандерів та отримання цінності, коли потік ордерів SCA стане достатньо прибутковим, і як абстракція облікового запису (AA) слугуватиме базовим рівнем для транзакцій на основі намірів, коли інфраструктура дозріє?