From f7b13982a5426ec6fdd2c9941ab798c021a04d43 Mon Sep 17 00:00:00 2001 From: Alex Forshtat Date: Mon, 19 Aug 2024 18:14:39 +0200 Subject: [PATCH] AA-419: "signature" -> "authorizationData" & "calldata" -> "executionData" --- RIPS/rip-7560.md | 44 ++++++++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/RIPS/rip-7560.md b/RIPS/rip-7560.md index c086c72..0e2df8c 100644 --- a/RIPS/rip-7560.md +++ b/RIPS/rip-7560.md @@ -70,7 +70,7 @@ smart contracts. This, however, is impossible without an addition of Native Acco A new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction with type AA_TX_TYPE is introduced. Transactions of this type are referred to as -“AA transactions”. Their payload should be interpreted as: +"AA transactions". Their payload should be interpreted as: ``` @@ -80,18 +80,18 @@ Transactions of this type are referred to as sender, deployer, deployerData, paymaster, paymasterData, - callData, + executionData, builderFee, maxPriorityFeePerGas, maxFeePerGas, validationGasLimit, paymasterValidationGasLimit, paymasterPostOpGasLimit callGasLimit, accessList, - signature + authorizationData ]) ``` -The base gas cost of this transaction is set to `AA_BASE_GAS_COST` instead of 21000 to reflect the lack of “intrinsic” +The base gas cost of this transaction is set to `AA_BASE_GAS_COST` instead of 21000 to reflect the lack of "intrinsic" ECDSA signature verification. ### Gas fees are charged directly from the contract balance @@ -123,8 +123,8 @@ The meanings of the `maxPriorityFeePerGas` and `maxFeePerGas` are unchanged from For all the existing transaction types, G_txdatazero (4 gas) and G_txdatanonzero (16 gas) per byte is charged for the `data` parameter. -Transaction Type AA_TX_TYPE introduces the following dynamic length inputs: `callData`, `paymasterData`, -`deployerData`, `signature`. Each of these parameters' gas cost is counted towards transaction data cost. +Transaction Type AA_TX_TYPE introduces the following dynamic length inputs: `executionData`, `paymasterData`, +`deployerData`, `authorizationData`. Each of these parameters' gas cost is counted towards transaction data cost. This transaction data gas cost is referred to as `calldataGasUsed` and is subtracted from the `validationGasLimit` before execution of the transaction. The transaction is considered INVALID if `validationGasLimit` is smaller than `calldataGasUsed`. @@ -212,8 +212,8 @@ struct TransactionType4 { uint256 callGasLimit; bytes deployerData; bytes paymasterData; - bytes callData; - bytes signature; + bytes executionData; + bytes authorizationData; } ``` @@ -228,7 +228,8 @@ function validateTransaction(uint256 version, bytes32 txHash, bytes transaction) The gas limit of this frame is set to `validationGasLimit - senderCreationGasUsed - calldataGasUsed`.\ The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\ -The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section +The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty `authorizationData`, +as defined in section [Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).\ The `version` parameter is added in order to maintain the Solidity method ID in case of changes to this struct in future revisions of this EIP. @@ -248,7 +249,8 @@ function sigFailAccount(uint256 validAfter, uint256 validUntil); Calls to the `AA_ENTRY_POINT` approval callbacks have the following meaning: - `acceptAccount` - This callback is called by the account after it verified the transaction and agreed to pay for its execution. -- `sigFailAccount` - This callback is called by the account if the transaction is syntactically valid, but the signature is incorrect. +- `sigFailAccount` - This callback is called by the account if the transaction is syntactically valid, +but the `authorizationData` is incorrect.\ Note that this callback is used during gas estimation and does **not** indicate a valid transaction. The parameters passed to the callback functions have the following meaning: @@ -277,7 +279,8 @@ The amount of gas used by this frame is referred to as `paymasterValidationGasUs - The `version` parameter is `VERSION` - The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\ -- The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section +- The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty `authorizationData`, +as defined in section [Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash). @@ -294,7 +297,8 @@ function sigFailPaymaster(uint256 validAfter, uint256 validUntil, bytes context) Calls to the `AA_ENTRY_POINT` approval callbacks have the following meaning: - `acceptPaymaster` - This callback is called by the paymaster after it verified the transaction and agrees to pay for its execution. -- `sigFailPaymaster` - This callback is called by the paymaster if its paymasterData is expected to contain a signature, but its signer is incorrect. +- `sigFailPaymaster` - This callback is called by the paymaster if its `paymasterData` is expected to contain + some kind of signature, but it does not contain a valid one.\ Note that this callback is used during gas estimation and does **not** indicate a valid transaction. The parameters passed to the callback functions have the following meaning: @@ -313,7 +317,7 @@ and the transaction is rejected and not included on-chain. #### Sender execution frame -The `sender` address is invoked with `callData` input. +The `sender` address is invoked with `executionData` input. The gas limit of this frame is set to `callGasLimit`.\ Calculation of the `calldataGasUsed` value is defined in the @@ -381,7 +385,7 @@ func validateAccountAbstractionTransaction(tx *Transaction) { assert callbackParamsSender != nil assert Date.now() <= callbackParamsSender.validUntil assert Date.now() >= callbackParamsSender.validAfter - assert callbackParamsSender.isValidSignature + assert callbackParamsSender.isValidAuthorizationData if (paymaster != address(0)) { paymasterInput := ABI.encodeWithSelector('validatePaymasterTransaction', tx, tx.hash) @@ -394,7 +398,7 @@ func validateAccountAbstractionTransaction(tx *Transaction) { assert callbackParamsPaymaster != nil assert Date.now() <= callbackParamsPaymaster.validUntil assert Date.now() >= callbackParamsPaymaster.validAfter - assert callbackParamsPaymaster.isValidSignature + assert callbackParamsPaymaster.isValidAuthorizationData } } @@ -445,7 +449,7 @@ Note that the `chainId` and `accessList` parameters are included in the transact available on-chain as part of the `TransactionType4` struct. In order to calculate the transaction hash that will be used during the signing of the transaction and validation of -the transaction signature by the `sender`, the value of the `signature` parameter is considered to be an empty +the transaction signature by the `sender`, the value of the `authorizationData` parameter is considered to be an empty byte array. ## Rationale @@ -475,14 +479,14 @@ RIP-7560 transaction validation, which may lead to this contract being drained. To do so we require specific call to the `AA_ENTRY_POINT` address to indicate RIP-7560 transaction acceptance. -### The Usage of `sigFailAccount` and `sigFailPaymaster` for signature failure +### The Usage of `sigFailAccount` and `sigFailPaymaster` for `authorizationData` check failure This callback is called by an account or a paymaster during their respective validation frames if they can verify -all relevant details of the transaction except for the transaction signature. +all relevant details of the transaction except for the transaction `authorizationData`. This callback is used during gas estimation, and it helps wallet and apps to determine the gas used by the validation -process before generating any real signatures. -The transaction is expected to consume the same amount of gas when updated with a valid signature. +process before generating any real signatures.\ +The transaction is expected to consume the same amount of gas when updated with a valid `authorizationData`. ## Backwards Compatibility