Significance of Account Abstraction (EIP-4337)

Overview of what it is, why it matters, and how it works down to the code level

Mar 6

We were at EthDenver this past week. One of the more notable announcements in the past week was the unveiling of the account abstraction standard (EIP-4337) to every EVM, as it has passed a security audit by Open Zeppelin. (See here for audit details.) With that, we will cover what it is about, why it matters, and how it works.

Background

Currently, there are two types of accounts within Ethereum:

Externally owned accounts (EOA): controlled by anyone with private keys
Smart contract accounts: a smart contract deployed to the network and controlled by code

The goal of this standard is to eventually have all of the accounts and wallets managed through smart contract accounts. (See significance below.)

While the idea of account abstraction started as early as 2016 (see here) and possibly earlier with implementations across other ecosystems, the EIP-4337 implementation implements such changes through the use of an alternative mempool without changing the underlying consensus mechanism and architecture (especially as this was worked on before the merge).

Significance

Below are the reasons why this implementation can potentially abstract away various customizations, allowing end users and developers to have a more seamless experience while ensuring that it is decentralized (removing the need for trust in bundlers).

UX improvement
1. Gas fee abstraction: lower user friction as dApps are now able to pay for gas fees on behalf of users. Additionally, accounts can now be created and controlled by an end user through the smart contract.
  
  Furthermore, this implementation allows for having a paymaster that can sponsor transaction gas fees with EIP-20 tokens at an exchange rate pulled from an on-chain DEX. This can potentially enable the abstraction of gas fees from the user interface.
2. Account recovery: allowing users to recover accounts via other methods than relying on seed phrases. This is because wallet creation is done through smart contracts, which create multi-signature wallets that can better support social recovery. (The creation process is done here.)
3. Signature abstraction and multi-operation (transaction signing): delegating transaction signing and approval to smart contracts, thus abstracting the said procedure. (Similar to EIP-3074)
dApp impact:
1. Different signature schemes: allows for a different signature scheme when authorizing a transaction as opposed to the current ECDSA methods. Some of the possibilities include BLS and Lamport.
2. Permission control: Through the use of smart contracts, there is a level of permission control you can have as to transaction logic.
Decentralization:
- Removing trust: The bundler pays the fee for the bundle transaction in ETH and gets compensated through fees paid as part of all the individual UserOperation executions.

Architecture overview and how it works

Overview

At a high level, users submit user operations through a separate mempool that does not affect consensus for other transactions.

The bundler (see bundler implementation here) bundles transactions before processing through the entry point interface. (See implementation here.)

A high-level overview of how EIP-4337 works through separate mempool. Source

Step-by-Step Process

Process implementation without paymaster. Source

Bundler validates (see validation implementation here) and batches multiple user operations (from different users) and calls to the entry point contract. (See bundler implementation here.)
The entry point interface validates transactions (can be defined based on dApp needs. See code here). In this step, wallets also validate signatures (The type of signature can be defined by dApps. See code here)
At the same time, the entry point contract validates prepayment to make sure that it has enough to cover the maximum amount for the gas fee and withholds such a fee (that can be refunded later). (See code here.)
If the wallet contract validates the bundle, it pays the entry point of the maximum cost of the transaction. This is similar to EOA, where the maximum cost of the transaction is paid and then refunded. (See EIP-1559)
(Optional) If there is the presence of a paymaster, then the wallet contract will not be required to pay for gas. Instead, it will verify paymaster staking. The entry point contract will have $0 as maximum cost of the transaction. (See paymaster validation code here.)
1. The paymaster will also have to validate that the underlying transaction is what it is allowed to pay for, such as whether the user is on the whitelist or that the user has sufficient balance to be charged later by the paymaster. (See paymaster validation code here.)
(Optional) If the transaction is validated by the paymaster, the entry point contract will then estimate the gas to be charged and charge the paymaster. The cost of the transaction will then be deducted from the paymaster. After this, the paymaster can then calculate how much to charge per user.
Process implementation with paymaster. Source
If the transaction is not rejected by the wallet contract validation, then it moves on to execute the transaction. Once it executes, and if there are any extra funds remaining from the transaction, it returns the fund to either the paymaster or the user.

Final Note

EIP-4337 brings the potential benefit of abstracting various components required to process a transaction away from end users, such as the need for users to set up an account or to be concerned about gas fees.

However, there are also limitations and can potentially increase the number of attack vectors. (Security audits do not guarantee immunity from future attacks.)

In the current implementation, there is only one user operation that is allowed to be included in a batch of user operations.

Furthermore, with the introduction of various interfaces, there are spots that attackers may exploit to increase the chance of DDoS attacks.

While such innovation is exciting and offers the potential to onboard the next billion users through a better user experience, it is also necessary to have a deeper understanding of the risks in using such standard and continuously iterate to improve this implementation.

Further Research

Historical context

NIST Announces First Four Quantum-Resistant Cryptographic Algorithms

Last Week’s Fireside Chat

The recording of the session is now available here. It was an hour-long conversation diving deep into Sui’s design philosophy and Evan’s thesis on Web 3. Learn about the uniqueness that Sui brings to web3!

Upcoming Events

3/9 - Building modular, customizable rollups with Eclipse - RSVP

This is a virtual AMA with Eclipse founder, Neel, to talk about Eclipse’s design and why it can help layer-1 blockchains scale. Latest news on Eclipse: link

Time/ Date: Thur, March 9, 2023, 11 am PT
Location: Online

** There are several events we are currently planning after this including chatting about potentially offering another variable that can help break out of the blockchain trilemma. Stay Tuned!

Iterative Ventures is a web3 investment fund & community with the aim of supporting digital asset adoption. We have a focus on infrastructure and technology owing to our technical background.

Please reach out (team@iterativeventure.com) if you would like to learn more or collaborate, including being featured in our community events/ media outlet.

Follow us on Twitter and join our Telegram community to get the latest update!