EIP-8141: Чому нативна абстракція акаунтів не є головною функцією оновлення Hegota в ethereum

Автор: imToken

На минулому тижні на зустрічі розробників Ethereum було офіційно обговорено включення EIP-8141 до оновлення Hegota. Результат виявився несподіваним: цей пропозиція, яку підтримав сам Vitalik, не була включена до «головних функцій» Hegota, а отримала статус «розглядається до включення» (CFI).

На цьому тижні команда Google Quantum AI опублікувала нову білую книгу, в якій зазначається, що за заданих припущень щодо апаратного забезпечення оцінка кількості фізичних кубітів, необхідних для розшифрування ECDLP-256, знизилася в 20 разів порівняно з попередніми розрахунками. Хоча це не означає, що квантові атаки вже на порозі, це чітко нагадує нам, що якщо система облікових записів у майбутньому не зможе гнучко змінювати логіку перевірки, багато сьогоднішніх обговорень щодо досвіду використання гаманців можуть в кінцевому підсумку перетворитися на проблеми безпеки.

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

Але зараз, на цьому етапі, EIP-8141 здається все більше варто обговорювати та уважно розглядати.

EIP-8141, запропонований Vitalik Buterin та іншими ключовими учасниками, такими як timbeiko, офіційно називається Frame Transactions.

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

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

Якщо дивитися лише на поверхню, EIP-8141 обговорює набір дуже конкретних функцій: оплата Gas стабільною монетою, об’єднання кількох операцій у одну транзакцію, підтримка більш гнучких способів підпису та навіть виділення місця для майбутніх квантово-стійких підписів. Можна сказати, що протягом багатьох років, від ERC-4337 до EIP-7702, багато покращень досвіду гаманця суттєво полягали у тому, щоб рахунок більше не був просто приватним ключем, а став вхідним пунктом із можливістю налаштування правил.

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

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

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

Якщо ви користувалися imToken або іншими Web3 гаманцями, ви, швидше за все, зіткнулися з такими проблемами, як наявність великої кількості USDC у гаманці, але неможливість відправити транзакцію через відсутність ETH (оскільки Gas можна сплатити лише ETH); втрата мнемонічної фрази означає повну втрату коштів і неможливість відновлення; операція «авторизація + обмін» вимагає двох підписів і двох підтверджень тощо.

Ці питання не пов’язані з тим, що гаманець «недостатньо добрий», а є результатом дизайну моделі облікового запису Ethereum.

З цієї точки зору еволюція за останні два роки дуже чітко видна: ERC-4337 без змін у протоколі спочатку запустив абстракцію облікових записів на рівні застосунків; EIP-7702 далі підтвердив, що EOA не є повністю нерозширюваними — вони принаймні можуть тимчасово отримувати частину здатностей, подібних до розумних облікових записів.

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

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

В кінцевому підсумку, EIP-8141 вводить новий тип транзакції — фрейм-транзакцію (Frame Transaction), номер типу транзакції 0x06.

Якщо базова логіка традиційних транзакцій Ethereum полягає в тому, що одна транзакція відповідає одному виклику, то EIP-8141 має на увазі розбити одну транзакцію на набір «кадрів», які можуть виконуватися у визначеному порядку, розділяючи таким чином перевірку, оплату та виконання, які раніше були зв’язані разом.

Кожен «кадр» має три режими виконання:

• VERIFY (перевірка кадру): відповідає за перевірку законності транзакції, виконуючи користувацьку логіку перевірки облікового запису; якщо перевірка пройдена, викликає ново введений оператор APPROVE для авторизації виконання та вказання ліміту газу.
• ВІДПРАВНИК (надсилання фрейму): виконує реальні дії, такі як переказ коштів, виклик контракту тощо. Адреса викликача — це адреса самого відправника транзакції.
• DEFAULT (вхідний кадр): використовується як адреса вхідного виклику для розгортання контрактів, перевірки Paymaster тощо;

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

Раніше перевірка транзакцій, оплата Gas та виконання реальних операцій майже завжди були зв’язані з однією дією облікового запису, але в дизайні EIP-8141 ці дії можна розділити на окремі кадри, які протокол виконує в чіткій послідовності. Саме тому обліковий запис більше не обмежений одним приватним ключем для «підписання цілого», а набуває форми, більш схожої на програмований виконавчий суб’єкт.

Наведемо конкретний приклад: припустимо, ви хочете сплатити газ за допомогою USDC для виконання операції Swap. У рамках EIP-8141 це теоретично може бути організовано як повний процес кадру: спочатку обліковий запис перевіряє підпис і права на виконання, потім платник або Paymaster перевіряє умови, за яких він згоден покрити витрати, далі здійснюється оплата комісії відповідним активом, і нарешті виконується сама операція Swap.

Таким чином, оплата Gas і основна транзакція можуть бути включені в одну атомну процедуру: або всі успішно виконуються, або всі відміняються.

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

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

• Оплата газу абстрагована: наявність стабільної монети в гаманці більше не означає, що вам потрібно мати додаткову кількість ETH для виконання операцій; у майбутньому оплата газу DApp, Paymaster або іншими спонсорами буде більш природною;
• Кілька дій об’єднано: процеси, які раніше вимагали кілька підписів, наприклад «авторизація + Swap» або «авторизація + стейкінг», тепер можуть бути об’єднані в одну більш повну дію;
• Правила безпеки облікового запису увімкнено: мультипідпис, соціальне відновлення, щоденні ліміти, таймлок, зміна ключів — це більше не лише додаткові функції, що надаються окремими гаманцями, а починають ставати частиною більш нативної логіки облікового запису;
• Схема підпису більше не обмежена єдиним шляхом ECDSA: це вперше надає можливість на рівні протоколу майбутнього переходу облікових записів на інші криптографічні системи, включаючи постквантові схеми підпису;

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

Навіть якщо зараз ви використовуєте існуючий Web3-гаманець, наприклад imToken, вам не потрібно переносити кошти, оскільки він сумісний зі старими версіями — ваші існуючі EOA-адреси можна продовжувати використовувати, достатньо лише вибрати «оновлення» логіки перевірки облікового запису у відповідний момент.

Але, з іншого боку, саме через глибокі зміни він не став головною функцією Hegotá у найновішій хвилі обговорень. Проте, згідно з процесом EIP champion 2026 року, CFI (Considered for Inclusion) означає не відмову, а перехід до серйозного розгляду, але ще не до фінального рішення щодо запуску.

Іншими словами, основні розробники не відкидають напрямок EIP-8141, а, визнаючи його цінність, вважають, що він зараз все ще занадто «важкий».

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

Що далі відбудеться? Це можна розглянути як дві лінії:

• EIP-8141, оскільки він перебуває у статусі CFI, означає, що він продовжується оцінюватися; автори пропозиції продовжать додавати ключові деталі щодо безпеки пулу транзакцій, правил перевірки та реалізації клієнтів, а на наступних зустрічах ACD знову розглянуть, чи він готовий до подальшого просування;
• Якщо ці невизначеності зможуть бути постійно зменшені, вони матимуть можливість на наступних оновленнях перейти до більш суттєвого етапу включення; якщо ні — вони можуть бути повністю відкладені на пізніший цикл оновлень;

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

З цієї точки зору справжня цінність EIP-8141 полягає не в тому, чи є вона єдиною правильною відповіддю, а в тому, що вона вперше повністю поставила питання «Яким має бути фінальний вигляд нативного абстрагування облікових записів» на стіл обговорень протоколу Ethereum.

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

Незалежно від того, чи зможе EIP-8141 наздогнати Hegotá, сама ця дискусія хоча б підтверджує один факт:

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