If you’ve been following Vitalik on Twitter (or me, but that’s much less likely...) you may have heard about account abstraction. Vitalik says implementing it has been a long term "dream" for Ethereum developers. And he's made several proposals to do so.
Maybe you've also heard that both StarkNet and zkSync, two leading Layer 2 solutions, have announced that they'll launch with native account abstraction.
But WTF is it?
And why is it a game changer for crypto's adoption?
I'll try to answer these questions in this short series of blog posts. This first post covers Ethereum accounts and highlights some of their limitations. This leads to account abstraction and how it solves these problems.
In summary, account abstraction moves crypto from the current approach of one-account-fits-all, where someone can lose everything with a small mistake, to a future where an account can be tailored to someone's needs. Where you can build a safety net for self-custody. And give them much slicker UX too.
This gets us so excited because it makes self-custody a viable option for a mainstream audience. An alternative to a scary world of seed phrases, or only relying on centralized exchanges.
Let's dive in.
How do Ethereum Accounts work?
To understand account abstraction we first need to understand how accounts work on Ethereum today.
There are two types of accounts on Ethereum:
- Externally Owned Accounts (EOA)
- Contract Accounts (CA).
In this post, we’ll focus on EOAs as they're the ones that matter most to users (for now). I'll sometimes simply refer to them as Accounts. You can read this if you want to know more about Contract Accounts.
As the name indicates, EOAs are accounts owned by something external to the blockchain - namely, users.
EOAs have three properties:
- A balance to represent the amount of ETH available to the account
- A nonce to ensure that every transaction is unique
- An address to uniquely identify the account on the network
The state of the blockchain, hence the state of an account, can only be modified through transactions. This trigger must come from something external to the blockchain, hence on Ethereum, every transaction must be initiated from an EOA. That means that when a transaction is executed by the Ethereum Virtual Machine (EVM) the first account being touched must be an EOA and the corresponding account must pay a fee to the miner for the execution of the entire transaction.
How do you prove account ownership?
There must be some kind of authorization to prevent anyone from using the ETH of your account, right?
Here's where things become interesting!
Every account on Ethereum is associated with a cryptographic object called a signer.
A signer, also called a keypair, is made of two keys: a private key and a public key.
The private key, a.k.a. the secret, can be used to sign digital messages, and the public key can enable anyone to verify that a given signature was signed by its corresponding private key. All the complicated math behind the cryptography guarantees that if I give you my public key you have no way to derive my private key, and if I give you a message signed with my private key you can be sure that I’m the only one who could have signed.
There exists multiple ways to generate cryptographic signatures based on keypairs. Ethereum uses a specific signature scheme called ECDSA on a specific elliptic curve called Secp256k1.
How is an account associated with a signer? Through the account address.
The address of an EOA is derived from the public key of a signer. More specifically, the address is the last 20 bytes of the Keccak-256 hash of the public key.
The owner of the account can thus authorize a transaction from its account by signing the parameters of the transaction with the corresponding private key. Upon reception of the transaction and the signature, the EVM will verify that the signature is valid for the target account, verify that the transaction nonce matches the account nonce, execute the transaction, and deduce the transaction fee from the account balance.
Let’s recap what we have learned so far
An account on Ethereum is made of three components:
- A state containing a balance and a nonce
- Hardcoded logic in the EVM to validate and execute a transaction from the account
- An address
We also know that the account is tightly coupled to a signer (keypair) through its address, which is derived from the public key of the signer, as well as its hardcoded logic which specifies exactly what is a valid signature from the signer.
The last point highlights a very important design choice of the Ethereum blockchain: the concept of Account (the object holding your tokens) and the concept of Signer (the object authorized to move these tokens) are basically the same thing! If you have a private key you automatically have an account at the associated address, and to own an account at a given address you must be in possession of the corresponding private key. That logic is hardcoded at the heart of the EVM.
That approach has the benefit of being simple to understand and simpler to implement. It’s also very easy to get started: simply generate a keypair on your computer and you are good to go.
And, more importantly, you can say catchy phrases like “Not your keys, not your coins”!
But this coupling of accounts and signers has also a lot of problems.
What if you lose your private key or someone else has it?
Because your private key is your account, losing your key means losing your account.
Even worse, if someone else has your private key they also have your account... and all the tokens it contains. And there is nothing you can do about it!
Hundreds of millions of dollars, if not billions, have already been lost or stolen because of a loss or theft of private keys.
Sure, you can use a hardware wallet, write your private key on a piece of metal, and store it in a safe. This was ok for the early adopters of the technology. But do we really believe that this experience can scale to billions more users?
What if you want to use a different signing scheme than ECDSA, or use a different elliptic curve? We know that quantum computers are coming and can break ECDSA.
Can we do better?
Yes, we can. And it’s simple to understand.
Let’s decouple the object holding your tokens (the account) from the object authorized to move these tokens (the signer).
How do you do that?
Turn accounts into smart contracts with their own logic to define what a valid transaction is. The only requirement is that they comply with a specific interface with methods to validate and execute transactions.
In computer science lingo we say that the account has been abstracted, hence the term: account abstraction.
And we can immediately see why it's so powerful. It’s no longer one-account-fits-all-use-cases. Instead, each user can have an account that is adapted to their needs.
- Do you want to use a different signing scheme than ECDSA? No problem, you can write an account for that.
- Do you want to use multiple keys to authorize transactions? No problem, you can write an account for that.
- Do you want to change the signer of your account every week? No problem, you can write an account for that.
The possibilities are endless and I’m looking forward to seeing what new use cases will emerge on chains that support account abstraction such as StarkNet and zkSync 2.0.
In part 2 of this series, I will discuss some concrete examples of features that are uniquely enabled by account abstraction and show why we believe at Argent that they are a game-changer for the adoption of blockchain technology.
