What Really is Account Abstraction ?

As you know there is hype around Account abstraction and ERC 4337. On the net, you can find many articles describing all its amazing features and telling you why it is a revolution that is going to reduce friction and bring massive adoption in web3 ecosystem. You can also find many other articles that also dive into technical considerations and attempt to explain its architectural details. This article is not like this. In this article we’re not going to talk about what we can do with ERC 4337 or how it works. We are going to talk about what IS the ERC 4337 account abstraction standard. What is a standard? What is an account? What do we mean by ‘abstract’?

At the end of this reading, you’re not going to be expert of account abstraction, but you will get some basic yet fundamental piece of knowledge I wished I had clearly set in my mind before diving into this hot topic.

What is an Account ?

2 type of accounts

The account is the basic brick of EVM ecosystem. It is an entity holding a state and being able to perform transactions on it and on the state of other accounts. The overall state of an EVM blockchain is the sum of all its accounts states.

Each account is identified by a unique 20 byte hexadecimal number called the address.

Accounts are divided onto 2 categories:

• External Owned Account (EOA): This type of account is controlled by an external user (humans or web2 clients) via an ECDSA private key. It can initiate transactions by signing them and pay gas fees but cannot perform complex logic: It can only transfer native coin value, deploy a smart contract, and call smart contract functions. Creating an EOA is free. Among the two types of account, it is the one most closely related to the concept of account as we know it in the traditional Web2 world.
• Smart Contract Account (SCA): This account type is what makes second-generation blockchain like Ethereum different from first-generation blockchain like Bitcoin. It allows executing complex arbitrary logic on custom state. It is not related to an external user; it cannot be controlled by a private key and cannot initiate transactions. Its code can only be triggered by transactions initiated by an EOA or another SCA. Creating this kind of account has a cost because it increases network storage. From a Web2 perspective, we would have called this a program, but from the technical standpoint of the EVM, it is indeed an account.

The Same Structure

Despite their difference, both EOA and SCA have, according to a technical point of view, the same structure which is composed of 4 fields:

• nonce: For an EOA, this integer is a counter of the number of transactions performed by the account. It is a protection against replay attack, preventing malicious actors from re-executing several times a signed transaction. For an SCA account, the nonce represents the number of smart contracts it has created.
• Balance: The number of wei owned by this account.
• codeHash: If account is a smart contract, this field corresponds to the hash of its EVM code. This code can be retrieved from a database via the codeHash. If the account is an EOA, then this field is the hash of an empty string. It is the only field that cannot be changed.
• StorageRoot: A SCA can have a custom state (variables, arrays, mappings …). This data is encoded via a Merkle Patricia tree whose root hash is stored on the StorageRoot. This field is changed each time the storage has been modified by a transaction. This field is empty for EOA.

Currently, there are 2 account implementations in EVM space, with both their pros and cons. Smart account goal is to abstract these differences to have the best of both worlds.

What is a Standard ?

Nothing new with ERC 4337 ?

When I first heard about account abstraction, I had a misconception: As ERC 4337 was depicted as a revolution, I felt it should involve some cutting edge, complex and mysterious technology, or paradigm like ZK or MPC. But as I was digging into the subject, I realized that ERC 4337 was just a smart composition and customization of already existing concepts : gasless transaction (gas stations network which implement ERC 2771), transaction batching (Like Ambir wallet ), multi sign (like Gnosis Safe wallet ), social recovery (like Argent or Loopring wallet)…

And this is one of its biggest strengths compared to previous account abstraction EIP (EIP-86, EIP-2938…): There is no need to change the consensus layer protocol.

But at first, this fact got me confused. Why should I need to use ERC 4337 in the first place? I mean, if I want to bring custom logic to my account, I already have the possibility to deploy a smart contract implementing all features I wish my EOA had (multi signature, transaction batching, transaction scheduling, spend threshold…) and consider it like my account. If I need gasless or token paid transactions, I could use the Gas station network.

This was one of my first thoughts when I read about ERC 4337. Then I recalled what an ERC is. The goal of an ERC is to propose a new standard for smart contract development (for difference between ERC and EIP look here). The merit of ERC 4337 is to gather several unrelated already existing concepts into the concept of « account abstraction » in a standardized way. To grasp a better understanding of the importance of standards and ERC 4337, let us take a well-known example: the ERC 20 token standard.

ERC 20 standard example

When we talk about fungible tokens, we often think of the ERC 20 standard. But ERC 20 is not the only existing standard for developing fungible tokens. Indeed, there are plenty standards that implement the concept of ownership and transfer of non-differentiable virtual entities: FA1.2 on Tezos, ERC 777, …

In fact, a fungible token does not even necessarily need to follow a specific standard.

To allow an account to transfer its token to another account, the ERC20 use this function signature:

transfer(address to, uint256 value)

But nothing prevents you from deploying a fungible token having different transfer functions:

• transfer(uint256 value,address to)
• transfer(address to,int value)
• transfer(address from, address to,uint256 value)
• send(address to,uint256 value)
• …

As long as your custom function allows transferring funds from the sender to the receiver, it performs more or less the same feature as the ERC20 equivalent.

This is great so why using ERC20 anyway ?

Well, first, designing a new fungible token architecture from scratch is a waste of time and energy since you already have one.

Secondly, because your own custom token implementation may not meet the same security and gas optimization requirement as a widely used, battle tested token standard designed and discussed by multiple ecosystem experts.

But more important, if you do not use a well-known token standard, nobody will use your token. How could a wallet enable fungible token feature if each token contract had a different interface? For each token it would have to implement a specific interaction logic.

This becomes even more tricky on chain where the contract size has to be optimized.

For example, look at this Uniswap V2 piece of code :

See how fungible token transfer is handled easily by using the function selector of ERC20 standard transfer function. Imagine if developers had to handle a specific function selector for each custom signature of transfer function. In fact, there would never have been DeFi.

Benefit of using standard

To sum it up, ERC 4337 brings to account abstraction following benefits:

• Efficiency: As a developer you do not need to reinvent the wheel to implement an account abstraction
• Performance: This standard has been designed and reviewed by several experts. It has been thought to avoid gas costs and code complexity overhead.
• Security: Same thing for security. Using an architecture that has been meticulously crafted and scrutinized by multiple professionals is less prone to unexpected bugs and flaws.
• Interoperability: Account abstraction is a far more complex and wider concept than fungible token. Thus, the need for standardization to avoid the proliferation of several incompatible implementations.
• Wide Adoption: A recognized standard reassures new users and lowers the barrier entry for newcomers by providing architecture and implementation templates to them.

What is Abstraction ?

What do we mean by « abstract account »? What does abstraction even mean in the first place?

Well, abstraction is usually considered as the process by which we filter features of something (A concept, a physical object, a phenomenon …) to select only those that are relevant for a specific purpose and omitting unnecessary details. « Abstraction » is also the name given to the result of this process.

This definition may seem a bit … abstract?
Let us give some practical examples:

Consider the following images.

What do they have in common?

Well, we can notice that all these figures have:

• A perimeter
• An area
• A certain number of angles
• …

All these common features can be grouped into an abstract concept one can name « geometrical shapes ». From various and diverse entities (Square, triangle, circle, …), we can create the abstract idea of « geometrical shape » by considering only certain properties and ignoring others (Having a diameter, having parallel sides …).

By the same process, the concept of « primate » is an abstraction of several species (Human, gorilla, …) built by selecting a set of properties such as prehensile five-digit hands and short muzzle.

Another example, more related to the crypto topic, is the concept of money. During human history, the word “money” has been used to qualify quite different realities and concepts such as salt, seashell, gold/silver/bronze coin, fiduciary currencies like euro and dollar, crypto currencies like bitcoin …

All these things have been or are used as money

What do these highly heterogeneous elements have in common that allows us to abstract them together under the term ‘money’?

Well, beyond their difference, they share 3 essential features that made them suitable for being called money. They all have been used as:

• A medium of exchange
• A store of value
• A unit of account

By focusing on these 3 abstract features, we abstract the concept of money, and we obtain a more generalizable and functional definition that reflects all various concrete implementations.

Abstraction in computer science

In computer science, abstraction consists in hiding all technical aspects that are not relevant to the functional scope of the user.

For example, programming languages are abstractions since they hide low level details about how data is represented and computed on the hardware; allowing the developer to focus on more high-level tasks.

Think about the concept of « variable ». There is no such thing as a variable on your physical machine. You have ram, register, stack, heap, cache…
But not variables.
A variable is a handy abstraction for referencing and editing a piece of data stored somewhere in the memory without having to handle low level assembly instructions.

Consider this C instruction:

int a = 1 + 2;

Once compiled, this instruction will produce a different machine code depending on the processor architecture. The same instruction compiled for two different processors will give two different machine codes. Yet both machine codes perform the same functional task, which is adding two numbers, storing the result as a 4 byte (probably) value somewhere in memory and keeping track of its address. This line of code hides these hardware considerations and emphasis on more high-level features.

In the same way, one can say that no code tools add another layer of abstraction by hiding programming languages behind a non-developer friendly interface.

Abstraction of EOA

So far, we have seen that abstracting something consists in reaching a more general definition which hides concrete implementation details and focuses on core essential features.

How does this apply to abstract accounts?

First of all, let us identify what could be considered as the core features of a blockchain user account:

• Authentication: Ensure that only the account owner can control it.
• Paying the network: Pay fees for hardware and network usage necessary to perform global state changing transactions.
• Value Ownership: Store securely all kinds of valuable digital assets: native coin, tokens, NFT …
• Interact with other accounts: Initiate and order transactions (send native coin, call a function) to other blockchain accounts, may it be EOA or SCA.

Until smart accounts, these features had a single implementation: the EOA.

As shown in the table below, account abstraction allows new implementations of these features, which leverage security, flexibility, scalability, usability …

Until now, the notion of user account on EVM blockchain was confounded with the concept of EOA. Account abstraction allows us to generalize the concept of user account to new implementations. Some technical aspects such as seed phrase or gas payment are no longer essential. They are abstracted away the same way web browsers hide IP address and TLS handling to users. This enhances user experience and eases adoption.