Account Abstraction: что это такое и зачем нужно криптомиру

В Ethereum существует два типа аккаунтов:

• EOA(Externally-owned account). Контролируется кем-либо, у кого есть приватный ключ.
• Contract account. Смарт-контракт, который размещен в сети блокчейн.

Про систему аккаунтов можно прочитать тут.

Согласно новому стандарту ERC-4337 два типа аккаунта объединяются в один. Результатом является единая учетная запись, способная одновременно совершать транзакции с токенами и создавать контракты. Можно сказать, что это уровень выше над двумя типами аккаунтов - абстракция.

Ответ прост: для построения кошельков нового поколения, которые объединят в себе преимущества смарт-контракта и EOA аккаунта.

Сегодня большинство кошельков (например Metamask) являются типичными представителями EOA на базе приватного ключа. Такая модель диктует необходимость подписывать все транзакции с использованием приватного ключа. Это усложняет работу пользователя с кошельком. Более того, в случае потери приватного ключа, будет потерян и доступ к кошельку.

С другой стороны существуют альтернативные кошельки на базе смарт-контрактов (Gnosis wallet). Смарт-контракт позволяет реализовать произвольную бизнес логику на кошельке. Например, мультиподпись. Но при этом пользователю такого кошелька все еще нужен EOA аккаунт, чтобы вызывать функции смарт-контракта и оплачивать газ.

Важно! EOA аккаунт необходим, так как в блокчейн только он может быть инициатором транзакции. EOA аккаунт подписывает своим приватным ключом транзакции и платит газ за их исполнение.

ERC-4337 объединяет в себе функции кошельков на базе EOA и смарт-контрактов с помощью использования псевдотранзакций вместо обычных транзакций. Это позволяет обойти необходимость подписи каждой транзакции приватным ключом. Этот подход пришел на смену ERC-2771 о метатранзакциях. Подробнее можно почитать тут. За счет псевдотранзакций достигается абстракция над аккаунтом пользователя. 

Alchemy подготовил серию статей на тему абстракции аккаунта. Эти статьи не просто рассказывают про новый стандарт, они пошагово объясняют, почему в стандарте были использованы те или иные подходы. Это самые полезные статьи с технической точки зрения, не считая статей Виталика, которые я встречал. Считаю, что для дальнейшего понимания, разработчикам, необходимо обязательно осилить их.

1. You Could Have Invented Account Abstraction: Part 1
2. Account Abstraction Part 2: Sponsoring Transactions Using Paymasters
3. Account Abstraction Part 3: Wallet Creation
4. Account Abstraction Part 4: Aggregate Signatures

А вот теперь можно идти и читать "законы".😜 ERC-4337, добро пожаловать!

Ниже покажу несколько общих схем и кратко расскажу, процесс работы стандарта. Основными actors выступают:

1. Bundler. Специальный сервис, который организует альтернативный мемпул для хранения псевдотранзакций и добавляет транзакции в Ethereum Block под видом обычных транзакций.
2. Entry point contract. Это singleton. По сути контракт, который является доверенной точкой входа для Bundler. Контракт занимается валидацией и исполнением транзакций.
3. Paymaster. Смарт-контракт, который может принимать участие в оплате газа за исполнение пользовательских псевдотранзакций.
4. Account. Или Wallet. По сути это смарт-контракт, который реализует логику работы кошелька пользователя. Вся основная бизнес логика работы кошелька в DApp описывается тут.

Принцип работы Bundler

На схеме происходит следующее:

1. Пользователи подготавливают свои псевдотранзакции. Правильно называть их UserOperations в терминах стандарта.
2. Затем они отправляются в альтернативный mempool.
3. Bundler извлекает UserOperations из альтернативного mempool.
4. Bundler производит упаковку UserOperations в обычные транзакции.
5. Bundler добавляет транзакции в Ethereum block.

Упрощенная схема работы ERC-4337

В самом простом варианте можно представить, что пользователи просят Bundler исполнить транзакцию на своем контракте Wallet за место них. При этом за газ будет платить Bundler. Можно придумать различные модели того, где Bundler будет брать средства для оплаты газа. Например, он может это делать безвозмездно или выдавать кредит пользователю с ожиданием того, что пользователь в будущем вернет ему оплату за газ, либо средства для оплаты газа могут списываться непосредственно с кошелька пользователя.

На схеме происходит следующее:

1. Пользователи отправляют свои UserOperations в альтернативный mempool, после чего они попадают к Bundler.
2. Bundler обрабатывает UserOperations и поочередно проверяет возможность выполнения через вызов validateOp() на контракте Wallet. Это необходимо, чтобы не потратить лишний gas в случае, если транзакция невалидна.
3. Bundler передает UserOperations доверенному контракту EntryPoint. Этот контракт снова валидирует транзакции и исполняет вызовы для каждого кошелька пользователя.

Чуть более сложная схема работы ERC-4337

Схема ниже похожа на упрощенную схему. Однако на схеме добавилось несколько новых контрактов: Factory, Paymaster, Aggregator.

На схеме происходит следующее:

1. Пользователи отправляют свои UserOperations в альтернативный mempool, после чего они попадают к Bundler.
2. Bundler отправляет UserOperations в контракт Aggregator для генерации комбинированной подписи. То есть UserOperations группируются и такая группа получает одну единственную подпись. Это позволяет дешевле исполнять транзакции группой, а не по одиночке. В процессе агрегации UserOperations валидируются через вызов validateOp() на соответствующих контрактах Wallet.
3. Bundler передает aggregated UserOperations доверенному контракту EntryPoint. Этот контракт снова валидирует транзакции и исполняет вызовы для каждого кошелька пользователя.
4. Однако, если контракт кошелька еще не был создан, перед выполнением транзакции пользователю будет создан кошелек через вызов контракта Factory.
5. Если в UserOperation был указан доверенный Paymaster контракт, то комиссия за газ будет списана с него для соответствующей UserOperation. Оплата за газ будет списана только в том случае, если контракт Paymaster разрешит. Для этого контракт EntryPoint проверяет Paymaster вызовом функции validate() у каждой UserOperation.

Стандарт ERC-4337 открывает новые возможности для кошельков пользователя. Ниже расскажу про самые основные и самые актуальные.

1. Multisig. Совместное использование кошелька группой пользователей. Это было доступно для кошельков на базе смарт-контрактов, но не на базе EOA.
2. Social recovery. Этот кейс определяет возможность восстановить доступ к кошельку. То есть, если один из участников потерял доступ к кошельку, другие владельцы кошелька могут восстановить ему доступ. Либо можно заложить в кошелек возможность восстановления доступа другим удобным способом.
3. Different signature schemes. Стандарт позволяет использовать другие алгоритмы проверки цифровой подписи. Такие как BLS или quantum resistant в будущем.
4. Batching multiple operation. Возможность вызывать несколько операций на кошельке в рамках одной транзакции. Например, при обмене токена на Uniswap, можно вызывать approve() и transferFrom() в одной транзакции.
5. Gas abstraction. Это позволяет устанавливать адрес с которого будет списываться оплата за газ. Это значит, что DApp могут оплачивать газ за пользователя или пользователь может оплачивать газ со своего второго кошелька. Возможны и другие варианты использования, такие как, оплата газа в ERC-20 токене или обмен одного токена на другой внутри контракта кошелька.

Важно! Благодаря стандарту возможно реализовать практически любой набор функций для кошелька. Ты можешь придумать свой вариант использования.

В ближайшем будущем мы планируем выпустить статью на тему того, как мы внедряли АА в одном из своих клиентских проектов. Подпишитесь, чтобы узнать о релизе этой статьи.

Bundler

Есть два популярных Bundler:

1. Bundler на go от stackup
2. Bundler на typescript от infinitism

Важно! На момент написания этой статьи node провайдеры данных уже начинают предлагать продукты, которые помогут построить Account Abstraction. Например, для получения раннего доступа в Alchemy нужно заполнить специальную форму. Сам продукт тут. Или Biconomy, который используется Account Abstraction для предоставления удобного SDK с помощью которого можно легко взаимодействовать с блокчейн.

Контракты

Для стандарта были написаны контракты. Посмотреть можно тут.

Контракт EntryPoint.sol.

Контракт простого кошелька SimpleAccount.sol.

Контракт фабрики кошелька FactorySimpleAccount.sol

Базовый контракт для реализации Paymaster

Важно! Аудитом контрактов занималась компания OpenZeppelin. Подробнее можно ознакомиться с результатом тут.

SDK для отправки UserOperation в сеть

Для того чтобы отправлять UserOperation в альтернативный mempool уже предлагаются различные sdk. Например, @account-abstraction/sdk. Этот sdk написан infinitism и совместим с их собственным bundler.

Спасибо большое за ознакомление с этим материалом! Если вы хотите принять участие в развитие данного и других материалов, переходите в наш репозиторий на GitHub. Будем рады вашим пропозалам!