Вбудований обліковий запис та захист від квантових загроз: чому EIP-8141 ще не став головною особливістю Ethereum Hegotá?

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

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

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

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

I. Що саме має вирішити EIP-8141?

EIP-8141 просувають Віталік Бутерін (Vitalik Buterin) і timbeiko та інші ключові учасники; офіційна назва — Frame Transactions (рамкові транзакції).

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

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

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

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

Всім відомо, що в існуючій системі акаунти Ethereum загалом поділяються на два типи. Перший — акаунти зовнішнього власника (Externally Owned Accounts, EOA), тобто ті, до яких усі звикли. Їх контролює приватний ключ: вони можуть ініціювати транзакції, але не мають програмованих можливостей. Другий — акаунти контрактів, тобто самі смарт-контракти: вони можуть виконувати складну логіку, але не здатні самостійно ініціювати транзакції.

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

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

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

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

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

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

II. Як працює EIP-8141?

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

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

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

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

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

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

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

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

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

То що це означає для користувачів гаманців? Виходячи з результату, зміна відчутна щонайменше в чотирьох рівнях:

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

III. Чому це не стало головним хітом Hegotá?

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

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

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

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

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

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

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

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

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

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

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

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