This article reviews the main principles behind account abstraction to better understand its potential. It discusses Ethereum accounts and their limitations, provides a simple definition of account abstraction, explains why we're talking about it so much, what it enables, and gives a glimpse into its future.

Inspired by the 3-Part series made by Julien Niset from Argent called “WTF is Account Abstraction” https://www.argent.xyz/blog/part-3-wtf-is-account-abstraction/

An Ethereum account allows one to use the blockchain. There are two types of accounts: contract accounts (or smart contracts) and EOAs (Externally Owned Accounts).

Contract accounts are deployed on Ethereum in an immutable way and allow the use of the blockchain through their programmable functions. EOAs allow to interact with Ethereum and its smart contracts via wallets (e.g. Metamask) that act as interfaces with the blockchain. We focus here on EOAs: user accounts.

An EOA has the following characteristics:

• Balance: amount of assets in the account

• Nonce: incremental parameter to check that transactions are done in the right order

• Address: hexadecimal sequence of 42 characters (0x...n) for identifying the account

Each EOA is assigned a signer. It is a cryptographic object composed of a pair of public and private keys (or "keypair"):

• The public key allows the identification of the wallet. It is from this key that we derive the public address of the account when it is created. (NB: the Ethereum address is derived from the last 20 bytes of the public key hash, by adding "0x" at the beginning)

• The private key is used to sign digital messages and to prove that you are the wallet owner, i.e. to prove that you can perform transactions (for example send money or interact from this account).

NB: It is possible to derive the public key from the private key according to the ECDSA model, but the reverse is impossible.

Today, on Ethereum Mainnet, an EOA is indistinguishable from the signer. It represents a limitation at the protocol level that affects the user experience and account security in several ways:

• There is only one private key per account; losing your private key means losing access to your account and all your assets.

• Protecting your private key, by hiding the 12 or 24 words that make up the seed phrase, is both sensitive and complex, even for advanced users.

• The signature model (ECDSA) is limited and not quantum-resistant.

• This same signature model is rigid: it cannot be modified at the will of the user or applications.

• The account must pay gas for each transaction, in the native token (ETH). This limits the user experience and privacy.

Solving these limitations seems urgent for several reasons: first of all, quantum computing is developing rapidly and could challenge the security of Ethereum accounts (by making the ECDSA signature model obsolete). But it is also and above all the perpetuation of bad practices for years that slow down the adoption of the technology by scaring users or pushing them to turn to centralized solutions.

Account abstraction is an alternative to the current user account model that addresses the limitations discussed above. In computer science, abstraction consists of removing, separating, or isolating characteristics of an element to reduce it to what matters the most.

The account abstraction consists of a transformation of the EOA into a smart contract, allowing to isolate the signer from the other elements of the account. This smart contract allows one to mimic the main functionalities of an account, i.e. to validate and execute transactions, and to add programming and customization capabilities.

The management of this new type of smart contract is done through smart contract wallets (such as Argent or Safe). For years, they have been used to emulate a form of account abstraction: that is, they implement the features of the account abstraction, without changing the Ethereum protocol. There are still EOAs, but some of the complexities are hidden. For example with Argent, a pioneer of smart contract wallets, each user has a secret EOA on their phone set as the owner of the smart contract. The management of the private key is abstracted thanks to a social recovery model.

Cf. Vitalik Buterin via "Why we need mass adoption of social recovery (enabled by account abstraction) https://vitalik.ca/general/2021/01/11/recovery.html

However, smart contract wallets are considered second-class citizens because Ethereum was designed to interact with EOAs and not smart contracts; each application needs to be customized to interact with smart contract wallets (see EIP-1271 and the isValidSignature function).

Account abstraction allows great improvements in security and usability, and opens the door to an infinite number of use cases, including:

• Social Recovery: enables you to abstract the complexity of private keys’ management by permitting you to reset a wallet from other entities (accounts, hardware wallets, users).

• Multicall: allows to group several operations and submit them into one (atomic) transaction to save gas, perform several operations in one draft, or schedule conditional transactions.

• Fraud monitoring: allows multi-factor validation (e.g. 2FA) with multiple signatures to interact with certain smart contracts or perform certain types of operations.

• Session keys: gives the possibility to authorize a smart contract to perform a set of actions during a given period.

• Custom gas management: allows users to avoid paying for gas for each transaction. Would also allow users or applications to pay for gas in any token or fiat currency.

• ...and many more.

The great strength of account abstraction is that it makes it possible to customize user account settings, including the signature model, which increases the scope of possibilities tenfold.

We have been talking about Account abstraction since the early days of Ethereum — Vitalik, among many others, is a strong advocate of it. Historically, EOAs were designed to favor the self-custody of your private keys to maximize the decentralization of the network.

Several proposed protocol updates have been devised to implement account abstraction on Ethereum: EIP-86, EIP-2938, EIP-3074, and the most recent EIP-4337.

EIP-4337 consists of making it easier to develop and manage smart contract wallets by mutualizing the infrastructure needed to run them. With EIP-4337, users no longer send transactions directly to the network. Instead, they submit transaction "intents" to a mempool, which are picked up by bundlers who verify, execute and submit the transactions to the EVM. Paymasters may be designated to fund gas fees. The specifications for this EIP have been defined and its implementation is underway.

Additional resources:

• Account Abstraction Implementation Roadmap https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap?utm_source=substack&utm_medium=email#Transaction-inclusion-lists

• History of EIPs on account abstraction https://hackmd.io/@matt/r1neQ_B38?utm_source=substack&utm_medium=email

In addition to these Ethereum protocol developments, the release of scalability solutions today represents a boon for account abstraction that can be implemented natively and at a large scale.

On Ethereum, we still use EOAs or smart contract wallets that mimic account abstraction. Implementing it on Ethereum, like any change in the protocol, would represent heavy and complex changes. But as Vitalik showed in his updated Ethereum roadmap, the “Account Abstraction Track” is already well underway and we should expect it to accelerate in the coming months.

Layer2 (L2) scalability solutions like Starknet and Zksync v2 support account abstraction natively. It will be fascinating to study the developments of account abstraction on these and perfect the model proposed by EIP-4337. We expect other L2/blockchains to follow suit.

However, in a world where 99% of the Ethereum activity happens on L2 (cf. Rollup-centric roadmap), the need for account abstraction on mainnet might be reduced. But if we move towards a world where chains/rolls are EVM compatible and/or equivalent, then it will still be necessary to bring this innovation to the Ethereum mainnet. On the other hand, if Ethereum adopts the account abstraction on mainnet, the majority of L2s will have to follow... 🐓🥚

The recent FTX bankruptcy highlights once again the need for self-custody solutions that allow us to emancipate ourselves from centralized solutions and secure our assets without third parties. Account abstraction, which positions smart contracts wallets as the standard for self-custody, appears to be the next logical step for accounts and wallets on Ethereum; but not only.

Feel free to reach out on @NathanSexer, share, and subscribe if you enjoyed it!