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

Передмова

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

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

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

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

1. Фон абстрагування рахунку

1.1 Значення абстрагування рахунку

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

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

) 1.2 стан ринку абстрагування рахунку

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

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

Дизайн EIP4337 не є помилковим, а виникає з різниці між основною мережею та L2, що вимагає відповідних рішень для кожної з них.

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

2. Що таке абстрагування рахунку?

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

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

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

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

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

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

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

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

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

Історичних варіантів було багато, але зрештою все зводиться до двох шляхів.

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

3. Огляд історії пропозицій абстрагування рахунку

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

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

Ще 15 листопада 2015 року Віталік у EIP-101 запропонував нову структуру рахунків, що базується на контрактах. Основні зміни включають:

• Змінити адресу на лише код та сховище
• Зміна підтримки комісії, дозволяє оплату токенами ERC20
• Зміна нативних токенів на сховище балансу типу ERC20 через попередньо скомпільовані контракти
• Спрощення полів транзакцій, залишаючи лише to, startgas, data та code

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

Деривативні функції включають:

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

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

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

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

• Вирішення проблеми розгортання коду: під час відсутності розгорнутого контракту сторони, використовуйте параметр code, що додається до транзакції, для виконання розгортання гаманця контракту
• Запропонувати новий операційний код PAYGAS, як роздільник для частини верифікації та виконання в параметрах транзакції

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

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

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

EIP-3074###2020-10-15(:додавання операційних кодів AUTH та AUTHCALL Додано два нові операційні коди в EVM, які дозволяють EOA авторизувати контракти для виклику інших контрактів від імені EOA.

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

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

) 3.3 Інші пропозиції, що підтримують абстрагування рахунку

EIP-2718###2020-06-13(:упаковка нового типу транзакцій Остаточно затверджена пропозиція визначає новий тип угоди як конверт для майбутніх додаткових типів угод. При введенні нового типу угоди, через специфічне кодування проводиться розмежування, що забезпечує зворотну сумісність без необхідності прямої сумісності. Як EIP1559 розмежовує комісії за угоди, використовуючи код нового типу угоди, що не впливає на первісний legacy тип угоди.

EIP-3607)2021-06-10(: Заборонити розгортання контрактів з адрес EOA Додаткове рішення на шляху AA, щоб запобігти конфлікту між адресою розгортання контракту та адресою EOA. Контроль методу генерації контрактів, забороняючи розгортати код на адресах, які вже є EOA.

) 3.4 Як зрозуміти розвиток абстрагування рахунку?

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

• Підтримка пакетних угод
• Підтримка оплати Gas
• Підтримка відновлення акаунту
• Підтримка мультипідпису
• Підтримка релейних транзакцій
• Підтримка оновлення алгоритму підпису
• Підтримка контрактних гаманців ERC4337
• Підтримка третіх сторін для оплати 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###, що вплине на зворотну сумісність(.

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

) 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 Етап верифікації

Для кортежу [chain_id, address, nonce, y_parity, r, s] кожного authorization_list:

1. Відновити адресу підписанта з підписів r, s за допомогою ecrecover
2. Підтвердьте ID ланцюга ### для запобігання повторному запуску розгалуженого ланцюга (
3. Перевірте, чи код підписувача authority є порожнім або делегованим.
4. Перевірка nonce authority підписувача ) для запобігання повторному підпису authority (
5. Встановіть код підписувача authority на 0xef0100 || адреса
6. Додати nonce authority підписувача ) для запобігання повторенню локального підпису (
7. Додати акаунт підписувача authority до списку відвіданих адрес

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

Нова версія змінює лише поведінку розгортання коду. Тепер код акаунта не встановлюється як contract_code, а отримується з authorization_list і встановлюється як код акаунта за адресою, що вказана.

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

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

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

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

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

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

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

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

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