Передмова

Стаття розділена на дві основні секції:

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

У другій частині буде зосереджено на порівнянні реакції ринку після введення EIP-4337, а потім вдатися до аналізу EIP-7702, який планується включити в наступне оновлення Ethereum. Ця пропозиція, як тільки її об'єднають, очікується, що значно змінить характер on-chain додатків.

EIP-7702 обіцяє революційні зміни, і ми докладно обговоримо це.

1. Фон Абстракції Облікового запису

1.1 Зміст абстрагування облікового запису

В кінці 2023 року засновник Ethereum Віталік Бутерін знову оновив дорожню карту розвитку ETH. Однак положення, пов'язані з Обліком Абстракції, залишилися без змін. Поточна основна модель продовжує еволюцію від EIP-4337 до наступної фази: Добровільне перетворення EOA (самостійне перетворення облікових записів EOA).

https://x.com/VitalikButerin/status/1741190491578810445

З моменту випуску EIP-4337 понад рік тому (1 березня 2023 року на WalletCon у Денвері, розробники Ethereum Foundation оголосили, що основні контракти ERC-4337 успішно пройшли аудит OpenZeppelin, що стало історичним віхолом для його офіційного запуску), він отримав широке визнання користувачів, але не виявив широкого поширення. Ця парадоксальна ринкова ситуація прискорила прогрес EIP-7702, який зараз підтверджено буде включено до наступного оновлення.

1.2 Поточний ринковий стан абстракції рахунку

Без додаткових вагань, давайте подивимося на дані.

Після року й півтора року розробки EIP-4337 набрав лише 12 мільйонів адрес у рахунках основних ланцюгів. Особливо дивно, що на головній мережі Ethereum лише 6 764 активних адреси. Хоча можуть бути проблеми зі статистичними розмірами, ця цифра все ще суттєво відрізняється від кількості адрес EOAs та CAs. Наприклад, кількість унікальних адрес на головній мережі Ethereum досягла 270 мільйонів (джерело: https://etherscan.io/chart/address).

Можна сказати, що EIP-4337 не зробив жодного суттєвого прогресу на mainnet.

(Джерело діаграми: https://dune.com/niftytable/account-abstraction)

Проте це не зменшує внутрішньої цінності Абстракції облікового запису (AA). З самого початку розробка EIP-4337 була призначена для вирішення значних проблем сумісності зі старими версіями на основній мережі. Внаслідок цього, з різними ланцюжками Layer 2, які інтегрують власний AA, EIP-4337 побачив значний зріст адрес на Layer 2. Наприклад, в липні кількість активних користувачів на ланцюгах Base та Polygon становила відповідно 1 мільйон та 3 мільйони, що досить вражаюче.

Отже, не в тому, що дизайн EIP-4337 є дефектним; він має багато переваг, які ми систематично узагальнимо. Поточна ситуація виникає з різниці між мейннетом та Layer 2, кожен з яких потребує індивідуальних рішень.

2. Що таке Облікова абстракція?

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

У архітектурі віртуальної машини Ethereum (EVM) існують два типи рахунків: Рахунки Зовнішнього Власності (EOA) та Контрактні Рахунки. В Рахунках Зовнішнього Власності власність та повноваження підпису належать одній та тій же сутності. Особа з особистим ключем володіє рахунком, а також має право підписувати та передавати всі його активи.

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

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

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

Так чому розділення власності настільки важливе?

Оскільки дизайн Зовнішніх Власницьких Рахунків (EOA) призводить до кількох проблем:

Захист приватного ключа: Втрата приватного ключа (внаслідок втрати, взлому або криптографічного компромісу) означає втрату всіх активів.

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

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

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

Конфіденційність транзакцій: Один до одного транзакції ускладнюють аналіз особистої інформації власника рахунку.

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

Для використання будь-якої програми на Ethereum користувачі повинні утримувати ETH (і несуть ризик коливань ціни ETH).

Користувачам потрібно мати справу з складною логікою комісій, такою як ціна газу, ліміт газу та блокування транзакцій (порядок nonce), що може бути занадто складним.

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

Рішення полягає в реалізації Абстракції облікового запису, яка розриває власність (Власник) та повноваження на підпис (Підписант) для вирішення цих питань. Історично виникло багато рішень, які врешті-решт збіглися в два основних підходи.

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

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

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

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

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

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

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

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

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

Причина відхилення цього пропозиції була проста: кроки були занадто амбіційними. Проблеми, такі як зіткнення хешів транзакцій та питання безпеки, не були повністю вирішені, що призвело до її відкладення. Однак багато з її переваг стали основними функціями в наступних EIP, зокрема EIP-4337 та EIP-7702.

Кілька EIP пізніше намагалися удосконалити цю логіку:

EIP-859: Account Abstraction on Mainnet (January 30, 2018) aimed to address code deployment issues. Its core function was to use the кодпараметр, доданий до транзакцій для розгортання контрактних гаманців, якщо контракт не був розгорнутий. Також було введено новий опкод PAYGAS для розділення частин перевірки та виконання транзакції.

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

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

3.2 Другий підхід полягає в тому, щоб дозволити адресам EOA керувати адресами ЦС.

EIP-3074: Додавання Операторів AUTH та AUTHCALL (15 жовтня 2020)

Цей EIP вводить два нові опкоди, AUTH та AUTHCALL, в EVM, дозволяючи EOAs авторизувати контракти на заміну їх ідентичності та виклик інших контрактів. У сутності, EOA може надіслати підписане повідомлення (транзакцію) довіреному контракту (званому Invoker). Контракт Invoker може використовувати опкоди AUTH та AUTHCALL для відправлення транзакції від імені EOA.

EIP-4337: Реалізація абстракції облікового запису через пули транзакцій (29 вересня 2021 р.)

Інспірований MEV, основна цінність цієї EIP полягає в тому, що вона уникне змін в протоколі шару консенсусу. EIP-4337 вводить новий об'єкт транзакції, UserOperation, який користувачі надсилають у пул оперативної пам'яті. Потім бандлери пакують і передають ці транзакції для виконання угод, ефективно переміщаючи операції з транзакціями та обліковими операціями на нижчому рівні на рівень угод.

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

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

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

EIP-2718: Новий тип операції-конвертації (13 червня 2020)

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

EIP-3607: Заборонити адреси EOA розгортати контракти (10 червня 2021)

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

3.4 Розуміння розвитку абстракції облікового запису

Щоб зрозуміти цінність переходу на адреси ЦС, важливо зрозуміти практичні ефекти EIP-4337, які можуть досягти...

Проте основним недоліком EIP-4337 є порушення принципу людських стимулів. Незважаючи на те, що вона здається пропонувати покращення, вона потрапляє в тупик розвитку ринку. Багато Dapps все ще несумісні з нею, що призводить до небажання користувачів використовувати CA-адреси. Крім того, використання CA може призвести до збільшення витрат на транзакції (наприклад, комісії за транзакції можуть подвоїтися в звичайних сценаріях передачі), що робить його сильно залежним від сумісності Dapps.

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

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, //1559 плата за транзакцію

max_fee_per_gas, //1559 комісія за транзакцію

ліміт_газу,

призначення, //Адреса цільової транзакції

значення,

дані,

access_list, //Список доступу, використовується для оптимізації газу в EIP-2929.

список авторизації,

signature_y_parity, // 3 параметри підпису, використовуються для перевірки підпису транзакції.

signature_r,

підпис_s

])

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

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

4.3 Життєвий цикл транзакції

4.3.1 Фаза верифікації

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

Використовуйте Екрековерфункція для відновлення адреси підписанта з підпису(r, s)Зверніть увагу, що це використовує існуючий механізм Ethereum, тому алгоритм підпису залишається без змін завдяки цьому EIP. Адреса відновлюється за допомогою: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s)Це схоже на те, якзадреса виводяться з підписів, але він застосовується до конкретного списку підпису.

Перевірте ідентифікатор ланцюга, щоб запобігти атакам повторення на різних ланцюгах.

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

Перевіртевладаnonce підписника для запобігання атак повторного відтворення підписів.

Встановитиавторитеткод підписувача до0xef0100 || адреса(для обходу стратегій запобігання зіткненням EIP-3607).

Збільшити владаномер nonce підписувача (щоб запобігти повторному відтворенню локального підпису).

Додайте влададодати обліковий запис підписанта до списку доступу (для переходу до гарячого сховища, зменшуючи витрати на газ для доступу).

4.3.2 Фаза виконання

Де виконуються код контракту та оперативні інструкції?

Нова версія змінює спосіб розгортання коду контракту. Замість прямого встановлення коду облікового запису вона отримує код з список авторизації address і встановлює його як код облікового запису.

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

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

4.4 Яка вартість EIP-7702?

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

EIP-7702 порушує багато довгострокових припущень: воно порушує незмінність того, що баланс рахунку може зменшуватися лише через транзакції, що походять з цього рахунку. Воно порушує незмінність того, що номер EOA збільшується на 1 після початку виконання транзакції (тепер він може збільшуватися одночасно на кілька значень). Воно руйнує захисну логіку, яка ґрунтується на порівнянні tx.originіmsg.sender, що може викликати потенційні ризики для багатьох існуючих контрактів. Це також порушує той факт, що сам EOA не може випускати події, що може вплинути на ідентифікацію та моніторинг певних подій на ланцюжку. Нарешті, це порушує припущення, що адреса EOA завжди успішно отримуватиме ERC20, 721, 1155 та інші активи (оскільки це може бути невдачею через механізм зворотного виклику).

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

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

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

У порівнянні з EIP-4337, EIP-7702 також підтримує делеговане виконання коду і пропонує два типи делегування:

Повна делегація: Це означає делегування повного контролю певної операції на конкретну адресу. Наприклад, користувач може делегувати управління всіма токенами ERC-20 на адресу розумного контракту, що дозволяє контракту виконувати всі пов'язані операції від імені користувача.

Захищена делегація: Це включає додавання обмежень та заходів безпеки під час делегування, щоб забезпечити безпеку та керованість делегованих операцій. Наприклад, користувач може делегувати лише часткові права управління токенами ERC-20 смарт-контракту або встановлювати умови (наприклад, витрачання максимум 1% від загального балансу щодня).

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

Основним недоліком EIP-7702 є те, що він передбачає оновлення м'якого вищого рівня, яке потребує узгодження від спільноти для подальшого просування. Його зміни є суттєвими і можуть мати широкий вплив на онлайн-екосистему. На основі початкової оцінки Шісі Джуном було виявлено кілька викликів, але ці виклики також можуть становити ринкові можливості:

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

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

Хоча EIP-7702 надає можливості контракту для адрес EOA, відповідний простір зберігання не може бути збережений.

Вартість окремих транзакцій трохи вища через значне збільшення розділу Calldata. Приблизна загальна вартість виклику становитиме 16 (газ)15 (байт) = 240 (газу) для витрат на calldata, плюс витрати згідно з EIP-3860 у розмірі 215 = 30, і приблизно 150 на витрати під час роботи. Таким чином, навіть підготовка облікового запису без операцій збільшила б вартість газу приблизно на 500.

« Якщо отримувач підписує код, в якому відсутня функція отримання, відправник може стикнутися з DoS при спробі відправити активи. » Подивіться справу. Це питання виникає, коли EOA A підписує щось, чого не повинно було — файл, який можна відтворити з неправильною реалізацією (якому не вистачаєreceive()).

Логіка консолідації та виведення на ланцюжку може бути неузгодженою. Наприклад, при переказі токенів ERC-20, якщо у рахунку одержувача є код, контракт токенів буде викликатиonERC20Receivedна рахунок отримувача. Якщо onERC20Receivedякщо повертання або повернення неправильного значення, переказ токенів буде скасований.

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

Це лише деякі з недоліків, підсумованих Шісі Джун на основі поточного пропозиції EIP-7702 та обговорень на офіційному форумі. Повний аналіз потребує вивчення завершеного коду реалізації.

5. Огляд

Стаття може здатися обширною, але вона містить лише близько 6 000 слів. Багато посилань на минулі тлумачення EIP вказані в тексті для подальшого дослідження, тому я не буду заглиблюватися в них тут.

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

Однак, на цей раз зміни є досить руйнівними, порушуючи кілька раніше «неможливих» правил on-chain та змінюючи логіку більшості DApps. Тим не менш, EIP-7702 твердо ухоплює найважливіший пункт: він значно знижує витрати користувача. Натомість, EIP-4337 майже подвоює витрати на транзакції.

Користувачі залишаються адресами EOA (Зовнішньо Власними Обліковими записами), але використовують логіку CA (Обліковий запис Контракту) лише при необхідності, що зменшує витрати на утримання. Немає потреби спочатку конвертувати у ланцюговий ідентифікатор CA перед здійсненням дій, що означає, що користувачам не потрібно реєструватися.

Користувачі можуть легко виконувати кілька транзакцій паралельно за допомогою свого ЕОА, таких як поєднання авторизації на списання та виконання списань. Це вбудовано знижує витрати на транзакції для користувачів. Для DApps, особливо проектів, які потребують управління на рівні підприємства на ланцюжку, таких як біржі, ця оптимізація є революційною. Якщо пакетна консолідація реалізована вбудовано, базові операційні витрати для бірж можуть бути зменшені більш як наполовину, в кінцевому підсумку користувачі також будуть отримувати вигоду.

Таким чином, хоча EIP-7702 вносить багато змін, його вплив на вартість сам по собі робить його варто вивчати та адаптувати для всіх DApps. Цього разу користувачі безумовно перебувають на боці EIP-7702.

Відмова від відповідальності:

1. Ця стаття перепечатана з [ PANews]. Усі авторські права належать оригінальному автору [Чотирнадцятий Лорд]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.