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

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

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

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

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

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

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

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

Більше ніж через рік після запуску EIP4337, користувачі загалом визнають його, але він не отримав широкого використання. Це суперечливе ринкове середовище прискорило процес EIP-7702, яка вже підтверджена для об'єднання в наступному оновленні.

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

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

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

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

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

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

У архітектурі EVM є два типи облікових записів: зовнішній обліковий запис ( EOA ) та обліковий запис контракту ( CA ). Власність та право підпису EOA фактично належать одній і тій же особі. Той, хто має приватний ключ, не лише має "власність облікового запису", але й може "підписати передачу всіх активів".

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

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

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

1. Важко захистити приватний ключ: втрата приватного ключа означає втрату всіх активів
2. Єдина алгоритм підпису: рідний протокол може використовувати лише алгоритм ECDSA
3. Підписні права занадто високі: немає рідного мультипідпису, однопідпису достатньо для виконання будь-якої операції
4. Комісія за транзакцію може бути сплачена лише ETH, не підтримується пакетна торгівля
5. Приватність交易 легко може бути розкрита: одноосібні交易 легко аналізувати інформацію про акаунт

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

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

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

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

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

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

3.1 Перший маршрут: перетворити EOA адресу в CA адресу

15 листопада 2015 року Віталік у EIP-101 запропонував нову структуру акаунтів з використанням контрактів. Зміна адреси на таку, що містить тільки код та простір для зберігання, зміна способу оплати комісій, перетворення рідного токена на клас ERC20 для зберігання балансу через попередньо скомпільовані контракти, спростити поля транзакцій.

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

Похідні функції включають:

1. Використання більше криптоалгоритмів для торгівлі
2. Має характеристики опору квантовим атакам
3. Етер має такі ж функціональні характеристики, як і ERC20.
4. Підвищення персоналізації акаунту

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

Далі є ряд EIP, які намагаються вдосконалити цю логіку:

EIP-859(2018-01-30): абстракція акаунтів основної мережі Вирішити проблему розгортання коду, запропонувати новий опкод PAYGAS.

EIP-7702(2024-05-07): налаштування коду акаунта EOA Як альтернативу EIP-3074 буде включено в майбутній ETH Prague/Electra хардфорк.

3.2 Другий варіант маршруту: дати можливість EOA адресі керувати CA адресою

EIP-3074(2020-10-15):додати операційні коди AUTH та AUTHCALL Додати два нові опкод, щоб EOA міг уповноважити контракт замість його особи викликати інші контракти.

EIP-4337(2021-09-29): Використання мемпулу транзакцій для реалізації абстракції акаунта Задля натхнення MEV, розроблено так, щоб повністю уникнути змін у протоколі рівня консенсусу. Запропоновано новий об'єкт UserOperation, який пакується в партії та доставляється бандлерами для виконання контрактних транзакцій.

EIP-5189(2022-06-29): через операції з абстрактними акаунтами Оптимізація логіки EIP4337, запобігання DoS-атакам через механізм фінансових штрафів.

3.3 Інші пропозиції, що підтримують AA

EIP-2718(2020-06-13):упаковка нового типу транзакцій Визначення нового типу транзакції, як конверт для майбутніх нових типів транзакцій.

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

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

По-перше, потрібно зрозуміти вартість після перетворення в CA, основний ефект якого - це фактичний результат EIP-4337.

Але основний недолік EIP-4337 полягає в тому, що він суперечить принципу людських мотивацій. Хоча він виглядає краще, він потрапляє в мертве коло розвитку ринку. Недостатня сумісність Dapp, користувачі не хочуть використовувати адреси CA, вартість використання CA вища, надмірна залежність від сумісності Dapp.

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

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

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

4.1 Огляд EIP-7702

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

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

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

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

[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, 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:

1. Відновлення адреси підписувача з підпису
2. Перевірка ID ланцюга
3. Перевірте, чи є код підписанта порожнім або делегованим.
4. Перевірка nonce підписувача
5. Налаштування коду підписувача
6. Збільшити nonce підписувача
7. Додати акаунт підписувача до списку відвіданих адрес

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

Нова версія змінила поведінку розгортання коду. Код завантажується за адресою, вказаною в полі address списку authorization_list, і виконується в контексті акаунта підписувача.

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

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

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

Розірвати кілька існуючих стереотипів:

1. Баланс акаунту може зменшитися через транзакції, які не походять з цього акаунту.
2. Після початку виконання транзакції nonce EOA може збільшитися на декілька.
3. Логіка захисту порівняння tx.origin та msg.sender не працює
4. EOA може генерувати події
5. EOA може не вдатися отримати активи ERC20/721/1155

4.5 Порівняння EIP-7702 та EIP-4337

1. Переваги EIP-7702:

• газ нижчий, не потрібно проходити через модуль entrypoint
• Витрати на міграцію користувачів нижчі, не потрібно заздалегідь розгортати смарт-контракти на блокчейні
• Також підтримує виконання кодових доручень: повне доручення та захищене доручення

2. Недоліки EIP-7702:

• Належить до м'якого хардфорку, потребує консенсусу для просування, зміни величезні
• Висока свобода, важко аудитувати, користувачам потрібен надійний захист гаманця
• Зміни в оригінальній архітектурі великі, багато інфраструктури важко безпосередньо адаптувати.
• EOA отримує можливість контракту, але простір для зберігання не може бути збережений
• Вартість окремої угоди трохи вища, збільшує частину Calldata
• Підписання отримувачем коду без функції отримання може призвести до DoS
• Логіка поповнення та зняття на блокчейні може бути непослідовною
• Події, що виходять з EOA, можуть викликати проблеми

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

5. Підсумок

Акаунт абстракції наразі може бути реалізований лише в останньому етапі модуля "Виправити все". Прискорення прогресу EIP7702 в основному несе виклики для безпеки системи. Хоча зміни величезні, завдяки зниженню витрат користувачів, це варто досліджувати всім Dapp для адаптації. Користувачі врешті-решт підтримають EIP7702.