Account Abstraction: an Overview

User experience is arguably at the very core of product growth. May this be one buying a car, choosing a donut to eat, booking a hotel, or registering for a blockchain wallet.

In the digital space, or generally, anything dematerialized, all users have to consider and be considering is their product experience. While the internet as a concept and the implication of its underlying technologies and product is still somewhat difficult to grasp for most of us (let’s propose that our generation have yet to discover what an internet-enabled data-gatherer warmonger waging international armed conflicts looks like), the navigation of the blockchain space may be ever more daunting for most. Where the benefits of such a technology are tremendous, should anyone be able to interact with Web 3.0 infrastructure, without being “crypto-native”, having bitcoins, or knowing anything about blockchain altogether?

The main difficulty with blockchain is developing a full understanding of how blockchain works, core mechanics and expressions of blockchain transactions rules, how to get started with blockchain interaction through managing an Externally Own Account (EOA), currency buy and conversion, what blockchain to choose, what coins to buy, non native token, ecosystem bridges, et more. This represents several friction points for its adoption.

That’s precisely what crypto-engineers have been working on. Where the fund custody simplification has been on the table for a while now (from 2017 onwards, with Ethereum Improvement Proposals (EIP) such as EIP-2938 and EIP-3074, which haven’t (due to implementation paradigm or circumstances?) found much traction but most controversy), some proposal recently got adopted by the blockchain Ethereum, which could represent a conceptual paradigm shift for the crypto-space: The EIP-4337, or “Smart contract wallets”, or again “do it without consensus layer changes”, or as most love to phrase it: “The key to crypto mass adoption”.

To understand what Account Abstraction means, let’s have a look at the taxonomy:

Account

What is a blockchain Account? Think of a blockchain account as a digital entity that holds some cryptocurrency funds. An account is defined by the following combination of elements: A public key (like account number?), A private key (the password you use to gain access to the account data and resources), An address ( derivative of the public key ), which is an identifier: the location of the account on a given blockchain, A nonce, or pseudo-random number for various utilities, A balance, that is an amount not null of cryptocurrency. ( a minimum required to interact with the blockchain due to interaction costs (gas)). These criterias create a blockchain identity that may initiate transactions on a given ledger. Note: A concept is important here: The Signer, and the Account. The Signer is an entity authorised to transact, that is interact, and spend funds on a given blockchain, represented by a combination of public and private keys. This is different from and Account, an entity holding the funds, where the capital rests.

Typically, today there are two types of blockchain accounts :

Externally Owned Account (EOA):

Ethereum accounts generated using wallet software - Entity managed by a human, freely created, at no cost. It is entirely controlled by the user’s private key. It represents the first touch point for initiating any network transaction, that is “ a signer-linked-to-account spending cryptocurrency for something to happen ”. In EOA, The Signer concept is merged with the concept of Account > the lost or theft of a signer key means the loss of the funds. It is literally like losing all one’s savings if you were to forget a password. To some, this basic risk mitigation would outweigh the enablement of crypto technology. Users have to bear wallet security management, and human usually sucks at managing any electronic stuff, let alone digital, let alone cloud-based - like a safe deposit connected to the whole wide world, where internet connection basic security still represents a black hole for most. It also has limited capabilities, where EOA are merely receptacles for digital capital, and effectively create digital signatures to sign transactions on demand. Interaction with the blockchain ecosystem is only made possible if users have enough digital currency. The question is: How to safely scale, ease and empower self-custody?

Contract Account (CA):

Ethereum accounts deployed as smart contracts - They are entities managed by code on a blockchain. This is like an automated account or wallet - the account has a programmable behaviour (arbitrary logic) as a published artefact. It is usually dissociated from the one-person-owner-self-custody schema and tends to represent a service account to enable some transactional processing (like shareholders’ funds management, organisational safe, etc). Code is the limit of its capabilities. Rules of pre or post-transaction handling, with predictable and deterministic behaviour. Contract Accounts are deployed on-chain, therefore requiring a certain amount of crypto-currency (provided by an EOA) to create and interact with, beyond the costs of whatever the account behaviour would automate.

Eventually, smart contract accounts offer much more possibilities than EOA. Would it be possible to transfer functionalities such as signature verification, gas payment, and more out away from the core protocol and into the Ethereum virtual machine? The idea of combining the two account types sounds promising - and this is where the innovation takes place: termed account contracts: special-purpose smart contracts defining and managing a user’s Ethereum account - that is, a real self-custodial smart contract wallet, on-chain. Where the internal rules of the user wallet would be immutable, standardised, and evolve with full transparency (an issue for some regarding current wallet software). This may be the beginning of the very end of self-custodial wallet off-chain (EOA). As early as the EIP-3074, opcode AUTH, and AUTHCALL would allow a smart contract to send a transaction on behalf of an EOA.

For you to appreciate the basic idea of abstraction and EIP-4337, let’s run a naive non exhaustive comparison:

Conventional

A conventional initiation to a blockchain ecosystem set up goes like this:

• user chooses a wallet account solution
• user creates an account
• user handles private key security and back up
• user chooses a marketplace, register, purchase token funds
• user transfer funds from market place to EOA = transaction + fees
• funds are received on EOA, we are ready to play with the blockchain!

A conventional blockchain transaction goes something like this :

• First, Bob want to send some crypto-currency to Alice

SIGNING

• Using public/private key, the EOA account signs a transaction > creates a digital signature

status : initiated transaction

BROADCASTING

• Digital signature sent to network > a first node intercepts it.
• The node records the transaction proposal and performs an initial verification.
• If valid, broadcast it to the entire network
• Each network node verifies the transaction
• When considered valid, the transaction proposal is stored in each node mempool (space dedicated for valid but yet unconfirmed transactions).

status : 0 confirmation transaction (UTX0)

CONFIRMATION

• Some miner ( specialised for block creation ) nodes start gathering and processing transactions proposal from mempool by incorporating them into a block (mining competition based on mathematical calculation or staking threats, and transaction fee incentivization)
• The selected block is propagated to all nodes on the network for validation, to update their local copy of the blockchain, enforcing / ensuring consensus Each node validates the transactions within the block (protocol compliance) and removes block transaction proposals copies from their own mempool If the block is found valid by consensus, it is added to the given blockchain Miner is rewarded

status: confirmed transaction

Abstraction

or “the quality of dealing with ideas rather than events”

The question should be: What is being abstracted and where does the abstraction occur? On a network level, “account abstraction” translates to the types of account transacting not being of any importance to the protocol. Every account is eventually a smart contract, with the above-mentioned benefits. For users, the complexity of managing EOA and these blockchain technology high friction points mentioned is concealed behind meta-interfaces. The goal is to hide away the details of interacting with a blockchain. Therefore, forget about the EOA initiation phase and any blockchain usage friction points. The idea is that users can generate a wallet address on the app (like an EOA public address) and immediately start to accept funds. This EIP-4337 proposal guidelines some meta concepts such as function calls, entities, and more, using a pattern playing with the following components: UserOperation, Bundler, EntryPoint Contract, and Account Contract (note: some implementations have been on-chain for a while and battle-tested).

Let’s paint the proposal procedure with broad stroke:

• First, Bob authenticates to some decentralised app ( dApps ), conventional web applications being Web 3.0 enabled. This app accepts social login, credit cards, and so forth. Bob clicks to show intent for action, example send some crypto-currency to Alice.

First

I am a Sender - an account contract having the capability to send a user operation, ie. the account making the operation.

Creation of a UserOperation (pseudo-transaction objects), that is: an instruction for what a user wants to do. This captures the user or app intent (effectively, the originator of the request). It is similar to regular unconfirmed transactions as it contains parameters like the sender (eg.signer), call data, nonce, and signature, with additional fields necessary for validation, gas payments, optional payment subsidization details, etc.

Second

Bundlers, effectively validator nodes ( ie. block builders, a class of actors ) gather UserOperation objects in the form of a handleOps call. Multiple things are happening at this stage: bundlers are incentivized to run simulations to ensure that a UserOperation won’t revert ( indeed, bundlers are compensated when the UserOperation object is handled, validated, and executed ). These simulations- (simulateValiation() function using RPC endpoints and the likes) look at the validity and configuration of UserOperation, ie. 1. validate the operation signature 2. Funds necessary to pay for execution, 3. Operation would execute as planned (ie. run an opcode simulation). If successful, the nodes submit the UserOperation to an alternative mempool. Like above, this is similar to a waiting room for transactions awaiting to be processed. If successful, “UserOperation” can be picked up with other by any Bundler, which packages (bundles) a multitude of UserOperations together. The bundler then performs a function call to an handleOps() function with the prepared bundled transaction on a “processing” smart contract entity, called EntryPoint, for execution. All further transaction and account dwelling responsibility is handed off to this entity.

Third

Entry point - It is a smart contract that handles the verification and execution logic for transactions. It alone interacts with the user’s smart contract wallet. (FYI: For now, only one EntryPoint contract exists on the Ethereum blockchain). When bundled UserTransaction is received by the EntryPoint.handleOps(), multiple processes are happening. First, handleOps() checks that whatever payment subsidiary has enough deposit within the entry point contract to cover the costs of processing the transaction, and that this subsidiary is willing to do so. Then, a verification procedure calls a special function validateUserOp on each account to recognize, identify the UserOp with the contract wallet, and requests the validation of the operation signature, checks it is not already executed, and more.

An Execution loop is launched: The handleOps submits the UserOperation payload (call data) to the contract account. ExecuteUserOp() function to run the transaction.

And it’s kind of done!

Note that some parts of the above mentioned are general implementation workings for such a pattern, while other components such as the EntryPoints behavior are already live and processing data. In all, this draws out a pattern for processing secured transactions, and abstract away the need for EOA.

The freedom around this pattern offers tremendous opportunities. EIP-4337 proposes guidelines for contract development standard providing core directives on how to handle fees, and interact with off-chain web 2.0 a.k.a normal internet infrastructure. With smart contract wallets, as mentioned above, remember that the code is the limit! Hence, important questions come into play : can we decouple the relation between a Signer and an Account? Should the implementation modality of custodial or interactive tooling be a choice for blockchain users?

Such possibilities would enables most of the following:

• Authenticate users with social platform logins to web 3.0 infrastructure
• Enable a wide range of meta security features like freezing, recovery patterns ( social recovery, proxy, etc), transaction limits and more.
• Offset or subsidies gas fees? Sponsorship (paymaster pattern)?
• Batch complex operations together (remove user atomic transaction control burden)
• Automatic, schedule, recurring payments? Imagine setting the rules and behaviour of your Web3 (bank) account.
• Added Security? Like authorization entity (Signer) rotation, revocation ? multiple transaction Signers? Automated multi-signature operations? Other efficient signature algorithms (Post-quantum, BLS)? The choice of elliptic curve? Various signature scheme?
• Phone security modules holding cryptographic keys? Critically, where the wallet is generally what links a user to a product (acting as identity verification) in the blockchain space, this and other possibilities would potentially mean uninterrupted user experience.

The above could make the user experience with Web 3.0 very much “Bank-Like”. Entrepreneurs would now potentially be able to build blockchains enabled Application, without users knowing anything about crypto. Sounds promising? The following months shall see multiple products officialising their implementations and approaches. Stay tuned!