ERC-4337: Exploring the Technical Components of Account Abstraction — Part 2

On March 1st 2023, ERC-4337 rolled out to Ethereum mainnet adding the ability for smart contracts to transact on behalf of the user.

But in reality, what actually changed?

The core consensus layer that Ethereum relies on wasn’t touched, instead ERC-4337 added a layer that gave developers the opportunity to fundamentally change the way users interact and transact on chain.

If you are reading this, you probably already knew that from part one of this series.

In this article we will look at the five major technical components that were introduced by ERC-4337 and how they work together to execute user transactions.

The Components of Account Abstraction (ERC-4337)

There are five key major components under the ERC-4337 standard that you should care about: UserOperation, Bundler, EntryPoint, Aggregator, and Paymaster.

UserOperation

In simple terms: A UserOperation captures user’s intent and operations including the sender, payload, and gas-related information. As it was designed to avoid the need for consensus change, the Ethereum team opted to create a completely new structure that captures all required elements of a transaction to be sent on behalf of a user.

To avoid any confusion, they specifically did not label it a “transaction”.

In greater detail: Instead of initiating a traditional transaction, smart contract wallets can now create pseudo-transaction objects known as UserOperations (userOp) that represent the user’s desired transaction intent.

UserOperation has no access to any information that might change between simulation and execution, such as current block time, hash, number, etc. This is to ensure that it will still be valid and capable of paying for its execution on chain.

A UserOperation is also only allowed to access data related to the sender address.

Like a transaction: A UserOperation contains sender, to, calldata, maxFeePerGas, maxPriorityFee, signature, and nonce

Unlike a transaction: The nonce and signature fields usage is not defined by the protocol but instead by each account implementation.

UserOperations Mempool

In simple terms: The UserOperations mempool is a pool of pending UserOperations waiting to be processed by the network. Instead of going to the traditional public mempool, UserOperations are sent to the UserOperations mempool.

In greater detail: The UserOperations mempool is the final “stop” before any UserOperation land on chain as an actual transaction, a new stakeholder known as “bundler” (covered below) can then pull each UserOperation out of this mempool, act as the EOA, pay their gas and send them on to the consensus layer to be executed as a transaction.

This is a dedicated high-level UserOperations mempool that is only for UserOperations, it is also referred to as the canonical mempool. This canonical mempool follows and enforces strict ERC-4337 rules. The ERC does also allow for alternative mempools (alt-mempool) for UserOperations that do not follow the canonical mempool rules.

UserOperations that conform to the ERC rules are propagated to the canonical mempool. The ones that don’t can be sent to other alternative mempools with different rules. The UserOperations in these alternative mempools are propagated only to the participants of that pool.

Bundlers are able to support exceptions to the canonical mempool rules through whitelisting and participating in another alt-mempool with a different ID. Bundlers have the freedom to participate in both the canonical mempool (where they must apply the ERC rules without exceptions) and in the alternative pools.

NB: The final version of the UserOperations mempool hasn’t been fully defined, so expect further changes. A completely decentralized mempool is a must for the adoption and the health of the protocol. The permissionless P2P version is in the specifications writing phase.

Bundler

In simple terms: A Bundler acts as the EOA for all UserOperations it has pulled out of the canonical mempool & alt-mempools, sends them to the EntryPoint contract to be validated and sanity checked, to then finally, join the transaction flow we are used to in the pre ERC-4337 world i.e: on chain.

In greater detail: A Bundler is a specialized operator that listens to the UserOperation mempool and alt mempools, pulls multiple UserOperations, bundles them together, and sends that bundle to the EntryPoint contract for execution. This looks very similar to an EOA to smart contract transaction, with the execution of UserOperations as the internal transactions. The “from” address will be the Bundler, and the “to” address will be the EntryPoint contract.

Bundlers choose which UserOperation objects to include in their bundle transaction based on similar value-maximizing logic used by block builders on Ethereum today.

What is The Economic Model/Incentive of Being A Bundler?

The Bundler acts as the “from” address when getting the bundle transaction on-chain, and because of this, the Bundler will pay the gas fee for the bundle transaction in ETH. Bundlers are then compensated through fees paid as part of all the individual UserOperation executions.

Before accepting a UserOperation, Bundlers will simulate it to verify that the signature is correct, ensure that the UserOperation can pay its fees, and ensure that the user operation will behave in the same way in the simulation and execution. It is up to the Bundler to avoid including UserOperations that failed validation, to avoid absorbing the gas cost of those unable to pay.

NB: In the ERC-4337 framework Block Builders may also participate as Bundlers to provide enhanced execution guarantees but it is not a requirement. Without this enhanced execution guarantee, the bundle is sent to the public pool and it risks being front-run which can cause the bundle to fail.

Paymaster

In simple terms: A Paymaster is an optional stakeholder that can sponsor transactions for other users. Why? A Paymaster can be used to enable a number of interesting new features for transacting on Ethereum, for instance:

• Application developers can easily subsidize fees for their users e.g. as an onboarding/acquisition promotion
• Users can easily pay gas fees with ERC-20 tokens or off-chain payment methods like credit cards or other subscription services.

In greater detail: It is not mandated within the ERC-4337 flow that a paymaster must be used. If a UserOperation has opted to use a paymaster they will typically fall into two definitions:

• A Verifying Paymaster: these paymasters provide gas abstractions linked to an off-chain process. For example, it can enable users to pay their transaction fees with a credit card or subscription service without sacrificing the custody of their account.
• A Deposit Paymaster: these paymasters provide gas abstractions linked to an ERC-20 token on-chain.

A Paymaster must either limit its storage usage or have a stake.

NB: In order to deter misuse, the system will either reduce the speed or temporarily ban a Paymaster responsible for submitting a significant amount of invalid UserOperations. To protect against “sybil attacks” from these entities, global entities are required to place a stake within the system, making a denial-of-service (DoS) attack costly. This stake remains unslashed and can be withdrawn at any time, subject to an unstaking delay. Exceptions apply to global entities that do not access global storage.

Aggregator

In simple terms: An Aggregator is a special class of actors that utilize a helper smart contract to a bunch of UserOperation signatures and turns them into one signature i.e aggregate them.

In greater detail: It is a helper smart contract trusted by contract accounts to validate aggregated signatures. The bundled UserOperations are validated by an Aggregator in a single step rather than validating each signature separately. It is designed to improve the efficiency and cost of transaction processing at scale.

Today’s reality: The volume of ERC-4337 transactions is not yet high enough to have the benefits of signature aggregation, but it is growing quickly and Aggregators are a key stakeholder to help enable scale once we hit a critical mass.

The process of implementing this compression is beyond the scope of this discussion. However, it is already integrated into the design of ERC-4337. The most popular way to compress this is with BLS signature aggregation.

From a user’s point of view they don’t see anything different, but the developer will need to implement BLS signature logic into the Smart Account.

The Ethereum Foundation has already created a template you can use here.

EntryPoint

In simple terms: The EntryPoint contract is a singleton contract that verifies and executes the bundles of UserOperations sent to it. It checks and enforces that all UserOperations submitted to land on-chain from the bundler are real and valid.

In greater detail: The EntryPoint contract is the global entry point that all ERC-4337-compliant smart contract wallets must use to transact on the EVM. This concept is similar to the single staking deposit contract.

The use of an EntryPoint simplifies the logic used by smart contract wallets, pushing the more complicated functions needed to ensure safety to the entry point rather than in the wallet itself. Its core purpose is to prevent wallets from doing unwanted or unauthorized actions before entering the network.

The EntryPoint sequence

The following image and sequence explains how the EntryPoint manages a batch of UserOperations sent by the Bundler. Typically, there are two phases involved, but in the case that the bundle utilizes an aggregator, an additional phase is added.

The EntryPoint sequence is relatively simple and has two real journeys:

• If there is an aggregator:

Aggregator Loop -> Verification Loop -> Execution Loop

If there is not an aggregator:

Verification Loop -> Execution Loop

Each Loop in the sequence has its own role and looks like this:

Loop 1: Aggregator Loop

If aggregators are used in a bundle, the EntryPoint checks them first. It validates the signature.

Loop 2: Verification Loop

First, it checks if a contract account exists. If it doesn’t, it creates it (“factory” contract, CREATE2 ).

If the paymaster is not defined: The sequence verifies if the Contract Account has a sufficient deposit in the EntryPoint to pay for gas. If it does it then pays for the UserOperation.

If the paymaster is defined: The sequence verifies if the paymaster has sufficient deposits in the EntryPoint contract. If it does, the contract then validates the UserOperation.

Loop 3: Execution Loop

It Call-s Contract Account with callData.

If the paymaster is defined, it calls custom fee logic in Paymaster.

When the UserOperation passed this gauntlet of sequence loops it’s then finally time for it to land on the chain.

ERC-4337 & UserOperations — An Alternative “Transaction” Flow

While ERC-4337 specifically used terminology that did not include the word “transaction” in order to avoid confusion — realistically it can be seen as an alternative flow for users to get transactions on chain. Once all the components are connected it gives protocols the ability to introduce a new user intent layer to the existing EOA transaction flow.

Users of AA wallets will transmit their intent to the UserOperations mempool. Bundlers transfer those intentions into a signed transaction that the network can process as before.

While to a developer it may look like a “transaction” with extra steps, to the user it represents the difference between manually inputting a username/password and writing it down in notebook for safe keeping, or using OAuth to get access to a web3 app in just a couple of clicks.

Eden Network’s Commitment

Today, we are actively working on building out robust infrastructure tooling to fully support the implementation of ERC-4337. Follow us on Twitter or join our Discord to be the first to hear about this new product set.

If you are a team or individual building for account abstraction, we want to hear from you and see if we can collaborate. Please reach out on Discord and send our partnerships team a message.