AA-427: New aggregated signatures ERC

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), Kristof Gazso (@kristofgazso), Tjaden Hess (@tjade273)
+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 validation frame that is shared by multiple transactions.
+
+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, run the aggregator-specific code 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).