Глибоке дослідження минулого та майбутнього абстрактних акаунтів Ethereum

Ця стаття поділяється на дві основні частини:

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

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

EIP-7702 має епохальне значення, давайте детально розглянемо це.

1. Фон абстракції акаунта

1.1 Значення абстракції акаунта

Засновник Ethereum Віталік, оновлюючи дорожню карту ETH наприкінці 2023 року, не змінив налаштування абстракції акаунтів. Наразі основна модель переходить від EIP-4337 до наступного етапу добровільного перетворення акаунтів EOA.

Більше ніж рік з моменту запуску EIP4337, 1 березня 2023 року на WalletCon у Денвері офіційно оголосили про (, що отримав широке визнання серед користувачів, але його використання залишається невисоким. У цій суперечливій ринковій ситуації прогрес EIP-7702 значно прискорився, і вже підтверджено, що він буде об'єднаний у наступному оновленні.

) 1.2 акаунт абстрактний стан ринку

Після півтора року розвитку кількість акаунтів EIP4337 на основних ланцюгах становить лише 12 мільйонів, з яких на основній мережі Ethereum лише 6,764 активні адреси, що суттєво відрізняється від кількості EOA та CA адрес. Кількість незалежних адрес на основній мережі Ethereum досягла 270 мільйонів, можна сказати, що EIP4337 на основній мережі практично не має суттєвого розвитку.

Однак це не впливає на сутнісну цінність AA. Дизайн EIP4337 визначає, що йому важко вирішити проблему зворотної сумісності основної мережі. З різними L2, які рідко вбудовують AA, кількість адрес EIP4337 на L2 отримала сплеск, при цьому кількість активних користувачів у Base та Polygon у липні досягла 1 мільйона та 3 мільйонів відповідно.

Отже, проблема не в дизайні EIP4337, у нього є багато переваг. Сучасний стан справ зумовлений різницею між основною мережею та L2, які потребують відповідних рішень.

![Глибоке розуміння минулого та майбутнього абстракції акаунтів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp(

2. Що таке абстракція акаунта?

Акаунтна абстракція в основному вирішує проблему розділення прав власності.

У архітектурі віртуальної машини Ethereum)EVM( є два типи акаунтів: зовнішній акаунт)EOA( та контрактний акаунт)Contract Account(. Право власності та право підпису зовнішнього акаунту фактично належать одній і тій же особі. Особа, що володіє приватним ключем, не лише має "власність" акаунту, але й має право "підписувати передачу всіх активів".

Це визначається структурою транзакцій акаунта Ethereum. З структури транзакції видно, що стандартна транзакція Ethereum не має поля From. Під час переказу коштів конкретна адреса, з якої використовуються кошти, визначається через параметри VRS ), тобто підпис користувача (, що зворотно розкриває адресу From.

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

Основний ефект EIP4337 полягає в додаванні поля Sender Address у поле транзакції, що дозволяє розділити приватний ключ і адресу, яка підлягає обробці.

Причина, чому розділення прав власності є таким важливим, полягає в тому, що проектування зовнішніх акаунтів )EOA( може викликати більше проблем:

1. Складно захистити приватний ключ: втрата приватного ключа ), атаки хакерів, криптографічний злом ( означають втрату всіх активів.

2. Одночасний алгоритм підпису: оригінальний протокол може використовувати лише алгоритм підпису та перевірки ECDSA при верифікації транзакцій.

3. Права підпису занадто високі: без нативного мультипідпису ) мультипідпис може бути реалізований лише через смарт-контракт (, однопідпис може виконувати будь-які дії.

4. Комісія за транзакцію може бути сплачена лише ETH, пакетні транзакції не підтримуються.

5. Витік конфіденційності交易: одноосібні交易 легко аналізувати конфіденційні дані акаунта.

Ці обмеження ускладнюють звичайним користувачам використання Ethereum:

По-перше, для використання будь-якого додатку на Ethereum користувачі повинні володіти Етер ) і брати на себе ризик коливання цін (.

По-друге, користувачам потрібно обробляти складну логіку зборів, такі поняття, як ціна Gas, обмеження Gas, блокування транзакцій ) порядок Nonce ( є занадто складними для користувачів.

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

Отже, рішення полягає в реалізації абстракції акаунтів, що дозволяє декомпонувати право власності )Owner( та право підпису )Signer(, що поступово вирішить вищезазначені проблеми.

В історії існувало безліч варіантів, які врешті-решт злилися в два напрямки.

![Глибоке дослідження минулого та майбутнього абстракції акаунтів Ethereum])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(

3. Аналіз історичних пропозицій AA

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

) 3.1 Перший варіант маршруту: перетворення EOA-адреси на CA-адресу

Ще 15 листопада 2015 року, навколо EIP-101, Віталік запропонував нову структуру акаунтів на основі контрактів. Змінити адресу на лише код і простір зберігання, змінити підтримку комісії на оплату через ERC20, через попередньо скомпільований контракт перетворити рідний токен на аналог ERC20 для зберігання балансу ###, що може мати функції автоматичного утримання дозволу тощо (, спростити поля транзакції до тільки to, startgas, data та code.

Зараз це виглядає як великий стрибок у трансформації, який значно змінить базовий дизайн, дозволяючи кожному акаунту мати власну "кодову" логіку ), що є метою EIP-7702 (.

Воно також може похідно генерувати інші функції, наприклад:

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

2. Має антиквантові характеристики, оскільки код може бути оновлений.

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

4. Підвищення користувацького простору акаунта, сумісність з соціальним відновленням, підтримка SBT, відновлення ключів тощо.

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

Пізніше була низка EIP, що намагалися вдосконалити цю логіку:

EIP-859: абстракція акаунта основного ланцюга )2018-01-30(

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

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

EIP-7702: налаштування коду EOA акаунту )2024-05-07(

Це ядро механізму, що обговорюється в цій статті, EIP. Віталік опублікував EIP-7702 як альтернативу EIP-3074. Таким чином, EIP-3074 був відкинутий, EIP-7702 буде включено в майбутній ETH Prague/Electra)Pectra( хардфорк, про що ми детальніше розповімо пізніше.

) 3.2 Другий маршрут: нехай адреса EOA керує адресою CA

EIP-3074:додати операційні коди AUTH та AUTHCALL###2020-10-15(

У EVM додано два нові OpCode AUTH та AUTHCALL, що дозволяє EOA через ці два opcode уповноважувати контракти замість ідентичності EOA викликати інші контракти.

У загальному підсумку, EOA може надіслати підписане повідомлення ) трансакцію ( до свого надійного контракту ), який називається Invoker (. Цей контракт Invoker може використовувати коди операцій AUTH та AUTHCALL замість цього EOA для здійснення трансакцій.

EIP-4337: реалізація абстракції акаунтів за допомогою мемпулу транзакцій)2021-09-29(

Вона була спроектована під впливом MEV, її основна цінність полягає в можливості повністю уникнути змін у протоколі рівня консенсусу.

EIP4337 пропонує новий об'єкт транзакцій UserOperation, який користувачі надсилають до мемпулу, звідки бандлери з точки зору майнерів пакетно упаковують і постачають для виконання контрактних транзакцій. По суті, це зводить базові транзакції та операції акаунтів на рівень виконання контрактів.

EIP-5189:Операції з абстрактними акаунтами через ендорсер )2022-06-29(

Це можна вважати оптимізацією логіки EIP4337, яка передбачає механізм запобігання атакам DoS шляхом створення фінансових штрафів для зловмисних Bundler через підтримку ендорсерів.

) 3.3 Інші пропозиції для підтримки AA

EIP-2718:упаковка нового типу транзакцій ###2020-06-13(

Це фінальна пропозиція, яка визначає новий тип交易, як конверт для майбутніх нових типів交易.

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

EIP-3607: зробити акаунт адреси EOA недоступним для розгортання контрактів )2021-06-10(

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

) 3.4 Як зрозуміти розвиток абстракції акаунтів?

Спочатку потрібно зрозуміти цінність, що переходить у CA.

В основному це фактичний ефект EIP-4337, який може реалізувати:

• Підтримка різних алгоритмів підпису
• Підтримка соціального відновлення
• Підтримка токенів з можливістю налаштування плати за Gas
• Підтримка пакетних угод
• Підтримка управління акаунтом
• Підтримка газових витрат третьої сторони

Але основним недоліком EIP-4337 є порушення принципу людських мотивів.

Воно виглядає краще, але потрапило у мертве коло розвитку ринку. Багато Dapp ще не сумісні, користувачі не хочуть використовувати адресу CA, а навіть використання CA має вищі торгові витрати ### у звичайних сценаріях переказу, комісія за транзакцію подвоюється (, також надто залежить від сумісності самого Dapp.

Тому на основній мережі Ethereum досі не отримав поширення.

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

Але щоб справді знизити GAS, необхідно, щоб сам Ethereum здійснив м'який форк-апгрейд, змінивши обчислення GAS або змінивши модулі споживання GAS для операційних кодів. Проте, якщо вже йдеться про м'який форк, чому б не розглянути EIP-7702?

![Глибоке пояснення минулого та майбутнього абстракції акаунтів Ethereum])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp(

4. Повний аналіз EIP-7702

) 4.1 Що таке EIP-7702

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

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

) 4.2 структура даних

Він визначає новий тип транзакції 0x04, який є результатом RLP кодування наступного вмісту TransactionPayload:

rlp###[ chain_id, nonce max_priority_fee_per_gas, max_fee_per_gas, gas_limit, призначення, значення, дані, access_list, authorization_list, signature_y_parity, signature_r, signature_s ](

Важливо, що був доданий об'єкт authorization_list, який зберігає код, який підписувач хоче виконати у своєму EOA. Користувач підписує транзакцію одночасно з підписанням коду контракту, який існує у вигляді двовимірного списку, що вказує на можливість зберігати кілька операційних відомостей для виконання пакетних операцій.

authorization_list = [[chain_id, адреса, ні, y_parity, р, с], ...]

)