Розшифровка минулого та майбутнього абстрактного треку рахунку ETH від 4337 до 7702

Вступ

Цей текст складається з двох великих модулів:

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

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

EIP-7702 має революційні зміни, і послухайте, як чотирнадцятий пан розповідає докладно

1. Контекст абстрактного обліку

1.1 Позиціонування абстрактного значення облікового запису

Засновник Ефіріуму Vitalik оновив дорожню карту розвитку ETH в кінці 2023 року, але налаштування, що стосуються абстракції облікового запису, залишилися незмінними. Сучасна основна модель також переходить від EIP-4337 до наступного етапу - добровільної конвертації EOA (акаунта зовнішньої власності)

Протягом понад року з моменту випуску EIP4337 (на WalletCon у Денвері 1 березня 2023 року було оголошено, що основний договір ERC-4337, розроблений ІТН фондом і реалізований розробниками, пройшов аудит OpenZeppelin і вважається історичною Нода).

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

1.2 Абстрактний стан ринку облікового запису

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

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

Можна сказати, що на Основній мережі EIP4337 не має жодного суттєвого розвитку.

（дані діаграми надані з джерела: ）

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

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

2、абстрактний обліковий запис - що це таке?

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

В архітектурі EVM існує два види рахунку (наприклад, ETH Віртуальна машина): зовнішній рахунок (EOA) і контрактний рахунок (Contract Account), а права власності та підписання зовнішнього рахунку фактично належать одному суб’єкту. Особа, яка володіє закритим ключем, не тільки має «право власності» на цей рахунок, а й має право «передати всі активи під підпис».

Це визначається структурою транзакційного рахунку Ethereum

Зі структури наступного малюнка видно, що стандартна транзакція Ethereum не має поля From. Тому, коли я зробив переказ коштів, на що саме були витрачені кошти на Адреса? Фактично, адреса From визначається шляхом розшифрування параметра VRS (тобто підпису користувача).

Тут маємо справу з ECDSA та іншими концепціями несиметричного шифрування, односторонніми функціями порогового значення і так далі. Ми не будемо розгортати всі ці поняття, в загальному, це забезпечується криптографією для забезпечення безпеки, що, звичайно, призводить до складнощів з адресами EOAАдреса, які об’єднують власність.

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

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

Тому що зовнішній рахунок (EOA) є дизайном, який породжує багато проблем:

1. Закритий ключ складно захистити: користувач, який втратив Закритий ключ (втрата, хакерський напад, розкриття шифрування), втрачає всі активи.
2. Алгоритм підпису少：原生протокол在验证交易上只能使用 ECDSA 签名和验签Алгоритм。
3. Високі права на підпис: немає вбудованої багатоадресної підпису (багатоадресний підпис можна реалізувати лише через смарт-контракт для співпраці), одиночний підпис може виконувати будь-яку операцію.
4. Комісія за угоду може бути оплачена лише в ETH і не підтримує пакетні угоди.
5. Розкриття приватності угод: Однозначна угода легко аналізує рахунок ходлера інформацію про приватне життя.

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

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

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

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

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

На самом деле, в истории существует много вариантов, которые в конечном итоге сводятся к двум направлениям

3. Історія пропозицій АА

Здається, є багато пропозицій з розв’язання проблеми 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: абстракція рахунку головного ланцюга - 30 січня 2018 року

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

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

EIP-7702: встановлення коду облікового запису EOA 2024-05-07

Це також основний ЕІР для подальшого обговорення механізму, який був представлений Віталіком як альтернатива ЕІР-3074 (2024-05-07). Тому ЕІР-3074 був відхилений, а ЕІР-7702 був включений у майбутній Хардфорк ETH Prague/Electra (Pectra), деталі будуть розкриті далі.

3.2 Другий варіант - це покернути EOAАдреса, щоб запустити CAАдреса

**EIP-3074: Додавання опкодів AUTH та AUTHCALL --2020-10-15

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

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

EIP-4337: Використання пулу пам’яті транзакцій для реалізації абстракції рахунку–2021-09-29

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

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

EIP-5189: Маніпулювання абстрактним рахунком за допомогою ендорсерів-2022-06-29

Це є оптимізацією логіки EIP4337 та є захистом від зловживання мережею Bundler шляхом встановлення механізму ендорсера з фінансовою штрафною відповідальністю для запобігання атакам Dos-блокування.

3.3 Інші пропозиції для підтримки AA

EIP-2718: Пакетна оболонка для нового типу транзакції - 2020-06-13

Це фактично закінчена пропозиція, яка визначає новий тип операцій як конвертацію для майбутніх операцій.

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

EIP-3607: Дозволяє Адреса EOA не розгортати контракт - 2021-06-10

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

3.4 Як розуміти еволюцію абстрактного розвитку облікового запису?

Спочатку потрібно зрозуміти цінність, яку набуває перетворення в CA.

Фактично, це просто ефект EIP-4337, який може бути реалізований

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

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

Таким чином, на мережі основної мережі ETH до цих пір не вдалося поширитися.

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

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

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

4.1 Що таке EIP-7702

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

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

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

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

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

4.3 Життєвий цикл торгівлі

4.3.1 Верифікаційний етап

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

1. З використанням ecrecover відновити підписувача Адреса з підпису r, s (зверніть увагу, що це механізм самого Ethereum, тому цей EIP не змінює алгоритм підпису). authority = ecrecover (keccak (MAGIC || rlp ([chain_id, address, nonce])), y_parity, r, s] (аналогічно вище знаходженню from Адреса з розшифрування підпису, тут отримується локальна Адреса підпису для цього списку)
2. Перевірка ідентифікатора ланцюжка (захист від повторного відтворення ланцюжка розділення).
3. Перевірте, чи є код підписувача authority порожнім або делегованим (перевірте, чи є транзакція дійсною 7702-транзакцією, і в подальшому вона буде виконуватися за допомогою механізму делегування).
4. Перевірте нонсе уповноваженого, який підписав документ (повтор підпису антиавторитетних осіб).
5. Встановіть код підпису авторитету на 0xef0100 || адресу (для обходу стратегії запобігання зіткнень EIP3607)
6. Збільшення nonce підписника authority (захист від повторного використання локального підпису).
7. Додайте рахунок підписувача authority до списку вже відвіданих Адрес, які було переведено на гарячі Адреси (перевірити Падіння запитування збереження вартості газу)

4.3.2 Виконавчий етап

Де знаходиться код контракту, який потрібно виконати, а також інструкції для дій?

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

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

Таким чином, коли потрібно виконати код авторизації, завантажте код з Адреса, вказаного в полі адреси authorization_list, та виконайте його в контексті рахунку підписника.

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

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

4.4 Яка цінність EIP-7702?

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

Завдяки його появі було розбито багато колишніх упереджень, таких як:

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

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

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

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

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

У порівнянні з EIP4337, існує також два способи делегування виконання коду:

Повне делегування

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

Захищена делегація

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

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

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

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

1. Високий рівень свободи, складно аудитувати, користувачі будуть потребувати надійний Гаманець для забезпечення безпеки захисту.
2. Зміни у вихідній архітектурі занадто великі, хоча вони розділені на різні типи угод, але багато базових угод, особливо незмінні угоди на ланцюжку, не можуть бути безпосередньо адаптовані.
3. Забезпечується здатність до контракту для EOAАдреса, але відповідне простору зберігання не може бути збережено.
4. Вартість окремої угоди трохи збільшується через значне збільшення частини Calldata, приблизно оцінена загальна вартість виклику складатиме 16 (газ) * 15 (байт) = 240 (газ) витрат на Calldata, плюс витрати EIP-3860 2 * 15 = 30, плюс приблизно 150 витрат на час виконання. Отже, навіть якщо ви готуєте рахунок, навіть нічого не роблячи, потрібно додатково витратити 500 газу.
5. «Якщо отримувач підписав код без можливості отримання, відправник може стикнутися з DoS при спробі надіслати активи.» Див. приклад. Фактично проблема полягає в тому, що EOA A підписав те, що він не повинен був підписувати - файл з помилковою реалізацією (без receive()).
6. у блокчейні логіка поповнення та виведення може бути неузгодженою, наприклад, при переказі Токенів ERC-20, якщо отримувачеві рахунку присвоєний код, то контракт Токену викличе onERC20Received отримувачевого рахунку. Якщо onERC20Received повертає або повертає неправильне значення, то передача токенів буде скасована.
7. Крім того, якщо EOA може створювати події, чи можуть виникнути які-небудь проблеми? Деякі інфраструктурні питання можуть вимагати уваги.

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

Дивіться нижче:

5. Загальний висновок

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

На даний момент, абстрагування рахунку дійсно можна розмістити тільки в шостому модулі, тобто відновлення всього, тобто на останньому етапі впровадження. Зараз значно прискорилися темпи реалізації EIP7702, що створює більше викликів для безпеки системи. Можна передбачити, що в кінцевому рахунку він буде реалізований, адже він вже стався злиття ETH, зміна Алгоритму консенсусу та інші такі революційні події. Як тоді можна говорити про звичайні нові типи транзакцій?

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

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

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

Таким чином, хоча він змінився багато, але відносно витрат це вимір вартий уваги для всіх Dapp, оскільки цього разу користувачі обов’язково стоять на боці EIP7702.