What is an account?

An account represents a user onchain, and enables that user to interact with the blockchain.

Through an account, you may send transactions and interact with other contracts. To "own" an onchain asset (e.g. ERC20 token or an NFT), it has to be associated with your account address.

Ethereum account structure

Within Ethereum individual user accounts are known as Externally Owned Accounts (EOAs).

EOAs differ from smart contracts in that they are not controlled by code. An EOA is determined by a pair of private and public keys.

The account’s address is derived from those keys and only by possessing the private key can you initiate transactions from an account. While Ethereum contracts are passive, that is, they can only change if they were called inside a transaction, EOAs can initiate transactions.

While simple, EOAs have a major drawback – there’s no flexibility in the account behavior, i.e. the Ethereum protocol dictates what it means for a transaction initiated by an EOA to be valid (the signature scheme is fixed). In particular, control over the private key gives complete control over the account. Although this is theoretically a secure method of account management, in practice it has some drawbacks, such as requiring you to keep your seed phrase secure yet accessible to you and limited flexibility surrounding wallet functionality.

EIP-4337, a design proposal for Ethereum outlines account abstraction whereby all accounts are managed via a dedicated smart contract on the Ethereum network, as a way to increase flexibility and usability. You can add custom logic on top of the basic EOA functionality, thereby bringing account abstraction into Ethereum.

What is Account Abstraction?

The idea behind account abstraction is to allow more flexibility in the management of accounts rather than have their behavior determined at the protocol level. This can be achieved by introducing account contracts - smart contracts with programmable logic that determines the user’s account.

Using account abstraction you can now program how your account functions.

For example, you can:

Determine what it means for a signature to be valid or what contracts your account is allowed to interact with. This is known as "signature abstraction"
Pay transaction fees in different tokens - this is sometimes known as "fee abstraction"
Design your own replay protection mechanism and allow sending multiple uncoupled transactions in parallel. Compare this to the sequential nonce solution used in Ethereum, which results in transactions being inherently sequential, i.e., even if you want to send two transactions in parallel, you must wait for some confirmation on the first before sending the second. Otherwise, the second transaction may be rejected due to an invalid nonce. With account abstraction, one can discuss different solutions that bypass the need for a sequential nonce. This is known as "nonce abstraction"

Today, Starknet offers signature abstraction. In the future, we will enrich the current account abstraction design (see e.g. the paymaster proposal for fee abstraction).

Examples of customizing account functionality

Two examples of how you might program an account to function using account abstraction are:

Social recovery: A process where if you lose your wallet, you are able to retrieve it via a selected social network, vastly improving the typical experience of wallet recovery.
Operating your account via facial recognition: With signature abstraction, you can use your phone’s native hardware to sign transactions, making it practically impossible to take control of another user’s account (even in the case of the phone itself being stolen).