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

Вступ

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

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

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

Прочитавши цю статтю, читачі отримають уявлення про:

1. Що таке модульна абстракція облікового запису
2. Як обліковий запис взаємодіє з модулями
3. Яка послідовність виклику модулів
4. Як знайти та перевірити модулі відкритим способом

Короткий огляд АА

Ландшафт SCA

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

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

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

👉 Якщо ви не знайомі з AA або ERC4337, перегляньте попередні дослідження SevenX тут.

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

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

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

1. Вплив ведмежого ринку:
   Незважаючи на те, що АА надає такі переваги, як безперебійний вхід і відбір газу, переважаючий ведмежий ринок переважно складається з освічених користувачів EOA, а не нових, тому немає стимулу для dApps і гаманців. Незважаючи на це, провідні програми все ще знаходяться на шляху до впровадження АА, наприклад Cyberconnect забезпечив близько 360 000 операцій UserOps (транзакцій АА) лише на місяць, представивши свою систему АА та безгазове рішення.
2. Перешкоди міграції:
   Для гаманців і додатків, які накопичили користувачів і зберегли активи в EOA, безпечне та зручне перенесення активів залишається проблемою. Тим не менш, такі ініціативи, як EIP-7377, дозволяють EOA ініціювати одноразову транзакцію міграції.
3. Проблема підписання:
   Сам розумний контракт, природно, не може підписувати повідомлення, оскільки він не має закритого ключа, як EOA. Зусилля, такі як ERC1271, роблять це можливим, але підписання повідомлень не працюватиме до першої транзакції, що створює проблему для гаманців, які використовують контрфактичне розгортання. А ERC-6492 , запропонований Ambire , є зворотно сумісним наступником ERC-1271, який потенційно вирішує попередню проблему.
4. Накладні витрати на газ:
   Розгортання, моделювання та виконання SCA потребують вищих витрат порівняно зі стандартними EOA. Це стає стримуючим фактором для усиновлення. Проте було проведено кілька тестів, як-от відокремлення створення облікового запису від операцій користувача та усунення перевірки наявності облікового запису, щоб зменшити ці витрати.
5. Інженерні труднощі:
   Команда ERC-4337 створила репозиторій eth-infinitism , щоб надати розробникам базову реалізацію. Проте, оскільки ми переходимо до більш нюансованих або специфічних функцій для різних випадків використання, інтеграція та декодування стають складними.

У цій статті ми зануримося в проблему №5: інженерні труднощі.

🤔️

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

Щоб детальніше розповісти про інженерні труднощі:

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

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

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

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

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

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

Як обліковий запис викликає модулі для реалізації функцій

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

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

Про delegateCall

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

Проксі-контракт і delegateCall

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

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

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

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

Що безпечно:

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

Що таке структура Safe

1. Контракт безпечного облікового запису: основний договір проксі (з урахуванням стану)
   Безпечний обліковий запис є проксі-контрактом, оскільки він делегатом викликає одиночний контракт. Безпечний обліковий запис містить власників, порогове значення та адреси впровадження, які встановлюються як змінні проксі-сервера, що визначає його стан.
2. Контракт Singleton: центр інтеграції (без стану)
   Singleton обслуговує обліковий запис Safe та інтегрує та визначає різні інтеграції, включаючи плагін, хук, обробник функцій і засіб перевірки підпису.
3. Контракт модуля: спеціальна логіка та функції:
   Модулі потужні. Плагіни як модульного типу можуть визначати різні функції, такі як потоки платежів, механізми відновлення та ключі сеансу, і можуть служити мостом між web2 і web3 шляхом отримання даних поза мережею. Інші модулі, такі як Hook як запобіжник і Function Handler, реагують на будь-які інструкції.

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

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

Діамантові проксі ERC-2535

Алмазна архітектура ERC2535

Про ERC2535, Diamond Proxies:

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

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

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

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

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

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

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

Тим не менш, основна відмінність полягає в обробці логічних контрактів. Ось ближчий погляд:

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

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

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

Яка послідовність виклику модулів

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

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

Назви функцій у різному дизайні

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

ERC6900

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

Модулі виявлення та безпеки

Як знайти та перевірити модулі відкритим способом

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

Безпечний протокол{Core}

Безпечний протокол{Core}

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

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

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

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

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

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

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

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

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

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

Закриття думок

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

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

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

Важливі частини

1. Безпечний документ: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Документ Rhinestone: https://docs.rhinestone.wtf/
3. Документація Biconomy: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Відмова від відповідальності:

1. Цю статтю передруковано з [SevenX Ventures ]. Усі авторські права належать оригінальному автору [SevenX Ventures]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.