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

Наша класифікація підходів до абстрагування рахунків така:

1. Покращення / програмованість EOA: Це включає зміни на рівні протоколу, які дозволяють EOA (зовнішні власні облікові записи) переозначити частину логіки виконання їх правил валідності. Як відомо в розробницькій спільноті, EOA - це облікові записи, які зазвичай пов'язані з кінцевими користувачами. Таким чином, рішення, які вписуються в цей підхід, нададуть кінцевим користувачам більше контролю над тим, які дії вони можуть схвалити, порівняно з тим, як це можна управляти сьогодні.
2. Конверсія/міграція EOA: Цей підхід включає пропозиції, які ставлять на меті повну конверсію EOA в CA (контрактні рахунки). Інтегральна ідея цього підходу полягає в тому, що контрактні рахунки вже пропонують більшість переваг, які пропонують розумні рахунки, тому немає потреби ускладнювати речі ще більше; всі повинні просто використовувати контрактний рахунок як основний (через гаманці розумного контракту).

Цей підхід має механізми, які дозволяють EOA переходити до CA, не переміщуючи свої активи, такі як EIP 7377 та EIP 5003(при урахуванні разом з EIP 3074).

1. Розумні облікові записи: Ця група пропозицій включає дизайни, які дозволяють як EOA, так і центрам сертифікації поводитися як «розумні облікові записи», дозволяючи їм повністю перевизначати свої правила дійсності.

Раніше було запропоновано різні проекти для створення розумних рахунків та утвердження абстрагування рахунку на рівні протоколу; EIP-86 та EIP-2938Однак, було багато заперечень через сприйняті складності, які вводить такий дизайн, і дещо більшості вважають, що Ethereum не готовий до такої складності.

Після відродження теми Віталіка після Злиття,ERC-4337було запропоновано як версія з можливістю вибору стандарту розумного рахунку, схожа на інфраструктуру PBS (розділення пропонента-будівельника) для MEV (максимально видобувної вартості). Таким чином, користувачі, які прагнуть отримати переваги розумних рахунків, можуть просто використовувати трубопровід ERC-4337 для переозначення логіки свого рахунку та правил валідності транзакцій у структурах, які називаються UserOperation (або UserOps у скороченому вигляді).

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

Щоб вирішити цю складність,RIP 7560було розроблено як утверджена версія інфраструктури ERC 4337 в Ethereum та його L2, щоб вона успадковувала схеми сопротиві деяким мережам замість того, щоб визначати новий набір правил (як це робить ERC 4337 з ERC 7562.

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

Посібник з облікових записів та транзакцій Ethereum

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

Рахунки Ethereum - це сутності з балансом ефіру (ETH) і здатністю надсилати транзакції в блокчейн Ethereum. Вони представлені у вигляді 42-значного шістнадцяткового «адреси», яке служить унікальним вказівником на рахунок та транзакції рахунку.

Адреса діє як ключ до стану триєвого ланцюжка. Листові вузли цього триє є структурами даних рахунків, які можна розкласти на чотири поля:

1. nonce: Лінійний лічильник, який використовується для позначення кількості вихідних транзакцій, ініційованих рахунком. Він також важливий для запобігання повторних атак.
2. баланс: сума ефірів (ETH), виміряна у вей, що належить обліковому запису.
3. codeHash: Хеш EVM-виконуваного коду, що міститься на рахунку. EVM (Ethereum Virtual Machine) - це спеціальне середовище виконання Ethereum, яке відповідає за обробку складних переходів стану, що виходять за межі простих транзакцій «надіслати». Вміст коду рахунку незмінно програмується для здійснення конкретних форм переходу стану на блокчейні Ethereum через EVM.
4. storageHash: Хеш кореня зберігання облікового запису, який використовується для представлення змісту зберігання облікового запису як 256-бітного хешу кореневого вузла дерева Меркла Патріці. Просто кажучи, це хеш даних змінної стану, що стосуються вмісту коду облікового запису.

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

1. Зовнішньо-власні рахунки (EOA) - які ініціалізуються як криптографічна пара ключів:

• Приватний ключ, який є шифрованим і доведено випадковим 64-рядковим символом у шістнадцятковій системі числення, та його комплементарний еквівалент;
• Публічний ключ, який походить від приватного ключа за допомогою ECDSA (еліптичний цифровий алгоритм підпису на основі кривих).

EOA мають порожні поля codeHash та storageHash і можуть бути контрольовані лише тими, хто володіє приватними ключами. Їх адреси можна отримати з відповідного відкритого ключа, дописавши "0x" до останніх двадцяти символів хешу keccak-256 відкритого ключа рахунку.

1. Контрактні рахунки (ЦС) – які можуть бути створені лише за допомогою вже існуючого EOA. Вони ініціалізуються завдяки EOA, який розгортає вміст виконуваного коду на EVM. Цей вміст коду (зберігається як codeHash) закріплений в EVM і відповідає за контроль облікового запису, визначаючи його логіку та взаємодію.

їхні транзакції повністю базуються на витягуванні та підґрунті на логіці їх розгорнутого коду.

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

Адресу CA отримують з адреси його створювача та його nonce до моменту розгортання контракту.

Транзакції

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

Так що це за "транзакції"?

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

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

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

Рахунки та валідність транзакцій

На Ethereum ЕОА оптимізовані для зручності використання, оскільки вони призначені для кінцевих користувачів. Вони можуть надсилати транзакції в певному порядку та працювати автономно. Їх також можна створити локально, найбільш поширений метод - використання постачальників гаманців, таких як MetaMask, Rainbow, Rabby тощо.

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

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

Ці властивості залежать від наступних логічних параметрів, які визначають правила, яким повинні відповідати транзакції рахунку:

1. Логіка аутентифікації - Використовується для визначення того, як рахунок підтверджує свою ідентичність перед мережею під час зміни свого балансу та/або логіки.
2. Логіка авторизації - Використовується для визначення політики доступу до облікового запису, тобто, хто може мати доступ та вносити зміни до балансу та / або логіки облікового запису.
3. Логіка Nonce - яка визначає порядок виконання транзакцій з рахунку.
4. Логіка оплати газу - Використовується для визначення сторони, відповідальної за врегулювання плати за газ у транзакції.
5. Логіка виконання - Використовується для визначення, які форми транзакцій може відправляти рахунок або як виконується транзакція.

Ці параметри призначені для жорсткості для зовнішньо контрольованих облікових записів (EOA):

• Аутентифікація та авторизація здійснюється за допомогою приватного ключа на основі ECDSA, тобто користувач, який бажає відправити транзакцію зі свого EOA, повинен використовувати свій приватний ключ для доступу до рахунку та таким чином довести, що він має право вносити будь-які зміни до його балансу.
• Логіка nonce реалізує послідовну схему лічильника, яка дозволяє виконувати лише одну транзакцію за унікальним nonce послідовно за рахунком.
• Логіка оплати газу передбачає, що плата за газ для транзакцій повинна бути розрахована відправником/початковим рахунком.
• Логіка виконання передбачає, що звичайні зовнішні адреси можуть відправляти лише наступні форми транзакцій:

1. Регулярні перекази між двома EOAs.
2. Розгортання контракту.
3. виклики контрактів, які спрямовані на логіку рахунку розгорнутого контракту.

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

З іншого боку, CAs мають більшу гнучкість у цих параметрах:

• Аутентифікація не є обов'язковою, оскільки їхні транзакції мають наслідковий/тягнучий характер.
• Авторизація для CAs може мати дві форми:

1. Можливість «викликати» код вмісту CAs (або виконати його смарт-контракт), що залежить від логіки смарт-контракту облікового запису та його невід'ємності.
2. Здатність вносити зміни до вмісту коду CA, що в основному залежить від того, чи можна оновити вміст коду.

У більшості практичних випадків логіка, що використовується в цьому випадку, є схемою багато-підписового підпису, яка передбачає, що для того, щоб зміна логіки ЦЗ була дійсною, потрібно M з N дійсних підписів (де M < N) від певних рахунків (зазвичай ЕОА),.

• Їхнє упорядкування транзакцій здійснюється на основі відносного значення nonce. СА сам може надсилати стільки транзакцій до стількох різних викликачів, скільки це можливо, проте кожен викликач обмежений відповідно до власних можливостей.
• Оплата газу зазвичай здійснюється викликачем логіки CA.
• Логіка виконання CAs є більш різноманітною для покращення UX, таких як багатовикликові транзакції та атомні транзакції.

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

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

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

Дилема облікового запису Ethereum

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

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

Деякі з проблем щодо них:

1. Чутливість до квантових атак – Схема підпису ECDSA, що використовується їхнім ключовим парою, не є квантово-стійкою, і з оптимістичним графіком 5-10 років для досягнення промислових квантових систем, це становить значну загрозу для Ethereum та його додатків, які в значній мірі покладаються на схему ECDSA для криптографічних доведень та безпеки.
2. Відсутність виразності – Жорсткий формат правил дійсності EOAs усуває можливість користувачів виразно виражати свої транзакції за допомогою функцій, таких як атомарність транзакцій та пакетна обробка та делегування транзакцій.
3. Самостійність – У кожного були свої чесні долі «я вичерпав пальне» у середині транзакції. Це сталося через вимогу того, що EOAs розраховують газ для своїх транзакцій самостійно, що б не було занадто великою проблемою, якби ефір (ETH) не був єдиною прийнятною валютою для газу. Хоча це загальна проблема машин на основі рахунків (і навіть на основі UTXO), Ethereum завжди мала намір бути іншою.

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

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

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

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

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

Часова шкала абстрагування рахунку

Концепція абстрагування рахунку (принаймні через розумні рахунки) завжди була невід'ємною частиною дорожньої карти Ethereum. Легенда говорить, що складність, пов'язана з її реалізацією, загрожувала подальшому затриманню запуску Ethereum, тому була відкинута на поточний дизайн з різними рахунками, що пропонують різні функціональні можливості. Вона знову затрималася через фокус Ethereum на The Merge, і тепер знову з'являється як головна частина наступного великого оновлення мережі - Pectra. Однак її складність все ще вважається значним недоліком, що заважає її увіковічненню, особливо з урахуванням того факту, що Ethereum переключився на розкрут-центричну дорожню карту.

Вимоги тепер двохкрокові:

1. Стандарти рахунку повинні бути більш виразними, але без втрати автономії. Новий стандарт, який запечатлює розрив між стандартами EOA та CA.
2. Новий стандарт повинен зменшити розрив між EOA та CA, при цьому повністю сумісний з Ethereum та його L2 екосистемою.

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

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

Часто виникає плутанина навколо відмінностей між розумними рахунками та гаманцями для розумних контрактів, тому дозвольте явно описати ці відмінності нижче:

• Розумні рахунки - це рахунки Ethereum, які концептуалізовані для забезпечення рівних частин програмованості та автономності. Ідея полягає в тому, що як EOAs, так і CAs можуть стати розумними рахунками просто використовуючи який-небудь механізм (наприклад, ERC 4337), який дозволяє їм замінити свої мережеві правила валідності на індивідуальні правила валідності, як вони вважають за потрібне.
• Smart contract wallets, з іншого боку, просто постачальники гаманців, які служать інтерфейсами для контрактних рахунків (так, гаманець не є рахунком).

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

Повернемося до розмови; Раніше ми вже розглядали параметри, які використовуються для визначення правил валідності операцій з рахунками:

• Аутентифікація
• Авторизація
• Логіка Nonce
• Логіка оплати газу
• Логіка виконання

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

Останній параметр визначає, як повинен виконуватися транзакція.

У вступі ми надали загальний огляд поточного ландшафту AA у вигляді певного виду класифікації для різних запропонованих рішень. Тепер ми зосередимося на першому класі рішень проблеми рахунку Ethereum - програмованості EOA.

Програмовані зовнішні облікові записи

Найбільша привабливість Ethereum полягає в його молодій, але живій екосистемі DeFi, яка включає в себе різноманітні децентралізовані додатки, які є його основними ліквідними стоками. Більшість цих DApps оптимізовані для обслуговування EOAs, тому їх важко інтегрувати з CAs та, в кінцевому підсумку, зі смарт-рахунками. Хоча смарт-контрактні гаманці справді допомагають CAs у цьому випадку, вони мають свої власні обмеження та зовсім інший UX.

Тимчасове рішення, яке досліджується, поки як DApps, так і постачальники гаманців звикають до розумного стандарту рахунку, полягає в наданні тимчасових покращень до ЗЕР, які дозволяють їм подолати більшість їх накладених обмежень, будь то їх перевірка або логіка виконання.

Нижче ми розглянемо технічні характеристики трьох основних EIP, які надають можливості для програмованості EOA; від менш відомого EIP 5806до амбіційногоEIP 3074а в кінці кінців до переможцяEIP 7702.

Програмованість через EIP-5806

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

Перш ніж ми продовжимо далі, давайте здійснимо поїздку по пам'яті розвитку Ethereum доEIP-7.

EIP-7 запропонував створення опкоду 0xf4/DELEgateCALL, який використовується для відправлення повідомлень у першинний рахунок з логікою вторинного рахунку, зберігаючи значення полів [sender] та [value] першинного рахунку.

Іншими словами, основний рахунок «успадковує» (або позичає, якщо ви бажаєте) логіку вторинного рахунку на певний термін, як вказано в виклику повідомлення, щоб логіка останнього виконувалася в контексті першого.

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

EIP-5806 узагальнено

Добре, тому які делеговані виклики дозволяють залежність СА? Ну, EIP-5806 використовує EIP-7 як натхнення для запропонування розширення функціональності делегованого виклику для ЕОА, тобто дозволяємо також ЕОА бути залежними від СА, тому що ні.

Специфікації

EIP 5806 introduces a new Сумісний з EIP-2718тип транзакції, який упакований наступним чином:

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Ці транзакції розроблені так, щоб поле [to] - яке представляє адресу одержувача - може приймати лише адреси як 20-байтові вхідні дані, що вимикає відправника від використання опкоду CREATE.

Мотивація кожного компонента схеми РЛП полягає в наступному:

• chainID: ідентифікатор поточного ланцюга, сумісний з EIP-115, доповнений до 32 байт. Це значення забезпечує захист від атак повторного відтворення, так що транзакції в оригінальному ланцюжку не відтворюються тривіально на альтернативних ланцюгах EVM з аналогічною історією та меншою економічною безпекою.
• nonce: Унікальний ідентифікатор для кожної транзакції, який також забезпечує захист від повторних атак.
• max_priority_fee_per_gas і max_fee_per_gas: Значення комісії за газ, яку має сплатити транзакція EIP-5806 для замовлення та включення відповідно.
• gas_limit: Максимальна кількість газу, яку може спожити одна транзакція типу 5806.
• призначення: Одержувач транзакції
• дані: Вміст виконуваного коду
• access_list: Агенти, які умовно авторизовані на виконання транзакцій EIP-5806.
• signature_y_parity, signature_r та signature_s: три значення, які разом представляють підпис secp256k1 над повідомленням - keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Хоча упаковка транзакцій EIP-5806 в конверти EIP-2718 дозволяє їм бути дуже зворотно сумісними, зовнішні облікові записи (EOAs) не еквівалентні CA. Тому деякі обмеження повинні бути визначені щодо того, як EOA використовує делеговані виклики, щоб запобігти порушенню незмінності.

Ці обмеження спрямовані на наступні опкоди:

• SSTORE/0x55: Цей код операції дозволяє обліковому запису зберігати значення у сховищі. Він обмежений у транзакціях EIP-5806, щоб заборонити EOA встановлювати/отримувати доступ до сховища за допомогою викликів делегатів, таким чином запобігаючи потенційним проблемам, які можуть виникнути в майбутньому через міграцію облікових записів.
• CREATE/0xF0, CREATE2/0xF5 і SELFDESTRUCT/0xFF: Ці опкоди широко дозволяють викликачу створювати новий рахунок. Доступ до них обмежений, щоб запобігти зміні номеру послідовності EOA в іншому виконавчому каркасі (у цьому випадку створення/знищення контракту), поки він здійснює транзакцію EIP-5806, щоб запобігти недійсності очікування, що транзакції мають послідовні номери.

Потенційна застосовність/випадки використання

Основна застосовність EIP 5806 - це абстрагування виконання для EOAs. Дозволяючи EOAs взаємодіяти надійно з розумними контрактами поза простими викликами до їхньої логіки, це надає їм функції, такі як:

• Умовне виконання транзакцій
• Групування транзакцій
• Мультикол транзакції (наприклад, затвердження та виклик)

Критику

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

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

Друге зауваження (яке є палицею з двома кінцями) – це простота EIP-5806; є певна думка, що винагорода за прийняття EIP-5806 може бути не варта витрат, оскільки це дозволяє лише абстракцію виконання, а не багато іншого. Будь-яке інше обмеження валідності залишається визначеним мережею для EOA, які погоджуються на EIP-5806, на відміну від інших дещо схожих EIP, які ми обговорюємо в наступних підрозділах.

Програмованість через EIP-3074

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

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

Цей EIP пропонує додати до EVM два нових опкоди:

• [AUTH] який встановлює змінну контексту [authorized] рахунку для виконання від імені другого рахунку [authority], на підставі ЕCDSA підпису останнього.
• [AUTHCALL] який надсилає/здійснює виклики для облікового запису [authority] від/як обліковий запис [authorized].

Ці два опкоди дозволяють EOA делегувати контроль за попередньо встановленою CA та виступати як один через неї, не розгортаючи контракт і не несучи пов'язані з цим витрати та зовнішності.

Специфікації

EIP-3074 дозволяє транзакціям використовувати формат підпису [MAGIC], щоб запобігти зіткненню з іншими форматами підпису транзакцій. Активний рахунок, до якого передаються інструкції [AUTHCALL], визначається як поле контекстної змінної з іменем [authorized], яке зберігається лише протягом однієї транзакції і мусить бути визначене заново для кожного нового [AUTHCALL].

Перед тим, як займатися складнощами кожного опкоду, це сутності, що беруть участь у транзакції EIP-3074:

• [authority]: Основний обліковий запис для підпису (EOA), який делегує доступ / контроль до другого облікового запису, який зазвичай є контрактним обліковим записом.
• [authorized]: обліковий запис, до якого потрібно передати інструкції [AUTHCALL] для виконання. Іншими словами, це обліковий запис, в якому логіка [AUTHCALL] виконується від імені [органу], використовуючи обмеження, визначені [викликом].
• [invoker]: Дочірній контракт, призначений для управління взаємодією між [авторизованим] обліковим записом і логікою [AUTHCALL], особливо у випадках, коли основною логікою коду контракту останнього є спонсорство газу.

Контракти Invoker отримують повідомлення [AUTH] зі значенням [COMMIT] від [authority]; це значення визначає обмеження, які обліковий запис бажає накласти на виконання [authorized] інструкцій [AUTHCALL].

Таким чином, інвокери відповідають за забезпечення того, що [contract_code], визначений у [authorized] рахунку, не є шкідливим і має здатність задовольнити невід'ємність, встановлену головним підписаним рахунком в [COMMIT] значенні.

Опкод [AUTH] має три вхідні елементи стеку; або, ще простіше, він визначається трьома входами, які обчислюють один вихід. Ці вхідні дані:

1. авторитет: це адреса EOA, яка генерує підпис
2. зміщення
3. Довжина

Останні два входи використовуються для опису діапазону змінної пам'яті від 0 до 97, де:

1. [пам'ять(зміщення: зміщення+1)] - [yParity]
2. [пам'ять (offset+1 : offset+33] - [r]
3. [пам'ять (зсув+33 : зсув+65)] - [s]
4. [пам'ять (зміщення+65 : зміщення+97)] – [COMMIT]

Змінні [yParity], [r] та [s] інтерпретуються колективно як підпис ECDSA, [magic], на кривій secp256k1 над повідомленням:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

де:

• [MAGIC] — це сигнатура ECDSA, отримана в результаті комбінації змінних:
  • [chainID], який є ідентифікатором, сумісним з EIP 115, поточного ланцюжка, використовується для забезпечення захисту від повторення атак на альтернативних ланцюжках EVM зі схожою історією та меншою економічною безпекою.
  • [nonce], що є поточним номером випускника транзакції адреси підписанта, доповнений зліва до 32 байтів.
  • [invokerAddress], що є адресою контракту, що містить логіку виконання [AUTH].
• [COMMIT] - це 32-байтове значення, яке використовується для вказівки додаткових умов дійсності транзакції в логіці попередньої обробки ініціатора.

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

Вартість газу для цієї опкоди обчислюється як сума:

1. Фіксована плата за [ecrecover] передкомпіляцію та додаткова плата за хеш keccak256 та деяку додаткову логіку, оцінюванням в 3100 одиниць
2. Плата за розширення пам'яті, яка розраховується аналогічно опкоду [RETURN] і застосовується, коли пам'ять розширюється поза визначений діапазон поточного розподілу (97 одиниць)
3. Загальна вартість 100 одиниць, що виникає при гарячому [authority] і 2600 одиниць при холодному з метою запобігання атакам через неправильне визначення ціни на опкоди доступу до стану.

[AUTH] реалізовано так, щоб не змінювати пам'ять, і бере значення [authority] як аргумент, щоб було легко перевірити його значення з наданою підписом.

Операція [AUTHCALL] має сім вхідних елементів стеку, які використовуються для обчислення одного вихідного елемента стеку.

Він має ту саму логіку, що й код операції [CALL], тобто; Він використовується для відправки повідомлень-дзвінків в обліковий запис і запуску певної логіки в його контрактах. Єдине відхилення в їхній логіці полягає в тому, що [AUTHCALL] призначений для встановлення значення [CALLER], перш ніж приступити до виконання.

Отже, [AUTHCALL] використовується [authority], щоб спричинити контекст-залежну поведінку в [authorized] з логічними перевірками, які відбуваються наступним чином:

1. Перевірте значення [authorized]. Якщо воно не встановлено, виконання вважається недійсним, і фрейм негайно закривається. Це допомагає запобігти несправедливим зборам через непередбачені випадки відмови.
2. Перевіряє вартість газу для запланованої поведінки [authorized].
3. Перевіряє значення, яке відповідає вимогам EIP-150, для операнда [gas].
4. Перевіряє доступність загального витрати газу - [value] - на балансі [authority].
5. Виконання відбувається після відрахування [value] з балансу рахунку [authority]. Якщо [value] більше, ніж їхній баланс, виконання анулюється.

Вартість газу для [AUTHCALL] обчислюється як сума:

• Фіксована вартість для виклику [warm_storage_read]
• Вартість розширення пам'яті складає [memory_expansion_fee]; яка розраховується так само, як вартість газу для опкоду [CALL]
• Динамічна вартість [dynamic_gas]
• Вартість виконання підвиклику [subcall_gas]

Доступ до даних, що повертаються з [AUTHCALL], здійснюється через:

• [RETURNDATASIZE] - що поміщає розмір буфера даних повернення в стек виводу
• [RETURNDATACOPY] - яке копіює дані з буфера повернених даних в пам'ять.

Щоб все це зібрати разом з набагато меншою кількістю технічних термінів; транзакції Ethereum зазвичай вказують два значення:

1. tx.origin - який забезпечує авторизацію транзакції.
2. msg.sender - в якому фактично відбувається транзакція.

У ЗРР, як вже зазначалося, авторизація тісно пов'язана з виконанням, тобто (tx.origin == msg.sender). Цей простий незмінний дає поштовх більшості проблем, які ми пояснили в підрозділі «Рахунки та валідність транзакцій» цього звіту.

Повідомлення [AUTH] від [authority] дозволяє змінювати функцію tx.origin на [authorized], залишаючись при цьому msg.sender. Крім того, воно дозволяє встановлювати обмеження цього привілею з використанням значення [COMMIT].

[AUTHCALL] потім дозволяє [authorized] отримати доступ до логіки контракту, використовуючи [invoker] як посередника, щоб забезпечити, що контракт, до якого він хоче отримати доступ, є безпечним. Тобто для кожного [AUTHCALL] [authorized] повинен вказати певний [invoker] для їхнього [COMMIT].

Потенційна застосовність/Варіанти використання

EIP 3074 в основному відповідає за те, що дозволяє ЕОА делегувати свою логіку авторизації іншому рахунку, проте його відкрите виконання дозволяє здійснювати набагато більше в різних контекстах.

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

• Логіка Nonce: EIP-3074 дозволяє залишити Nonce EOAs недоторканим після відправки повідомлення [AUTH], тим часом як його Nonce для кожного [AUTHCALL] залежить від того, з яким викликачем він взаємодіє. Таким чином, він дозволяє паралельне використання Nonce для EOAs, щоб вони могли відправляти багато неперекриваючихся [AUTHCALL], які їм заманеться.
• Логіка оплати газу:Як вказаноу ЕФП, викликачі можуть бути розроблені з можливістю спонсорства газу. Таким чином, комісії за газ для [COMMIT] користувача можуть бути зняті з джерела транзакції або з будь-якого допоміжного рахунку, чи то особистого, чи то сервісного реле (сервіси спонсорства газу).

Крім того, логіка виконання інтуїтивно абстрагована; нарешті, ініціатор (який є CA) тепер відповідає за виконання запитів на транзакції від імені EOA.

Критики

• Централізація викликача

Цитуючиодин з авторів: «Я не очікував би, що гаманці надають функціональність для підписування довільних викликачів ...». Можливо, найбільша проблема, яку ставить ініціатива 3074, полягає в тому, що інновації на його основі дуже легко нахиляться до дозволених та власних потоків угод; так само, як поточні ітерації ринків MEV та PBS Ethereum.

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

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

• Проблеми сумісності у напрямку в майбутньому

EIP-3074 закріплює схему підпису ECDSA, оскільки вона все ще вважається більш дійсною, ніж схема авторизації, введена через invoker. Хоча є аргументи, що квантова стійкість на даний момент не є визначальною проблемою, і що в майбутньому, коли ECDSA може бути скомпрометованим, буде набагато гірше; неофіційною метою Ethereum є завжди бути попереду таких проблем. Ймовірне, що відмова від квантової і цензурної стійкості на користь маргінальних поліпшень UX може не бути найкращим вибором у найближчому майбутньому.

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

Навіть з дорожньою картою нативної абстракції рахунку, опкоди [AUTH] та [AUTHCALL] з часом стануть застарілими в EVM, що призведе до значного технічного боргу Ethereum, аби досягти незначного покращення UX.

• Необоротність схеми ECDSA

Після відправки повідомлення [AUTH] і делегування контролю, очікується, що EOA уникне звичайної схеми авторизації за допомогою закритого ключа, оскільки відправка «звичайної» транзакції призводить до анулювання дозволу, який вона делегувала кожному викликачу.

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

Програмованість через EIP-7702

Ця пропозиція спочатку була висунута як дещо мінімалістична варіація EIP 3074, і буланавіть мали на увазібути оновленням до цього. Він був створений, щоб вирішити якісь неефективності EIP 3074, особливо щодо питань навколо його несумісності з вже процвітаючою екосистемою 4337 та пропозицією про абстрагування рахунку – RIP 7560.

Його підхід полягає в додаванні нового типу транзакції, сумісного з EIP 2718 - [SET_CODE_TX_TYPE] - який дозволяє EOA вести себе як розумний рахунок для визначених транзакцій.

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

Характеристики

EIP-7702 дозволяє ЕОА «імпортувати» вміст коду контракту через транзакцію, сумісну з 2718 [SET_CODE_TX_TYPE] форматом:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

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

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

де кожна кортеж визначає значення [адреси].

Перед продовженням сторони, що беруть участь у SET_CODE_TX_TYPE, є:

• [authority]: яке є EOA/первинним обліковим записом для підпису
• [address]: це адреса облікового запису, що містить делегований код.

Коли [authority] підписує SET_CODE_TX_TYPE, вказуючи [address], створюється делегатний покажчик. Це є «програма-вказівник», яка призводить до того, що всі запити на отримання коду, спричинені діями [authority] у будь-який момент, будуть направлені на спостережний код [address].

Для кожної кортежної [chain_id, address, nonce, y_parity, r, s], логічний потік транзакції типу 7702 виглядає наступним чином:

1. Перевірка підпису [authority] з наданого хешу за допомогою: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Запобігання атакам повтору між ланцюжками та інші вектори атакиперевіркою ідентифікатора ланцюжка.
3. Перевірка, чи в [authority] уже є вміст коду.
4. Перевірка Nonce, щоб забезпечити, що Nonce [authority] дорівнює Nonce, включеному в кортеж.
5. Якщо транзакція є першою транзакцією SET_CODE_TX_TYPE [authority], їй стягується плата PER_EMPTY_ACCOUNT_COST. У разі, якщо його баланс менший за значення цієї плати, операцію відмовляють.
6. Відбувається делегування призначення, при якому код [authority] встановлюється як вказівник [address].
7. Нонс підписувача – [повноваження]– збільшується на одиницю.
8. [authority] додається до адрес зі списком доступу, який (спрощено) є набором адрес, які зроблені таким чином, що повернення області видимості транзакції з них призводить до того, що вони (адреса) повертаються до попереднього стану, до того, як було введено скасовану область видимості. Це визначено в EIP-2929для увімкнення кешування повторно використовуємих значень та запобігання непотрібним платежам.

Фух! Щоб пов'язати все назад; цей EIP дозволяє EOAs надсилати транзакції, які встановлюють вказівник на код контракту, що дозволяє їм реалізувати цю логіку в подальших транзакціях. Таким чином, він строго сильніший, ніж EIP 5806, оскільки дозволяє EOAs фактично мати вміст коду стільки часу, скільки вони хочуть (на відміну від EIP 5806, який просто дозволяє EOAs відсилати делеговані виклики).

Потенційна застосовність/використання

• Абстрагування виконання

Хоча можна стверджувати, що це вже не абстракція, оскільки EOA активно приймає логіку, яку вона бажає виконати, вона все ще не є «первинним власником» цієї логіки. Крім того, вона не містить безпосередньої логіки, вона просто вказує на вказівник до логіки (щоб зменшити обчислювальну складність). Тому ми йдемо з абстракцією виконання!

• Спонсорство газу

Хоча інваріант require(msg.sender == tx.origin) порушений для дозволу самоспонсорства, EIP все ще дозволяє інтеграцію підтримуваних пересилань транзакцій. Однак, застереження полягає в тому, що таким пересилальникам потрібна система, заснована на репутації або стейкі, щоб запобігти атакам на грифінг.

• Умовні політики доступу

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

Це також дозволяє існування підключень, які дозволяють "зниження привілеїв", так що конкретні dAPPs мають доступ лише до балансу рахунку за певних умов. Наприклад, можна уявити дозвіл на витрату токенів ERC-20, але не ETH, або на витрату до 1% від загального балансу на день, або лише на взаємодію з певними додатками.

• Розгортання розумного контракту міжланцюжкового

Через свою невибіркову природу транзакція EIP-7702 може дозволити користувачеві отримати доступ до опкоду CREATE2 та використовувати його для розгортання байткоду на адресу без будь-яких інших обмежувальних параметрів, таких як логіка ринку комісій (наприклад, EIP-1559 та EIP-4844). Це дозволяє відновлювати адресу та використовувати її на різних станових машинах з однаковим байткодом, де її рахунок на кожному ланцюжку відповідає за визначення інших контекстних змінних параметрів.

Критика

• Відсутність зворотної сумісності

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

Деякі з його логіки включають:

1. Зміна номера EOA серед операції: EIP-7702 не обмежує жодної операції для забезпечення послідовності. Це означає, що EOA може використовувати операції, такі як CREATE, CREATE2 і SSTORE при виконанні транзакції EIP-7702, дозволяючи збільшити його номер в іншому контексті.
2. Дозволяючи рахункам з ненульовим значенням codeHash бути ініціаторами транзакцій: EIP-3607 було впроваджено для зменшення можливих наслідків «столкнувшихся адрес» між EOAs та CAs. Столкнення адрес виникає, коли 160-бітне значення адреси EOA повністю еквівалентне адресі CA.

Більшість користувачів не мають розуміння дійсного вмісту рахунку (або навіть різниці між рахунком та адресою!), тому дозволити колізії адрес означає, що EOA може виступати як CA та приваблювати кошти користувачів у довготривалій боротьбі, щоб в кінці кінців вкрасти все. EIP-3607 вирішує це, вимагаючи, щоб рахунки, які містять код, не могли витрачати свій баланс, використовуючи свою власну логіку авторизації. Однак EIP 7702 порушує цей інваріант, щоб дозволити EOAs залишатися автономними навіть після отримання певної рівня програмованості.

• Схожість до EIP-3074

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

Висновок

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

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

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

EIP-7702 наразі є обличчям рекламної кампанії для механізмів, які прагнуть надати можливість програмування EVM для EOAs, оскільки його було визначено як заміну слоту EIP 3074 в оновленні Pectra. Він успадковує відкритий дизайн механізму 3074, значно зменшуючи площу атаки / ризики. Він також дозволяє значно більше, уникнувши обмежень 3074 для певних класів опкодів.

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

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

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

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

Disclaimer：

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