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:
- 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 theaggregatorInfo
field in theValidationResult
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 callvalidateUserOpSignature()
to validate theUserOperation
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 theacccount
. - The bundler MUST call
validateUserOp
a second time on the account with theUserOperation
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 allUserOperations
in the array, and revert otherwise. This method is called on-chain byhandleAggregatedOps()
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:
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 ashandleOps
, but it must transfer the correct aggregator to each userOp, and also must callvalidateSignatures
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 anaggregator
value, as returned by the account's validateUserOp()
- The
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.