Ethereum Account Abstraction – Everything you need to know

Ethereum is at the forefront of the crypto charge, and Ethereum account abstraction might be a key aspect of bringing it to the masses. But what is it precisely, and what makes it necessary?

Many see the network as the future of blockchain finance, as it holds several advantages over Bitcoin. It is the first blockchain to support smart contracts and the largest (volume-wise) after Bitcoin.

But as beautiful as the future of Ethereum and crypto may look, mass adoption remains a genuine concern.

While crypto enthusiasts may not need help creating and preserving the security of their self-custodial Ethereum wallets, the user experience for newly onboarded users could be better. This is especially true when setting up a non-custodial wallet. The process of generating and safely storing seed phrases remains quite complicated and, if a user loses access to her seed phrase, they might as well forget about whatever coins their wallets hold because the funds will be beyond their reach. Surely, onboarding a billion users under such circumstances will remain to be seen as challenging.

To improve the existing technology and lower the barriers of entry for new users, developers at the Ethereum Foundation began to propose the concept of Ethereum account abstraction. In this article, we'll look at what this is, how it works, and most importantly, how it will benefit users.

How do Ethereum accounts work?

To use the Ethereum network, you must create an Ethereum account. A typical Ethereum account has a public address and a private key. You should not confuse Ethereum accounts for Ethereum wallets, as the latter is only an interface that helps you interact with tokens on the blockchain.

An Ethereum account consists of four key components: nonce, balance, codeHash, and storageRoot.

1. The nonce is a counter that tracks the number of Ethereum transactions an account sends or the amount of contracts an account creates, depending on the account type.
   
2. The balance is the amount of wei owned by an account. Wei is a denomination of ether, Ethereum's native currency.
   
3. The codeHash of an Ethereum account is the code tied to that account on the Ethereum Virtual Machine, a virtual computer built on the Ethereum blockchain. Since only contract accounts (explained below) are tied in code to the EVM, in accounts without code (also known as externally owned accounts or EOA), the codeHash is an empty string.
   
4. The storageRoot of an Ethereum account is the hash that encodes the account's storage content. Also known as the storage hash, it is a 256-bit hash of a Merkle Patricia trie's root node. A Patricia Merkle Trie is one of the key data structures for Ethereum’s storage layer and provides a cryptographically authenticated data structure that can be used to store all (key, value) bindings.

Essentially, Ethereum accounts are of two types: externally owned accounts (EOA) and contract accounts (CA).

Let’s have a look at both types of accounts and what differentiates them.

Externally Owned Accounts (EOA)

A 'regular' Ethereum account with which you can initiate transactions, send, and receive ETH or any other Ethereum-based token (ERC-20, ERC-721, etc), and interact with smart contracts is an externally owned account (EOA). The average Ethereum user owns an EOA, and through wallets, the account interacts with the blockchain.

Externally owned Ethereum accounts cost nothing to create, as they incur no storage requirements. They are simple accounts unassociated with data storage or code. EOAs are the only Ethereum account type with private keys, and these private keys have control over transaction signing. Also, when two EOAs interact, they can only initiate ETH or token transfers.

In summary, an externally owned Ethereum account has a public address and a private key, can sign transactions and interact with smart contracts. This type of account requires no storage, and is represented on the EVM with an empty code string.

Contract Accounts (CA)

Contract accounts are a tad different from EOAs, as a code written on the EVM controls their activities. They are also commonly known as smart contracts. This code, once written, cannot be altered and will define the nature of transactions the contract account can complete. CAs do not initiate transactions, unlike their EOA counterparts. Instead, they can only send transactions in response to a transaction received.

For example, if you send a token to a contract account to exchange said for ETH tokens, the CA receives your transaction and, through its code, sends the corresponding amount of ETH to your address. Apart from being able to transfer tokens, contract accounts can also create new contracts.

Since CAs are controlled by their code's logic, they do not have private keys. Also, contract accounts use network storage. As such, creating them comes at a cost. The nonce of a contract account counts the number of contracts every specific CA has created.

What is Ethereum account abstraction?

Data abstraction in computer science translates to hiding information to increase efficiency. For example, a software developer can learn how to write a compiler or understand the mechanisms between the compiler, processors, or memory functions when building with high-level programming languages. Data abstraction keeps the 0s and 1s underneath, allowing developers to work directly with more user-friendly languages. In turn, this saves time and allows for more complex operations.

In the case of Ethereum, this form of data abstraction seeks to eliminate the existence of two types of accounts by unifying them. Thus, a single contract account will be empowered to transact with tokens and create contracts, unifying both account types. Instead of being separate account types, both EOAs and CAs will fall under a single type.

A crucial thing to understand about account abstraction is that it doesn’t change the consensus layer of the Ethereum blockchain. Instead, transactions will move off the blockchain and onto the EVM, eliminating the distinction between accounts. Let’s look into what exactly motivates this idea, whether it is truly achievable, and what are its benefits.

Motivations for account abstraction

Earlier, we pointed out the problems with the existing technology of Ethereum accounts and how a lack of flexibility translates to a poor user experience. With the complexities involved in the current account model, the developers are severely limited in offering a better user experience.

The core motivation for account abstraction stems from the goal of reducing from two account types to only one account type i.e., contract type. A single account type for all the Ethereum accounts will enable developers to provide a seamless experience to users on a single account with the functionality to transact tokens as well as create new contracts. It will also make it easier for developers to create better protocols and services without the need to make distinctions between account types since transacting will be moved fully into the EVM and off of the blockchain protocol.

Another motivation is to offer a rich user experience such as multi-signature security, social recovery, rate-limiting, creating allow/deny-list of addresses, and gasless meta-transactions. Currently, only contract accounts (smart contract wallets) are capable of offering these features, however, the UX offered by these accounts is hindered by relying on fluctuating gas prices. Additionally, since contract accounts cannot pay gas, the user needs an EOA to pay gas fees or leverage a relayer (usually centralized entities).

Account abstraction can offer the best of both worlds and drastically improve the user experience by taking steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.

To effect these numerous changes and pave the way for more implementations, better flexibility, and an upgrade in the Ethereum user experience, developers have created several Ethereum Improvement Proposals (EIPs) on account abstraction, spearheaded by Vitalik Buterin, co-founder of Ethereum.

Proposed EIPs for account abstraction

EIP stands for Ethereum Improvement Proposal, which are the core methods through which updates and decisions are made on the Ethereum blockchain. Here are several EIPs that were proposed to tackle the issues of account abstraction.

EIP-86 (Status: inactive)

EIP-86 can be said to be the first EIP (Ethereum Improvement Proposal) aimed at account abstraction. After an initial proposal to prepare a security abstraction, the EIP-86 proposed implementing changes that would abstract out signature verification and the nonce scheme. These changes would allow users to create contract accounts that are not hard-coded to follow the traditional model but could be programmed to use any signature or nonce scheme in transaction processing.

The ECDSA and the default nonce scheme were the only mechanisms providing account security in the traditional model. In the proposed model, all accounts would become contracts, contracts would be able to pay gas fees, and users could tweak the account security and implement their desired signature/nonce scheme.

EIP-2938 (Status: inactive)

EIP-2938 offers a restricted version of account abstraction. The proposal sought to allow smart contracts to function as EOAs, allowing them to initiate transactions and pay for gas. In EIP-2938, developers propose introducing a new type of transaction and two new opcodes, aiming to keep implementation simple and allow more complex features over time.

The account abstraction transaction type would contain three fields – nonce, target, and data – where data represents all parameters that its contract must execute and the transaction must validate. In contrast, the target represents the smart contract with the logic to validate transactions.

EIP-2938 is a simple proposal. As such, it does not support several features of account abstraction like nonce abstractions and meta transactions and does not remove EOAs.

EIP-3074 (Status: in review stage)

EIP-3074 takes another path, distinct from its predecessors attempted. Instead of converting smart contracts to EOAs, EIP-3074 tries to adapt EOAs, adding a few changes here and there to make them behave like smart contracts. This is achieved by introducing two EVM instructions: “AUTH and AUTHCALL.”

The proposal seeks to allow users to hand over control of their 'regular' accounts to a contract by signing a message with their account. With the signed message and two new opcodes, an invoker (the smart target contract) could initiate transactions in the EOAs instead.

EIP-3074 focuses on enabling transaction sponsoring and multicall execution and allowing users with EOA accounts to enjoy the benefits of account abstraction without creating new accounts or transferring their assets. The proposal could achieve flexibility, albeit it does not eliminate security concerns. Notably, users under EIP-3074 still have to back up their seed phrase.

EIP-4337 (Status: active)

The most recent proposal, EIP-4337, looks to improve smart contract wallets. In a drastic departure from the usual approach, EIP-4337 simplifies the creation and operation of smart contract wallets on Ethereum by sharing the load across the required on-chain and off-chain infrastructure.

EIP-4337 eliminates the need for sending transactions, with users required to send a set of User Operations instead. Different users send UserOperation objects into a separate mempool. Bundlers then pack the User Operations into a single bundle transaction and send it to the EntryPoint contract, executing the transaction and compensating the bundlers duly. EIP-4337 eliminates the worry of subsidizing gas fees, but it fails to end the era of EOAs on Ethereum. It was proposed in 2021 and was recently authorized in 2023 because it ensured zero consensus-layer protocol changes.

Use Cases

Ethereum account abstraction, when achieved, will drive several implementations and user experience changes and allow developers the freedom to build or operate accounts on their terms.

Account abstraction will also enable developers to use smart contract logic to determine not just the effects of transactions, but also the fee payment and validation logic. Hence it could allow several crucial security benefits such as multi-sig and smart recovery wallets, the ability to change keys without changing wallets, and quantum safety.

Here are some use cases which account abstraction will help bring to reality:

• Wallets: Users will be able to benefit from advanced security features such as multi-sig, and smart recovery as well as leverage the ability to change keys without changing wallets.
• Sponsored transactions: Account abstraction will allow entities or their subsidiaries to transact in several ways, like paying fees on users' behalf and allowing users to pay gas fees in ERC-20 tokens, which will be converted and relayed to the blockchain as ETH.
• Meta-transactions: Users can accept meta-transactions (gasless) and pay for gas without trusting a relayer. Although gas costs might quickly add up, this is particularly useful for apps that require users to make frequent or small transactions.
• Batch transactions: Smart accounts allow us to batch multiple transactions together and approve all of them at once. With this, DeFi transactions may now seem just as straightforward as TradFi transactions for the first time.

So: Is Ethereum account abstraction the next massive change for the network?

While Ethereum account abstraction is not yet a reality, it has become a hot discussion topic since the success of the Merge. Over the years, Ethereum's developers have pushed back account abstraction, favoring urgent blockchain upgrades.

Now, it is only reasonable that Ethereum accounts become easier to use and understand and more welcoming to onboard the less tech-savvy. Ethereum account abstraction, as of now, appears to be the most likely way to effect a massive UX change for Ethereum to lead the mass adoption charge in crypto.

About Panther

Panther is a decentralized protocol that enables interoperable privacy in DeFi using zero-knowledge proofs.

Users can mint fully-collateralized, composable tokens called zAssets, which can be used to execute private, trusted DeFi transactions across multiple blockchains.

Panther helps investors protect their personal financial data and trading strategies, and provides financial institutions with a clear path to compliantly participate in DeFi.

Stay connected: Telegram | Twitter | LinkedIn | Website

Share this article on: