Глибоке розуміння минулого та майбутнього абстракції акаунтів Ethereum

Ця стаття поділена на дві великі частини:

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

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

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

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

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

Засновник Ethereum Віталік у кінці 2023 року знову оновив дорожню карту розвитку ETH, але позиція щодо абстракції акаунтів не змінилася. Поточна основна модель переходить від 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( та контракти акаунти)CA(. Власність та права підпису EOA фактично належать одній і тій же особі. Людина, яка володіє приватним ключем, не тільки має "власність акаунта", але й має право "підписувати переведення всіх активів".

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

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

Важливість розподілу прав власності полягає в тому, що:

1. Важко захистити приватний ключ: втрата приватного ключа означає втрату всіх активів.

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

3. Завищені права підпису: без рідного мультипідпису, одноосібний підпис може виконати будь-яку операцію.

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

5. Витік приватності угод: одноосібні угоди легко аналізувати інформацію про власника акаунта.

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

• Використання будь-якого додатку вимагає наявності ETH та ризику коливань ціни.
• Потрібно обробити складну логіку зборів, концепції Gas price, Gas limit, Nonce тощо занадто складні.
• Хоча додатки для гаманців намагаються оптимізувати користувацький досвід, але ефект обмежений.

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

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

![Глибоке занурення в минуле та майбутнє абстракції акаунтів Етер])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(

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

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

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

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

) 3.2 Другий шлях: дати змогу адресі EOA керувати адресою CA

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

Додано два нових OpCode в EVM: AUTH та AUTHCALL, щоб EOA могла авторизувати контракти для виклику інших контрактів замість ідентичності EOA через ці два OpCode.

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

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

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

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

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

Оптимізовано логіку EIP4337, шляхом створення механізму фінансових штрафів для )endorser(, щоб запобігти 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, який можна реалізувати:

• Соціальне відновлення
• безгазова транзакція
• Пакетна торгівля
• Оплата газу
• акаунт заблоковано
• Налаштована підпис

Але основний недолік 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, TransactionPayload є результатом RLP-кодування наступного вмісту:

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, р, с], ...]

) 4.3 Життєвий цикл угоди

4.3.1 Етап верифікації

Виконання етапу початку транзакції, для кожного кортежу authorization_list [chain_id, address, nonce, y_parity, r, s]:

1. Відновити адресу підписанта з підписів r, s за допомогою ecrecover.

2. Підтвердження Chain ID ### для захисту від повторних атак на розгалуження (.

3. Перевірте, чи код підписувача authority є пустим або делегованим ) для перевірки, чи є транзакція дійсною 7702 транзакцією (.

4. Підтвердження nonce authority підписувача ) для запобігання повторному підпису authority (.

5. Налаштуйте код підписувача authority на 0xef0100 || address), щоб обійти стратегію запобігання колізіям EIP3607 (.

6. Додати nonce authority підписувача ) для запобігання повторному підпису локальною підписом (.

7. Додати акаунт підписувача authority до списку відвіданих адрес ), знизити газові витрати на запити зберігання (.

)# 4.3.2 Етап виконання операцій

"Нов" версія змінює лише поведінку розгортання коду.

Не встановлюйте код акаунту як contract_code, а замість цього отримуйте код address з authorization_list і встановлюйте його як код акаунту.

Під час виконання коду авторизації код завантажується з поля address списку authorization_list, виконується в контексті акаунта підписувача.

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

Операційні команди та відповідні параметри зберігаються у полі data вантажу транзакції.

4.4 Цінність EIP-7702

Змінилася вся ланцюгова лінія Web3 гаманців, покращено користувацький досвід.