AA-340: Update the RIP-7560 with the EIP-7702 transaction type fields

RIPS/rip-7560.md

@@ -8,7 +8,7 @@ status: Draft
 type: Standards Track
 category: Core
 created: 2023-09-01
-requires: 4337, 6780
+requires: 7702
 ---
 
 ## Abstract
@@ -61,7 +61,7 @@ smart contracts. This, however, is impossible without an addition of Native Acco
 | Name                  | Value                                                                           |
 |-----------------------|---------------------------------------------------------------------------------|
 | FORK_BLOCK            | 	TBD                                                                            |
-| AA_TX_TYPE            | 4                                                                               |
+| AA_TX_TYPE            | 126                                                                             |
 | AA_ENTRY_POINT        | `address(7560)`                                                                 |
 | AA_SENDER_CREATOR     | `address(ffff7560)`                                                             |
 | AA_BASE_GAS_COST      | 15000                                                                           |
@@ -90,14 +90,22 @@ A new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction with type
   validationGasLimit, paymasterValidationGasLimit, paymasterPostOpGasLimit
   callGasLimit,
   accessList,
+  authorizationList,
   signature
 ])
 
 ```
 
-The base gas cost of this transaction is set to AA_BASE_GAS_COST instead of 21000 to reflect the lack of “intrinsic”
+```
+authorizationList = [[chain_id, address, nonce, y_parity, r, s], ...]
+```
+
+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.
 
+The `authorizationList` parameter has the exact same behaviour as defined by the
+[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702).
+
 ### Gas fees are charged directly from the contract balance
 
 The maximum gas cost of the AA_TX_TYPE transaction is defined as:
@@ -201,7 +209,7 @@ We define the following Solidity struct to represent the AA transaction on-chain
 
 ```solidity
 
-struct TransactionType4 {
+struct TransactionTypeRIP7560 {
     address sender;
     address deployer;
     address paymaster;
@@ -217,10 +225,20 @@ struct TransactionType4 {
     bytes paymasterData;
     bytes callData;
     bytes signature;
+    address[] authorizationList;
+    bool[] authorizationListStatus;
 }
 
 ```
 
+Note that the `authorizationList` struct parameter only includes the list of addresses recovered from each element
+of the RLP-encoded transaction payload.
+
+As there is a gas cost associated with providing any element of the `authorizationList` regardless of its validity,
+and in order to avoid repeated `ecrecover` executions in on-chain validation,
+we introduce the `authorizationListStatus` struct parameter.
+Its elements contain `true` for entries that did result in setting the EOA code, and `false` otherwise.
+
 We then define the following Solidity method and the `sender` of the transaction is invoked with the corresponding data:
 
 ```solidity
@@ -230,7 +248,7 @@ 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 `transaction` parameter is interpreted as an ABI encoding of `TransactionTypeRIP7560`.\
 The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, 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
@@ -269,7 +287,7 @@ The gas limit of this frame is set to `paymasterValidationGasLimit`.
 
 The amount of gas used by this frame is referred to as `paymasterValidationGasUsed`.
 
-The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\
+The `transaction` parameter is interpreted as an ABI encoding of `TransactionTypeRIP7560`.\
 The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
 [Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).
 
@@ -420,8 +438,8 @@ keccak256(AA_TX_TYPE || 0x00 || rlp(transaction_payload)
 
 ```
 
-Note that the `chainId` and `accessList` parameters are included in the transaction hash calculation but are not
-available on-chain as part of the `TransactionType4` struct.
+Note that the `chainId`, `accessList` and `authorizationList` parameters are included in the transaction hash
+calculation but are not available on-chain as part of the `TransactionTypeRIP7560` 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
@@ -544,7 +562,7 @@ The full mitigation may be achieved by separating the validation from into a sep
 ### Size of the `nonce` parameter
 
 Note that the `nonce` transaction parameter is defined as a 64-bit integer by the Ethereum protocol,
-however in the `TransactionType4` struct it is defined as `uint256 nonce`.
+however in the `TransactionTypeRIP7560` struct it is defined as `uint256 nonce`.
 
 We will propose a mechanism that uses the higher 192 bits of the `nonce` field in a separate RIP.
 In the meanwhile it is strictly recommended that the wallets use `require(nonce < type(uint64).max)` check.