diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md new file mode 100644 index 0000000000..d557125e63 --- /dev/null +++ b/ERCS/erc-4337-agg.md @@ -0,0 +1,145 @@ +--- +eip: +description: An ERC-4337 improvement to aggregation of all UserOperation signatures in a bundle +title: Signature Aggregation for Account Abstraction +author: Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat) +discussions-to: +status: Draft +type: Standards Track +category: ERC +created: +requires: 4337, 7562 +--- + +## Abstract + +[ERC-4337](./eip-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 + +### 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: + +```solidity +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](./eip-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()` + +```solidity +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: + +```solidity +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 + +## 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. + +## Reference Implementation + +See `https://github.com/eth-infinitism/account-abstraction/tree/main/contracts` + +## 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](../LICENSE.md).