Account Abstraction (ERC-4337): смарт-аккаунты, бандлеры и оплата газа токенами

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

Классическая модель в Ethereum делит аккаунты на EOA (Externally Owned Account — управляется приватным ключом) и Contract Account (управляется кодом). Account Abstraction стирает жёсткую грань: сам аккаунт пользователя становится контрактом, а правила проверки и оплаты задаются кодом.

Зачем это нужно пользователю и рынку

Где AA уже работает: три модели

1) «Надпротокольная» AA в EVM (путь через стандарты). На Ethereum и совместимых сетях широко применяют модель с UserOperation и EntryPoint, где транзакции юзеров собирают bundler-ы, а логику контроля газа/подписи выполняют смарт-контракты аккаунтов и paymaster-ы. Это позволяет внедрять AA без изменения консенсуса сети.

2) Нативная AA на L2/ZK-сетях. Некоторые сети изначально делают все аккаунты смарт-контрактами. Так устроены, например, Starknet и zk-EVM-сети семейства zkSync Era. Для разработчика это значит: не надо «совмещать» EOA+контракт — любой аккаунт уже контракт.

3) AA-подобные модели вне EVM. В NEAR аккаунты изначально «читаемые» (например, alice.near) и имеют access keys с разными правами: можно давать dApp «функциональный ключ» без права перевода средств. Это решает ряд UX-задач AA даже без термина «AA».

Базовые термины AA (простыми словами)

  • Smart Account (контракт-аккаунт). Кошелёк-смарт-контракт. Он хранит правила: какие подписи принимать, как считать nonce, откуда брать оплату газа.
  • UserOperation (заявка пользователя). «Транзакция-заготовка» с данными о вызовах, подписях и лимитах, которую не гонят в обычный mempool, а отправляют в альтернативный пул для сборки в пакет.
  • Bundler (собиратель). Узел, который принимает UserOperation-ы, симулирует их, отбрасывает невалидные и формирует «пакет» исполнения через EntryPoint.
  • EntryPoint (контракт-врата). Единая точка входа, через которую исполняются операции аккаунтов: валидация, списание комиссий, вызовы целей.
  • Paymaster (спонсор). Контракт/сервис, который берёт на себя оплату газа (в ETH или за счёт токенов/депозита приложения).
  • Aggregator. Компонент, агрегирующий подписи (например, BLS) для экономии газа и скорости.
Эти элементы — «кирпичики» AA. DApp-ам важно уметь распознавать подпись контракта (см. Мультиподпись (multisig) — кворум ключей и защита средств, Приватный ключ (private key)) и работать с валидаторами EIP-подписи.

Как проходит выполнение (жизненный цикл)

  1. Пользователь формирует UserOperation (в кошельке или внутри dApp), где указывает цели вызовов, бюджет газа, источник оплаты (через paymaster) и подпись(и).
  2. Bundler симулирует операцию: проверяет подписи, лимиты, наличие средств/депозита у paymaster, отсутствие конфликтов nonce.
  3. Подтверждённые заявки склеиваются в «пакет» и отправляются в EntryPoint для батч-исполнения.
  4. Комиссии списываются по логике аккаунта/пеймастера, вызываются целевые контракты. В случае ошибки у каждой операции есть отдельная логика возврата.

Пользовательский эффект: меньше «лишних» операций и всплывающих окон, оплата газом в удобной валюте, гибкая безопасность.

Сильные и слабые стороны AA

Плюсы:

  • «Веб-уровень» UX: батчи, спонсорство газа, passkeys, социальное восстановление.
  • Политики безопасности на уровне кода: лимиты, таймлоки, мульти-роль.
  • Инклюзия: проще онбординг (кошелёк создаётся по факту первой операции), можно платить газом в стейблкоине, у dApp — меньше барьеров.

Компромиссы:

  • Сложность стека. Появляются новые роли (bundler, paymaster), которые тоже нужно мониторить и аудировать.
  • Единая точка — EntryPoint. Критичный контракт требует аудитов и строгой дисциплины обновлений.
  • Совместимость dApp. Приложения должны правильно понимать «подписи контрактов» (EIP-1271 и пр.) и особенности AA-мемпула.

Модели и стандарты (как это оформлено в EVM-мире)

  • AA поверх протокола (на смарт-контрактах). Наиболее распространённая модель: UserOperation → Bundler → EntryPoint → Smart Account → Paymaster. Это даёт программируемые кошельки уже сегодня, без хардфорков базового слоя. Подробности — на технической странице.
  • Модульные аккаунты. Идея «плагинов» и «модулей» к смарт-аккаунту: добавляете социальное восстановление, лимиты, мультисиг, WebAuthn как модули, а не переписываете кошелёк «с нуля».
  • Новая «мостовая» логика для EOA. На уровне протокола появилось решение, позволяющее обычному EOA временно вести себя как смарт-аккаунт в пределах одной транзакции — это снимает часть барьеров миграции на смарт-кошельки.
Для читателя 24k: чтобы не «распухал» термин, глубокая архитектура, мемпул-правила и кейсы внедрения разобраны в Account Abstraction — удобные кошельки на смарт-контрактах.

Нативная AA: Starknet и zkSync (и почему это важно)

  • Starknet. В сети все аккаунты — контракты по умолчанию. Проверка подписи/лимитов — в коде аккаунта; «EOA как класса» нет. Это упрощает UX и снимает многие «костыли» совместимости, но требует от dApp изначальной поддержки такого формата аккаунтов. См. Starknet — L2-валидити-роллап на STARK: Cairo, аккаунты по умолчанию и масштаб.
  • zkSync Era. L2-сеть с нативной AA: смарт-аккаунты, «спонсоры» комиссий, настраиваемая проверка подписи, сессионные ключи, мультисиг «из коробки».
  • Что это значит для экосистемы. Нативная AA показывает «как может быть» в идеале: все — аккаунт-контракты, AA — по умолчанию. Для EVM-мира это вектор развития: либо протокольные улучшения, либо «надпротокольные» стандарты, и/или их комбинация.

Вне EVM: почему часто вспоминают NEAR

В NEAR аккаунты именованные (например, ivan.near) и имеют много ключей с разными правами. DApp может получить «функциональный ключ» без права перевода средств, пользователи — безопасную ротацию ключей и мультисиг-паттерны. Это не «AA в терминах Ethereum», но решает те же UX-задачи: гибкая аутентификация и управление доступом в кошельке.

Как это снижает комиссии и «фрикции»

  • Батчирование вызовов. Вместо 3–5 отдельных транзакций — один «пакет». Меньше накладных расходов, меньше «человеческих» ошибок.
  • Оплата газа токенами. Пользователь может не держать ETH на каждом L2: комиссии списывает dApp/спонсор или тот же стейблкоин.
  • Умные лимиты и «сессии». Игры/соцсети могут выдавать «сессионные ключи»: не нужно подтверждать каждый клик.
Смотрите общие статьи по комиссиям: Gas fee в Ethereum: сколько платить и как экономить (gwei, EIP-1559), Gwei — что это в Ethereum и как считать комиссии.

Безопасность: на что обратить внимание

  • Аудиты EntryPoint/аккаунтов. Критическая часть стека; ошибки здесь — системные риски.
  • Симуляция и правила мемпула. Чтобы защититься от «засорения» альтернативного пула, bundler-ы применяют строгие правила валидации и симуляции.
  • Paymaster-риски. Если спонсор газа исчерпал депозит или работает с багами — операции «падают». Инфраструктуру спонсирования стоит диверсифицировать.
  • Политики кошелька. Социальное восстановление и делегирование полномочий — мощно, но требует продуманных лимитов/таймлоков/кворумов.

Практика: что даёт AA конечному пользователю

Покупки и игры. Оплатили NFT/внутриигровую покупку — без танцев с одобрениями и переключением сетей; dApp оплатил газ или списал стейблкоин.

DeFi-операции. Один клик — несколько шагов: вывод залога, своп, погашение долга, повторный деплой. Под капотом — пакет обращений с контролем лимитов.

Подписки и лимиты. Ежемесячные транши на сервис или «карманные деньги» на детский кошелёк с уведомлениями и дневным лимитом.

Безопасность ключей. Восстановление через доверенных лиц/устройства; авторизация по Passkey с «вторым фактором»; временные права для dApp.

Сравнение моделей (сводка)

Параметр ERC-стек поверх протокола Нативная AA (Starknet, zkSync) «EOA→умный на один tx» (протокольная)
Тип аккаунтов EOA + контракт-кошелёк Все аккаунты — контракты Обычный EOA временно получает логику контракта
Совместимость Нужна поддержка dApp (EIP-подписи, AA-мемпул) «По умолчанию» Минимальна: EOA остаётся базовой сущностью
UX Батчи, спонсорство газа, модули То же, «нативно» Ближе к EOA-опыту, но с «умным» поведением в tx
Риски Сложность стека, зависимость от EntryPoint и bundler Совместимость с «классическим» EVM-миром Новые векторы фишинга через делегирование/авторизации
Где применяют Ethereum/L2 и EVM-сети Starknet, zkSync Era Обновления семейства «Pectra» в Ethereum

Роадмап и эволюция

  • Стандартизация правил валидации. Для альтернативного пула операций формулируются правила валидации (защита от DoS, интерференции операций), чтобы bundler-ы работали предсказуемо и безопасно.
  • Модульные аккаунты. «Плагины» для смарт-кошельков (соц. восстановление, лимиты, WebAuthn, батч-шаблоны) — как экосистема расширений.
  • Протокольные улучшения. В обновлениях Ethereum закреплена возможность временно «наделять EOA кодом» в рамках транзакции (мост между EOA и смарт-аккаунтом). Это помогает доставлять «фичи AA» миллионам текущих EOA-кошельков.

Мини-гайд: как выбрать AA-кошелёк

  • Совместимость с dApp. Проверяйте, умеет ли dApp принимать подписи контракт-аккаунта (EIP-поддержка), и есть ли режимы «sponsored gas».
  • Безопасность. Наличие аудит-отчётов для аккаунта/EntryPoint, политика обновлений, механизмы аварийного отключения модулей.
  • Модули. Поддержка социальных восстановлений, лимитов, мульти-сиг, Passkeys/WebAuthn.
  • Инфраструктура. Кто ваш «paymaster»? Есть ли альтернативы? Как пополняется депозит? Поддерживаются ли ваши L2?
  • Экспортируемость. Можно ли перенести аккаунт/модули на другой провайдер? Используются ли стандартизованные интерфейсы?

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

AA «ломает» децентрализацию? Нет. Bundler-ы и спонсоры — разделяемые роли. Их может запускать кто угодно; конкуренция и открытые правила снижают риски централизации.

Это «убивает» EOA? Нет. В EVM-мире AA работает поверх: вы можете оставаться на EOA, а «умные» сценарии — включать через смарт-аккаунты или протокольные механики «EOA-на-один-транзакшн».

Где дешевле комиссии — с AA или без? Зависит от сценария. Батчи/агрегация подписей и спонсорство могут уменьшить издержки «на клик». Но появляется инфраструктурная комиссия спонсора/сервиса — её нужно учитывать.

Насколько безопасно «соц. восстановление»? Безопасно при правильно выбранном кворуме и таймлоках. Рекомендуется разделять хранителей (люди/устройства), лимитировать права и использовать 2FA-паттерны.

Что насчёт «модульных кошельков»? Это эволюция AA: аккаунт — платформа для плагинов. Вы не перепрошиваете кошелёк под каждую фичу, а добавляете/удаляете модули по интерфейсу.

См. также в 24k Wiki

Task Runner