Гаманець Account Abstraction: посібник для Web3-команд

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

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

Цей посібник призначений для команд, що оцінюють таку зміну. Він охоплює складові ERC-4337, економіку Paymaster, MPC-співпідписання, BroSettlement, BroWallet, AI-агентів, контроль Co-Signer, події WebSocket, звірку журналу, ідемпотентність та API-ключі з обмеженою сферою — усе, що перетворює смартгаманець із функції на підзвітну робочу систему.

Зміст

• Чому розробники обирають гаманці Account Abstraction
  • Операційна проблема більша за онбординг
• Як ERC-4337 насправді переміщує транзакції
  • Перевірка передує виконанню
• Смартгаманці та зовнішні облікові записи
  • Проміжний варіант розширюється
• Paymaster і реальна вартість спонсорування
  • Спонсорування потребує власника бюджету
• Інтеграція AA-гаманців із MPC та операційним журналом
  • Перший рівень — контрольоване підписання
  • Другий рівень — обмежений доступ до API
  • Третій рівень — фінансова істина
  • Четвертий рівень — докази на основі подій
• Безпека, ризик і відповідність у світі AA
  • Контроль має діяти до підписання
  • Вимоги відповідності належать до схеми подій
• Як обрати AA-стек без залежності від постачальника
  • Де доречний гаманець Account Abstraction

Чому розробники обирають гаманці Account Abstraction

Фінтех-команда може витрачати тисячі щомісяця на невдалі транзакції, втрачати 18% активацій на кроці seed-фрази й вважати кожен симптом окремою продуктовою проблемою. Підтримка обробляє повернення gas, інженери досліджують відкочені транзакції, фінансова команда оцінює стимули, а команда з відповідності з'ясовує, хто взагалі авторизував дію. Спільна причина — модель рахунку для технічно підготовленого власника, а не для установи, що обслуговує клієнтів.

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

Важливе запитання не в тому, чи прибере AA-гаманець запит на gas, а чи здатна операційна модель контролювати нові компоненти.

Операційна проблема більша за онбординг

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

ERC-4337 став важливою віхою, коли контракт EntryPoint розгорнули в основній мережі 1 березня 2023 року без зміни базового протоколу Ethereum. За дорожньою картою Ethereum, до вересня 2026 року ERC-4337 забезпечив понад 26 млн смартгаманців і 170 млн UserOperation. Програмовані рахунки перейшли від експерименту до робочого використання трохи більш ніж за три роки.

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

Практичний висновок: розглядайте Account Abstraction як проєкт контролю транзакцій. Кращий онбординг — видимий результат, а не сама архітектура.

Якісне технічне завдання рано відповідає на п'ять запитань:

• Хто авторизує операцію? Окремо визначте користувачів, сервіси, AI-агентів, MPC-підписувачів та аварійних операторів.
• Хто платить за виконання? Моделюйте спонсорування як контрольовані витрати, а не невидиму субсидію.
• Що записує фінансова команда? UserOperation, результат gas, відшкодування, стан рахунку й зобов'язання клієнта в журналі з послідовним додаванням.
• Що перевіряє команда з відповідності? Результати скринінгу, політики, адресу призначення й особу підписувача.
• Що відбувається за розбіжності інфраструктури? Передбачте запізнілі квитанції, дублікати callback, відмови й реорганізації.

Решта архітектури випливає з цих відповідей.

Як ERC-4337 насправді переміщує транзакції

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

Життєвий цикл:

1. Застосунок створює намір. Користувач схвалює переказ USDC або виклик контракту. Гаманець створює UserOperation з відправником, calldata, полями gas, підписом і, за спонсорування, paymasterAndData.
2. Гаманець підписує за логікою рахунку. EOA зазвичай перевіряє ECDSA-підпис однієї адреси. Смартрахунок у validateUserOp може перевірити сесійний ключ, поріг multisig, ліміт витрат, стан відновлення чи іншу політику.
3. Операція потрапляє до альтернативного мемпулу. Бандлери оцінюють UserOperation за дійсністю й прибутковістю та обирають для включення.
4. Бандлер викликає EntryPoint. Він пакує операції в одну блокчейн-транзакцію й викликає handleOps. EntryPoint перевіряє рахунок і Paymaster до виконання, а потім передає calldata смартрахунку.

Перевірка передує виконанню

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

Для спонсорованого переказу USDC із сесійним ключем UserOperation фактично заявляє: «цей ключ може переказати USDC за дозволеною політикою». Смартрахунок перевіряє ключ і межі, Paymaster — право на спонсорування, бандлер подає операцію через EntryPoint. Користувачу не потрібен нативний gas, але бізнес усе одно перевіряє політику до оплати.

Це не усуває ризик повторного відтворення. Авторизацію треба прив'язати до мережі, EntryPoint, nonce, строку й контексту політики. Застосунок зберігає стабільний ID операції до подання, щоб повторна спроба не створила другий переказ.

Детальніше моделі порівняно в матеріалі про смартконтрактні гаманці.

Архітектурна зміна — не просто «транзакції без gas». Авторизація переходить у код рахунку й стає видимою частиною життєвого циклу. Кожна UserOperation є структурованою подією з наміром, перевіркою, виконанням, витратами gas і станом звірки.

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

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

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

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

Проміжний варіант розширюється

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

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

Тип продукту часто визначає вибір:

• Споживчі застосунки й вбудовані гаманці виграють від кращого онбордингу, пакетування та абстракції gas.
• Гаманці AI-агентів — від обмежених сесійних повноважень і лімітів, якщо агент не розширює власні права.
• Біржі й казначейства можуть обрати EOA або MPC-рахунки, де переважають сумісність і зберігання активів.
• Просте голосування DAO або пасивне зберігання може не потребувати AA без вимог до відновлення, делегування чи політик.

Архітектуру зберігання оцінюють разом із моделлю рахунку. Допоможе огляд кастодіальних і некастодіальних гаманців.

Paymaster і реальна вартість спонсорування

Спонсорування gas змінює платника, але не скасовує gas. Paymaster попередньо фінансує EntryPoint і покриває дозволену UserOperation, бандлер подає транзакцію й отримує відшкодування. Користувач бачить простіший процес, а оператор отримує проблему бюджету, зловживань, звірки й відповідності.

Два поширені шаблони:

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

Офчейн-компонент перевіряє право, формує або підписує дані, застосовує ліміти й відхиляє підозрілі запити. Він не замінює ончейн-контроль: дані має перевірити Paymaster, а бізнес — звірити рішення з результатом EntryPoint.

Спонсорування потребує власника бюджету

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

Поширені шляхи зловживань:

• Повторне відтворення: авторизацію повторюють після потрібної операції. Прив'язуйте її до nonce, мережі, рахунку, строку й контексту.
• Ненадійна оцінка gas: надмірні або маніпульовані вимоги. Обмежуйте значення очікуваним профілем продукту.
• Sybil-онбординг: багато рахунків споживають початкову субсидію. За потреби прив'язуйте право до контрольованої ідентичності.
• Відмова Paymaster: політика чи баланс залишає операції в очікуванні або повторах. Явно фіксуйте відмови й вік очікування.
• Витік бюджету між орендарями: один клієнт витрачає бюджет іншого. Відокремлюйте ідентичність спонсорування й облікові виміри від адреси.

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

Політика обмежує витрати:

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

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

Інтеграція AA-гаманців із MPC та операційним журналом

AA-гаманець готовий для установи лише тоді, коли підписання, авторизація, облік і спостережуваність мають спільний ID операції. Чотири рівні відокремлюють криптографічні повноваження від бізнес-політики й фінансової істини.

Перший рівень — контрольоване підписання

Смартрахунок може приймати підпис MPC Co-Signer, якщо модуль перевірки розпізнає авторизацію. BroSettlement надає DKG/MPC 2-з-3, контрольований клієнтом Co-Signer та відправлення в підтримувані мережі. Важливе розділення обов'язків: сервіс застосунку запитує операцію, але не має достатніх повноважень завершити її самостійно.

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

Другий рівень — обмежений доступ до API

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

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

Третій рівень — фінансова істина

Незмінний операційний журнал фіксує бізнес-подію до або разом із відправленням і оновлює її стан. Записи розрізняють активи клієнта, комісії платформи, спонсорований gas, поповнення Paymaster, повернення й невдалі або сторновані дії.

Четвертий рівень — докази на основі подій

Події WebSocket мають надходити в аудит і звірку, а не лише UI. Визначте OperationCreated, OperationMined і AccountChanged, зберігайте сиру подію, нормалізований стан, час джерела й статус обробки.

Квитанції бандлера можуть приходити не по порядку: подія про майнінг — раніше обробки відповіді про подання. Делегування nonce також створює гонки. Використовуйте автомат із монотонними змінами, стійкі блокування або резервування та звірку з даними блокчейну, а не порядок callback.

Для межі зберігання використовуйте MPC-інфраструктуру порогового підписання, залишаючи бізнес-політику й облік у власних системах.

Безпека, ризик і відповідність у світі AA

Account Abstraction не усуває модель загроз, а розподіляє її між кодом рахунку, модулями, підписувачами, Paymaster, бандлерами, відновленням, API та оновленнями. Це може покращити контроль, але створює корельовані збої: помилка компілятора, небезпечний модуль, скомпрометований підписувач або занадто широка політика Paymaster можуть вплинути на багато рахунків.

Розділяйте рішення:

• Авторизація: хто — користувач, сервіс, агент чи оператор — запитав дію?
• Перевірка: чи приймає рахунок підпис і контекст політики?
• Спонсорування: чи покривається gas?
• Виконання: який контракт і метод запустяться?
• Розрахунок: що підтвердив блокчейн?
• Звітність: які докази зберігаються для фінансів, ризику й відповідності?

Контроль має діяти до підписання

Рушій політик має дозволяти лише схвалені контракти, методи, активи й шаблони. RBAC обмежує створення політик, схвалення змін, ротацію підписувачів і відновлення. MPC додає стійкості, але не робить небезпечний запит безпечним. Co-Signer застосовує робочу політику, яку застосунок не обходить.

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

Ончейн-звірка порівнює фактичну зміну стану з внутрішнім журналом. Успішна відповідь API — не розрахунок, а подана операція — не підтверджене виведення. Фінансам потрібна контрольована послідовність: запитано, підписано, відправлено, видобуто, звірено та, за потреби, фіналізовано.

Вимоги відповідності належать до схеми подій

Санкційний скринінг, Travel Rule та звітність MiCA не додають після завершення. Підписана схема подій зберігає контекст ініціатора й бенефіціара, рішення скринінгу, оцінку або посилання, юрисдикційний контроль і версію політики.

Операції за принципами SOC 2 також охоплюють доступ до бандлера й Paymaster, секрети, керування змінами, реагування, моніторинг та строки зберігання доказів. AA-система придатна до аудиту настільки, наскільки придатні її офчейн-сервіси.

Смартрахунок може зробити політику виконуваною. Він не зробить незадокументовану політику захищуваною.

Як обрати AA-стек без залежності від постачальника

Вибір починається з умов виходу, а не скриншотів функцій. Спільні примітиви ERC-4337 не заважають залежності від однієї реалізації рахунку, бандлера, Paymaster, SDK або моделі ключів.

Поставте п'ять запитань:

1. Які версії EntryPoint підтримуються? Підтвердьте сумісність з аудитованим ERC-4337 v0.7 або новішим та процес оновлення.
2. Чи замінюються компоненти незалежно? Бандлер або Paymaster мають змінюватися без переписування створення рахунку, політики, журналу й подій.
3. Чи SDK відкриває адресу та ID операцій? Системам зберігання, індексації, скринінгу й обліку потрібні стабільні ID.
4. Чи можна замінити модулі підписувачів? Перевірте власний HSM, зовнішній MPC-кластер або Co-Signer поруч зі стороннім керуванням ключами.
5. Як працює міграція? Оцініть захист від повтору, зміну реалізації, модулі, безперервність адреси, відновлення й відкат.

Де доречний гаманець Account Abstraction

AA добре підходить споживчим застосункам, вбудованим гаманцям, платежам, іграм, iGaming та AI-агентам, де онбординг, пакетування, сесійні повноваження або спонсорування gas істотно впливають на продукт. Він також корисний для програмованого відновлення чи політики на рівні рахунку.

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

Підсумок контролю ризиків

Зменшуйте повноваження: розділяйте запити застосунку, рішення політики та MPC-підписання.

Робіть стан стійким: пов'язуйте ідемпотентність, хеші UserOperation, журнал і WebSocket.

Зберігайте вибір: інтерфейси рахунку, бандлера, Paymaster, підписувача й звірки мають бути замінними.

BroLabel надає вбудовані MPC-гаманці, створені через API контексти користувачів і агентів, незмінний операційний журнал, відправлення в мережі, події WebSocket у реальному часі, обмежені засоби розробника та контрольований клієнтом Co-Signer. Для команди, що оцінює гаманець Account Abstraction як інституційну інтеграцію, BroLabel є модульним інфраструктурним варіантом поруч із обраними компонентами смартрахунку, бандлера та Paymaster.