Understanding Aggregators in ERC-4337

Signature aggregators allow multiple transactions to be made with a single signature.

ERC-4337 is a specification that provides a structure for account abstraction, a framework for creating smart contract accounts and handling their transactions.

In addition to the standard handling of transactions, it also provides handling for operations that use signature aggregators. These allow multiple transactions to be approved with a single signature.

Here's how it works.

Aggregators can turn many transactions into one.

How Aggregators Improve Signatures

In ERC-4337, an Aggregator is a helper contract trusted by accounts to validate an aggregated signature, a signature that approves multiple operations. The concept of an aggregated signature is used to improve the efficiency and scalability of the transaction processing. The idea is to bundle multiple UserOperations into a single transaction and validate their signatures in a single step, rather than validating each signature separately.

To ensure the validity of the bundled UserOperations, the Aggregator performs several checks, such as verifying the validity of the user's signature, checking the validity of the UserOperation's nonce, and verifying that the paymaster sponsoring the transaction has sufficient funds to cover the gas costs.

How It Works

The Aggregator plays an important role in the UserOperation processing, as it ensures that the UserOperations are valid and prevents any malicious transactions from being executed. The EntryPoint contract calls the Aggregator's simulateValidation method to validate the UserOperation before executing it.

In addition to the standard handling of user operations, the EntryPoint also provides handling for operations submitted by Aggregators. The handleAggregatedOps function is responsible for this, and it performs the same steps as the handleOps function but with some additional considerations.

You can read more about how the EntryPoint works here.

When handling a batch of operations that contain UserOperations from multiple aggregators (as well as operations without aggregators), the handleAggregatedOps function must transfer the correct Aggregator to each UserOperation, and also call the validateSignatures function on each Aggregator after performing the per-account validation.

In addition to the validation step, the Aggregator also provides a guarantee that the UserOperations it has validated will be executed in a timely manner. To do this, the Aggregator stakes its own funds and commits to executing the UserOperations within a specified time range. This ensures that the UserOperations will not be delayed or cancelled, and provides an additional layer of security for the users.

Security With Bundlers

It's worth noting that not all block-builders on the network are required to be bundlers, and that bundlers/clients whitelist the supported aggregators. This allows users to choose the Aggregator that best fits their needs and provides the highest level of security and efficiency.

Example: BLS Signature Aggregation

The ETH Infiniitism team has created an example of signature aggregation using BLS - Boneh–Lynn–Shacham - signatures. BLS signatures are attractive because multiple signatures generated under multiple public keys for multiple messages can be aggregated into a single signature.

The example can be found here: https://github.com/eth-infinitism/account-abstraction/tree/develop/contracts/samples/bls

The Aggregator is a key component of the ERC-4337 specification and provides a number of important benefits for users. By allowing multiple UserOperations to be bundled into a single transaction and validated in a single step, the Aggregator helps improve the efficiency and scalability of the transaction processing, while also providing a guarantee that the UserOperations will be executed in a timely manner.