By
Dimitar Bogdanov
June 22, 2023
4 Min Read
Account abstraction is one of the hottest topics in the Ethereum community right now and for good reason. It’s a long dream of some of the brightest people in the Web3 space and if realized could bring tremendous benefits in terms of usability and security for Ethereum users. Lately, the account abstraction discourse and efforts have been revolving around the promising EIP-4337 proposal, which introduces a method that could enable AA without making changes to the Layer 1 Ethereum. But there are even earlier attempts to make Ethereum account abstraction a reality.
In this article we’re taking a look at what Ethereum account abstraction is, why it’s important and why it has been so difficult to implement. And we’ll also see why we might be on the verge of seeing this dream finally realized.
When we talk about account extraction, we first need to touch upon Ethereum accounts - what they are, what purpose do they serve, etc. Put simply, an Ethereum account is an entity that has an ETH balance and can send transactions on the Ethereum network. There are two types of Ethereum accounts - externally owned accounts and smart contracts. The former are essentially user accounts, while the latter are accounts that are controlled by smart contracts.
For this article we’ll be focusing on the EOAs, as account abstraction really concerns them. Every Ethereum user needs such an account in order to receive and send transactions on the network. However, because EOAs are such an essential part of the Ethereum ecosystem, they’ve been hard-coded from the beginning and remained virtually unchanged and are a very rigid part of the protocol. And while they remain perfectly serviceable in their current state, they are also very inflexible.
For example, adding new functionalities to accounts is practically impossible because the logic that drives the EOAs has been hardcoded at the L1 Ethereum level. Then, there’s also another important detail - the fact that any transaction or smart contract execution ultimately has to be initiated from an EOA. This limits how users interact with the Ethereum network and increases the gas cost for any interaction with the platform.
This is why account abstraction is so needed. Essentially, what it aims to achieve is to replace EOAs with smart contracts. This would allow developers to write custom logic for accounts which would have a huge impact on the Ethereum ecosystem, improving security, usability, the quality of wallet UI and more. In the following section, we’ll go over some of the biggest improvements account abstraction is set to bring to Ethereum.
If account abstraction is achieved, it could be game-changing for Ethereum in a number of ways. Let’s take a closer look.
Before we delve into how account abstraction could benefit users, we need to point out that developers have found ways to solve some of the problems that stem from the reliance on EOAs. Smart contact wallets, for example, have advanced features like social recovery, but those are difficult to develop because of the fact that interactions with Ethereum are initiated via EOA transactions. This makes them a stopgap solution rather than a true game changer for the network.
Account abstraction would make it possible for any custom logic to be coded into accounts, which would ultimately bolster developers’ ability to innovate and create impactful dApps and Web3 services.
An externally owned account is just a public key-private key pair controlled by whoever owns the private key. This means that if you lose your private key, or if it gets stolen, you lose control over your account and there’s nothing you can do to restore it. Smart wallets offer a solution, but, as we mentioned above, they are currently very difficult to develop because any logic developers program into the smart contract has to ultimately be translated into a set of EOA transactions.
With account abstraction, smart contracts would be able to initiate transactions, so the logic they contain would be implemented directly and much more easily. So developers would be able to easily write custom logic for accounts to power advanced functionalities like key recovery. This could be a huge driver of Web3 adoption, as it spares users the hassle of dealing with seed phrases.
Account abstraction would also allow for developers to implement advanced security options to ensure better protection for accounts. Some of these include multi-factor authentication, blacklists for scam addresses, daily transfer limits and more.
As it currently stands, the only signature scheme used on Ethereum is the ECDSA (Elliptic Curve Digital Signature Algorithm) and accounts are bound to that particular algorithm. Account abstraction would remove that limitation, allowing developers to implement alternative schemes. This could bring significant benefits to the Ethereum ecosystem at large. For example, implementing more efficient signature algorithms would result in lower gas fees on the network. Furthermore, ECDSA is not a quantum-resistant algorithm, which makes it vulnerable to future quantum-computing attacks. Adopting quantum-resistant schemes will make the network much more future-proof.
Currently, each blockchain interaction requires a separate transaction. This approach can be really cumbersome and time-consuming, not to mention expensive, for operations that consist of multiple blockchain operations. For example, a typical DeFi interaction today requires three transactions - approve, deposit and borrow - which have to be executed and signed sequentially. But with account abstraction we can have a ‘multicall’, where all these transactions are bundled together and signed at once, and the sequence of interactions is executed in a single transaction. This would drastically improve the user flow of dApps, with fast and seamless interactions underpinning vastly better UX and UI.
Account abstraction would also bring a number of other improvements to the Ethereum network. For example, it would give users the ability to pay gas fees not just in ETH, but in any token. It would also make accounts upgradable and would make it possible for people and projects to pay fees on the behalf of other entities.
Account abstraction would also enable ‘trusted sessions’, which would allow users to pre-prove rules for interacting with a dApp and use it as they see fit without having to sign every transaction. Much like multicalls, trusted sessions are expected to push dApp UX standards to a whole new level.
Efforts to achieve account abstraction on Ethereum have been underway for a while. We already mentioned smart contract wallets, but since, in their current form, they are more of a clever workaround, we won’t focus on them here, but we’ll revisit the concept when we talk about EIP-4337. For now, though, let’s take a look at the earlier attempts to achieve account abstraction.
Published in 2020, the EIP-2938 proposed an account abstraction method centered around making smart contracts act as top-level accounts that can initiate transactions and pay gas fees. To achieve this, EIP-2938 introduced a new transaction type that includes three fields: nonce, which serves as a transaction counter; target, which is the entry point contract address; and data, which is the EVM bytecode. To execute these new transactions, two new opcodes (instructions) were added to the EVM: NONCE, which tracks the transaction sequence and PAYGAS, which calculates how much gas is needed to execute the transaction and withdraws that amount from the contract’s balance.
Shortly after EIP-2938, EIP-3074 proposed a method focused on enabling externally-owned accounts to delegate control to smart contracts, thus allowing smart contract logic to approve transactions coming from an EOA. To achieve this, two new opcodes, AUTH and AUTHCALL have to be added to the EVM. The delegation also requires the user to sign a message with their EOA. Using the message and the two opcodes, the contract - called an invoker - handles the transactions for the EOA.
Before we move on to the most recent account abstraction breakthrough in the form of EIP-4337, we should also mention EIP-2771, which focuses solely on making gasless transactions possible for users. The proposal introduces so called meta-transactions, which allow for third parties to pay users’ gas costs, and that without making any changes to L1.
Both EIP-2938 and EIP-3074 are currently inactive, as the account abstraction effort has shifted towards another approach, introduced in late 2021 with EIP-4337. The new approach seeks to build on the smart contract wallet concept.
But wait, didn’t we say earlier that smart contract wallets are difficult to work with because they are not supported by the right infrastructure? Well, EIP-4337 aims to change that and to do so without introducing changes to the L1 protocol.
Instead, the proposal introduces a higher-level mempool that works with a new object called UserOperations. So, instead of transactions users will be sending UserOperations to that mempool. From there, validators can pick up UserOperations, bundle them into a transaction and send them to a special smart contract called EntryPoint contract, which handles transaction execution and validator rewards.
The approach proposed in EIP-4337 will allow developers to write custom smart contract wallets much more easily.
The latest developments in that space indicate that, at least for now, Layer 2 is the way to go when it comes to account abstraction. Work on implementing EIP-4337 is progressing steadily, with the EIP-4337 EntryPoint contract having been deployed on the Ethereum mainnet earlier this year. Meanwhile, some Layer 2 projects like StarkNet are working on AA solutions inspired by EIP-4337.
With no L1 account abstraction in sight, it’s encouraging to see projects and teams stepping in to make AA on Ethereum a reality. At LimeChain, we’re not only eagerly anticipating to see the results of these efforts, but we’re also looking forward to actively contributing to the space, as we firmly believe that account abstraction will be a key driver of Web3 mass adoption.
