Account Abstraction — удобные кошельки на смарт-контрактах

Account Abstraction (AA) — это подход в Ethereum и совместимых сетях, при котором аккаунты пользователей работают как смарт-контракты. В отличие от классических EOA-аккаунтов (Externally Owned Account) с одной приватной ключевой подписью, «абстрактные» аккаунты позволяют настраивать правила авторизации, оплачивать комиссии по-новому, добавлять восстановление доступа и автоматизировать операции.

На практике AA чаще всего реализуется по стандарту ERC-4337 (контрактный уровень), а также обсуждаются протокольные варианты (например, расширения, упрощающие AA на L1 и Layer2).

Зачем нужен Account Abstraction

Классические кошельки (EOA) ограничены: одна подпись = один владелец, никакой логики восстановления, только пользователь платит газ в родной валюте (напр., ETH). AA решает эти проблемы:

  • Гибкая авторизация — мультиподпись, пороги, социальное восстановление;
  • Оплата газа «не-ETH» и спонсорство — комиссии может платить сервис через Paymaster;
  • Батчинг/бандлинг — несколько действий за одну «операцию» (подписал — и всё выполнено);
  • Session keys — краткоживущие ключи для игр/dApp без постоянных подтверждений;
  • UX как в Web2 — логины, 2FA, политики устройства, лимиты и расписания.

История и контекст

  • До 2023 — идея AA активно обсуждалась, но на уровне протокола Ethereum оставалась сложной; появлялись «смарт-кошельки» без единого стандарта.
  • 2023 — стандарт ERC-4337 включил AA на контрактном уровне: не меняя L1-протокол, через EntryPoint и бандлеров.
  • 2024–2025 — ускорилась поддержка в L2 (Optimistic и ZK-роллапы), кошельки добавляют «смарт-аккаунты» по умолчанию, расширяются сценарии (игры, подписки, B2B).

Как это работает (ERC-4337, по шагам)

Основные компоненты:

  • Smart Account — смарт-контракт пользователя с правилами авторизации и логикой верификации;
  • UserOperation — «операция пользователя» (вместо сырой транзакции), описывает, что и как выполнить;
  • Bundler — узел, который собирает множество UserOperation и отправляет их в EntryPoint;
  • EntryPoint — контракт-координатор, валидирует операции и вызывает целевые контракты;
  • Paymaster — спонсор/провайдер газа (может брать плату в стейблкоинах или субсидировать);
  • Aggregator — агрегатор подписей (например, BLS) для минимизации газа;
  • Factory — контракт для детерминированного деплоя аккаунтов (создаёт смарт-аккаунт при первом использовании).

Поток: 

1. Пользователь формирует **UserOperation** (через кошелёк с AA);
2. Операция попадает к **Bundler**, который проверяет валидность «в мемпуле 4337»;
3. Bundler вызывает **EntryPoint**, тот валидирует подписи/политику аккаунта и **Paymaster**;
4. При успехе EntryPoint исполняет целевые вызовы (батч) и списывает комиссию (указанный платёж).

Возможности AA на практике

  • Социальное восстановление — хранители (guardians) подтверждают восстановление;
  • Мультиподпись/порог — несколько устройств/ключей, разные роли;
  • Оплата газа в токенах — USDC, USDT и др., или спонсорство dApp;
  • Подписки и расписания — периодические платежи/триггеры;
  • Session keys — делегируешь ограниченные права на короткое время для игр/DeFi/NFT;
  • Анти-фишинг-логика — политики доменов, белые списки адресов, лимиты.

Преимущества и ограничения

Плюсы:

  • Сильный UX-рывок: проще онбординг, меньше «подписать, подтвердить, оплатить газ»;
  • Безопасность по правилам: пороги, устройства, соц. восстановление;
  • Гибкая оплата: газ не только в ETH, спонсорство для новых пользователей;
  • Эффективность: батчинг и агрегирование подписей снижают комиссии.

Минусы/Риски:

  • Сложность логики — больше поверхностей атаки в смарт-аккаунте;
  • Зависимость от бандлеров/пеймейстеров — риски централизации/цензуры;
  • Совместимость с dApp — не все интерфейсы корректно поддерживают AA;
  • Риск UX-перегрузки — если политики слишком сложны, пользователю трудно.

EOA vs Smart Account vs MPC

Характеристика EOA (классика) Smart Account (AA) MPC-кошелёк
Модель Один ключ Код-логика в контракте Распределённая подпись (неск. частей)
Восстановление Нет Да (соц./порог/политики) Да (через провайдера/схему)
Газ ETH от пользователя Любые токены/спонсорство (Paymaster) ETH от пользователя
Батчинг Нет Да (одна операция → много действий) Нет (обычно)
Риски Потерял ключ — всё Ошибки кода/зависимости от сервисов Зависимость от MPC-провайдера
На практике AA и MPC комбинируют: MPC хранит ключи, а смарт-аккаунт добавляет политики/UX.

Где уже используется

  • Кошельки со «смарт-аккаунтами» и AA-SDK (в т.ч. на L2);
  • dApp-интеграции с Paymaster для онбординга без газа;
  • Игры и NFT-платформы — session keys для мгновенных действий;
  • Корпоративные сценарии — роли, лимиты, белые списки контрагентов;
  • Подписки, регулярные платежи, «оплата за использование» в DeFi.

AA и Layer2 / другие сети

AA органично ложится на роллапы (низкие комиссии, быстрые подтверждения). Многие L2 внедряют ERC-4337 на старте. Параллельно AA-подход распространяется в EVM-совместимых сетях, а также в экосистемах с иным аккаунтингом (часть сетей интегрирует схожий функционал на уровне протокола).

Безопасность и лучшие практики

  • Аудит смарт-аккаунта и EntryPoint-совместимости;
  • Консервативные политики по умолчанию (лимиты, дневные бюджеты, белые списки);
  • Социальное восстановление через независимых хранителей/устройства;
  • Изоляция session keys (scope/TTL/лимиты);
  • Мониторинг bundler/paymaster (SLA, цензура, отказоустойчивость).

Типовые сценарии внедрения (для продукта)

  • Онбординг «без кошелька»: e-mail/соц. логин → создаётся smart account на лету;
  • «Платит приложение» — Paymaster покрывает газ (или берёт в стейблкоине);
  • Одно подтверждение = серия действий (approve + swap + stake) в DEX/DeFi;
  • Игровые session keys (временные права на конкретную коллекцию/игру);
  • Корпоративные роли (инициатор, апрувер, лимиты контрагента).

Частые вопросы (FAQ)

Можно ли мигрировать EOA в AA? Да, часто через «upgradable proxy/фабрику» или связывание EOA как одного из ключей/ролей. Есть решения, помогающие «апгрейдить» аккаунт.

Кто платит газ? В AA можно оплатить газ токеном, отличным от ETH, или передать оплату Paymaster (спонсорство/биллинг).

Это безопаснее обычных кошельков? И «да», и «нет». Больше возможностей для защиты (порог, восстановление), но и больше поверхностей атаки (ошибки кода/конфигурации). Нужны аудит и аккуратные политики.

AA сегодня и перспективы

К 2025 году Account Abstraction становится «дефолтным» опытом в кошельках и на L2: лучшее онбординг-UX, гибкая оплата, сценарии для игр и корпоративного применения. На горизонте — дальнейшая стандартизация, улучшение совместимости c dApp, более строгие политики безопасности, развитие агрегаторов подписей и расширение поддержки на уровне протокола.

См. также

* Ethereum * Layer2 * Смарт-контракты * Криптокошелёк * Gas Fee * DeFi * dApp * zk-Proof * Cross-chain Bridge

Заключение

Account Abstraction делает аккаунт программируемым: вместо одного ключа и жёстких правил — гибкая логика авторизации, батчи, оплата газа «как удобно» и социальное восстановление. Это ключ к массовому онбордингу Web3: привычный UX, меньше фрикции, больше контроля и безопасных сценариев для пользователей и бизнеса.

Task Runner