Абстракция аккаунтов с первых принципов

Если вы когда-либо пользовались самостоятельным (self-custodial) кошельком в Ethereum, вы пользовались аккаунтом, контролируемым извне, — EOA, — осознавали вы это или нет. Разговор об абстракции аккаунтов начинается с понимания того, что такое EOA, почему её устройство ограничивает всё, что вы можете делать on-chain, и как абстракция аккаунтов ERC-4337 обходит эти ограничения, не затрагивая базовый протокол. Эта статья — точка входа в серию, которая проведёт вас от исходных ограничений до того, как SSP использует абстракцию аккаунтов для работы своего multisig по схеме 2-из-2 на цепочках EVM.

Это основополагающая, концептуальная часть. Если нужен предметный разбор самого стандарта ERC-4337, читайте Что такое абстракция аккаунтов (ERC-4337)? вместе с этой статьёй; здесь мы выстраиваем интуицию о том, почему этот стандарт существует.

Аккаунт, который дал вам Ethereum

В Ethereum есть два вида аккаунтов. Контрактные аккаунты управляются кодом. EOA — обычные кошельки, которыми пользуется большинство, — управляются одним приватным ключом. Кто владеет этим ключом, может авторизовать любую транзакцию из аккаунта, и протокол проверяет ровно одно: что транзакция несёт действительную подпись ECDSA на кривой secp256k1, созданную ключом, который контролирует адрес.

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

Что это устройство закладывает в основу

Четыре ограничения напрямую вытекают из модели «один ключ — одна подпись»:

• Один ключ — единая точка отказа. Потеряли ключ — средства пропали. Утекла копия — у злоумышленника есть всё. На уровне протокола нет второго фактора, нет соподписанта, нет политики, которая могла бы заблокировать кражу.
• Никакой пользовательской логики проверки. EOA не может сказать «требуй две подписи», или «разрешай этот мелкий платёж автоматически, но требуй дополнительного одобрения сверх порога», или «позволяй этому ключу тратить только по будням». У аккаунта нет логики. У него есть проверка подписи.
• Отправитель обязан иметь ETH на gas. Каждая транзакция EOA платит свой gas в ETH. Новый пользователь, у которого есть только токен ERC-20, но нет ETH, не может перевести этот токен, потому что не может оплатить комиссию. Плательщик комиссии и отправитель транзакции вынужденно совпадают.
• UX seed-фразы беспощаден. Поскольку ключ и есть аккаунт, регистрация означает записать seed-фразу и беречь её вечно. Нет пути восстановления, не задействующего эту фразу, и одна ошибка необратима.

Это не баги. Это следствия того, что проверка живёт в протоколе, а не в аккаунте.

Главная идея: сделать аккаунт программируемым

Абстракция аккаунтов — это идея вынести ту логику проверки из протокола в сам аккаунт. Вместо того чтобы сеть жёстко кодировала «транзакция действительна, если у неё одна корректная подпись ECDSA», smart account — контракт, хранящий ваши средства, — сам решает, что считается действительной транзакцией.

Как только аккаунт становится программируемым контрактом, четыре ограничения растворяются в проектных решениях:

• Он может требовать две подписи вместо одной — именно так multisig становится возможным без нативной поддержки протокола.
• Он может реализовать правила восстановления, так что потерянный ключ перестаёт быть концом истории.
• Он может позволить кому-то другому платить gas, отделяя плательщика комиссии от отправителя.
• Он может группировать несколько действий — например, одобрение и обмен — в одну атомарную операцию.

Аккаунт перестаёт быть пассивной парой ключей и становится программируемой логикой, которую контролируете вы.

Как ERC-4337 обеспечивает это без хардфорка

Сложность в том, что изменить способ, которым Ethereum проверяет транзакции, обычно означает изменить базовый протокол — медленное, спорное обновление в масштабах всей сети. ERC-4337 полностью обходит это. Он вводит абстракцию аккаунтов как слой поверх существующей сети, не требуя изменений консенсуса.

Механизм опирается на несколько элементов:

• UserOperations. Вместо отправки обычной транзакции smart account выражает намерение как UserOperation — структурированный объект, описывающий, что аккаунт хочет сделать и как это следует проверять.
• Альтернативный mempool. UserOperations живут в своём собственном mempool, отдельном от обычных транзакций.
• Bundlers. Bundler собирает UserOperations из этого mempool, упаковывает их вместе и отправляет в цепочку как настоящую транзакцию, оплачивая gas базового слоя.
• Контракт EntryPoint. Единственный проаудированный контракт EntryPoint — это узкое место on-chain. Он вызывает каждый smart account, чтобы запустить собственную логику проверки этого аккаунта, и затем выполняет операцию, если проверка пройдена.
• Paymasters. Опциональный контракт paymaster может согласиться покрыть gas для UserOperation — именно это делает возможными безгазовые сценарии и оплату в токенах.

Вместе это позволяет любому контракту выступать полностью программируемым аккаунтом, проверяемым по собственным правилам, тогда как базовый протокол Ethereum остаётся ровно таким, каким был. Стандарт описан в EIP-4337, а собственная дорожная карта абстракции аккаунтов Ethereum отслеживает, куда движется более широкая работа.

Почему это важно для пользователей самостоятельного хранения

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

• Multisig без нативной поддержки. Smart account может требовать больше одной подписи, так что кошелёк может требовать одобрения каждого перевода двумя независимыми устройствами. Это тот строительный блок, на который опирается SSP, подробнее в EVM Multisig по-абстрактному.
• Варианты восстановления. Программируемая проверка открывает дверь сценариям восстановления, которые не сводятся к одной хрупкой seed-фразе.
• Спонсирование gas. Paymasters означают, что комиссию можно отделить от отправителя, сглаживая худшее трение при регистрации.
• Группировка. Несколько шагов могут исполняться как одна операция, снижая и число кликов, и риск сбоя на полпути.

Практическая разница между EOA с одним ключом и программируемым smart account достаточно велика, чтобы заслужить отдельного разбора — см. EOA против smart account: различия, которые важны.

Где здесь SSP

SSP — это самостоятельный (self-custodial) кошелёк, построенный вокруг multisig 2-из-2. Один ключ живёт в браузерном расширении SSP Wallet; второй — в мобильном приложении SSP Key. Каждая транзакция конструируется в расширении и соподписывается на телефоне, так что ни одно устройство в одиночку не может двигать средства.

На цепочках EVM SSP реализует эту схему 2-из-2 с помощью ERC-4337. Кошелёк — это smart account ERC-4337, логика проверки которого требует оба ключа, а две частичные подписи объединяются — в стиле MuSig2 на secp256k1 — в единую агрегированную подпись Schnorr, которую контракт проверяет on-chain. Смарт-контракты SSP прошли аудит Halborn в 2025 году. Полному устройству посвящена статья Архитектура абстракции аккаунтов SSP.

Иными словами, абстрактная возможность, описанная выше, — аккаунт, который навязывает собственное правило множественной подписи, — это ровно то, что SSP превращает в рабочий кошелёк на Ethereum, Polygon, Base и других поддерживаемых цепочках EVM.

Остальная часть этой серии

Эта часть задала проблему и главную идею. Серия строится дальше отсюда:

1. Абстракция аккаунтов с первых принципов — эта статья: почему EOA ограничивают и что значит абстракция аккаунтов.
2. EOA против smart account: различия, которые важны — прямое сравнение двух моделей аккаунтов.
3. Архитектура абстракции аккаунтов SSP — как SSP встраивает ERC-4337 в кошелёк 2-из-2.
4. Спонсирование gas и paymasters: разбор — как paymasters отделяют того, кто платит, от того, кто отправляет.
5. Абстракция аккаунтов на неэфировых цепочках — как та же идея переносится за пределы Ethereum.

Начните с разбора ERC-4337, если хотите стандарт в отрыве, а затем вернитесь сюда за общей картиной. С этого момента аккаунт перестаёт быть ограничением и начинает быть тем, вокруг чего вы можете программировать.