Что такое Account Abstraction простыми словами

Account Abstraction — не новый блокчейн

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

Это не форк Ethereum и не отдельная сеть. На практике AA сегодня чаще всего реализуют через ERC-4337: поверх существующего протокола, без изменения консенсуса.

Чем smart-аккаунт отличается от EOA

Точка отсчёта — обычный EOA vs Contract Account: EOA управляется ключом, контракт — кодом.

Smart-аккаунт — это Contract Account, который специально заточен под роль кошелька: проверка подписи, батчинг вызовов, спонсорство газа. Не каждый контракт — smart-аккаунт.

Проверяем тип аккаунта через RPC

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider("https://ethereum.publicnode.com");

const addresses = [
  {
    name: "Vitalik (EOA)",
    address: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
  },
  {
    // EntryPoint v0.7 — singleton ERC-4337, не кошелёк пользователя
    name: "EntryPoint v0.7 (контракт)",
    address: "0x0000000071727De22E5E9d8BAf0edAc6f37da032",
  },
];

for (const item of addresses) {
  const code = await provider.getCode(item.address);
  const type = code === "0x" ? "EOA" : "Contract Account";

  console.log(`${item.name}: ${type}`);
  console.log(`bytecode length: ${code === "0x" ? 0 : (code.length - 2) / 2} bytes`);
  console.log("---");
}

У EOA getCode() вернёт 0x. У smart-аккаунта — байткод кошелька. Сам факт «есть код» ещё не доказывает ERC-4337: нужна совместимость с EntryPoint и логика валидации UserOperation.

Как это работает

В классической модели только EOA может начать транзакцию: подпись ключом → сеть принимает TX.

В Account Abstraction пользователь формулирует намерение (что вызвать, с каким газом, кто платит). Дальше инфраструктура AA (в ERC-4337 — Bundler + EntryPoint) упаковывает это намерение в обычную транзакцию Ethereum и доставляет его в смарт-аккаунт.

Схема на уровне идеи:

Пользователь подписывает UserOperation
        ↓
Bundler собирает UserOp в обычную TX
        ↓
EntryPoint вызывает smart-аккаунт
        ↓
Аккаунт проверяет правила и выполняет callData

Детали пути UserOperation → Bundler → EntryPoint — в следующей статье раздела.

Зачем это разработчику

Для продукта AA снимает ограничения EOA-UX:

• Газ без ETH на кошельке — Paymaster может оплатить комиссию (или принять стейблкоин).
• Несколько действий одной операцией — approve + swap в одном UserOperation вместо двух подписей.
• Гибкая авторизация — passkey, сессионные ключи, социальное восстановление, мультиподпись — всё это логика контракта, а не «один seed навсегда».
• Онбординг без MetaMask — часто сочетают с embedded-кошельком: вход по email, под капотом — ключ/аккаунт, снаружи — приложение.

Если пользователи продукта — не крипто-энтузиасты, AA обычно интереснее, чем «подключите расширение и купите ETH на газ».

Частые ошибки

Считать AA отдельной сетью или L2 → это модель аккаунта и стандарт (часто ERC-4337) поверх Ethereum / L2, а не новый блокчейн.

Путать любой контракт со smart-аккаунтом → у Uniswap-пула тоже есть bytecode, но это не кошелёк. Smart-аккаунт умеет валидировать операции пользователя и исполнять их как кошелёк.

Думать, что «приватный ключ больше не нужен» → ключ или его аналог (passkey, шарды MPC) всё равно участвует в авторизации. Меняется то, какие правила может задать код аккаунта поверх подписи.

Что дальше

• ERC-4337: как устроена транзакция без изменения протокола — путь UserOperation → Bundler → EntryPoint на коде
• EOA vs Contract Account — базовая модель двух типов аккаунтов в Ethereum
• Smart-аккаунт vs EOA: в чём разница на практике — сравнение подписей, восстановления, батчинга и газа