Навіщо нам потрібна абстракція облікового запису?

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

Наприклад, багато людей думають, що використовувати ключі складніше, ніж використовувати електронну пошту для управління обліковими записами; управління ключами складне і небезпечне; і кожен переказ (наприклад, USDC) вимагає споживання нативних токенів (таких як Етер і Sol), що є нелогічним.

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

У процесі розвідки Ethereum запропонував абстрагування рахунку такі рішення, як ERC-4337, EIP-3074 і EIP-7702. Інші L1, такі як Solana, мають функції, які забезпечують абстрагування рахунку протокол рівня, такі як програмні похідні адреси (КПК), а Cosmos також має схожий дизайн, такий як x/authz і модуль абстракції плати. У цій статті ми представимо та порівняємо вищезгадані рішення, розберемося в тонкощах проектування різних рішень, продемонструємо компроміси та міркування різних рішень.

background

EOA проти контрактного облікового запису

Зовнішній обліковий запис (EOA) і контрактний рахунок – це два рахунок типи, визначені в Ethereum офіційному документі. Облікові записи EOA контролюються приватними ключами, і користувачі можуть підписувати різні транзакції через приватні ключі, щоб контролювати активи в рахунок. Договірний рахунок контролюється кодом самого рахунок, а інші облікові записи можуть змусити договір рахунок виконати певну логіку, викликавши код договору рахунок.

Абстракція

облікового запису Концепцію абстрагованих рахунків можна простежити з 2016 року (https://github.com/ethereum/EIPs/issues/86). абстрагування рахунку базується на двох поточних типах рахунок у Ethereum — EOA та контрактних рахунках. Це покращить інтерактивний досвід Ethereum користувачів за допомогою таких способів:

1. Дозволяє користувачам використовувати кілька сигнатур, таких як Шнорр, BLS, постквантові сигнатури тощо;
2. Дозволяє користувачам сплачувати газ комісії за допомогою токенів ERC20 або користувацької логіки оплати;
3. Дозволяє користувачам відновлювати свої облікові записи за допомогою електронної пошти, соціальних мереж тощо;
4. Дозволяє користувачам керувати коштами на своїх рахунках за допомогою точних дозволів, таких як встановлення щоденного ліміту на зняття коштів;
5. Дозволяє виконувати кілька операцій у блокчейні в одній атомарній транзакції. Наприклад, користувач може завершити операції затвердження та свопу в транзакції DEX одним підписом.

Ethereum Дорожня карта Дорожня карта

Ethereum (https://ethereum.org/en/roadmap/) висвітлює майбутній шлях оновлення Ethereum. Наразі більшість досліджень у Ethereum-спільноті обертається навколо дорожньої карти Ethereum. Абстракція рахунку є обов'язковою частиною цього:

Джерело: https://x.com/VitalikButerin/status/1741190491578810445

Спільнота Ethereum сподівається спиратися на ERC-4337 і впровадити абстрагування рахунку рішення в межах протокол за допомогою таких пропозицій, як EIP-3074 або EIP-7702, і, нарешті, досягти абстрагування рахунку Endgame.

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

EIP-3074 проти ERC-4337

Щоб зрозуміти рахунок абстраговані рахунки, нам потрібно зрозуміти, як працює EOA. На малюнку нижче представлений найпоширеніший процес купівлі та продажу токенів у ланцюжку:

Взагалі кажучи, користувачам потрібно здійснити дві транзакції під час купівлі та продажу: спочатку уповноважити Uniswap передати свої USDC на своп, а потім надіслати ще один запит на транзакцію, щоб Uniswap виконала дію. Uniswap передає USDC користувача рахунок та надсилає відповідну кількість ETH користувачеві відповідно до поточної ціни.

ERC-4337 об'єднує дві вищезгадані транзакції в одну:

Як видно з наведеного вище малюнка, користувачеві потрібно двічі підписатися, щоб уповноважити бандлера керувати активами користувача в рахунок 4337, який відрізняється від рахунок EOA користувача. Після того, як бандлер отримує авторизацію, він об'єднує авторизований контент у бандл і видає його для завершення транзакції. У той же час, якщо користувач не має Ethereum токенів для газ комісій, також може бути введена роль paymaster, що дозволить paymaster сплачувати газ комісії та отримувати від користувача токени ERC20 однакової вартості.

EIP-3074 і ERC-4337 мають деяку схожість, але спосіб реалізації EIP-3074 знаходиться в протокол Ethereum:

У стандарті ERC-4337 ми дозволяємо Bundler обробляти активи в нашому гаманці смарт-контрактів у блокчейні за допомогою підписів. У EIP-3074 бандлер уповноважений безпосередньо обробляти активи в нашому гаманці EOA за допомогою підписів. Щоб ордер це зробити, спільноті Ethereum потрібно додати до Ethereum протокол два нові коди операцій: AUTH та AUTHCALL.

AUTH використовується для перевірки того, чи авторизована поведінка бандлера щодо обробки EOA рахунок активів користувача, а AUTHCALL використовується для «обману» смарт-контракту взаємодії з користувачем (у нашому прикладі USDC та Uniswap), змушуючи смарт-контракт думати, що транзакція походить від EOA рахунок користувача. Перевага цього полягає в тому, що супроводжуючим Uniswap і USDC не потрібно оновлювати розгорнуті смартконтракти, і в той же час облікові записи EOA можуть користуватися функціями абстрагування рахунку.

Порівняння між EIP-3074 та ERC-4337

У спільноті Ethereum EIP зазвичай відноситься до пропозицій, які вимагають підтримки Ethereum оновлень, тоді як ERC відноситься до специфікацій, які можуть підтримуватися без Ethereum оновлень.

Таким чином, з назви двох абстрагування рахунку схем видно, що ERC-4337 простіше реалізувати, ніж EIP-3074, тому що ERC-4337 не вимагає жорсткого форк Ethereum мережі. Це також одна з причин, чому ERC-4337 був запущений і все частіше використовується на полігонах і базах, але EIP-3074 щойно був прийнятий 183-м Ethereum All Core Developers Execution Call (ACDE).

Джерело: https://dune.com/niftytable/account-abstraction

Крім того, ERC-4337 вимагає від користувачів перенесення своїх поточних рахунків на нові контрактні облікові записи та вимагає DApp підтримка для функціонування EIP-1271. EIP-3074 не вимагає цих додаткових опор. Це основна причина низького рівня впровадження ERC-4337. У той же час, ERC-4337 не може підтримка один підпис для авторизації декількох операцій у блокчейні без введення проміжного контракту з декількома викликами, але EIP-3074 може, що також спричиняє обмеження ERC-4337.

Однак у EIP-3074 є і свої проблеми. Найважливіша з них полягає в тому, що код операції AUTH має занадто високі дозволи, що може дозволити зловмиснику повністю контролювати EOA рахунок користувача. Зрештою, як би хакер не обманював ваш підпис AUTH, лонг він може розпоряджатися активами у вашому гаманці EA. Враховуючи, що фішингові атаки в даний час дуже поширені, і більшість з них обманюють підписи користувачів, після впровадження EIP-3074 це стане більш серйозною проблемою.

У зв'язку з цим lightclient, один з авторів EIP-3074, запропонував метод пом'якшення для перехоплення шкідливих сигнатур на рівні гаманця. Для отримання детальної інформації, будь ласка, перейдіть за посиланням: https://x.com/lightclients/status/1778823652584120497. ERC-4337 не має цієї проблеми, хоча хакери все одно можуть обманом змусити користувачів підписати шкідливі UserOps. Це пов'язано з труднощами для UserOp отримати повноваження щодо розпорядження всіма активами в рахунок користувача. На момент написання статті розробники в ACDE погодилися видалити EIP-3704 з Pectra Devent 0 і включити EIP-7702 в наступну Pectra Devnet 1.

Що змінилося в EIP-7702?

EIP-7702 намагається інтегрувати переваги EIP-3074 та ERC-4337 для формування середнього шляху. Користувач надсилає підписану операцію бандлеру. Коли бандлер надішле транзакцію в ланцюжок, EOA рахунок користувача тимчасово стане смарт-контрактом рахунок на кшталт 4337 рахунок. Далі, подібно до прогресу AUTH у EIP-3074, рахунок смарт-контракту перевірятиме авторизовану операцію бандлера користувача. Потім, так само, як і AUTHCALL, виконати операції, авторизовані користувачем. Після виконання транзакції користувач рахунок буде відкочений назад до звичайного EOA рахунок.

Переваги EIP-7702 полягають у наступному:

1. Успадковує всі переваги EIP-3074: не вимагає від користувачів переходу з облікових записів EOA на облікові записи смарт-контрактів з новими адресами; може виконувати кілька операцій в одній атомарній транзакції;
2. Смарт-контракт рахунок код та інфраструктуру ERC-4337 можна використовувати повторно;
3. Смарт-контракт абстрагування рахунку, представлений ERC-4337, і рішення EOA абстрагування рахунку, представлене EIP-3074, можуть бути об'єднані, щоб запобігти розпаду Ethereum на дві різні системи абстрагування рахунку і прокласти шлях для облікового запису абстракції в кінці гри в дорожній карті Ethereum;
4. Два коди операцій AUTH і AUTHCALL не будуть додані до EVM Ethereum: з урахуванням рахунок дорожньої карти Ethereum облікові записи EOA будуть перетворені на абстрагування рахунку в майбутньому, і ці два коди операцій стануть зайвими.

Крім того, EIP-7702 успадковує всі ризики безпеки від EIP-3074.

Спільнота вирішила включити EIP-7702 у наступне оновлення Pectra у 2025 році. Якщо він буде впроваджений, він значно змінить екосистему Ethereum і принесе поступові покращення в поточну версію абстрагування рахунку інфраструктури ERC-4337.

Solana Програма похідна Адреса

Абстракція облікового запису на Solana

абстрагування рахунку Solana схожа на ERC-4337 Ethereum. Це облікові записи, похідні від оригінальних рахунків (аналогічно рахункам EOA), схожі на 4337 контрактних рахунків. Перш ніж зрозуміти абстрагування рахунку Solana, необхідно зрозуміти модель рахунок, яку використовує Solana.

У широкому сенсі, облікові записи можна класифікувати як виконувані облікові записи, які можуть виконувати код, або невиконувані облікові записи, які не можуть цього робити. Якщо розглянути це питання далі, то на Solana існує три типи облікових записів: нативна програма, програмний обліковий запис і обліковий запис даних.

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

Ця рахунок модель дозволяє програмним обліковим записам створювати певні облікові записи та керувати ними, пропонуючи розробникам можливість визначати власні правила та логіку для керування ними. Завдяки цій моделі рахунок програма Program Derived Адреса (PDA), тип рахунок даних, розширює можливості абстрагування рахунку можливостей на Solana від підвищення безпеки користувачів за допомогою гаманців з мультипідписом і двофакторної автентифікації до забезпечення механізмів соціального відновлення, серед іншого.

Програмна похідна Адреса

Для контексту, усі облікові записи лежать на кривій Ed25519 і мають пару ключів відкритий-закритий. КПК, який лежить за межами кривої Ed25519, є детерміновано виведеним 32-байтовим рядком, який виглядає як відкритий ключ і не поставляється з відповідним закритим ключем. КПК дозволяють розробникам створювати власні правила та механізми підпису транзакцій, які можуть дозволити власнику програми рахунок КПК автономно виконувати транзакції від імені КПК, повністю розпізнаних та підтримуваних мережею Solana.

PDA та абстракція облікового запису

Гаразд, тепер, коли ми розуміємо, як походять КПК, вам може бути цікаво, як ці поняття пов'язані з абстрагування рахунку. Абстракція облікового запису відбувається під капотом за допомогою функції, відомої як Cross Program Invocation (CPI).

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

Джерело: Solana

Щоб перевірити легітимність транзакцій, пов'язаних з КПК, середовище виконання Solana внутрішньо викликає create_program_address, використовуючи signers_seeds і program_id програми, що викликає. Якщо буде знайдено дійсний КПК, середовище виконання пов'яже КПК з програмою, що викликає, і розпізнає програму як авторизованого підписанта.

В даний час Squads розробляє рішення для абстрагування рахунку на Solana на базі КПК. Однак продукт, що надається Squaads, наразі більше схожий на рішення рахунок смарт-контрактів Gnosis Safe і ще не повністю розробив свій функціонал абстрагування рахунку.

Переваги КПК

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

Обмеження КПК

1. КПК, незважаючи на те, що вони корисні для закладення основи для абстрагування рахунку можливостей, можуть бути складними в реалізації порівняно з рахунок парою ключів.
2. І, як і ERC-4337, він вимагає від користувачів виконувати рахунок міграцію на новий рахунок, що може знизити рівень впровадження Solana абстрагування рахунку.

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

Оскільки абстрагування рахунку все більше займають частку думки розробників, було запущено authz, частину ядра Cosmos SDK, щоб дозволити рахунок виконувати певні дії від імені іншого рахунок за допомогою грантів авторизації, що аналогічно EIP-3074 та EIP-7702.

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

За допомогою authz можна надати 3 типи авторизацій:

1. GenericAuthorization. Цей дозвіл надає необмежений дозвіл грантоотримувачу на виконання повідомлення від імені грантодавця.
2. SendAuthorization. Цей дозвіл, як і схвалення в ERC20, спрямований на те, щоб надати грантоотримувачу доступ до позитивного ліміту витрат, який визначає максимальну суму, яка може бути витрачена від імені грантодавця.
3. Авторизація стейкінгу. Цей грант дозволяє грантоотримувачам керувати такими діями стейкінгу, як делегування, скасування делегування або повторне делегування від імені грантодавця.

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

Розуміння операційної структури

Authz можна використовувати для надання дозволів на різноманітні дії, однак для простоти ми розглянемо, як працює authz для уможливлення загальних транзакцій голосування.

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

Переваги, які приносить авторизація?

1. Операційна безпека: валідатори та інші користувачі можуть надавати дозволи окремій рахунок голосувати за пропозиції щодо управління або виконувати певні дії, підвищуючи рахунок безпеку та зменшуючи навантаження на безпеку.
2. Оптимізовані операції: транзакції можуть бути виконані з потребою в доступі до ключів валідатора, транзакції гаманця з мультипідписом також можуть бути оптимізовані за допомогою однієї транзакції для надання Authz грантоотримувачу рахунок.
3. Немає необхідності в перенесенні: Подібно до EIP-3074 і EIP-7702, операції авторизації відбуваються в початковому рахунок користувача. Користувачам не потрібно переносити свої активи з початкового рахунок на новий рахунок, щоб увімкнути абстрагування рахунку.
4. DAO Операційна ефективність та гнучкість: Підмножина прав на виконання може бути надана окремим DAO членам для конкретних дій.
5. Стейкінг Компаундування винагород: Authz полегшує використання повторного стейкінгу та еквівалентних послуг для автоматизованого накопичення винагород за стейкінг.

Обмеження та ризики для Authz:

Зверніть увагу на типи транзакцій, які ви авторизуєте через Authz. Зловмисна авторизація може виконувати різні типи авторизацій, які можуть завдати шкоди користувачеві.

1. GenericAuthorization: надає необмежений дозвіл на виконання наданого повідомлення від імені грантодавця. Якщо ви повністю не усвідомлюєте, що ви підписуєте, настійно не рекомендується підписувати такі типи дозволів. Деякі гаманці також можуть не надавати попередження під час підписання транзакцій Authz.
2. SendAuthorization: Дозволяє грантоотримувачу надіслати максимальну кількість токенів, яку грантоотримувач може витратити, якщо це не вказано грантодавцем. Також важливо перевірити AllowList, в якому вказується конкретна адреса, на яку грантоотримувач може відправити токени.

Fee Grant Module

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

Однак ця перешкода стала проривом з інтеграцією Fee Grant Module. Подібно до контракту paymaster, який дозволяє абстрагування рахунку на Ethereum, модуль Fee Grant Module на Cosmos дозволяє грантодавцю надавати винагороду грантоотримувачу, сплачуючи частину або всі комісії за транзакцію. Кошти залишаються під контролем грантодавця, і він може відкликати грантову допомогу в будь-який час.

Види гонорарних грантів

Надбавку на оплату можна розділити на два типи: базова надбавка та періодична надбавка.

Базова допомога дозволяє грантоотримувачу використовувати гонорари грантодавця рахунок до тих пір, поки не буде досягнуто ліміту витрат або закінчення терміну дії. Після цього грант буде припинено державою. Важливо зазначити, що BasicAllowance реалізує одноразове надання внесків. Якщо ліміт витрат і час порожні, то немає обмежень щодо терміну дії та витрат на надбавку до оплати.

Періодична надбавка дозволяє періодично поновлювати гранти на оплату після кожного зазначеного періоду часу. Period_spend_limit вказує максимальну кількість монет, які можна витратити за період. Period_reset відстежує, коли має відбутися наступний період, і period_can_spend відстежує кількість монет, що залишилися до початку нового періоду.

Розуміння операційної структури

Використання AllowedMsgAllowance створює дозвіл на вказані типи повідомлень. Надбавка може бути як базовою, так і періодичною. Якщо встановлено час закінчення терміну дії, FeeAllowance буде поставлено в чергу в стані з додаванням префікса закінчення терміну дії до гранту, а Endblocker перевіряє стан FeeAllowanceQueue на наявність прострочених грантів, обрізаючи будь-які, якщо вони знайдені. Окрім MsgGrantAllowance, надбавка на оплату також може бути скасована за допомогою MsgRevokeAllowance.

Разом узяті, модулі Authz і Fee Grant відкривають інноваційні та різноманітні варіанти використання, які в кінцевому підсумку створюють кращий користувацький досвід в екосистемі Cosmos.

Висновок

Абстракція облікового запису Станом на 27 травня 2024 року цифри оцінюються.

Зі схваленням спотових BTC ETF та ETH ETF інституційний та роздрібний попит значно зріс, що обіцяє розпочати нову хвилю користувачів, які прагнуть отримати доступ до галузі. Абстракція облікових записів стане важливим наративом цього року, оскільки протоколи та децентралізовані програми прагнуть створити безперебійний досвід для розширення своїх спільнот.

ВІДМОВА ВІД ВІДПОВІДАЛЬНОСТІ

Цей матеріал призначений лише для загальної інформації та не є і не повинен тлумачитися як будь-яка форма результатів дослідження, професійних порад, пропозицій, пропозицій, рекомендацій або торгової стратегії. Жодні гарантії, заяви, гарантії чи зобов'язання, явні чи неявні, не надаються щодо справедливості, точності, своєчасності, повноти чи правильності будь-якої загальної фінансової та ринкової інформації, аналізу та/або думок, наданих у цьому звіті, і HashKey Capital не несе жодної відповідальності чи відповідальності щодо використання або довіри до будь-якої такої інформації. Будь-яка інформація в цьому звіті може бути змінена без попередження. Цей звіт не розглядався Комісією з цінних паперів та ф'ючерсів Гонконгу, Грошово-кредитним управлінням Сінгапуру або будь-яким регулюючим органом Гонконгу чи Сінгапуру.

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

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

Будьте в курсі останніх новин HashKey Capital -

Веб-сайт — https://hashkey.capital/

Твіттер — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

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

1. Цю статтю передруковано з [Medium]. Усі авторські права належать оригінальному автору [HashKey Capital]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно впораються з цим.

2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.

3. Переклад статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.