Ethereum’s underlying technology is continuously evolving, and the growing ecosystem makes the future in terms of adoption look bright. The main challenges to scalability are being addressed to support the performance needs of more sophisticated dApps and smart contracts that are being deployed to the platform with solutions like The Merge of the Beacon Chain and the Ethereum Mainnet, optimistic and zero-knowledge rollups, and sharding.

At some point the question of adoption connects directly to the overall user experience of the process of onboarding new users, and the compatibility of dApps with the core logic of the way distributed ledger systems like Ethereum operate. We have all at some point been through the painful process of creating a wallet for the first time. Storing seed phrases, manually adding and switching networks, having to fetch tokens just to get started at all, etc. are examples of tasks that no user would say they signed up for or had in mind. As for developers, they need more sophisticated functionality than to prompt dApp users to sign a transaction for every small action within the application, or keep a bunch of assets handy before even starting to use a dApp.

In this article we’ll be talking about how account abstraction (AA) comes in as an enhancement to accounts on Ethereum, how it’s implemented and the way it works, and the problems it solves. But first, let us understand what Ethereum accounts look like at present.

Current State of Ethereum Accounts

The Ethereum Virtual Machine (EVM) can be understood as a piece of software that computes state change in a distributed ledger network as newer transaction blocks are added. A state is essentially a large data structure that holds all accounts, balances, and EVM code that are used in tandem to execute arbitrary logic that is defined in the form of smart contracts. The nodes that run the client software and form the Ethereum network all run instances of EVM and provide the run-time environment to execute smart contract logic.

Ethereum accounts encapsulate a bunch of data stored on-chain, which we refer to as account state. The account state is made up of four components:

• Nonce: A counter that records the number of transactions made by the account that increments by 1 every time a transaction is made. Helps prevent against replay attacks since the account can only send one transaction with a particular nonce to the network
• Balance: Amount of Ether owned by the account in wei
• Storage hash: A 256-bit hash that encodes the storage contents of the account. It is empty by default
• Code hash: The EVM code hash that gets executed when a contract is called. For EOAs, it is the hash of an empty string

Source: Ethereum.org docs

Currently, there are two distinct types of accounts on Ethereum: Externally Owned Accounts (EOAs) and smart contract accounts. Let’s talk a bit about each of them.

EOAs are generated in the form of public-private key pairs. We haven’t gotten to AA yet, but It’s important to think of the account that you’re probably using right now as an abstract representation of this public-private key pair, because it is exactly that.

A private key is the heart and soul of an EOA account. It is a 256-bit/32-byte string that is generally expressed as a 64-character hexadecimal string, something like ce1555a2143c25e51c0e5a5c75298b6beda56770e0f81fb724e8ba0607027d5c. Think of this as a really long random number, and it isn’t inaccurate to think that because that’s how a machine generates it, as an even longer, much longer binary string. A wallet tool like MetaMask, or any other, does that for you when you create a wallet. It does this by running an Elliptic Curve Digital Signature Algorithm (ECDSA), which relies on a secp256k1 curve and a random number used as a seed to generate the private-public key pairs. The EVM carries out signature validation for all actions performed by an account using this same ECDSA algorithm.

A public key is equally important, because the address that you use to send and receive tokens is generated by running it through a hash function. In the case of Ethereum addresses, the last 20 bytes of the Keccak-256 hash are used to generate an address.

Now contract accounts on the other hand are generated when smart contracts are deployed to the network. They are defined with logic that can be triggered with transactions sent to them carrying input data. They differ from EOAs in important ways. Most notably, contract accounts do have unique public addresses, but they don’t have associated private keys. It isn’t possible for smart contracts to initiate transactions of their own accord, and they don’t sign transactions either. Thus, an EOA must always initiate transactions and sign them. Smart contracts can invoke methods in other contracts too, and such calls are referred to as internal transactions.

Here’s a table highlighting differences between the two types of accounts.

The Idea of Account Abstraction

With the understanding of Ethereum accounts that we just developed, it is clear that certain properties of EOA pose difficulties when it comes to programmability of accounts. There are a number of other issues entailed, as mentioned below:

1. EOAs are hard to create and maintain for users. Creating a wallet is still a tedious process that each newly onboarding user must go through, and storing private keys safely is no easy task in itself either.
2. In the event of key loss, there’s basically no way to recover or reset your keys, resulting in the permanent loss of assets.
3. Heavy dApps such as games, social media platforms, content sharing platforms, etc. need to automate processes that frequently read and write data from/to the chain. This task becomes very challenging since only EOAs can initiate and sign transactions, and even if a dApp manages to implement workarounds, UX or security usually take a hit.
4. Gas fees must be paid up by the same EOA sending the transaction, i.e., contracts, or other EOAs can’t pay gas fees on your behalf, and neither can you do the same for other accounts.
5. Transactions can’t be batched together. We have all experienced this when we try to bridge or swap assets and need to make and sign two separate transactions, one to approve, and one to send, both of which incur gas fees.

Account abstraction is an attempt to address all the limitations of EOAs that we just pointed out. The idea is to achieve the level of versatility that contract accounts have for all accounts by allowing contract accounts to start transaction executions and pay gas fees on other accounts’ behalf. This discussion is not new, and multiple proposals have been devised in the form of protocol updates that implement account abstraction in different ways.

EIP-4337

Out of the proposed methods, EIP-4337 is particularly promising since it doesn’t require any core protocol changes to the way EVM processes transactions or the consensus mechanism, and has undergone significant active development.

It implements a separate higher level mempool to which users send off-chain messages referred to as user operations. User operations package the signatures and other data necessary for verification and establishing the action that the user intends to perform. This eliminates the need for users to send individual transactions.

User operations are packaged into a single transaction by either a network actor called block proposer, or a bundler service that produces transaction bundles for the block proposer. The nodes that are connected to the UserOperation mempool carry out specific validations to ensure that user operations are guaranteed to pay fees before forwarding them to the bundler.

Source: Vitalik’s article on AA

Bundlers check transactions to make sure that every user operation pays transaction fees before packing them into a bundle transaction, which then gets sent to be executed and recorded on-chain. They pay the transaction fees for the bundle transaction and receive compensation later in the form of fees when each user operation is eventually executed.

Source: EIP-4337 Draft

Every contract account has functions that verify signatures and nonce of the user operation for validation, and interpret calldata to fetch instructions for various wallet operations. A global Entry point contract is a part of on-chain infrastructure that defines the behavior of associated contract accounts and helps simplify the conditions for the limited number of execution functions that can trigger wallet operations like transfers or gas fee payments.

A stated objective of EIP-4337 is to eliminate the need for EOAs. Developers benefit greatly from this simplification of account types, as a single type of account is easier to handle, and functionality can be added to it as necessary. Additionally, creating more advanced flows and business logic becomes more convenient since with contract accounts all transactions take place within the scope of the EVM.

Promise and Potential

The real potential of AA comes from the use cases it enables at the application level. Here are a few examples of what AA helps bring to reality.

Enhanced Wallet Security

• AA can enable advanced security features such as multisig for any account without having to use a separate multisig wallet contract
• It can enable transaction limiting for an account to protect against sudden outflow of a large amount of funds, or the number of transactions that can be made within a fixed period of time
• Addresses can be blacklisted/whitelisted to limit interaction with other accounts
• Accounts can be programmed with a dead man’s switch that gets activated if the account isn’t active for an extended period of time
• Accounts can designate trusted individuals who can help recover lost keys without changing the wallet via social recovery

Gasless Transactions

• AA enables accounts to execute transactions without having a token balance in their accounts and avoiding relay networks (meta transactions)
• Contract accounts can implement paymasters that pay gas fees on behalf of users when performing operations, which can greatly improve user experience in practice
• Gas fees can be paid in tokens other than the native token

Batched Transactions

• Multiple transactions can be batched into one atomic transaction to perform multiple operations when executed and save gas fees, or put conditions in place to control the flow of execution
• Applications such as games that can make a high number of microtransactions fairly frequently can group transactions together into batches, so that multiple transactions are executed at the same time and avoid unnecessary interruptions that can affect gameplay

Challenges

Every new innovation comes with its challenges, and implementing AA has its own difficulties that need to be tackled.

Since smart contract accounts exist purely in the form of code within the scope of the EVM, the number one priority is to keep wallet accounts secure and protected from hackers and malicious actors. Methods like multi-factor authentication can help mitigate risks to a certain extent, but code reliability becomes even more crucial than it already is without AA in place. For instance, all transactions go through the Entry point contract, and so it is extremely important to ensure its safety and robustness to maintain the integrity of transaction validation and signing.

Also, sophisticated contract account logic can become resource-intensive due to high processing needs, which may in turn lead to higher gas fees temporarily till further optimization.

Conclusion

At the end of the day, AA is an exciting development that can finally address some of the pain points from a user experience perspective. Providing developers with the tools to lower the entry barrier for new users is a step in the right direction towards mass adoption. It remains to be seen how different networks implement AA while trying to preserve interoperability, which is a challenge in itself as each chain will probably come up with its own model of AA infrastructure and account logic.

AA is still in the draft stage before it goes online on Ethereum Mainnet, but the good news is we’re working with Biconomy to bring it to Mantle soon! This will pave the way for dApps with significantly better user experience and build user-friendly onboarding flows for new users looking to explore the world of web3. Most of Ethereum’s network activity takes place on L2 networks, and ease of use is as important a factor as rich functionality. We’re excited to see what ideas developers will come up with.

---

Already have an idea? Follow us on Twitter to keep up with the announcements regarding upcoming hackathons and other events. You can also get in touch with us via Discord or Telegram.