The Runway to Account Abstraction

14 min readApr 28, 2023

Have you ever heard about account abstraction? Account Abstraction is that stuff that seems to be the gateway to web3 gaining mainstream adoption. But what is it exactly? In this article, we will understand what account abstraction means and the efforts towards achieving it on Ethereum.

What is Account Abstraction?

Account abstraction involves two words, Account and Abstraction. We will begin by breaking down the concepts of Account and Abstraction. Let us start with what an account is on Ethereum.

There are two types of accounts on Ethereum, Externally Owned Accounts (EOAs) and Contract Accounts. EOAs are accounts that are controlled by a user using a private key. The account you currently use on Ethereum is an EOA. You have a private key which gives you authority over that account. On the other hand, Contract Accounts are smart contracts. They have no associated private keys; the code they hold controls them. Every smart contract is a Contract Account.

Abstraction is the noun of the adjective abstract. From the Merriam-Webster dictionary, when something is abstract, it is disassociated from any specific instance. So an abstract account would be an account that is not specific, meaning it is neither an EOA nor a Contract Account. This process of making accounts on Ethereum abstract or the state of having abstract accounts on Ethereum is called Account Abstraction (AA). For this article, we will use the acronym AA in place of Account Abstraction.

Account Abstraction is the process of making all the accounts on Ethereum equal in the eyes of the Ethereum protocol. Currently, EOAs are seen as first-class citizens by the Ethereum protocol because they can initiate and sign transactions but contract accounts cannot. This means that for a transaction to occur, an external actor such as a user has to sign a transaction with a private key. The signed transaction is sent to the blockchain and accepted by the Ethereum protocol provided it is valid. Contract Accounts, on the other hand, do not have private keys to sign their transactions. But with account abstraction, transactions can be signed by the user using any means. The associated contract validates the transaction instead of the Ethereum protocol.

Another way to think about Account Abstraction would be using the Abstraction concept in Object Oriented Programming (OOP). Let us take a look at an abstraction scenario. We can create an abstract account class in pseudocode like so:

abstract class Account {
  abstract function sign(data);
  abstract function sendTransaction(data);
}

Any class that inherits from the abstract Account class above automatically becomes an Account. We do not care about how the class implements sign and sendTransaction functions. Looking at it from an Ethereum perspective, only EOAs can perform these functions and the protocol cares about how they are done. With Account Abstraction, we want both EOAs and Contract Accounts to inherit from the abstract Account class. They will now perform the functions of an account without the Ethereum protocol caring about how each of them does so.

It is important to note that current Account Abstraction proposals on Ethereum focus on making Contract Accounts abstract. There are discussions around removing EOAs from Ethereum and replacing them with smart contracts.

Why do we need Account Abstraction (AA)?

Account Abstraction will benefit the cryptocurrency and the blockchain ecosystem in general. It improves the UX of cryptocurrency and blockchains, allowing the ecosystem to reach mainstream adoption quickly. Here are some benefits:

Batched Transactions: If you have swapped on a DEX like Uniswap, you would have noticed that you approved Uniswap to spend your tokens before the actual swap. Apart from these being two separate transactions and consuming gas fees, you give infinite approval to Uniswap. An infinite approval allows you to swap the same tokens on Uniswap without doing an approval transaction next time. But it also introduces a security flaw of allowing Uniswap to spend your tokens anytime. With AA, you can bundle multiple actions into a single transaction. This means you can afford to approve just enough for Uniswap to spend and swap just that amount in one transaction. Since you can keep doing this in one transaction, you do not need to give infinite approvals to Uniswap or any other smart contract.
Sponsored Transactions: Would it not be cool to have only stablecoins in your wallet and not worry about getting ETH to cover transaction fees? Account Abstraction allows you to pay your transaction fees in almost any token. You can even skip paying transaction fees altogether because someone paid them on your behalf. A good example is Uniswap paying transaction fees for all its users. It will work like meta transactions but without the accompanying complications.
Social Recovery: As a cryptocurrency user, you must have seen this message or something similar: “Before you continue, write these words down on a sheet of paper”. That is the message you get when you create a new wallet. You lose access to your funds if you lose these words and can have your funds stolen if these words fall into the wrong hands. With Social Recovery, you do not need a seed phrase and if you forget your password or change devices, you can access your wallet using the help of people you know.

The above is a non-exhaustive list of the benefits of AA but is enough for us to understand why we need it.

How do we achieve Account Abstraction (AA)?

To achieve AA the Ethereum protocol has to see EOAs and Contract Accounts as the same. Only EOAs can currently initiate transactions on Ethereum. EOAs can send transactions because the Ethereum protocol requires valid transactions to be signed by a private key using the ECDSA signature algorithm on the Secp256k1 curve and also satisfy other conditions like nonce and balance checks. EOAs have private keys, so they can fulfil this condition, while Contracts accounts do not and therefore cannot satisfy this condition.

To achieve AA we will make the Ethereum protocol use new conditions that Contract accounts can satisfy to validate transactions.

Account Abstraction (AA) Hurdles

We have many Ethereum Improvement Proposals (EIPs) that discuss and suggest different approaches Ethereum can take to achieve AA. Each proposal no longer uses the transaction validity check enshrined in the Ethereum protocol instead, it leverages the EVMs execution. The EVM execution refers to any computational steps done in a smart contract. Currently, for a transaction to be valid, it has to satisfy these conditions:

Nonce: The nonce of the transaction must be equal to the current nonce of the account sending it. It prevents transaction replays.
Signature: The signature is checked for validity and is used to derive the transaction sender.
Balance: The sender’s balance must be enough to cover gas fees and send the value indicated in the transaction.

Note: The Ethereum Yellow Paper defines more conditions, but for the sake of this article, we will consider only these.

But with AA, the protocol does not need to do all this. The EVM execution performs one or more checks above to ensure the transaction is valid. After the checks are complete and gas fees are paid, it completes the actual execution e.g. swapping assets on a DEX. Thus we can divide each AA transaction into two phases, validation and execution phase. The point where the gas fee payment occurs separates the execution into two phases.

Validation Phase: This phase occurs before the gas fee payment during the EVM execution. In this phase, a contract performs checks to ensure it is a valid transaction. This phase ends when the contract pays the gas fees.
Execution Phase: This phase begins after the gas fee payment. The fees cover the gas spent during the validation and execution phases.

Unlike when the protocol guaranteed the transaction would pay gas fees, AA brings about the uncertainty of gas fee payment. It is possible the EVM execution fails during validation and the transaction does not pay for gas. This introduces the possibility of Denial of Service (DOS) attacks, where validators are inundated with transactions that do not pay gas fees. A simple on-chain transaction can cause a large number of pending transactions in the mempool to be invalid by changing a state they depend on for validity. So during execution, they all fail and end up not paying for gas.

AA proposals address these issues. Each one provides solutions for mitigating these DOS attacks. They approach it using methods like forbidden opcodes, mempool and propagation rules/guidelines, validation phase gas limits etc. Validators first simulate the validation phase of the transactions to ensure they follow these rules, are valid and pay gas. After the checks, the validator bundles transactions into a block for execution.

The Runway

Ethereum has four Ethereum Improvement Proposals (EIPs) proposed to help it achieve Account Abstraction or at least, its benefits. They are EIPs 86, 2938, 3074 and 4337.

Let us look at how each proposal achieves AA and tackles the issues associated with their approach.

EIP 86: Abstraction of transaction origin and signature (Created 2017–02–10)

This EIP is a proposal to abstract the origin and signature of a transaction. The Ethereum protocol would not care about who is sending it and would not check the signature for validity.

In this proposal, any transaction sent with its signatures set to v=CHAINID, r= 0 and s=0 is considered a valid transaction, and its sender is set to the 0xffffffffffffffffffffffffffffffffffffffff address. It should also have its value, gasPrice and nonce set to 0. The transaction is sent to a smart contract indicated in its to field. This contract can be referred to as a forwarding contract. The data field of the transaction contains the data used for calling the forwarding contract. The parameters used in making the call are arranged in the calldata like so: [sig, nonce, to, value, gas price, data]. The contract reads all this, validates the transaction using any signature algorithm it wants, pays gas fees, ends the validation phase and does the actual execution.

Before adding a transaction to the mempool, validators must confirm it pays the required gas fees. This EIP proposes that validators check the transaction pays gas fees using Regular Expressions. They test the code of the target contract with Regular Expressions for verified and safe contract codes that pay fees and pass other checks. These checks involve checking: if the right private key was used to sign the transaction, the gas price is sufficiently high, the nonce in the transaction matches the nonce in the state and the target contract has enough balance to satisfy the fees.

This EIP introduces a new transaction type for AA transactions and lets a forwarding contract determine transaction validity. But the proposed solution of using Regular Expressions to ensure transactions pay fees and reduce DOS attacks limits contract design to a set of already tested contracts. It does not address the scenario where multiple transactions in the mempool are rendered invalid by a single on-chain transaction.

EIP-2938: Account Abstraction (Created 2020–09–04)

This proposal introduces a new transaction type (EIP 2718 transaction type). The new transaction is of the form: rlp([nonce, target, data]). Where the target is the contract to call, the nonce must be the nonce of the target contract, and data is the calldata passed to the target.

The contract receives the transaction and checks if it is valid using its code. After successful validation, the contract calls PAYGAS, a new opcode proposed by this EIP. PAYGAS takes two arguments off the stack: version_number and memory_start. The version_number determines how gas information is read from memory using memory_start. PAYGAS reads the gas information as gas price and gas limit and then subtracts the ETH equivalent from the contract balance. This marks the end of the validation phase since the contract has paid for the gas but also marks the beginning of the execution phase where the actual transaction activity begins. The PAYGAS opcode acts as a checkpoint such that even if the transaction reverts in the execution phase, it only reverts to the point right after the execution called PAYGAS, so the validator still gets the fees.

If the transaction fails during the validation phase the validator ends up paying for the fees without a refund. Restrictions are placed during the validation phase to prevent this. A gas cap is placed on the verification phase to ensure it does not exceed using that gas amount. Environment opcodes BLOCKHASH & TIMESTAMP; call/create opcodes CREATE, CALL and external state access opcodes DELEGATECALL & EXTCODESIZE are forbidden from being used. These opcodes can behave differently between the transaction simulation and actual execution on-chain. A good example is a simulation using the TIMESTAMP opcode. It can return a time which satisfies a condition during simulation but return another time during the actual execution which fails to satisfy that same condition.

This EIP lets a contract determine transaction validity to achieve account abstraction. It also introduces an Opcode, PAYGAS, used with other guidelines to ensure validators get paid the gas fees.

EIP-3074: AUTH and AUTHCALL opcodes (Created 2020–09–04)

This EIP is not an Account Abstraction proposal. It takes a different approach to achieve some of the benefits of account abstraction like sponsored transactions and batch calls. Unlike the Account Abstraction EIPs that aim to allow Contract Accounts to behave like EOAs, this EIP allows EOAs to have contract characteristics by allowing a contract to act on its behalf. The Ethereum Protocol still does transaction validity checks.

It introduces two opcodes AUTH and AUTHCALL and a call context variable called authorization. These opcodes are called in a smart contract known as the invoker. The AUTH opcode is called with an ECDSA signature and the EOAs address called authority as arguments. The signature verifies that authority is giving control to the Invoker contract. If it is valid, the authorization variable is set to authority else it unsets the authorization variable. Any contract call done using AUTHCALL in the Invoker sets the caller (msg.sender in Solidity) to the set authorization variable it is considered an invalid call if authorization is unset. The called contract thus sees its caller as the EOA. This effectively allows the Invoker to act like the EOA and perform actions AA can help us achieve. The gas fees and value sent in AUTHCALL are not deducted from the EOAs balance. The Invoker pays for the value sent with AUTHCALL while the Invoker’s caller pays for all the gas fees. Invoker’s caller is called a sponsor because he helps the EOA pay transaction fees (sponsored transactions).

The Invoker must be secure to prevent it from acting maliciously as the EOA. The Invoker must also not be upgradeable to prevent the introduction of malicious implementation code that can reuse EOA signatures.

ERC-4337: Account Abstraction Using Alt Mempool (Created 2021–09–29)

Unlike other Ethereum proposals we have looked at, this proposal does not propose any consensus changes like new opcodes or transaction types. So it is classified as an Ethereum Request for Comments (ERC). In case you have not noticed, the others were EIPs.

In this proposal, users interact with the blockchain normally. But they do not create a transaction when they interact with their wallets. Instead, they create a UserOperation (UserOp) containing fields similar to a normal transaction. This UserOp is sent to someone called a bundler this can be a block builder or anyone that can send transactions to a block builder or validator. The bundler has a special mempool for UserOps. He is called a bundler because he bundles multiple UserOps into a normal transaction. This transaction calls a function handleOps on the EntryPoint contract passing all the UserOps. The EntryPoint is a contract which serves as the entry point into the blockchain for UserOps. It helps with the validation and execution phases of each UserOp it receives. Each user has a smart contract account and each UserOp is sent to the smart contract account to be validated. If a smart contract does not exist, a contract called, Factory contract creates it. The Factory contract creates the account before the validation begins using CREATE2. During validation, the gas fees have to be paid. The fees can be paid by the user's account or by another account called a Paymaster. The Paymaster has to agree to make payment, so the Entrypoint also sends the UserOp to the Paymaster for validation only after a successful account validation. After a successful validation phase, the account is called with the UserOp’s calldata field for execution. The EntryPoint uses a validation loop to validate all the UserOps followed by an Execution loop. But how does the bundler protect himself from DOS attacks?

The bundler ensures that the UserOps are valid and pays their transaction fees. He also reduces the number of transactions in the mempool that can be made invalid by a single on-chain transaction. This proposal suggests rules that contracts involved in a UserOp (Paymaster, Account, Factory) have to follow during the validation phase. One such rule is not calling forbidden opcodes like DELEGATECALL, CALL, and TIMESTAMP. It prevents the contracts from accessing these opcodes because their effects may change between simulation and execution. Another rule also limits the storage access of these contracts. But it introduces a reputation system that allows these entities to access their storage but also bans or throttles their usage depending on the number of invalid transactions they receive in the mempool.

This proposal achieves account abstraction by letting users send transactions called UserOps which are added to the blockchain after they are validated by their smart contract accounts. This approach is similar to how current smart contract wallets on the Ethereum blockchain like Sequence work.

Takeoff

We have been able to establish what Account Abstraction is, why we need it, how we can achieve it and the various proposals concerning it. Among the proposals, ERC 4337 has seen a lot of buzz at the time of writing this piece. It is the approach Ethereum will be taking to achieve Account Abstraction in the short term. EIP 86 and EIP 2938 have not seen any activity for more than at least six months and consequently have the stagnant label on the EIPs website. EIP 3074 still has some activity but it sure does not look like it will be included in any hard fork for quite some time because Ethereum is more concerned about scaling currently. But ERC 4337 does not require any hard fork to be used by the Ethereum ecosystem and that is why it will be coming faster than the others.

Thanks for getting to the end with me. That was a long read, but I hope you got a good understanding of Account Abstraction and Ethereum’s work in that regard.

You can drop a clap for the article and share if you liked it. If you have any questions, observations or suggestions please do not hesitate to comment.

Thanks @blessingEmah, @m_a_y_o_w_a, @0xdarlington and @nuel_ikwuoma for your help reviewing this piece.