Account Abstraction 101

This is my first article on Account Abstraction, so I will keep things basic and general. Later on we will get to implementing AA in the real world.

Acccount Abstraction (AA) is a novel way of managing user accounts on the Blockchain.

Currently, there are two types of accounts: Smart Contracts and EOAs, Externally Owned Accounts.

With Smart Contracts, we can do many interesting things because they can execute logic.

With EOAs, not so much. They can only sign messages and send transactions.

The purpose of AA is to provide “Smart Wallets” where we have EOAs coupled with a Smart Contract that does most of the work for that EOA. This allows developers to improve the User Experience 100x because they can hide almost all complexities of the blockchain behind AA.

We can allow end users to interact with the blockchain without sending transactions, worrying about gas costs, or losing their secret phrase. To make things even more interesting, all of the above has been implemented without any changes to the core Ethereum protocol. Meaning that EOAs and Smart Contracts are still the only two types of accounts. AA is completely on top, so all security and decentralization properties are preserved, which is double awesome.

For this to work, however, multiple new processes and actors are involved. Because someone needs to pay for gas, send the transactions, and verify that the user can interact with their given “Smart Wallet”.

This is all documented in EIP-4337, one of the most complex EIPs of all time. But here, I’m going to explain things in a simple manner and big picture only.

Benefits of Account Abstraction

Implementing AA will have massive impact on the end user experience, especially for new-comers. That is why people are talking about AA as something that could onboard the next 1 billion users to Blockchain. Here are some of the coolest things that can be done with AA.

• Gas Sponsoring – as an app developer, you can pay for gas for your users, so they don’t need to acquire tokens before trying out your dApp.
• Social recovery – recovering your funds from your wallet from another trusted account.
• Transaction batching – Batching approvals and transfers in one transaction greatly simplify interaction with many DeFi protocols.
• Session keys – grant limited permission for another account to perform transfers on your behalf. Useful for subscriptions etc.

Two main AA innovations

There are two main requirements that lead to the creation of the AA system.

Moving from simple Wallets to Smart Wallet Contracts

If we want to provide Social Recovery or Session keys or to automate payments, then we must have some logic running alongside our wallet, so a Smart Contract is required.

With AA accounts, all funds are stored in the Smart Wallet but the user still has their own private key that they use to control their Smart Wallet.

User Operations

If we want to provide seamless blockchain experiences, we cannot have the end user signing transactions every 2 minutes.

A User Operation simply describes the transaction that needs to be executed. For example: “Swap 3 ETH for DAI on Uniswap”. Then this User Op will be executed by the AA system. Let’s see what this AA system consists of.

How Account Abstraction Works

End User creates User Operation

The user creates User Operations by signing messages with his private key that get sent to the User Operations mempool. With AA there is a new mempool just for User Operations, just like the mempool for real transactions.

Bundler

From the User Ops mempool, a Bundler (or executor) picks it up, creates the actual transaction and executes it. But at this point we want the user operation to be run from the users Smart Wallet because that’s where the user keeps their funds, that’s the actual wallet.

So the Bundler picks a User Operation and calls handleOp(UserOperation) on the users Smart Wallet.

But there are some trust issues for the Bundler, it needs to trust the user’s Smart Wallet to give him a reward for executing the transaction and paying for gas.

Entry Point Contract

To address the trust issue, the bundler interacts with an Entry Point contract. This is a singleton contract and there exists only one official entry point contract per chain. The Entry Point contract is verified and audited and the Bundler trust that it will get him the reward.

The Entry Point contract performs validation of the User Operation and the Smart Wallet, it checks that the corresponding transaction will go through and that the wallet has enough ETH to pay the bundler.

Then it’s also responsible for executing the User Op from the Smart Wallet.

Paymasters

Paymasters are actors that can pay for gas on behalf of users. If you have a dApp that you want people to try for free, you can set up a Paymaster that pays for gas for interactions with your smart contracts.

Yes, we are adding another complication to the AA setup, but it is well worth it, there are many interesting things Paymasters can do.

• Sponsoring only the first 5 transactions per user.
• Sponsoring a maximum of 100 transactions per minute.
• Allowing users to pay you in stablecoins for sponsoring their transactions.

Factories

But how will these Smart Wallets get on the blockchain in the first place. One way is for users or someone else to deploy them any time a new Smart Wallet is created. But a more efficient way is to have a factory that holds the bytecode of a contract and can just redeploy new Smart Wallets without breaking a sweat.
In fact, it is possible to send funds to Smart Wallets before they even are deployed, because deployment happens with the new CREATE 2 opcode where we know the address of the contract even before it’s been created. So in reality, the first time a user wants to interact with their own Smart Wallet, the wallet might get deployed right at that moment, I think it was the Entry Point contract that calls upon Factories to deploy/instantiate new Smart Wallets at the time of their first interaction.