Initial commit for Signature Aggregation RIP-7560 transaction subtypes #2
Conversation
There was a problem hiding this comment.
@forshtat I think we still need to work on this one. Things like who pays for AA_TX_TYPE_AGGREGATED_SIG transactions, whether they're only created by the builder or can come from an intent solver (which requires sig+fees), as well as the incentives model, still need to be fleshed out.
| the Ethereum mainnet. | ||
|
|
||
| Another reason to support aggregation for transactions is snark aggregation. | ||
| Some signature schemes, such as the ones relying on `secp256r1`, are expensive to verify. |
There was a problem hiding this comment.
This may no longer be a good example, with the growing adoption of RIP-7212 (secp256r1 precompile)
| Some signature schemes, such as the ones relying on `secp256r1`, are expensive to verify. | ||
| An aggregated zero-knowledge proof that the signatures of a large number of transactions were verified | ||
| may be cheaper to verify on-chain than verifying each of them separately. | ||
|
|
There was a problem hiding this comment.
Another motivation, that we may or may not want to mention here, is the ability to perform some validation on a set of transactions. For example, AtomicAggregator doesn't actually aggregate signatures (each account still validates its own) but enforces a relation between the transactions.
This could be a powerful tool for intents, CoW swaps, etc. but it makes "aggregation" a bit of a misnomer - it's a hack that uses the aggregation subtype for a different use case.
There was a problem hiding this comment.
this is a strange beast. it seems completely unrelated to the account. you require a "protocol" (e.g in account signature) for a wallet to sign its "agreement" for the userop placement.
current definition is that the account leaves all is signature checking to that external entity, and this is a use-case where the account checks itself.
There was a problem hiding this comment.
@yoavw , do you still thikn we should mention the AtomicAggregator here?
There was a problem hiding this comment.
Yes, a strange beast and not related to signature aggregation (or account validation). The account would be validating as usual, just returning an aggregator for a different purpose. But I think it's a valid use case that could enhance intent protocols, for which there seems to be a lot of demand. An intent solver could benefit from being able to atomically bundle a set of transactions. And it doesn't require changing anything in the RIP - just renaming aggregator to something more inclusive. Intent protocols will probably use it that way even if it's called aggregator.
|
|
||
| ### Execution layer validity of a block with aggregated transactions included | ||
|
|
||
| The `validateAccountAbstractionTransaction` function's logic is not modified compared to RIP-7560. |
There was a problem hiding this comment.
Except for retSender having to include the aggregator's address.
| Therefore, the gas cost of the aggregated validation transaction is evenly divided by the number of transactions it | ||
| validates and is added to each aggregated transaction's gas cost. |
There was a problem hiding this comment.
This incentivizes the builder to make aggregated batches small (e.g. batches of 1 transaction). It's a zero-sum game - the more the user pays, the more the builder earns. And in the current model the user has no say in this.
The alternative is that the builder (or whoever sends the AA_TX_TYPE_AGGREGATED_SIG transaction) pays for aggregation directly, and gets compensated by the user transaction, e.g. via builderFee (if it's the builder) or via the transaction itself (if it's something like an intent solver). But even then, there's still information asymmetry that works against the user. The builder knows how many pending transactions it has for an aggregator, but the user doesn't. If the user sets builderFee too low for the current number of pending transactions, the transaction gets delayed until it is worthwhile to include it. If the user sets it too high, the savings on big aggregated batches go to the builder rather than the user.
We still need to figure out the incentives model for aggregation in a way that doesn't bring back pre-1559 inefficiencies.
There was a problem hiding this comment.
I think we started the gas incentive for aggregation elsewhere on TG, so not starting the discussion again here.
|
|
||
| ``` | ||
|
|
||
| 0x04 || 0x01 || rlp([chainId, transactionCount, aggregator, aggregatedSignature, aggregatedSigValidationGasLimit, accessList]) |
There was a problem hiding this comment.
I don't remember where we landed on the discussion regarding having gas fees and a signature for this transaction type. In this form it doesn't, so it will only be created by the builder. This precludes use cases where an aggregated batch comes from a separate entity such as an intent solver that uses AtomicAggregator to combine transactions from multiple users as part of the same intent.
There was a problem hiding this comment.
I don't see how AtomicAggregator can create it: this tx type is not signed by itself, and doesn't pay for itself: It is thus can only be generated by the same bundler putting in all other UserOps into this block.
|
|
||
| However, allowing the block builder to arbitrarily reorder transactions in the block, mixing aggregated and regular | ||
| transactions, would make this RIP impractically complex while the MEV extraction was never an intended feature | ||
| in the first place. |
There was a problem hiding this comment.
Block builders are free to reorder by splitting aggregated batches (even if they're for the same aggregator). They need to include multiple AA_TX_TYPE_AGGREGATED_SIG transactions for that aggregator in this case, but can control the order. Therefore the same strategies are still possible (except if something like AtomicAggregator is used to explicitly prevent them).
That's another reason I think the builder should be paying for AA_TX_TYPE_AGGREGATED_SIG transactions rather than splitting their cost among the aggregated transactions. If the builder chooses to make the batches smaller to control the order, the builder should be the one paying for the additional blockspace and work it causes.
| type: Standards Track | ||
| category: Core | ||
| created: 2023-09-01 | ||
| requires: 7560 |
There was a problem hiding this comment.
If we remove validation/execution separation from 7560 and move it to PR3 than this RIP probably also requires that.
Co-authored-by: Yoav Weiss <[email protected]>
| Some signature schemes, such as the ones relying on `secp256r1`, are expensive to verify. | ||
| An aggregated zero-knowledge proof that the signatures of a large number of transactions were verified | ||
| may be cheaper to verify on-chain than verifying each of them separately. | ||
|
|
There was a problem hiding this comment.
this is a strange beast. it seems completely unrelated to the account. you require a "protocol" (e.g in account signature) for a wallet to sign its "agreement" for the userop placement.
current definition is that the account leaves all is signature checking to that external entity, and this is a use-case where the account checks itself.
|
|
||
| ```solidity | ||
|
|
||
| function validateSignatures(uint256 version, bytes[] aggregatedTransactions, bytes aggregatedSignature) external view; |
There was a problem hiding this comment.
this is a kind of method that is hard to be replaced with EOF section.
I has 2-d input (array of bytes), which requires opionated encoding.
OTOH, there is less chance of "signature collision", since it is only in the aggregator itself, not account or paymaster.
There was a problem hiding this comment.
Yes, encoding is needed. See our current discussion re SSZ. We still don't need a method for it. Just another EOF "entrypoint" which will be called with an array of SSZ-encoded transactions and the aggregated sig.
| This addition follows the design of [ERC-4337](./eip-4337) signature aggregation and will enable | ||
| Ethereum transactions to natively support sharing validation inputs for the first time. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
On L2s the cost of transaction is proportional to the size it requires to store on L1.
There are attempts to compress transactions. This compression works better when compressing multiple transactions together.
However, signatures is the one thing that can't be compressed at all.
Compression can reduce the calldata size of a transaction to below 32 bytes, and thus signature becomes a large burden on the storage data in use.
With signature aggregation, a single signature is used on-chain for a large # of transaction, greatly reduce the calldata overhead for each transaction.
| Some signature schemes, such as the ones relying on `secp256r1`, are expensive to verify. | ||
| An aggregated zero-knowledge proof that the signatures of a large number of transactions were verified | ||
| may be cheaper to verify on-chain than verifying each of them separately. | ||
|
|
There was a problem hiding this comment.
@yoavw , do you still thikn we should mention the AtomicAggregator here?
|
|
||
| ``` | ||
|
|
||
| 0x04 || 0x01 || rlp([chainId, transactionCount, aggregator, aggregatedSignature, aggregatedSigValidationGasLimit, accessList]) |
There was a problem hiding this comment.
I don't see how AtomicAggregator can create it: this tx type is not signed by itself, and doesn't pay for itself: It is thus can only be generated by the same bundler putting in all other UserOps into this block.
| * `sender` deployment frame (once per account) | ||
| * `sender` validation frame (required) | ||
| * `paymaster` validation frame (optional) | ||
| * `aggregator` individual signature validation frame (required) |
There was a problem hiding this comment.
the above call to validateTransactionSignature (but only if sender validation frame returns this aggregator.
| return value as `signatureReplacement` and replace the `signature` transaction parameter with `signatureReplacement` | ||
| when the transaction is being included in the block. | ||
|
|
||
| This step allows the `aggregator` to provide any necessary context or metadata to the `sender` validation step without |
There was a problem hiding this comment.
separate "Rationale for xxx" section should be extracted form the "spec"
|
|
||
| ### Generating aggregated signatures | ||
|
|
||
| It is the block builder's job to combine an array of transaction signatures into a single aggregated signature. |
There was a problem hiding this comment.
this paragraph is misleading, and I'm not sure what it does here.
first, account declares its designed aggregator (return it in validationData)
I think we should reverse the rules:
We define aggregator contract SHOULD expose aggregateSignatures, so any bundler can use it.
It MAY stop using it, only if it knows all block-builders support a native code to perform the same operation.
| Therefore, the gas cost of the aggregated validation transaction is evenly divided by the number of transactions it | ||
| validates and is added to each aggregated transaction's gas cost. |
There was a problem hiding this comment.
I think we started the gas incentive for aggregation elsewhere on TG, so not starting the discussion again here.
|
|
||
| Accepts the Transaction Type `AA_TX_TYPE_AGGREGATED_SIG` hash. | ||
|
|
||
| This is a special kind of transaction with `from` field set to the `coinbase` and `to` field set to `aggregator`. |
There was a problem hiding this comment.
any special reason to put "from:coinbase" ? this is something that can't be simulated reliably. maybe its better to set it to ENTRYPOINT ?
No description provided.