From d6219688d87626dc0009dadfa2c7290011ae5265 Mon Sep 17 00:00:00 2001 From: Alex Forshtat Date: Thu, 22 Aug 2024 11:49:51 +0200 Subject: [PATCH 1/6] Initial commit for new aggrageted signatures ERC --- ERCS/erc-4337-agg.md | 100 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 ERCS/erc-4337-agg.md diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md new file mode 100644 index 0000000000..8ca21ba092 --- /dev/null +++ b/ERCS/erc-4337-agg.md @@ -0,0 +1,100 @@ +--- +eip: +description: An account abstraction improvement proposal which enables multiple UserOperations to be authenticated using a single shared signature parameter. +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 + +## Motivation + +## Specification + +* Support aggregated signature (e.g. BLS) +* **Aggregator** - a helper contract trusted by accounts to validate an aggregated signature. Bundlers/Clients whitelist the supported aggregators. + +```solidity +function handleAggregatedOps( + UserOpsPerAggregator[] calldata opsPerAggregator, + address payable beneficiary +); + +struct UserOpsPerAggregator { + PackedUserOperation[] userOps; + IAggregator aggregator; + bytes signature; +} +``` + +* If the account does not support signature aggregation, it MUST validate that the signature is a valid signature of the `userOpHash`, and + SHOULD return SIG_VALIDATION_FAILED (and not revert) on signature mismatch. Any other error MUST revert. + +An account that works with aggregated signature, should return its signature aggregator address in the "sigAuthorizer" return value of validateUserOp. +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 below 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. + + +### 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 returning its address from `validateUserOp`. +* During `simulateValidation`, this aggregator is returned to the bundler as part of the `aggregatorInfo` struct. +* The bundler should first accept the aggregator (aggregators must be staked. bundler should verify it is not throttled/banned) +* To accept the UserOp, the bundler must call **validateUserOpSignature()** to validate the userOp's signature. + This method returned an alternate signature (usually empty) that should be used during bundling. +* The bundler MUST call `validateUserOp` a second time on the account with the UserOperation using that returned signature, and make sure it returns the same value. +* **aggregateSignatures()** 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. +* **validateSignatures()** MUST validate the aggregated signature matches for all UserOperations in the array, and revert otherwise. + This method is called on-chain by `handleOps()` + +```solidity +struct AggregatorStakeInfo { + address aggregator; + StakeInfo stakeInfo; +} +``` + +The account MAY return an aggregator. See [Using Signature Aggregator](#using-signature-aggregator) + +* 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 + + +* **code: -32506** - transaction rejected because wallet specified unsupported signature aggregator + * The `data` field SHOULD contain an `aggregator` value + +## Rationale + +## Backwards Compatibility + +## Reference Implementation + +## Security Considerations + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 85d4935bb908248dad48d59a8219f2fe501efde4 Mon Sep 17 00:00:00 2001 From: Alex Forshtat Date: Thu, 22 Aug 2024 16:25:39 +0200 Subject: [PATCH 2/6] Clean up the ERC --- ERCS/erc-4337-agg.md | 115 ++++++++++++++++++++++++++++++------------- 1 file changed, 80 insertions(+), 35 deletions(-) diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md index 8ca21ba092..9bf19f4428 100644 --- a/ERCS/erc-4337-agg.md +++ b/ERCS/erc-4337-agg.md @@ -13,40 +13,31 @@ requires: 4337, 7562 ## Abstract -## Motivation +[ERC-4337](./eip-4337) defined a way to achieve Account Abstraction on Ethereum using an alternative `UserOperation` mempool. -## Specification +However, one big limitation remains: +each transaction must carry its own `signature` or other form of validation input in order to be included. -* Support aggregated signature (e.g. BLS) -* **Aggregator** - a helper contract trusted by accounts to validate an aggregated signature. Bundlers/Clients whitelist the supported aggregators. +We propose an extension to the ERC-4337 that introduces a validation frame that is shared by multiple transactions. -```solidity -function handleAggregatedOps( - UserOpsPerAggregator[] calldata opsPerAggregator, - address payable beneficiary -); +This addition will enable `UserOperations` to support sharing validation inputs, saving gas and guaranteeing atomicity of the bundle. -struct UserOpsPerAggregator { - PackedUserOperation[] userOps; - IAggregator aggregator; - bytes signature; -} -``` - -* If the account does not support signature aggregation, it MUST validate that the signature is a valid signature of the `userOpHash`, and - SHOULD return SIG_VALIDATION_FAILED (and not revert) on signature mismatch. Any other error MUST revert. +## Motivation -An account that works with aggregated signature, should return its signature aggregator address in the "sigAuthorizer" return value of validateUserOp. -It MAY ignore the signature field. +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 -* `handleAggregatedOps` can handle a batch that contains userOps of multiple aggregators (and also requests without any aggregator) -* `handleAggregatedOps` performs the same logic below 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. +### 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 +A signature aggregator exposes the following interface: ```solidity interface IAggregator { @@ -60,16 +51,21 @@ interface IAggregator { } ``` -* An account signifies it uses signature aggregation returning its address from `validateUserOp`. -* During `simulateValidation`, this aggregator is returned to the bundler as part of the `aggregatorInfo` struct. -* The bundler should first accept the aggregator (aggregators must be staked. bundler should verify it is not throttled/banned) -* To accept the UserOp, the bundler must call **validateUserOpSignature()** to validate the userOp's signature. - This method returned an alternate signature (usually empty) that should be used during bundling. -* The bundler MUST call `validateUserOp` a second time on the account with the UserOperation using that returned signature, and make sure it returns the same value. -* **aggregateSignatures()** 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. -* **validateSignatures()** MUST validate the aggregated signature matches for all UserOperations in the array, and revert otherwise. - This method is called on-chain by `handleOps()` +* 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 { @@ -77,24 +73,73 @@ struct AggregatorStakeInfo { StakeInfo stakeInfo; } ``` +### Bundling changes -The account MAY return an aggregator. See [Using Signature Aggregator](#using-signature-aggregator) +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 +* 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). From 293d5cc24d6c0a94390971e161860f8a30bc472e Mon Sep 17 00:00:00 2001 From: Alex Forshtat Date: Sun, 8 Sep 2024 10:47:07 +0200 Subject: [PATCH 3/6] Update ERCS/erc-4337-agg.md Co-authored-by: Dror Tirosh --- ERCS/erc-4337-agg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md index 9bf19f4428..04e5201710 100644 --- a/ERCS/erc-4337-agg.md +++ b/ERCS/erc-4337-agg.md @@ -1,6 +1,6 @@ --- eip: -description: An account abstraction improvement proposal which enables multiple UserOperations to be authenticated using a single shared signature parameter. +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: From 95abc85692b3d300e3d9c4de2b25c59ed91ccd98 Mon Sep 17 00:00:00 2001 From: Alex Forshtat Date: Tue, 10 Sep 2024 16:24:28 +0200 Subject: [PATCH 4/6] Update --- ERCS/erc-4337-agg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md index 04e5201710..83abc68d51 100644 --- a/ERCS/erc-4337-agg.md +++ b/ERCS/erc-4337-agg.md @@ -2,7 +2,7 @@ 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) +author: Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat) discussions-to: status: Draft type: Standards Track From 25a656166e9d4ae1836b6e8e0292934073a50587 Mon Sep 17 00:00:00 2001 From: shahafn Date: Tue, 10 Sep 2024 17:29:13 +0300 Subject: [PATCH 5/6] Update ERCS/erc-4337-agg.md --- ERCS/erc-4337-agg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md index 83abc68d51..0d47fe4a8d 100644 --- a/ERCS/erc-4337-agg.md +++ b/ERCS/erc-4337-agg.md @@ -18,7 +18,7 @@ requires: 4337, 7562 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. +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. From 32571191c344c47cfe8a5f21472c639a955203df Mon Sep 17 00:00:00 2001 From: Dror Tirosh Date: Tue, 10 Sep 2024 17:40:14 +0300 Subject: [PATCH 6/6] aggregateSignatures --- ERCS/erc-4337-agg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-4337-agg.md b/ERCS/erc-4337-agg.md index 0d47fe4a8d..d557125e63 100644 --- a/ERCS/erc-4337-agg.md +++ b/ERCS/erc-4337-agg.md @@ -78,7 +78,7 @@ struct AggregatorStakeInfo { 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. +* For each aggregator, call `aggregateSignatures()` to create aggregated signature, and update the UserOps. ### New "entry point" function in the ERC-4337 `EntryPoint` contract