---
title: ERC-4337 Progress report #1
---

# ERC-4337 Progress report #1

###### Thursday, July 21, 2022

Hello everyone.

It has been two weeks since the previous post, and we are glad to announce a major improvement to the ERC-4337 that will be crucial for adoption of Account Abstraction, especially for Layer 2 networks: adding support for Aggregated Signatures.

The core benefit of signature aggregation is that instead of passing and verifying a signature for each individual UserOperation in a bunde, we only need to pass a single signature that verifies the entire bundle of UserOperations. If this verification passes, it means that all signatures in a batch were in fact valid, and if there was a single invalid signature in a batch the aggregated signature verification will fail as well.

This way we save a lot of crucial calldata size, which is the major part of trasnaction cost for L2 networks. Signature aggregation promises a great savings in both calldata and, eventually, execution gas, and going from "Account Abstraction gives you more flexibility but costs a little bit more gas" to "Account Abstraction gives you more flexibility AND saves you gas" will help us eventually overtake the EOAs.

This operation, however, requires some off-chain work to aggregate those signatures and a special entity on-chain to validate such a signature for all operations.

If you want to learn more, a good place to start is to watch the `BLS aggregation by Vitalik Buterin and Justin Drake` talk here:

{%youtube DpV0Hh9YajU %}
[YouTube](https://www.youtube.com/watch?v=DpV0Hh9YajU)

Note 1: While the desing is generic enough to support any signature scheme we did use BLS for our main target and terminology.

Note 2: Currently, the gas cost of verifying an aggregated BLS signature on-chain on the Ethereum mainnet is still higher than the cost of having individual `ecrecover` for each UserOp. It may never be worth doing on the Mainnet or maybe will require some new precompiles to be financially viable.

## TL;DR

If you or your Wallet users are happy with the cost-to-benefit ratio of staying on the Ethereum Mainnet running an `ecrecover` for each UserOp you will not be affected by this change.

If your Wallet users are ready to leave ECDSA and EOAs in the past and want to try out BLS signatures, the ERC-4337 is now ready to help!

## Deep dive into the changes

*Please feel free to skip this section - it got a little too long and boring. You have been warned.* :smiley:

Previously, the ERC-4337 declared the Wallet contracts to be the only ones responsible for doing two things EOAs get from the protocol: checking user signature and providing replay protection (nonce).

This approach, however, does not allow the Wallet to delegate signature verification to a third party, which is necessary if we want to verify a signature only once for an etire batch.

Now, a new entity is introduced:

## 1. Aggregator - a smart contract whose tasks are to:

1. Combine an array of individual signatures into a single aggregated signature.

function aggregateSignatures(
    bytes[] calldata signaturesForAggregation
) external view returns (
    bytes memory aggregatedSignature
);

2. Verify an aggregated signature to be a valid one over an array of UserOperations.

function validateSignatures(
    UserOperation[] calldata userOps,
    bytes calldata signature
) external view;

3. Verify an individual signature to be a valid one over a singe UserOperation. Alternatively, it provides a data the Bundler needs to perform the verification in native code.
4. Provide the Bundler with all the data that it or the Wallet may need to know about the verified signature.

#### Off-chain computation

The tasks #3 and #4 are done in a single method:

function validateUserOpSignature(
    UserOperation calldata userOp,
    bool offChainSigCheck
) external view returns (
    bytes memory sigForUserOp,
    bytes memory sigForAggregation,
    bytes memory offChainSigInfo
);

Notice how tasks #1, #3 and #4 are actions that do not happen on-chain and are only called as a view call. However, these operations may be computationally intensive.

It is important to allow Bundlers to run computationally intensive operations natively, outside the EVM, so we made some effort to keep those separable from the rest of the Aggregator interface.

The `validateUserOpSignature` method is executed as part of the `EntryPoint::validateUserOpSignature()` so it is executed for every UserOp in the mempool on every block construction run. Running it in the EVM may not be feasible for some signature schemes.

This method has two modes of operation: performing the actual signature verification in the EVM (`offChainSigCheck=false`) or in the native code of the Bundler (`offChainSigCheck=true`).

#### Notes on offChainSigInfo and sigForUserOp

Note that there is no defined interface between the Wallet and the Aggregator. Different implementations of the ERC-4337 may have arbitrary interactions between these components.

The returned `offChainSigInfo` value is the only way to pass the Public Keys from the Wallet to the Bundler for native code signature verification.

The returned `sigForUserOp` value is the only way for the Aggregator to pass an arbitrary message to the Wallet about the signature it has verified. It is a bytes array that will be passed as `UserOp.signature` to the Wallet. It must be signed if it containes a sensitive information.

## 2. Wallet must verify EntryPoint and Aggregator addresses

Previously, the UserOp always contained the signature that only the Wallet would check. This meant there was a limited trust between the Wallet and the EntryPoint. Now, if the Wallet supports aggregation, it will delegate the signature check entirely. Malicious Aggregator can take over the Wallet. The `_validateSignature` parameters include the address of the Aggregator used to verify this particular UserOp:

function _validateSignature(
    UserOperation calldata userOp,
    bytes32 requestId,
>>> address aggregator <<<
) internal virtual view;

## 3. EntryPoint runs aggregated signature verification loop

The EntryPoint still iterates over UserOps to verify them by calling to their Wallet's `validateUserOp` and Paymaster's `validatePaymasterUserOp`, and later executes the UserOps in a bundle in the second iteration.

However, the UserOps that use an Aggregator don't do any signature validation in their `validateUserOp`.

Instead, before executing any UserOps the EntryPoint that iterates over the `aggregators` array and calls their `validateSignatures` method. The entire bundle will revert in case the signature is invalid.

The EntryPoint supports mixing multiple Aggregators and Wallets without an Aggregator in a single bundle. All the UserOps using the same Aggregator need to be placed next to each other in the `ops` array. The ones without an Aggregator come last. The execution order of transactions can be controlled by the bundler by filling an optional `execOrder` parameter.

function handleOps(
    UserOperation[] calldata ops,
    address payable beneficiary,
    AggregatorInfo[] calldata aggregators,
    uint[] memory execOrder
) public;

## 4. Aggregator code rules

The code in the `validateUserOpSignature` has a set of rules similar to that of the Paymaster: it is not allowed to access the storage of any contract other than Aggregator itself and the Wallet it is verifying the signature for.

## 5. Desired Aggregation Algorithms Support

While the algorithms with signature aggregation support are fairly new and may not have been implemented for Ethereum yet, we would love to get community feedback on this feature. Here are some of the algorithms we hope the ERC-4337 is now compatible with.

Please respond if you or someone you know are working on a specification or a Solidity implementation of a signature aggreg algorithm so it can be added to our watchlist.

[BLS Multi-Signatures With Public-Key Aggregation](
https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html)

[One-Time and Interactive Aggregate Signatures from Lattices](https://crypto.stanford.edu/~skim13/agg_ots.pdf)

[Practical SNARK Aggregation](https://eprint.iacr.org/2021/529.pdf)