ERC-7766: Signature Aggregation for ERC-4337

An ERC-4337 improvement to aggregation of all UserOperation signatures in a bundle

Abstract

ERC-4337 defined a way to achieve Account Abstraction on Ethereum using an alternative UserOperation mempool.

However, one big limitation remains: each transaction must carry its own signature or other form of validation input in order to be included.

We propose an extension to the ERC-4337 that introduces a new entity, aggregator, that is called during validation, to validate multiple user operations at once.

This addition will enable UserOperations to support sharing validation inputs, saving gas and guaranteeing atomicity of the bundle.

Motivation

Using validation schemes that allow signature aggregation enables significant optimisations and savings on gas for execution and transaction data cost. This is especially relevant in the context of rollups that publish data on the Ethereum mainnet.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Aggregator - a new ERC-4337 UserOperation entity contract

• Aggregator - a helper contract trusted by accounts to validate an aggregated signature. Bundlers/Clients whitelist the supported aggregators.

Using Signature Aggregator

A signature aggregator exposes the following interface:

interface IAggregator {

  function validateUserOpSignature(PackedUserOperation calldata userOp)
  external view returns (bytes memory sigForUserOp);

  function aggregateSignatures(PackedUserOperation[] calldata userOps) external view returns (bytes memory aggregatesSignature);

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

• An account signifies it uses signature aggregation by returning its address from validateUserOp.
• During simulateValidation, this aggregator is returned to the bundler as part of the aggregatorInfo field in the ValidationResult struct.
• All aggregators MUST be staked.
• The bundler should first verify the aggregator is not throttled or banned according to ERC-7562 rules.
• To accept the UserOperation, the bundler must call validateUserOpSignature() to validate the UserOperation signature. This method returns an “alternate signature” that should be used during bundling.
  An “alternative signature” is normally an empty byte array but can also contain some data for the acccount.
• The bundler MUST call validateUserOp a second time on the account with the UserOperation using the returned “alternative signature”, and make sure it returns the same value.
• Implementations of an aggregateSignatures() function must aggregate all UserOp signatures into a single value.
• Note that the above methods are helper methods for the bundler. The bundler MAY use a native library to perform the same validation and aggregation logic.
• Implementations of a validateSignatures() function MUST verify the aggregated signature’s validity for all UserOperations in the array, and revert otherwise. This method is called on-chain by handleAggregatedOps()

struct AggregatorStakeInfo {
    address aggregator;
    StakeInfo stakeInfo;
}

Bundling changes

In addition to the steps described in ERC-4337, during bundling the bundler should:

• Sort UserOps by aggregator, to create the lists of UserOps-per-aggregator.
• For each aggregator, call aggregateSignatures() to create aggregated signature, and update the UserOps.

New “entry point” function in the ERC-4337 EntryPoint contract

We define the following addition to the core interface of the EntryPoint contract:

function handleAggregatedOps(
    UserOpsPerAggregator[] calldata opsPerAggregator,
    address payable beneficiary
);

struct UserOpsPerAggregator {
    PackedUserOperation[] userOps;
    IAggregator aggregator;
    bytes signature;
}

An account that works with aggregated signature should return its signature aggregator address in the authorizer return value of the validateUserOp function. It MAY ignore the signature field.

• handleAggregatedOps can handle a batch that contains userOps of multiple aggregators (and also requests without any aggregator)

• handleAggregatedOps performs the same logic as handleOps, but it must transfer the correct aggregator to each userOp, and also must call validateSignatures on each aggregator before doing all the per-account validation.

• code: -32506 - transaction rejected because wallet specified unsupported signature aggregator
  • The data field SHOULD contain an aggregator value, as returned by the account’s validateUserOp()

Rationale

Account returning the “alternative signature”

When using an aggregator contract, the accounts delegate their ability to authenticate UserOperations. The entire contents of the

In order to allow the validation function of the account to perform other checks, the validateUserOpSignature function generates a byte array that will replace the UserOperation signature when executed on-chain.

Backwards Compatibility

As ERC-4337 was created with signature aggregation on the roadmap, no modifications are needed to the deployed EntryPoint smart contracts.

This proposal introduces new features without affecting the existing ones, and does not break backwards compatibility.

Security Considerations

Malicious aggregators

The aggregator contracts are among te most trusted contracts in the entire ecosystem. They can authorize transactions on behalf of accounts, and they can invalidate large numbers of transactions with a simple storage change.

Both account developers and block builders should be extremely careful with the selection of aggregator contracts that they are willing to support.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat), "ERC-7766: Signature Aggregation for ERC-4337 [DRAFT]," Ethereum Improvement Proposals, no. 7766, September 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7766.