Four Shades of Account Abstraction

The Ethereum community is notoriously bad at naming things.

One such example is “account abstraction”. What exactly does account abstraction mean? Well, I think Will Ferrell puts it best:

Account abstraction has evolved a lot over time and is used to mean a lot of things.

The term more or less originated in a blog post by Vitalik Buterin titled “On Abstraction” in July 2015. In it, he explored how Ethereum provides a lot of abstraction for developing various applications, but does not provide abstraction natively for accounts. Transactions must be signed using the ECDSA algorithm. Account abstraction is, then, the blockchain allowing accounts to use any arbitrary verification logic.

Interestingly, Vitalik never uses the term “account abstraction” in this post.

Enabling this flexibility is a big task, and eight years later transactions still require ECSDA signatures. However many aspects of user accounts have been abstracted with smart contracts, even if a protocol transaction still requires an ECDSA signature.

Many early smart contract wallet developers argue that they have had account abstraction all along. After all, they allow verification logic to be customized even if an ECDSA signature is needed to initiate the transaction. However many protocol developers disagree, because the blockchain still requires the ECDSA signature.

This disagreement is exacerbated by the fact that “account abstraction” is, frankly, too vague to be useful. When viewed from the perspective of the blockchain, account abstraction means that the blockchain doesn’t specify what an account has to look like. When viewed from the perspective of a user or app developer, account abstraction means that users don’t need to have a private key.

This is why I prefer the term Smart Account. It doesn’t hold all of this baggage and is more inclusive because it is from the user’s point of view.

But, as long as the term account abstraction is used, I think it’s useful to categorize the many incarnations of abstracted accounts to improve clarity.

In my view, there are four shades of account abstraction:

1. Non-Native: A user has a smart contract wallet, but they still need their own private key to submit transactions on-chain.
   Example: Gnosis Safe
2. Semi-Native: User doesn’t need a private key because a trusted relay network can forward transactions to the blockchain.
   Example: Safe using Gelato Network, Biconomy’s previous gasless transaction service
3. Semi-Native+: User doesn’t necessarily need a private key because a trustless relay network can forward transactions to the blockchain.
   Example: ERC-4337
4. Native: Users don’t need a private key because the blockchain directly allows accounts to specify their own validation logic.
   Example: ZKSync

The jump from Semi-Native to Semi-Native+ represents a significant improvement, despite the seemingly minor distinction in names, as it introduces censorship resistance. This means users can enjoy the benefits of account abstraction without making additional trust assumptions. This is a difficult task, and what makes ERC-4337 exciting.

There are other benefits to the Semi-Native+ approach taken by ERC-4337. In particular, it provides a standard for smart contract wallet operations and helps us figure out how Native account abstraction should be done.

There is no doubt, however, that Native account abstraction is the endgame. It will likely take a couple of years, but ERC-4337 helps us get there.

‍