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

Публікація: imToken

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

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

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

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

1. EIP-8141 взагалі має вирішити що?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VERIFY (кадр верифікації): відповідає за перевірку того, чи транзакція є коректною. Він запускає кастомну логіку верифікації акаунта. Якщо проходить, тоді викликається нововведений op-code APPROVE, який авторизує виконання та задає ліміт Gas.

SENDER (кадр відправника): виконує реальні дії, наприклад переказ, виклик контракту тощо. Адреса відправника — це сам відправник транзакції.

DEFAULT (кадр входу): як викликача використовується системна адреса входу, для сценаріїв на кшталт розгортання контрактів, верифікації Paymaster і подібних.

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

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

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

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

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

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

Оплата Gas абстрагується: якщо у гаманці є стабільні монети, це більше не означає, що вам додатково потрібен ще трохи ETH, щоб щось зробити. У майбутньому Gas можуть оплачувати DApp, Paymaster чи інший спонсор — це стане більш нативним;

Багатокрокові операції об’єднуються: такі процеси, як «авторизація + Swap» або «авторизація + стейкінг», які зараз часто вимагають кількох підписів, мають шанс бути упакованими в одну більш завершену операцію;

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

Схеми підпису більше не обов’язково «замкнені» на одному лише шляху ECDSA: це дає акаунту в майбутньому вперше протокольну можливість міграції в інші парольні системи, включно зі схемами підпису після квантових атак;

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

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

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

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

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

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

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

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

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

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

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

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

Чи вдасться EIP-8141 зрештою наздогнати Hegotá — невідомо. Але сама ця дискусія принаймні вже показала одну річ:

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