Перехід від зовнішніх облікових записів (EOA) до облікових записів смарт-контрактів (SCA) набирає обертів і був прийнятий багатьма ентузіастами, включаючи самого Віталіка. Незважаючи на хвилювання, впровадження SCA не таке широке, як EOA. Ключовими серед них є виклики, пов’язані з ведмежими ринками, занепокоєння міграцією, проблеми з підписанням договору, накладні витрати на газ і, що найбільш критично, інженерні труднощі.
Найважливішою перевагою облікових записів (AA) є можливість використовувати код для налаштування функціональності. Однак однією з основних інженерних проблем є несумісність функціональних можливостей АА, а фрагментація перешкоджає інтеграції та відкриває двері для блокування постачальників. Крім того, забезпечення безпеки з одночасним оновленням і створенням функцій може бути складним.
Введіть модульну абстракцію облікових записів, як підмножину ширшого руху АА, цей інноваційний підхід може відокремити розумні облікові записи від їхніх спеціальних функцій. Мета полягає в тому, щоб створити модульну структуру для розробки безпечних, бездоганно інтегрованих гаманців із різними функціями. У майбутньому він може створити безкоштовний «магазин додатків» для облікових записів смарт-контрактів, який звільнить гаманці та dApp від функцій створення, але зосередиться на взаємодії з користувачем.
Прочитавши цю статтю, читачі отримають уявлення про:
Ландшафт SCA
Традиційний EOA представляє багато проблем, як-от початкова фраза, газ, крос-ланцюг і численні транзакції. Ми ніколи не збиралися створювати складності, але насправді блокчейн — це непроста гра для мас.
Account Abstraction використовує обліковий запис смарт-контракту, що дозволяє програмувати перевірку та виконання, де користувач може затверджувати серію транзакцій за один раз, а не підписувати та транслювати кожну, і реалізувати багато інших функцій. Це надає переваги взаємодії з користувачем (наприклад, відбір газу та ключі сесії), вартість (наприклад, пакетна транзакція) та безпека (наприклад, соціальне відновлення, мульти-підпис). Наразі існує два способи досягнення абстракції облікового запису:
👉 Якщо ви не знайомі з AA або ERC4337, перегляньте попередні дослідження SevenX тут.
Тема абстракції облікового запису (AA) обговорюється з 2015 року, і цього року ERC4337 привернула її до уваги. Однак кількість розгорнутих облікових записів смарт-контрактів все ще блідне порівняно з EOA.
Давайте заглибимося в цю дилему:
У цій статті ми зануримося в проблему №5: інженерні труднощі.
🤔️
Щоб детальніше розповісти про інженерні труднощі:
Щоб рухатися в цих водах, нам потрібні контракти з можливістю оновлення, які забезпечують безпечне й ефективне оновлення, багаторазові ядра для підвищення загальної ефективності розробки та стандартизовані інтерфейси, щоб гарантувати плавний перехід облікових записів контрактів між різними інтерфейсами.
Ці терміни об’єднують єдину концепцію: побудова модульної абстрактної архітектури облікового запису (Modular AA).
Модульний AA — це ніша в рамках ширшого руху AA, який передбачає модульну структуру розумних облікових записів, щоб налаштувати їх для користувачів і дати можливість розробникам плавно вдосконалювати функції з мінімальними обмеженнями.
Проте в будь-якій галузі створення та просування нового стандарту є великим викликом. На початкових етапах може бути багато різних рішень, перш ніж кожен зупиниться на головному. Однак приємно бачити тих, хто працює над абстракцією облікових записів, будь то 4337 SDK, розробники гаманців, команди інфраструктури чи розробники протоколів, які об’єднуються, щоб пришвидшити процес.
Як обліковий запис викликає модулі для реалізації функцій
Зовнішній виклик і виклик делегата:
Про delegateCall
У той час як delegatecall схожий на виклик, але замість виконання цільового контракту у власному контексті він виконує його в контексті поточного стану виклику контракту. Це означає, що будь-які зміни стану, зроблені цільовим контрактом, вносяться до сховища контракту виклику.
Проксі-контракт і delegateCall
Щоб реалізувати структуру, яку можна складати та оновлювати, необхідні фундаментальні знання під назвою «проксі-контракт».
Безпечна архітектура
Що безпечно:
Safe — це провідна модульна інфраструктура розумного облікового запису, розроблена для забезпечення перевіреної в боях безпеки та гнучкості, вона дає змогу розробникам створювати різноманітні програми та гаманці. Примітно, що багато команд будують на основі Safe або надихаються ним. Biconomy запустила свій обліковий запис , розширивши Safe рідними мультипідписами 4337 і 1/1. З огляду на розгортання понад 164 000 контрактів і зафіксовану вартість понад 30,7 мільярдів, Safe, без сумніву, є лідером у космосі.
Що таке структура Safe
Що відбувається, коли ми приймаємо Safe:
Алмазна архітектура ERC2535
Про ERC2535, Diamond Proxies:
ERC2535 стандартизує алмази, модульну систему смарт-контрактів, яку можна оновити/розширити після розгортання та практично не має обмежень щодо розміру. Досі багато команд надихалися цим, як-от Kernel Zerodev та експеримент Soul Wallet.
Що таке алмазна структура:
Що станеться, коли ми приймемо Diamond:
Між архітектурами Safe і Diamond багато схожості, обидві покладаються на проксі-контракти в основі та посилаються на логічні контракти для досягнення можливості оновлення та модульності.
Тим не менш, основна відмінність полягає в обробці логічних контрактів. Ось ближчий погляд:
«Підхід до безпечного розумного облікового запису» та «Діамантовий підхід» є прикладами різних структур, що включають проксі та модулі. Як збалансувати гнучкість і безпеку є вирішальним, і ці два методи потенційно можуть доповнювати один одного в майбутньому.
Яка послідовність виклику модулів
Давайте розширимо наше обговорення, представивши ERC6900, стандарт, запропонований командою Alchemy , натхненний Diamond і розроблений спеціально для ERC-4337. Він вирішує проблему модульності в розумних облікових записах, надаючи загальні інтерфейси та координуючи зусилля між розробниками плагінів і гаманців.
Коли мова заходить про процес транзакцій АА, існує три основні процеси: перевірка, виконання та перехоплення. Усіма цими кроками можна керувати за допомогою облікового запису проксі для виклику модулів, як ми обговорювали раніше. Хоча різні проекти можуть використовувати різні назви, важливо зрозуміти схожу основну логіку.
Назви функцій у різному дизайні
ERC6900
Дуже важливо розділити модулі на основі іншої логіки. Стандартизований підхід повинен диктувати, як повинні бути написані функції перевірки, виконання та підключення для облікових записів смарт-контрактів. Незалежно від того, чи це Safe чи ERC6900, стандартизація допомагає зменшити потребу в унікальних зусиллях щодо розробки, специфічних для певних реалізацій або екосистем, і запобігає блокуванню постачальника.
Як знайти та перевірити модулі відкритим способом
Рішення, яке набирає обертів, передбачає створення місця, яке дозволяє користувачам знаходити верифіковані модулі, які ми можемо назвати «реєстром». Цей реєстр функціонує подібно до «App Store» і має на меті сприяти створенню спрощеного, але процвітаючого модульного ринку.
Безпечний протокол{Core}
Безпечний{Core} протокол — це сумісний протокол із відкритим кодом для облікових записів смарт-контрактів, призначений для покращення доступності для різних постачальників і розробників, одночасно зберігаючи надійну безпеку завдяки чітко визначеним стандартам і правилам.
Дизайн зі стразами
Процес розгортається наступним чином:
Хоча ця схема знаходиться на ранніх стадіях, вона має потенціал для встановлення стандарту децентралізованим і спільним способом. Їхній реєстр дає змогу розробникам реєструвати свої модулі, аудиторам — перевіряти їхню безпеку, а гаманцям — інтегруватись, а користувачам — легко знаходити модулі та перевіряти їхню атестаційну інформацію. Кілька майбутніх застосувань можуть бути:
Концепція «Реєстру модулів» відкриває можливості для монетизації для розробників плагінів і модулів. Це може ще більше прокласти шлях до «ринку модулів». Деякі аспекти можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізовані ринкові майданчики, які запрошують внески та прозорі аудиторські записи для всіх. Впровадивши це, ми можемо уникнути прив’язки до постачальника та підтримати розширення EVM, додавши розширений досвід користувача, який залучає ширшу аудиторію.
Хоча ці підходи гарантують безпеку одного модуля, ширша безпека облікових записів смарт-контрактів не є надійною. Поєднання легітимних модулів і доказів відсутності конфліктів зберігання може бути складним завданням, що підкреслює важливість гаманця або інфраструктури АА для вирішення таких проблем.
Використовуючи модульний стек облікових записів смарт-контрактів, постачальники гаманців і dApps можуть бути звільнені від складнощів технічного обслуговування. У той же час зовнішні розробники модулів мають можливість пропонувати спеціалізовані послуги, адаптовані до індивідуальних потреб. Однак проблеми, які необхідно вирішити, включають досягнення балансу між гнучкістю та безпекою, просування модульних стандартів і впровадження стандартизованих інтерфейсів, які дають змогу користувачам легко оновлювати та змінювати свої розумні облікові записи.
Проте модульні облікові записи смарт-контрактів (SCA) є лише частиною головоломки впровадження. Для повної реалізації потенціалу SCA необхідна додаткова підтримка рівня протоколу від рішень рівня 2, таких як надійна інфраструктура пакетування та одноранговий мемпул, більш економічно ефективний і здійсненний механізм підписання SCA, міжланцюгова синхронізація та керування SCA і розробити зручні для користувача інтерфейси.
Дивлячись уперед, ми уявляємо майбутнє, де участь буде широко поширеною, що викликає інтригуючі запитання: як тільки потік замовлень SCA стане достатньо прибутковим, як традиційні механізми Miner Extractable Value (MEV) увійдуть у сферу для створення пакетів і отримання вартості? Коли інфраструктура розвивається, як абстракції облікового запису (AA) можуть служити базовим рівнем для транзакцій на основі намірів? Слідкуйте за оновленнями; ландшафт розвивається щохвилини.
Перехід від зовнішніх облікових записів (EOA) до облікових записів смарт-контрактів (SCA) набирає обертів і був прийнятий багатьма ентузіастами, включаючи самого Віталіка. Незважаючи на хвилювання, впровадження SCA не таке широке, як EOA. Ключовими серед них є виклики, пов’язані з ведмежими ринками, занепокоєння міграцією, проблеми з підписанням договору, накладні витрати на газ і, що найбільш критично, інженерні труднощі.
Найважливішою перевагою облікових записів (AA) є можливість використовувати код для налаштування функціональності. Однак однією з основних інженерних проблем є несумісність функціональних можливостей АА, а фрагментація перешкоджає інтеграції та відкриває двері для блокування постачальників. Крім того, забезпечення безпеки з одночасним оновленням і створенням функцій може бути складним.
Введіть модульну абстракцію облікових записів, як підмножину ширшого руху АА, цей інноваційний підхід може відокремити розумні облікові записи від їхніх спеціальних функцій. Мета полягає в тому, щоб створити модульну структуру для розробки безпечних, бездоганно інтегрованих гаманців із різними функціями. У майбутньому він може створити безкоштовний «магазин додатків» для облікових записів смарт-контрактів, який звільнить гаманці та dApp від функцій створення, але зосередиться на взаємодії з користувачем.
Прочитавши цю статтю, читачі отримають уявлення про:
Ландшафт SCA
Традиційний EOA представляє багато проблем, як-от початкова фраза, газ, крос-ланцюг і численні транзакції. Ми ніколи не збиралися створювати складності, але насправді блокчейн — це непроста гра для мас.
Account Abstraction використовує обліковий запис смарт-контракту, що дозволяє програмувати перевірку та виконання, де користувач може затверджувати серію транзакцій за один раз, а не підписувати та транслювати кожну, і реалізувати багато інших функцій. Це надає переваги взаємодії з користувачем (наприклад, відбір газу та ключі сесії), вартість (наприклад, пакетна транзакція) та безпека (наприклад, соціальне відновлення, мульти-підпис). Наразі існує два способи досягнення абстракції облікового запису:
👉 Якщо ви не знайомі з AA або ERC4337, перегляньте попередні дослідження SevenX тут.
Тема абстракції облікового запису (AA) обговорюється з 2015 року, і цього року ERC4337 привернула її до уваги. Однак кількість розгорнутих облікових записів смарт-контрактів все ще блідне порівняно з EOA.
Давайте заглибимося в цю дилему:
У цій статті ми зануримося в проблему №5: інженерні труднощі.
🤔️
Щоб детальніше розповісти про інженерні труднощі:
Щоб рухатися в цих водах, нам потрібні контракти з можливістю оновлення, які забезпечують безпечне й ефективне оновлення, багаторазові ядра для підвищення загальної ефективності розробки та стандартизовані інтерфейси, щоб гарантувати плавний перехід облікових записів контрактів між різними інтерфейсами.
Ці терміни об’єднують єдину концепцію: побудова модульної абстрактної архітектури облікового запису (Modular AA).
Модульний AA — це ніша в рамках ширшого руху AA, який передбачає модульну структуру розумних облікових записів, щоб налаштувати їх для користувачів і дати можливість розробникам плавно вдосконалювати функції з мінімальними обмеженнями.
Проте в будь-якій галузі створення та просування нового стандарту є великим викликом. На початкових етапах може бути багато різних рішень, перш ніж кожен зупиниться на головному. Однак приємно бачити тих, хто працює над абстракцією облікових записів, будь то 4337 SDK, розробники гаманців, команди інфраструктури чи розробники протоколів, які об’єднуються, щоб пришвидшити процес.
Як обліковий запис викликає модулі для реалізації функцій
Зовнішній виклик і виклик делегата:
Про delegateCall
У той час як delegatecall схожий на виклик, але замість виконання цільового контракту у власному контексті він виконує його в контексті поточного стану виклику контракту. Це означає, що будь-які зміни стану, зроблені цільовим контрактом, вносяться до сховища контракту виклику.
Проксі-контракт і delegateCall
Щоб реалізувати структуру, яку можна складати та оновлювати, необхідні фундаментальні знання під назвою «проксі-контракт».
Безпечна архітектура
Що безпечно:
Safe — це провідна модульна інфраструктура розумного облікового запису, розроблена для забезпечення перевіреної в боях безпеки та гнучкості, вона дає змогу розробникам створювати різноманітні програми та гаманці. Примітно, що багато команд будують на основі Safe або надихаються ним. Biconomy запустила свій обліковий запис , розширивши Safe рідними мультипідписами 4337 і 1/1. З огляду на розгортання понад 164 000 контрактів і зафіксовану вартість понад 30,7 мільярдів, Safe, без сумніву, є лідером у космосі.
Що таке структура Safe
Що відбувається, коли ми приймаємо Safe:
Алмазна архітектура ERC2535
Про ERC2535, Diamond Proxies:
ERC2535 стандартизує алмази, модульну систему смарт-контрактів, яку можна оновити/розширити після розгортання та практично не має обмежень щодо розміру. Досі багато команд надихалися цим, як-от Kernel Zerodev та експеримент Soul Wallet.
Що таке алмазна структура:
Що станеться, коли ми приймемо Diamond:
Між архітектурами Safe і Diamond багато схожості, обидві покладаються на проксі-контракти в основі та посилаються на логічні контракти для досягнення можливості оновлення та модульності.
Тим не менш, основна відмінність полягає в обробці логічних контрактів. Ось ближчий погляд:
«Підхід до безпечного розумного облікового запису» та «Діамантовий підхід» є прикладами різних структур, що включають проксі та модулі. Як збалансувати гнучкість і безпеку є вирішальним, і ці два методи потенційно можуть доповнювати один одного в майбутньому.
Яка послідовність виклику модулів
Давайте розширимо наше обговорення, представивши ERC6900, стандарт, запропонований командою Alchemy , натхненний Diamond і розроблений спеціально для ERC-4337. Він вирішує проблему модульності в розумних облікових записах, надаючи загальні інтерфейси та координуючи зусилля між розробниками плагінів і гаманців.
Коли мова заходить про процес транзакцій АА, існує три основні процеси: перевірка, виконання та перехоплення. Усіма цими кроками можна керувати за допомогою облікового запису проксі для виклику модулів, як ми обговорювали раніше. Хоча різні проекти можуть використовувати різні назви, важливо зрозуміти схожу основну логіку.
Назви функцій у різному дизайні
ERC6900
Дуже важливо розділити модулі на основі іншої логіки. Стандартизований підхід повинен диктувати, як повинні бути написані функції перевірки, виконання та підключення для облікових записів смарт-контрактів. Незалежно від того, чи це Safe чи ERC6900, стандартизація допомагає зменшити потребу в унікальних зусиллях щодо розробки, специфічних для певних реалізацій або екосистем, і запобігає блокуванню постачальника.
Як знайти та перевірити модулі відкритим способом
Рішення, яке набирає обертів, передбачає створення місця, яке дозволяє користувачам знаходити верифіковані модулі, які ми можемо назвати «реєстром». Цей реєстр функціонує подібно до «App Store» і має на меті сприяти створенню спрощеного, але процвітаючого модульного ринку.
Безпечний протокол{Core}
Безпечний{Core} протокол — це сумісний протокол із відкритим кодом для облікових записів смарт-контрактів, призначений для покращення доступності для різних постачальників і розробників, одночасно зберігаючи надійну безпеку завдяки чітко визначеним стандартам і правилам.
Дизайн зі стразами
Процес розгортається наступним чином:
Хоча ця схема знаходиться на ранніх стадіях, вона має потенціал для встановлення стандарту децентралізованим і спільним способом. Їхній реєстр дає змогу розробникам реєструвати свої модулі, аудиторам — перевіряти їхню безпеку, а гаманцям — інтегруватись, а користувачам — легко знаходити модулі та перевіряти їхню атестаційну інформацію. Кілька майбутніх застосувань можуть бути:
Концепція «Реєстру модулів» відкриває можливості для монетизації для розробників плагінів і модулів. Це може ще більше прокласти шлях до «ринку модулів». Деякі аспекти можуть контролюватися командою Safe, тоді як інші можуть проявлятися як децентралізовані ринкові майданчики, які запрошують внески та прозорі аудиторські записи для всіх. Впровадивши це, ми можемо уникнути прив’язки до постачальника та підтримати розширення EVM, додавши розширений досвід користувача, який залучає ширшу аудиторію.
Хоча ці підходи гарантують безпеку одного модуля, ширша безпека облікових записів смарт-контрактів не є надійною. Поєднання легітимних модулів і доказів відсутності конфліктів зберігання може бути складним завданням, що підкреслює важливість гаманця або інфраструктури АА для вирішення таких проблем.
Використовуючи модульний стек облікових записів смарт-контрактів, постачальники гаманців і dApps можуть бути звільнені від складнощів технічного обслуговування. У той же час зовнішні розробники модулів мають можливість пропонувати спеціалізовані послуги, адаптовані до індивідуальних потреб. Однак проблеми, які необхідно вирішити, включають досягнення балансу між гнучкістю та безпекою, просування модульних стандартів і впровадження стандартизованих інтерфейсів, які дають змогу користувачам легко оновлювати та змінювати свої розумні облікові записи.
Проте модульні облікові записи смарт-контрактів (SCA) є лише частиною головоломки впровадження. Для повної реалізації потенціалу SCA необхідна додаткова підтримка рівня протоколу від рішень рівня 2, таких як надійна інфраструктура пакетування та одноранговий мемпул, більш економічно ефективний і здійсненний механізм підписання SCA, міжланцюгова синхронізація та керування SCA і розробити зручні для користувача інтерфейси.
Дивлячись уперед, ми уявляємо майбутнє, де участь буде широко поширеною, що викликає інтригуючі запитання: як тільки потік замовлень SCA стане достатньо прибутковим, як традиційні механізми Miner Extractable Value (MEV) увійдуть у сферу для створення пакетів і отримання вартості? Коли інфраструктура розвивається, як абстракції облікового запису (AA) можуть служити базовим рівнем для транзакцій на основі намірів? Слідкуйте за оновленнями; ландшафт розвивається щохвилини.