Introduction

“Not your keys? Not your crypto!” is a blockchain mantra. But what do we mean by “keys”? Real-world keys change according to the function they serve. The key for your bike lock is not the same type as the high-security keys for a Brinks truck. However, on Ethereum, all keys have the same structure. Any operation on Ethereum - regardless of its value or the purpose it serves - requires signing a transaction with a seed phrase that should be known to the account owner and no one else. This is a major UX hurdle and a barrier to the mainstream adoption of crypto.

Account Abstraction helps blockchain applications break out of this paradigm. First introduced in a post by Vitalik in 2015, the concept of Account Abstraction is now coming to life on both Layer-2 blockchains such as Starknet and zkSync, and on Ethereum itself through EIP-4337. Account Abstraction delivers the power of web3 with the simplicity and comfort of web2 experience. It constitutes a major milestone towards scaling self-custody.

EOAs on Ethereum and their limitations

Let’s first remind ourselves how crypto accounts work on Ethereum. Ethereum has two basic entities: smart contracts and EOAs (externally owned accounts). An EOA is an entity with (1) an account address, derived from a private key, (2) an ETH balance, for paying fees or sending ETH to others, and (3) an identifier called ‘nonce’, which is a serial number for transactions sent from this EOA, used for replay protection. EOAs are the only entities on Ethereum that can send transactions For a transaction to be valid it must be signed with the private key from which the account address was derived. This means that “owning” an EOA is essentially owning the private key used for deriving the account address.

While smart contracts on Ethereum are fully programmable, the logic used to verify the validity of transactions is not programmable, but rather hard-coded in the EVM (Ethereum Virtual Machine). Valid transactions must strictly follow a set of rules, such as:

Signature scheme. Transactions must be signed using the ECDSA signature scheme, on the elliptic curve secp256k1
Transaction fee. The source of the transaction fee must be the same EOA that initiated the transaction. Moreover, the fee must be denominated in ETH.
Replay protection. Transactions must be sent sequentially by their ‘nonce’ identifier.
The private key is immutable. Since the account address is derived from the private key, it’s impossible to change the ‘secret’ used to sign transactions.

Those rules are embedded into the Ethereum protocol and cannot be changed. They stem from design decisions that optimize for protocol security and efficiency in operating Ethereum nodes. However, they restrict dApp developers from many use cases. For example, when using EOA it’s impossible to let another account pay your transaction fees. This would be a valuable feature for decentralized games that may want to subsidize the first few “moves” of each player. In other cases, blockchain users may want to authorize other users to send transactions on their behalf, perhaps with some limitation on the transaction value or frequency. This too is impossible using EOAs. In addition, while password rotation is a basic primitive in web2, it is impossible to change the password of an EOA, or count on other entities to help you recover your password without giving them full access to your account.

Account Abstraction to the rescue

Account Abstraction is the idea of decoupling the hard-coded logic described above from the EOA, turning all accounts into fully programmable smart contracts. This would provide account owners, wallets, and dApps flexibility in determining how transactions should be signed and accepted, and where transaction fees should come from. In other words, Account Abstraction is the technical infrastructure that enables Smart Contract Wallets.

The concept of Account Abstraction can be split into three categories that correspond to the three main limitations that currently exist in EOAs:

(1) Signer abstraction. Give smart contracts flexibility in determining what a validly-signed transaction is, rather than enforcing ECDSA scheme with a fixed private key as the only acceptable signature. This means that smart contracts could decide for themselves to accept other signature schemes - for example, ones that are more suitable for shared secrets. Contracts could also require different signature schemes for different entry point functions, or even not require any signature at all!

(2) Fee abstraction. On Ethereum, the first thing an account owner is required to do is fill the account with some ETH, so that they can pay transaction fees and start using the account. Imagine a blockchain architecture where dApps could subsidize transaction fees for their users, or let users pay fees in any token currency they wish (and perhaps swap to ETH on the fly); this would solve a major UX challenge Ethereum faces today.

(3) Nonce abstraction. This is a lesser-discussed and more delicate area of Account Abstraction, yet not less interesting. The ‘nonce’ identifier on EOAs provides protection from transaction replay, but it also enforces a transaction model that is inherently sequential. What if a smart contract wanted to accept two transactions in parallel from the same EOA, regardless of their order? This becomes possible when the ‘nonce’ mechanism can be controlled by the smart contract rather than being hard-coded into a generic transaction processing logic.

Scaling self-custody

15 years after the Bitcoin paper, crypto wallets today are still more like high-maintenance friends than the slick products we’d expect them to be. The CEX collapse of last year has taught us that self-custody is the way to go, but managing one’s own keys is still a significant burden and security risk. Even core crypto developers occasionally lose their keys or have them compromised (tweet). Smart contract wallets - operated through Account Abstraction - may be the catalyst for eliminating those risks and driving the mass adoption of self-custody wallets. Account Abstraction makes account management less burdensome through two mechanisms: smarter signing of transactions, and better recovery processes.

First, signer abstraction capabilities allow wallets to embed web2-like features into their products. For example, the Braavos wallet utilizes the secure enclave of iOS and Android devices to allow users to sign transactions with their fingerprint or face ID, without inputting any seed phrases at all. Similar signer abstraction features allow developers to control the security level required for approving individual transactions, case by case. This paves the way to true multi-factor authentication on web3 wallets. Similarly to your online bank account, daily transactions may be executed from a single device, but transacting with new recipients or executing particularly valuable transactions may prompt users to sign on multiple devices.

Account Abstraction also improves the UX of account recovery. Signer abstraction allows having multiple signers for an account, each of them with individual powers and privileges. For example, the major owner of an account may share some lower-privileged keys with friends, in a way that the friends could help recover the main key but not spend any of the assets in the account. This is often referred to as social recovery, and is already implemented in smart-contract based wallets, such as the ArgentX wallet.

Opportunities in crypto payments

Crypto payments are widely discussed as one of the major use cases of blockchain. However, this promise hasn’t materialized yet. Historically, this has been due to costly transaction fees, which are now coming down thanks to rollups and scalability solutions. However, mature payment solutions in TradFi aren’t successful merely because of low transaction costs. They require additional features, such as credit issuance, fraud detection, dispute processes and recurring payment mechanisms.

Account Abstraction allows translating those traditional payment concepts into the crypto space. For example, Visa has recently presented a proof-of-concept for using Account Abstraction for a recurring payment system. Imagine a programmable self-custodial wallet, that authorizes Visa to automatically pull funds (up to some monthly limit) on a recurring basis, without requiring the user’s signature on each transaction.

Gaming UX meets web3

Another area prone to disruption by Account Abstraction is web3 gaming, through batch transactions and fee abstraction.

A major barrier to bringing gaming activity on-chain - beyond transaction costs - is the need to sign a transaction for every on-chain activity. Prompting a user to click the ‘sign’ button in their wallet disrupts the flow of the game and makes the web3 gaming experience quite cumbersome. Account Abstraction allows game developers to create “session keys” that are pre-authorized to sign gaming transactions for a particular timeslot. Such keys could be stored in the browser’s or smartphone’s local storage, and be revoked as needed. This brings the UX of web3 games closer to the familiar experience in web2 games.

In addition, fee abstraction allows game developers to subsidize transaction fees for their users. This is a particularly good method for onboarding new players, who may be new to crypto or may want to experiment with the game before spending transaction fees.

The road ahead

Account Abstraction has always been on the Ethereum roadmap. Ethereum improvements proposals such as EIP-86 (2017), EIP-2983 (2020) and EIP-3074 (2020) paved the way to EIP-4337 (2021), which introduces a new decentralized infrastructure on top of Ethereum to operate smart contract wallets. In addition to EIPs, smart wallets dApps emerged on Ethereum, such as Gnosis. However, all those were second-class citizens to the native account model on Ethereum, the EOA.

The opportunity to fix the limitations of Ethereum and bring smart contract wallets to users may be through Layer 2 scaling networks. Layer-2s such as Starknet and zkSync have Account Abstraction embedded in the protocol level, making it easily accessible to developers through native tooling and infrastructure.

About the Author

Gal Ron is a product manager & blockchain researcher at StarkWare, where he works on building the ecosystem of Starknet, a zero-knowledge scaling technology for Ethereum. He previously graduated with an MBA from Stanford Graduate School of Business, and a Master’s degree in Computer Science from Tel Aviv University.