Ethereum має два типи облікових записів: Зовнішні облікові записи (EOA) та Контрактні облікові записи (CA). EOA контролюються приватним ключем, тоді як CA контролюються кодом розумного контракту, який міститься в них. EOA завжди були більш привілейовані, ніж CA, оскільки лише EOA можуть розпочати виконання транзакції, оплачуючи газ. Абстракція облікового запису (AA) - це пропозиція, яка дозволяє контракту бути «топ-рівневим» обліковим записом, подібним до EOA, який може оплачувати комісії та розпочинати виконання транзакцій.

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

Додаток Status Messenger пакує приватний месенджер разом з гаманцем Ethereum та браузером Web3 ÐApp, спрямованим на конфіденційність. Гаманець Status на даний момент є гаманцем EOA, що обмежує нас у наданні багатофункціонального UX, яке може запропонувати лише гаманець на розумних контрактах, такий як безпека багатофакторної автентифікації, соціальне відновлення, обмеження швидкості, дозвіл-/відмов-список адрес та безгазові мета-транзакції. Однак UX гаманців на розумних контрактах сьогодні серйозно ускладнений коливанням цін на газ, що не ефективно вирішується сторонніми передавачами. AA має на меті вирішити цю проблему.

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

Історія та мотивація

Абстракція облікового запису була початково запропонована як EIP-86у 2017 році для реалізації «Абстракції походження та підпису транзакції», але коріння мотивуючої ідеї сягає ще глибшепочаток 2016 року, де було запропоновано: «Замість використання механізму у протоколі, де ECDSA та типова схема одноразових чисел є єдиними «стандартними» способами захисту облікового запису, ми робимо перші кроки до моделі, в якій у довгостроковій перспективі всі облікові записи є контрактами, контракти можуть оплачувати газ, а користувачі вільні визначати свою власну модель безпеки.

Початкові пропозиції вважалися складними для впровадження через багато змін протоколу, необхідних і гарантій безпеки, які потрібно було виконати. Нещодавно Віталік та ін. запропонували проект дляEIP-2938який визначає набагато простішу реалізацію, зберігаючи мінімальні зміни в протоколі/консенсусі та забезпечуючи необхідні гарантії безпеки за допомогою правил мемпула вузлів. Віталіка Презентація зустрічі групи інженерів Ethereum та Презентація ETHOnline(разом з супровідними статтями @SamWilsn/ryhxoGp4D">1 & @SamWilsn2) Сем Вільсон та Ансгар Дітріх (двоє з інших авторів EIP) пропонують чудові вступи до теми. Ця стаття підкреслює ключові аспекти з усіх цих джерел.

Мотивація: Мотиваційна обґрунтування за AA дуже проста, але фундаментальна: Ethereum транзакції сьогодні мають програмовані ефекти (досягається за допомогою викликів до розумних контрактів), але вони мають фіксовану валідність в тому сенсі, що транзакції вважаються валідними лише в разі, якщо вони мають валідний підпис ECDSA з валідним nonce та достатнім балансом рахунку. AA покращує транзакції з фіксованою валідністю на програмовану валідність шляхом введення нового типу транзакції AA, який завжди походить з особливої адреси, для якої протокол не потребує підпису, перевірки nonce чи перевірки балансу. Валідність таких транзакцій AA визначається цільовим розумним контрактом, який може застосовувати власні правила валідності після чого він може вирішити сплатити за такі транзакції.

Отже, навіщо це корисно? Давайте візьмемо приклад гаманців Ethereum, щоб підкреслити користь AA.

Гаманці з розумними контрактами: Більшість гаманців Ethereum сьогодні є гаманцями EOA, які захищені приватним ключем, що генерується з фрази-зерна. (A BIP-39сід фраза або мнемонічний код - це впорядкований список з 12-24 слів, які випадковим чином вибираються зі списку з 2048 слів. Це забезпечує ентропію, необхідну для отримання бінарного насіння, яке генерується за допомогою функції PBKDF2. Потім бінарне насіння використовується для генерації асиметричних ключових пар для BIP-32Гаманець.) Користувач повинен записати фразу-сід десь у безпечному місці, оскільки вона може знадобитися пізніше для відновлення ключів у іншому гаманці. Такі гаманці, однак, вразливі до крадіжки особистих ключів або втрати фраз-сід, що призводить до втрати коштів користувача.

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

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

Приклади розумних контрактних гаманців Аржент, Authereum, Елегантний, Дхарма, Gnosis Safe, МонолітіMYKEY. Прийняття таких гаманців, здається, зростає, як це вказано нижче граф.

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

Gnosis Safe - це гаманець з розумним контрактом для багаторівневого управління коштами команди, який вимагає мінімальної кількості (m-of-n) учасників команди для схвалення транзакції перед її виконанням. Він також дозволяє безгазові підписи за допомогою мета-транзакцій.

Всі такі розширені можливості гаманця потребують використання нетривіальних смарт-контрактів. Користувачі гаманця можуть або мати EOA з газом для взаємодії з ними, або залежати від постачальника гаманця, щоб підтримувати мета-транзакції через реле постачальника або реле сторонніх мереж, таких як Газова станція мережі. Перше ґрунтується на ETH, який зазвичай купується на централізованих біржах після KYC, тоді як останнє має на меті зменшити це тертя UX при вході, перекладаючи тягар користувача на релеї за вартістю, яка компенсується постачальником гаманця в ланцюжку та/або користувачем позаланцюжково.

Проте, архітектури на основі релею мають три основні недоліки: (1) їх можуть вважати централізованими посередниками з потенціалом цензурування транзакцій (2) вони технічно / економічно неефективні через додаткову базову газову плату в розмірі 21000, необхідну для транзакції релею та їхню бізнес-потребу в заробітку на додаткових газових внесках (3) використання релею-специфічних протоколів змушує застосунки покладатися на інфраструктуру Ethereum, яка не є базовим шаром, з меншою кількістю користувачів та невизначеними гарантіями доступності.

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

Tornado Cash: Спільний мотивуючий застосунок - це міксер, такий як tornado.cashде@tornadoTornado покращує конфіденційність транзакцій, розриваючи онлайн-зв'язок між адресами за допомогою розумного контракту, який приймає депозити ETH, які пізніше можуть бути виведені іншою адресою. Від користувача очікується надання хешу секрету під час депозиту та пізніше надання доказу zkSnark під час виведення, щоб показати знання секрету, не розголошуючи сам секрет чи раніше здійснений депозит. Це розриває зв'язок виведення від депозиту.

Але є проблема курча-яйце з виведенням. Для виконання транзакції зняття з новоствореного адресу користувачеві потрібно мати деяку ETH, щоб оплатити газ. Джерело цієї ETH (зазвичай обмін) може порушити конфіденційність Tornado. Бажаною альтернативою є знову використання мережі релею, яка має недоліки, вказані раніше.

Абстракція облікового запису вирішить цю проблему, дозволивши контракту Tornado приймати транзакцію AA зняття користувача, перевіряти zkSnark, знімати певну кількість комісій за газ (з ранішньої суми депозиту) і потім переказувати залишок суми депозиту на адресу зняття.

Абстракція облікового запису

Абстракція облікового запису, запропонована в EIP-2938, дозволяє контракту бути обліковим записом верхнього рівня, який сплачує комісію та починає виконання транзакції. Це досягається шляхом введення змін у протокол з новим типом транзакцій AA, який потребує два нових опкоди: NONCE та PAYGAS, змін до правил пулу пам'яті та розширень для підтримки розширених використань. Типи облікових записів продовжують бути двома (EOA та обліковий запис контракту), і всі запропоновані зміни сумісні з поточними транзакціями, смарт-контрактами та протоколом.

Застосування АА розглядаються у двох категоріях: 1) Однокористувацькі застосунки, такі як розумні гаманці для угод, які створюють новий контракт для кожного користувача 2) Багатокористувацькі застосунки, такі як tornado.cash або Uniswap, де кілька користувачів взаємодіють з однаковим набором розумних контрактів.

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

Зміни протоколу

З'явився новий тип транзакції разом з двома допоміжними опкодами NONCE та PAYGAS. Це єдині зміни в протоколі.

Транзакція AA: Введено новий тип транзакції AA AA_TX_TYPE. Її полезне навантаження інтерпретується як RLP([nonce, target, data]) замість існуючого типу транзакції, чия корисна навантаження інтерпретується як RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

Пропущені gas_price та gas_limit в угоді AA вказуються цільовим контрактом AA під час виконання. Пропущений підпис ECDSA v, r, s в угоді AA замінюється контрактно-специфічними перевірками достовірності даних. Адреса to замінюється адресою цільового контракту. Значення відсутнє, оскільки вихідна адреса для всіх угод AA є спеціальною адресою ENTRY_POINT (0xFFFF…FFFF) і не є EOA, яка має пов'язане з нею значення.

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

Базова вартість газу угоди AA пропонується знизити до 15000 замість поточних 21000 (щоб відобразити економію відсутності внутрішнього підпису ECDSA). Крім того, угоди AA не мають внутрішнього обмеження газу. При початку виконання ліміт газу просто встановлюється на залишковий газ у блоку.

оператор NONCE: оператор NONCE (0x48) поміщає nonce викликача, тобто цільового контракту AA, на стек EVM. Таким чином, нонси викриті для EVM, щоб дозволити перевірку підпису над усіма полями транзакції (включаючи nonce) в рамках перевірки в контракті AA.

опкод PAYGAS: опкод PAYGAS (0x49) бере два аргументи зі стеку: (верхній) номер_версії, (другий зверху) початок_пам'яті. Номер_версії дозволяє майбутнім реалізаціям змінювати семантику опкоду. Наразі опкод має таку семантику:

1. Перевірте version_number == 0 (інакше викиньте виняток)
2. Прочитайте gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Прочитайте gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Перевірте contract.balance >= gas_price * gas_limit (інакше викличте виняток)
5. Перевірте globals.transaction_fee_paid == False (інакше викиньте виняток)
6. Перевірте рамку виконання AA == рамка верхнього рівня, тобто, якщо поточне виконання EVM виходить або повертається, виконання EVM всієї транзакції припиняється (інакше видається виняток)
7. Зменшити баланс контракту -= ціна_газу * ліміт_газу
8. Встановіть globals.transaction_fee_paid = True
9. Встановіть globals.gas_price = gas_price і globals.gas_limit = gas_limit
10. Встановіть залишок газу виконавчого контексту поточного виконання = ліміт газу - вже спожитий газ

Після виконання транзакції AA, (globals.gas_limit - remaining_gas) globals.gas_price передається майнеру, а контракт AA повертає залишковий газglobals.gas_price.

PAYGAS виступає як контрольна точка виконання EVM. Будь-які відкликання після цієї точки будуть відкликані лише до цього моменту, після чого контракт не отримує повернення коштів, і globals.gas_limit * globals.gas_price переходить до шахтаря.

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

Правила пам'яті

"The пам'ятьвказує на набір внутрішніх структур даних у вузлі Ethereum, які зберігають кандидатські транзакції перед тим, як вони будуть добуватися. Geth називає це "пулом транзакцій"; Parity називає це "черга транзакцій". Незалежно від назви, це пул транзакцій, що знаходиться в пам'яті і очікує включення в блок. Подумайте про це як про "чергу очікування" для транзакцій, які мають бути прийняті в блок.

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

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

Майнерам та вузлам тому потрібен передбачуваний механізм, щоб уникнути залежності від можливості підтвердження транзакції AA від інших транзакцій, що знаходяться у mempool. Якщо цього не буде, виконання однієї транзакції може анулювати багато/усі транзакції AA у mempool, що призведе до атак типу DoS. Щоб уникнути цього сценарію, існують два запропонованих правила, які мають бути дотримані (майнерами та вузлами, але не в самому протоколі) для транзакцій AA у mempool:

Обмеження опкодів

Щоб уникнути залежності валідності транзакції АА від будь-якого зовнішнього стану, наступні опкоди вважаються недійсними на етапі перевірки (тобто перед PAYGAS): опкоди середовища (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (будь-якого рахунку, включаючи цільовий рахунок), зовнішній виклик/створення чогось, крім цільового об'єкта або попереднього компіляції (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) та зовнішній доступ до стану, який читає код (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL), якщо адреса не є цільовою.

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

Обмеження префіксу байткоду

Якщо не-AA транзакції можуть впливати на стан AA контрактів, це вплине на правильність не-AA транзакцій у мемпулі. Щоб запобігти цьому, необхідно дозволити виконання тільки тих AA транзакцій, які спрямовані на контракти, у яких на початку байткоду є AA_PREFIX, де AA_PREFIX реалізує перевірку, що msg.sender є спеціальною адресою ENTRY_POINT транзакцій AA. Це ефективно запобігає взаємодії не-AA транзакцій з AA контрактами.

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

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

Очікувана транзакція AA до контракту AA може бути скасована лише блоком, що містить іншу транзакцію AA, яка спрямована на той самий контракт AA. Проте, оскільки це не зміни протоколу/консенсусу, майнери вільні включати транзакції в блок, які порушують ці правила.

Розширення

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

1. опкод SET_INDESTRUCTIBLE, який вимикає SELFDESTRUCT та дозволяє контрактам AA безпечно викликати бібліотеки з DELEGATECALL на етапі перевірки.
2. Опкод IS_STATIC, який повертає true, якщо поточний контекст є статичним і дозволяє не-AA викликачам транзакцій перевищувати раніше обмеження префіксу байткоду та безпечно отримувати значення з контрактів AA.
3. Опкод RESERVE_GAS, який встановлює нижню межу газу, споживаного контрактом AA при виклику з поза-транзакції AA, яка намагається записати стан контракту. Це служить для того, щоб змусити зловмисників витрачати мінімальну кількість газу, щоб відсторонити спроби анулювати будь-які транзакції AA в пулі пам'яті.

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

Наступні кроки

EIP-2938 з обліковим узагальненням наразі перебуває в режимі проекту та обговорюється на форумах з дослідження Ethereum. Наступним кроком для EIP є розгляд на включення в один з майбутніх жорстких вилучень. Автори EIP, схоже, мають на меті жорсткий вилучення після Берліна (Берлін приблизно запланований на якийсь час упочаток 2021 року) чий графік наразі не дуже чіткий. Тому цей процес ще досить ранній для EIP-2938.

Крім того, не зовсім зрозуміло, що для включення EIP-2938 в базовий рівень 1 (L1) Ethereum буде необхідно. Одержавши відносну гнучкість рішень на рівні 2 (L2) (як описано в нашомустаття) Рахункова абстракція може бути реалізована на конкретних L2 без потреби в оновленні всього L1. Однак існують переваги рівної підтримки AA на L1, навіть якщо деякі L2 реалізують свої власні версії AA. Тому залишається побачити, де і як буде реалізовано AA.

«Абстракція облікового запису трохи менш важлива, оскільки її можна реалізувати на L2 незалежно від того, підтримує чи ні L1 це». — Віталік про те, що продовжуватиме бути важливим на базовому рівні (у своєму поштана центричній дорозі Ethereum, спрямованій на роллапи).

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

Компанія також оцінює рішення рівня L2 як для підтримки декількох ланцюгів у своєму гаманці, так і для забезпечення необхідного масштабування для різних випадків використання, як описано в наших попередніхстаття. Наприклад, Keycard досліджує мережа платежівчи вимоги до дизайну масштабованості на рівні кредитних карток та майже миттєвої остаточності не виконуються сьогодні мережею Ethereum. Крім того, існує безліч ініціатив, таких якПрограма рефералів, Реакції SNT, Tribute-to-TalkіІмена ENS, всі вони скористаються масштабованістю L2 для можливого впровадження та розумного користувацького досвіду. Якщо життєздатне рішення L2 впроваджує AA, то проекти, які будуються на цьому L2, зможуть скористатися перевагами AA, не покладаючись на L1.

Огляд

Одним із фундаментальних аспектів протоколу Ethereum є те, що тільки Зовнішні Власні Рахунки (EOA) можуть оплачувати комісію за газ та запускати виконання транзакцій. Рахунки Контрактів (CAs) не можуть цього робити. Account Abstraction (AA) - це пропозиція, яка має на меті змінити це розмежування та дозволити спеціально сконструйованим CAs програмно перевіряти дійсність нового типу транзакцій AA, вирішувати оплату комісії за газ від їх імені та тим самим ефективно запускати їх виконання без вимоги до EOA.

AA має наслідки для значного покращення користувацького досвіду в різних сценаріях, таких як гаманці, міксери, ÐApps та DeFi без покладання на централізовані та неефективні архітектури на основі релеїв. Основні сценарії з одним орендарем, такі як гаманці з розумними контрактами, можуть бути безпечно підтримані з використанням AA за умови введення нового типу транзакції, двох нових опкодів та двох правил пулу пам'яті. Розширені додатки з кількома орендарями, такі як Tornado Cash, вимагають розширень цих змін протоколу та правил вузла.

У цій статті ми обґрунтували потребу в АА в контексті гаманців для смарт-контрактів. Ми висвітили ключові аспекти АА, описавши зміни протоколу та вплив на вузли. Ми згадали деякі запропоновані розширення для розширених використань та остаточно підсумували, позиціонуючи АА в контексті поточних дорожніх карт Ethereum та пріоритетів у Status.

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

Disclaimer:

1. Ця стаття перепечатана з [ статус], Переслати оригінальний заголовок «Account Abstraction (EIP-2938): Why & What», Усі авторські права належать оригінальному автору [Раджів Гопалакрішна]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Навчання в Gateкоманда, і вони оперативно з ним впораються.

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

3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.