Глибокий аналіз минулого та майбутнього абстрагування рахунку Ethereum
Передмова
Ця стаття поділена на дві основні частини:
Перша частина починається з першої пропозиції AA в 2015 році, систематизуючи основні змістовні пропозиції EIP до сьогодні, досліджуючи розвиток історії пропозицій AA та проводячи комплексну оцінку кожного з варіантів.
Другий розділ зосереджується на порівнянні ринкової реакції після впровадження EIP4337, а також на глибокому аналізі EIP7702, який буде включено в наступне оновлення Ethereum. Ця пропозиція, якщо буде об'єднана, кардинально змінить форму децентралізованих додатків.
EIP-7702 має епохальне значення, давайте разом заглибимося в його суть.
1. Фон абстрагування рахунку
1.1 Значення абстрагування рахунку
Етер засновник Vitalik в кінці 2023 року знову оновив дорожню карту розвитку ETH, але позиціювання абстрагування рахунку не змінилося. Поточна основна модель переходить від EIP-4337 до наступного етапу "добровільного перетворення акаунтів EOA".
1.2 Стан ринку абстрагування рахунку
Після півтора року розвитку, загальна кількість адрес EIP4337 на основних ланцюгах становить лише 12 мільйонів, з яких активних адрес на основній мережі Ethereum лише 6,764, що значно відрізняється від кількості EOA та CA адрес. Кількість незалежних адрес в основній мережі Ethereum досягла 270 мільйонів, можна сказати, що розвиток EIP4337 на основній мережі відбувається повільно.
Проте це не впливає на сутнісну цінність AA. Дизайн EIP4337 приречений на те, що він погано сумісний з попередніми версіями на основній мережі. З розвитком різних L2-ланцюгів, що загалом вбудовують рідне абстрагування рахунку, кількість адрес EIP4337 на L2 зазнала вибухового зростання, наприклад, у ланцюгах Base та Polygon активні користувачі у липні досягли 1 мільйона та 3 мільйонів відповідно, що є непоганим показником.
Отже, дизайн EIP4337 не є помилкою, він має багато переваг. Поточний стан справ є наслідком різниці між основною мережею та L2, які потребують відповідних рішень.
2. Що таке абстрагування рахунку?
абстрагування рахунку по суті є вирішенням проблеми розділення прав власності.
У архітектурі EVM існує два типи рахунків: зовнішній акаунт ( EOA ) та контрактний акаунт ( CA ). У зовнішньому акаунті право власності та право підпису належать одній і тій же сутності. Той, хто має приватний ключ, володіє не лише "правом власності" на акаунт, а й правом "підписувати передачу всіх активів".
Це визначається структурою транзакцій акаунтів Ethereum. З структури транзакцій видно, що стандартна транзакція насправді не має поля From. Під час переказу коштів конкретна адреса витрат визначається за допомогою параметра VRS (, тобто підпису користувача ).
А основний ефект EIP4337 полягає в тому, що у полі транзакції було додано адресу відправника, що дозволяє відокремити приватний ключ від адреси, яка підлягає обробці.
Причина, чому розділення прав власності є таким важливим, полягає в тому, що проєктування зовнішніх акаунтів (EOA) породжує безліч проблем:
Важко захистити приватний ключ: втрата приватного ключа означає втрату всіх активів.
Однотипний алгоритм підпису: оригінальний протокол для перевірки транзакцій може використовувати лише алгоритм ECDSA.
Підписане право надто високе: немає нативної функції мультипідпису, одноосібний підпис може виконувати будь-яку операцію.
Комісії за транзакції можна сплачувати тільки ETH, масові транзакції не підтримуються.
Приватність угод легко порушується: одноосібна угода легко аналізує інформацію про власника акаунта.
Ці обмеження ускладнюють звичайним користувачам використання Ethereum:
По-перше, користувач повинен володіти Етером і брати на себе ризик коливання цін.
По-друге, користувачам потрібно розібратися з складною логікою витрат, такою як ціна газу, ліміт газу, блокування транзакцій та інші поняття.
Нарешті, блокчейн-гаманець або програма намагаються покращити користувацький досвід за рахунок оптимізації продукту, але ефект обмежений.
Тому рішення полягає в реалізації абстрагування рахунку, що дозволяє декомпонувати власність (Owner) та право підпису (Signer), поступово вирішуючи вищезгадані проблеми.
В історії існувало багато варіантів, але врешті-решт все зводиться до двох шляхів.
3. Огляд історії пропозицій щодо абстрагування рахунку
Рішення проблеми, здається, має багато пропозицій EIP, але в кінцевому підсумку це дві основні ідеї. Кожна неприйнята пропозиція EIP, що розглядається, зосереджується на точках прориву існуючого рішення.
3.1 Перший маршрут: перетворення EOA адреси на CA адресу
Ще в листопаді 2015 року Віталік у EIP-101 запропонував нову структуру акаунта, що базується на контрактах. Змінивши адресу на лише код і простір для зберігання, підтримуючи оплату комісії ERC20, через попередньо скомпільовані контракти перетворюючи рідний токен на сховище балансу типу ERC20, спростивши поля транзакцій до to, startgas, data і code.
Ця пропозиція можна вважати великим стрибком у зміні, вона суттєво змінить базовий дизайн, дозволяючи кожній адресі акаунта мати свою власну "кодову" логіку (, що саме і має на меті реалізувати EIP-7702 ).
Вона також може породжувати інші функції, такі як:
Нехай транзакції використовують більше криптографічних алгоритмів, визначених методом підпису та автентифікації коду всередині кожної адреси.
Маючи властивості захисту від квантових атак, оскільки код може бути оновлений.
Зробити Етер, що має функції, аналогічні контракту ERC20, такі як авторизація на утримання.
Підвищення налаштування акаунту, сумісність з соціальним відновленням, підтримка SBT, відновлення ключів тощо.
Причиною, чому не продовжили просування, є те, що кроки були занадто великими, не враховано поточні проблеми з конфліктами хешів транзакцій та загрози безпеці, але кожна ідея переваг стала однією з основних функцій наступних EIP4337 та EIP7702.
Далі буде ряд EIP, які намагатимуться вдосконалити цю логіку:
EIP-859:абстрагування рахунку основної ланцюга(2018-01-30)
Спроба вирішити проблему розгортання коду. Основна функція полягає в тому, що якщо контракт сторони угоди не розгорнутий, то використовується параметр code, що додається до угоди, для виконання розгортання гаманця контракту. Також пропонується новий код операції PAYGAS, який, окрім сплати газу, також слугує роздільником між частиною валідації та частиною виконання в параметрах угоди.
Хоча тоді це не вдалося, але це також стало однією з основних логік EIP7702. Кожна транзакція EIP7702 в поєднанні з особливою структурою транзакції може супроводжуватися певним кодом, що дозволяє акаунту EOA мати можливості контракту в цій транзакції.
Це основний EIP, який обговорюється в цій статті, запропонований Віталіком як альтернатива EIP-3074. EIP-3074 було відхилено, EIP-7702 буде включено в майбутнє жорстке форк ETH Prague/Electra(Pectra).
3.2 Другий маршрут: дозволити EOA-адресі керувати CA-адресою
EIP-3074:додавання AUTH та AUTHCALL операційних кодів (2020-10-15)
В EVM додано два нових OpCode: AUTH та AUTHCALL, що дозволяє EOA через ці два opcode уповноважувати контракти замість ідентифікації EOA викликати інші контракти.
У загальному, EOA може надсилати підписані повідомлення ( транзакції ) до довіреного контракту (, що називається Invoker ). Цей контракт Invoker може використовувати операційні коди AUTH та AUTHCALL для заміни EOA при випуску транзакцій.
EIP-4337: реалізація абстрагування рахунку за допомогою пам'яті транзакцій (2021-09-29)
Узгоджено з MEV, основна цінність полягає в повному уникненні змін у протоколі рівня консенсусу.
EIP4337 пропонує новий об'єкт транзакції UserOperation, який користувач надсилає до пулу пам'яті; бандлери з точки зору майнерів пакетно упакують і доставлять угоду для виконання контракту. По суті, це переносить базові транзакції та операції з акаунтом на рівень виконання контракту.
EIP-5189: через операції бекера абстрагування рахунку (2022-06-29)
Це оптимізація логіки EIP4337, що запобігає DoS-атакам блокувань зловмисних Bundler через створення механізму підтримки штрафів за кошти.
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 тимчасово мати функціональність смарт-контракту в одній транзакції через нові типи транзакцій, підтримує пакетні транзакції, безгазові транзакції та управління користувацькими правами, не вимагаючи введення нового EVM opCode(, що вплине на зворотну сумісність).
Користувачам не потрібно розгортати смарт-контракти, щоб отримати більшість можливостей абстрагування рахунку, навіть можна надати третім особам можливість ініціювати транзакції від імені користувача, при цьому не вимагаючи від користувача надання приватного ключа, лише потрібно підписати інформацію про авторизацію.
4.2 структура даних
Визначення нового типу транзакції 0x04, TransactionPayload є RLP кодуванням наступного вмісту:
Важливо, що додано об'єкт authorization_list, який зберігає код, який підписувачі хочуть виконати у своєму EOA. Користувач підписує угоду одночасно з підписанням коду контракту, який існує у вигляді двохвимірного списку, що дозволяє зберігати кілька операційних даних для виконання пакетних операцій.
Встановіть код підписанта authority на 0xef0100 || address(, щоб обійти стратегію захисту від колізій EIP3607 ).
Збільшити nonce authority підписувачів ( для запобігання повторному підписанню в локальному масштабі ).
Додати акаунт підписувача authority до списку відвіданих адрес ( для гарячої адреси, зменшити витрати на газ для зберігання запитів ).
4.3.2 Етап виконання операцій
"Новий" версія змінює лише поведінку розгортання коду.
Більше не встановлюйте account_code як contract_code, а замість цього отримуйте код, вказаний address з authorization_list та встановлюйте його як account_code.
Під час виконання авторизаційного коду код завантажується з поля address authorization_list, виконується в контексті акаунту підписувача.
Це означає, що код користувацького контракту фактично зберігається за певною адресою в ланцюзі, а не безпосередньо включений у транзакцію.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
7
Поділіться
Прокоментувати
0/400
LiquidationWizard
· 07-25 01:53
Що знову за діла з цими 7702?
Переглянути оригіналвідповісти на0
GasWaster
· 07-24 18:03
о боже, ще один eip... витратив 2eth на невдалі txs минулого року, а тепер мені кажуть це?
Переглянути оригіналвідповісти на0
EntryPositionAnalyst
· 07-24 15:19
AA знову стало популярним через кілька днів.
Переглянути оригіналвідповісти на0
MetaMuskRat
· 07-22 06:03
Знову почали говорити про AA, напевно, це стара пляшка з новим вином у Блокчейні.
EIP-7702 перетворить екосистему Ethereum, абстрагування рахунку вступає в нову еру
Глибокий аналіз минулого та майбутнього абстрагування рахунку Ethereum
Передмова
Ця стаття поділена на дві основні частини:
Перша частина починається з першої пропозиції AA в 2015 році, систематизуючи основні змістовні пропозиції EIP до сьогодні, досліджуючи розвиток історії пропозицій AA та проводячи комплексну оцінку кожного з варіантів.
Другий розділ зосереджується на порівнянні ринкової реакції після впровадження EIP4337, а також на глибокому аналізі EIP7702, який буде включено в наступне оновлення Ethereum. Ця пропозиція, якщо буде об'єднана, кардинально змінить форму децентралізованих додатків.
EIP-7702 має епохальне значення, давайте разом заглибимося в його суть.
1. Фон абстрагування рахунку
1.1 Значення абстрагування рахунку
Етер засновник Vitalik в кінці 2023 року знову оновив дорожню карту розвитку ETH, але позиціювання абстрагування рахунку не змінилося. Поточна основна модель переходить від EIP-4337 до наступного етапу "добровільного перетворення акаунтів EOA".
1.2 Стан ринку абстрагування рахунку
Після півтора року розвитку, загальна кількість адрес EIP4337 на основних ланцюгах становить лише 12 мільйонів, з яких активних адрес на основній мережі Ethereum лише 6,764, що значно відрізняється від кількості EOA та CA адрес. Кількість незалежних адрес в основній мережі Ethereum досягла 270 мільйонів, можна сказати, що розвиток EIP4337 на основній мережі відбувається повільно.
Проте це не впливає на сутнісну цінність AA. Дизайн EIP4337 приречений на те, що він погано сумісний з попередніми версіями на основній мережі. З розвитком різних L2-ланцюгів, що загалом вбудовують рідне абстрагування рахунку, кількість адрес EIP4337 на L2 зазнала вибухового зростання, наприклад, у ланцюгах Base та Polygon активні користувачі у липні досягли 1 мільйона та 3 мільйонів відповідно, що є непоганим показником.
Отже, дизайн EIP4337 не є помилкою, він має багато переваг. Поточний стан справ є наслідком різниці між основною мережею та L2, які потребують відповідних рішень.
2. Що таке абстрагування рахунку?
абстрагування рахунку по суті є вирішенням проблеми розділення прав власності.
У архітектурі EVM існує два типи рахунків: зовнішній акаунт ( EOA ) та контрактний акаунт ( CA ). У зовнішньому акаунті право власності та право підпису належать одній і тій же сутності. Той, хто має приватний ключ, володіє не лише "правом власності" на акаунт, а й правом "підписувати передачу всіх активів".
Це визначається структурою транзакцій акаунтів Ethereum. З структури транзакцій видно, що стандартна транзакція насправді не має поля From. Під час переказу коштів конкретна адреса витрат визначається за допомогою параметра VRS (, тобто підпису користувача ).
А основний ефект EIP4337 полягає в тому, що у полі транзакції було додано адресу відправника, що дозволяє відокремити приватний ключ від адреси, яка підлягає обробці.
Причина, чому розділення прав власності є таким важливим, полягає в тому, що проєктування зовнішніх акаунтів (EOA) породжує безліч проблем:
Важко захистити приватний ключ: втрата приватного ключа означає втрату всіх активів.
Однотипний алгоритм підпису: оригінальний протокол для перевірки транзакцій може використовувати лише алгоритм ECDSA.
Підписане право надто високе: немає нативної функції мультипідпису, одноосібний підпис може виконувати будь-яку операцію.
Комісії за транзакції можна сплачувати тільки ETH, масові транзакції не підтримуються.
Приватність угод легко порушується: одноосібна угода легко аналізує інформацію про власника акаунта.
Ці обмеження ускладнюють звичайним користувачам використання Ethereum:
По-перше, користувач повинен володіти Етером і брати на себе ризик коливання цін.
По-друге, користувачам потрібно розібратися з складною логікою витрат, такою як ціна газу, ліміт газу, блокування транзакцій та інші поняття.
Нарешті, блокчейн-гаманець або програма намагаються покращити користувацький досвід за рахунок оптимізації продукту, але ефект обмежений.
Тому рішення полягає в реалізації абстрагування рахунку, що дозволяє декомпонувати власність (Owner) та право підпису (Signer), поступово вирішуючи вищезгадані проблеми.
В історії існувало багато варіантів, але врешті-решт все зводиться до двох шляхів.
3. Огляд історії пропозицій щодо абстрагування рахунку
Рішення проблеми, здається, має багато пропозицій EIP, але в кінцевому підсумку це дві основні ідеї. Кожна неприйнята пропозиція EIP, що розглядається, зосереджується на точках прориву існуючого рішення.
3.1 Перший маршрут: перетворення EOA адреси на CA адресу
Ще в листопаді 2015 року Віталік у EIP-101 запропонував нову структуру акаунта, що базується на контрактах. Змінивши адресу на лише код і простір для зберігання, підтримуючи оплату комісії ERC20, через попередньо скомпільовані контракти перетворюючи рідний токен на сховище балансу типу ERC20, спростивши поля транзакцій до to, startgas, data і code.
Ця пропозиція можна вважати великим стрибком у зміні, вона суттєво змінить базовий дизайн, дозволяючи кожній адресі акаунта мати свою власну "кодову" логіку (, що саме і має на меті реалізувати EIP-7702 ).
Вона також може породжувати інші функції, такі як:
Нехай транзакції використовують більше криптографічних алгоритмів, визначених методом підпису та автентифікації коду всередині кожної адреси.
Маючи властивості захисту від квантових атак, оскільки код може бути оновлений.
Зробити Етер, що має функції, аналогічні контракту ERC20, такі як авторизація на утримання.
Підвищення налаштування акаунту, сумісність з соціальним відновленням, підтримка 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(Pectra).
3.2 Другий маршрут: дозволити EOA-адресі керувати CA-адресою
EIP-3074:додавання AUTH та AUTHCALL операційних кодів (2020-10-15)
В EVM додано два нових OpCode: AUTH та AUTHCALL, що дозволяє EOA через ці два opcode уповноважувати контракти замість ідентифікації EOA викликати інші контракти.
У загальному, EOA може надсилати підписані повідомлення ( транзакції ) до довіреного контракту (, що називається Invoker ). Цей контракт Invoker може використовувати операційні коди AUTH та AUTHCALL для заміни EOA при випуску транзакцій.
EIP-4337: реалізація абстрагування рахунку за допомогою пам'яті транзакцій (2021-09-29)
Узгоджено з MEV, основна цінність полягає в повному уникненні змін у протоколі рівня консенсусу.
EIP4337 пропонує новий об'єкт транзакції UserOperation, який користувач надсилає до пулу пам'яті; бандлери з точки зору майнерів пакетно упакують і доставлять угоду для виконання контракту. По суті, це переносить базові транзакції та операції з акаунтом на рівень виконання контракту.
EIP-5189: через операції бекера абстрагування рахунку (2022-06-29)
Це оптимізація логіки EIP4337, що запобігає DoS-атакам блокувань зловмисних Bundler через створення механізму підтримки штрафів за кошти.
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 тимчасово мати функціональність смарт-контракту в одній транзакції через нові типи транзакцій, підтримує пакетні транзакції, безгазові транзакції та управління користувацькими правами, не вимагаючи введення нового 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:
4.3.2 Етап виконання операцій
"Новий" версія змінює лише поведінку розгортання коду.
Більше не встановлюйте account_code як contract_code, а замість цього отримуйте код, вказаний address з authorization_list та встановлюйте його як account_code.
Під час виконання авторизаційного коду код завантажується з поля address authorization_list, виконується в контексті акаунту підписувача.
Це означає, що код користувацького контракту фактично зберігається за певною адресою в ланцюзі, а не безпосередньо включений у транзакцію.