Account Abstraction (AA) — подход, при котором логика проверки подписи, учёта nonce, оплаты газа и дополнительных правил безопасности переносится из клиента кошелька в смарт-контракт аккаунта. Это делает кошельки программируемыми: можно внедрять соц. восстановление, мульти-подпись, лимиты расходов, оплату газа стейблкоинами и «однокликовые» сценарии из нескольких вызовов.
Классическая модель в Ethereum делит аккаунты на EOA (Externally Owned Account — управляется приватным ключом) и Contract Account (управляется кодом). Account Abstraction стирает жёсткую грань: сам аккаунт пользователя становится контрактом, а правила проверки и оплаты задаются кодом.
Зачем это нужно пользователю и рынку
- Гибкая аутентификация. Не только одна ECDSA-подпись: мульти-сиг, 2FA, WebAuthn/Passkeys, политики «подтверждение с телефона». См. Мультиподпись (multisig) — кворум ключей и защита средств и 2FA — как защитить аккаунт: TOTP, push или ключи FIDO2 (антифишинг).
- Восстановление доступа. «Социальное» восстановление, хранители, таймлоки — снижают риск потери сид-фразы. См. Некастодиальный кошелёк (non-custodial): ключи у вас — как настроить.
- Оплата газа не только ETH. Через «спонсоров» (paymasters) комиссии могут списываться из стейблкоинов/других токенов либо оплачиваться приложением.
- Автоматизация. Подписки, лимиты, «сессионные ключи» для игр/социальных dApp.
- Институциональные требования. Политики доступа, сегрегация ролей, аудит действий — нужные кирпичики для компаний.
Где AA уже работает: три модели
1) «Надпротокольная» AA в EVM (путь через стандарты). На Ethereum и совместимых сетях широко применяют модель с UserOperation и EntryPoint, где транзакции юзеров собирают bundler-ы, а логику контроля газа/подписи выполняют смарт-контракты аккаунтов и paymaster-ы. Это позволяет внедрять AA без изменения консенсуса сети.
2) Нативная AA на L2/ZK-сетях. Некоторые сети изначально делают все аккаунты смарт-контрактами. Так устроены, например, Starknet и часть zkEVM-сетей (например, zkSync Era). Для разработчика это значит: не надо совмещать EOA+контракт — любой аккаунт уже контракт.
3) AA-подобные модели вне EVM. В NEAR аккаунты изначально «читаемые» (например, alice.near) и имеют access keys с разными правами: можно давать dApp «функциональный ключ» без права перевода средств. Это решает ряд UX-задач AA даже без термина «AA».
Базовые термины AA (простыми словами)
- Smart Account (контракт-аккаунт). Кошелёк-смарт-контракт. Он хранит правила: какие подписи принимать, как считать nonce, откуда брать оплату газа.
- UserOperation (заявка пользователя). «Транзакция-заготовка» с данными о вызовах, подписях и лимитах, которую не гонят в обычный mempool, а отправляют в альтернативный пул для сборки в пакет.
- Bundler (собиратель). Узел, который принимает UserOperation-ы, симулирует их, отбрасывает невалидные и формирует «пакет» исполнения через EntryPoint. См. Bundler (бандлер): узел для обработки UserOperation в ERC-4337.
- EntryPoint (контракт-врата). Единая точка входа, через которую исполняются операции аккаунтов: валидация, списание комиссий, вызовы целей.
- Paymaster (спонсор). Контракт/сервис, который берёт на себя оплату газа (в ETH или за счёт токенов/депозита приложения). См. Paymaster (пеймастер): как спонсируются комиссии в Account Abstraction.
- Aggregator. Компонент, агрегирующий подписи (например, BLS) для экономии газа и скорости.
Эти элементы — «кирпичики» AA. DApp-ам важно уметь распознавать подпись контракта (см. Мультиподпись (multisig) — кворум ключей и защита средств и Приватный ключ: что это такое и как хранить его безопасно) и работать с валидаторами EIP-подписей.
Как проходит выполнение (жизненный цикл)
- Пользователь формирует UserOperation (в кошельке или внутри dApp), где указывает цели вызовов, бюджет газа, источник оплаты (через paymaster) и подпись(и).
- Bundler симулирует операцию: проверяет подписи, лимиты, наличие средств/депозита у paymaster, отсутствие конфликтов nonce.
- Подтверждённые заявки склеиваются в «пакет» и отправляются в EntryPoint для батч-исполнения.
- Комиссии списываются по логике аккаунта/пеймастера, вызываются целевые контракты. В случае ошибки у каждой операции есть отдельная логика возврата.
Пользовательский эффект: меньше «лишних» операций и всплывающих окон, оплата газом в удобной валюте, гибкая безопасность.
Сильные и слабые стороны AA
Плюсы
- «Веб-уровень» UX: батчи, спонсорство газа, passkeys, социальное восстановление.
- Политики безопасности на уровне кода: лимиты, таймлоки, мульти-роль.
- Инклюзия: проще онбординг (кошелёк создаётся по факту первой операции), можно платить газом в стейблкоине, у dApp — меньше барьеров.
Компромиссы
- Сложность стека. Появляются новые роли (bundler, paymaster), которые тоже нужно мониторить и аудировать.
- Критичный контракт EntryPoint: требует аудитов и строгой дисциплины обновлений.
- Совместимость dApp: приложения должны правильно понимать подписи контракт-аккаунтов (EIP-1271 и др.) и особенности AA-мемпула.
Модели и стандарты в EVM-мире
- AA поверх протокола (на смарт-контрактах).
Наиболее распространённая модель: UserOperation → Bundler → EntryPoint → Smart Account → Paymaster. Это даёт программируемые кошельки уже сегодня, без хардфорков базового слоя. Архитектура и мемпул разобраны в технической статье.
- Модульные аккаунты.
Идея «плагинов» и модулей к смарт-аккаунту: добавляете социальное восстановление, лимиты, мультисиг, WebAuthn как модули, а не переписываете кошелёк каждый раз.
- «Умное поведение» для EOA.
На уровне протокола появляется возможность временно заставить обычный EOA вести себя как смарт-аккаунт в пределах одной транзакции. Это снижает барьеры миграции на смарт-кошельки и даёт часть AA-функций существующим пользователям.
Нативная AA: Starknet и zkSync
- Starknet.
В сети все аккаунты — контракты по умолчанию. Проверка подписи/лимитов — в коде аккаунта; «EOA как класса» нет. Это упрощает UX и снимает многие костыли совместимости, но требует от dApp изначальной поддержки такого формата. См. архитектуру Starknet.
- zkSync Era.
L2-сеть с нативной AA: смарт-аккаунты, спонсоры комиссий, настраиваемая проверка подписи, сессионные ключи, мультисиг «из коробки».
- Значение для экосистемы.
Нативная AA показывает «как может быть в идеале»: все — аккаунт-контракты, AA — по умолчанию. Для EVM-мира это вектор развития: либо протокольные улучшения, либо «надпротокольные» стандарты, либо их комбинация.
Вне EVM: зачем часто вспоминают NEAR
В NEAR аккаунты именованные (например, ivan.near) и имеют несколько ключей с разными правами. DApp может получить «функциональный ключ» без права вывода средств, пользователи — безопасную ротацию ключей и мультисиг-паттерны. Формально это не «AA в терминах Ethereum», но решает те же UX-задачи: гибкая аутентификация и управление доступом в кошельке.
Как AA снижает комиссии и «фрикции»
- Батчирование вызовов.
Вместо 3–5 отдельных транзакций — один пакет. Меньше накладных расходов, меньше «человеческих» ошибок.
- Оплата газа токенами.
Пользователь может не держать ETH на каждом L2: комиссии списывает dApp/спонсор или тот же стейблкоин.
- Умные лимиты и «сессии».
Игры/соцсети могут выдавать «сессионные ключи»: не нужно подтверждать каждый клик.
Безопасность: на что обратить внимание
- Аудиты EntryPoint и аккаунтов.
Критическая часть стека; ошибки здесь — системные риски.
- Симуляция и правила мемпула.
Чтобы защититься от «засорения» альтернативного пула, bundler-ы применяют строгие правила валидации и симуляции.
- Paymaster-риски.
Если спонсор газа исчерпал депозит или работает с багами, операции падают. Инфраструктуру спонсоров стоит диверсифицировать.
- Политики кошелька.
Соц. восстановление и делегирование полномочий — мощный инструмент, но нужен продуманный кворум, таймлоки и разделение ролей.
Практика: что даёт AA конечному пользователю
- Покупки и игры.
Оплата NFT или внутриигровой покупки без танцев с одобрениями и переключением сетей; dApp оплатил газ или списал стейблкоин.
- DeFi-операции.
Один клик — несколько шагов: вывод залога, своп, погашение долга, повторный деплой. Под капотом — пакет вызовов с контролем лимитов.
- Подписки и лимиты.
Ежемесячные транши на сервис или «карманные деньги» на детский кошелёк с уведомлениями и дневным лимитом.
- Безопасность ключей.
Восстановление через доверенных лиц/устройства; авторизация по Passkey со вторым фактором; временные права для dApp.
Сравнение моделей (сводка)
| Параметр | ERC-стек поверх протокола | Нативная AA (Starknet, zkSync) | «EOA → умный на один tx» (протокольная) |
|---|---|---|---|
| Тип аккаунтов | EOA + контракт-кошелёк | Все аккаунты — контракты | Обычный EOA временно ведёт себя как смарт-аккаунт |
| Совместимость | Нужна поддержка dApp и AA-мемпула | Свой формат, нужна адаптация EVM-приложений | EOA остаётся базовой сущностью |
| UX | Батчи, спонсорство газа, модули | То же, «нативно» | Ближе к EOA-опыту, но с «умным» поведением в транзакции |
| Риски | Сложный стек, зависимость от EntryPoint | Совместимость с «классическим» EVM-миром | Новые векторы фишинга через делегирование |
| Где применяют | Ethereum, L2 и EVM-сети | Starknet, zkSync Era | В рамках обновлений протокола Ethereum |
Роадмап и эволюция AA
- Стандартизация правил валидации.
Для альтернативного пула операций формулируются правила валидации (защита от DoS, конфликтов операций), чтобы bundler-ы работали предсказуемо и безопасно.
- Модульные аккаунты.
Аккаунт как платформа для плагинов: соц. восстановление, лимиты, WebAuthn, батч-шаблоны — отдельные модули, а не форки кошелька.
- Протокольные улучшения.
В обновлениях Ethereum закрепляется возможность временно наделять EOA «поведением» смарт-аккаунта в рамках транзакции — мост между миллионами старых EOA и новым AA-миром.
Мини-гайд: как выбрать AA-кошелёк
- Совместимость с dApp.
Поддерживаются ли подписи контракт-аккаунтов (EIP-1271 и др.) и режимы sponsored gas?
- Безопасность.
Есть ли аудиты аккаунта и EntryPoint, как устроена политика обновлений и аварийное отключение модулей?
- Модули.
Есть ли социальное восстановление, лимиты, мультисиг, Passkeys/WebAuthn?
- Инфраструктура.
Кто ваш paymaster? Есть ли альтернативы? Как пополняется депозит? Поддерживаются ли нужные L2?
- Экспортируемость.
Используются ли стандартизованные интерфейсы, можно ли перенести аккаунт/модули к другому провайдеру?