Add ERC: Signature Aggregation for ERC-4337

Merged by EIP-Bot.

ERCS/erc-7766.md

@@ -0,0 +1,142 @@
+---
+eip: 7766
+title: Signature Aggregation for ERC-4337
+description: An ERC-4337 improvement to aggregation of all UserOperation signatures in a bundle
+author: Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat)
+discussions-to: https://ethereum-magicians.org/t/erc-7766-signature-aggregation-for-account-abstraction/21123
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-09-01
+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
+
+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:
+
+```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.md) 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, 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](../LICENSE.md).