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

Вступ

Ця стаття розділена на два великі модулі:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Торгові збори можна сплачувати тільки ETH, масові угоди не підтримуються.

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

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

По-перше, для використання додатків Ethereum необхідно мати ETH і брати на себе ризик коливання цін.

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

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

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

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

3. Огляд історії пропозицій AA

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

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

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

Цей план може похідними декілька функцій:

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-3074. EIP-3074 був відкинутий, EIP-7702 буде включено в найближчий ETH Prague/Electra хард-форк.

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

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

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

EOA може надіслати підписане повідомлення ( транзакцію ) до довіреного контракту (, який називається Invoker ). Цей контракт Invoker може використовувати команди AUTH та AUTHCALL замість 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: обмеження на розгортання контрактів з адрес 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?

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

4.1 Що таке EIP-7702

За допомогою нового типу транзакцій можна відрізняти, дозволяючи EOA тимчасово мати функції смарт-контракту в одній транзакції, підтримуючи пакетні транзакції, транзакції без Gas та управління правами доступу, не вводячи новий 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 Етап верифікації

На початку транзакції для кожного кортежу [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, а отримуйте код з поля address в authorization_list та встановлюйте його як код акаунту.

Виконуючи авторизаційний код, завантажте код з адреси, вказаної в authorization_list, та виконуйте його в контексті акаунту підписувача.

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

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

4.4 Вартість EIP-7702

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

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

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

2. Після початку виконання транзакції EOA nonce може збільшитися кілька разів.

3. Порушення логіки захисту порівняння tx.origin і msg.sender, багато існуючих контрактів мають ризик.

4. EOA може генерувати події, що впливають на деякі ідентифікації подій на ланцюгу.

5. EOA адреса може отримувати активи ERC20, 721, 1155 тощо, але це може не вдаватись ( через механізм зворотного виклику ).

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

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

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

Повна делегація(

• Виконати певну операцію