Move the 'calldataCost' from the 'callGasLimit' to 'validationGasLimit'

EIPS/eip-00.md

@@ -71,6 +71,7 @@
 | MAGIC_VALUE_SENDER    | 0xbf45c166  // bytes4(keccak256("validateTransaction(uint256,bytes32,bytes)"))          |
 | MAGIC_VALUE_PAYMASTER | 0xe0e6183a  // bytes4(keccak256("validatePaymasterTransaction(uint256,bytes32,bytes)")) |
 | MAX_CONTEXT_SIZE      | 65536                                                                           |
+| UNUSED_GAS_PENALTY    | 10                                                                              |
 
 ### New Transaction Type
 
@@ -96,9 +97,38 @@
 
 If `deployerData` is specified, its first 20 bytes contain the address of a `deployer` contract.
 
+### Optional "transaction counter header"
+
+In some cases the block builders may want to split up an array of type `AA_TX_TYPE` transactions into individual
+batches of transactions that perform validations and executions separately.
+
+Without a header transaction type this would only be possible by creating an artificial legacy type transaction.
+Instead, we propose to introduce an explicit "counter" transaction subtype.
+
+Their payload should be interpreted as:
+
+```
+0x04 || 0x01 || rlp([chainId, transactionCount])
+```
+
+Header transactions have a unique hash calculated as follows:
+
+```
+keccak256(AA_TX_TYPE || 0x00 || rlp(chainId, transactionCount, blockNumber, txIndex))
+```
+
+The `blockNumber` and `txIndex` parameters are added to the hash to achieve unique header transaction IDs.
+
+The header transactions are only used to help execution clients determine how many of the `AA_TX_TYPE` transactions
+belong to each individual batch.
+The block is not valid if a header transaction is located anywhere except before an `AA_TX_TYPE` transactions.\
+If a header transaction is included all `AA_TX_TYPE` transactions in the block must be covered by one.
+
+Header transactions do not affect blockchain state and do not cost any gas.
+
 ### Non-sequential nonce support
 
 Before EIP-9999, for accounts with associated code (smart contracts), the account nonce is only used and incremented
 when the account executes the `CREATE` (`0xf0`) opcode.
 
 However, with Smart Contract Accounts this creates a bottleneck for some use-cases.
@@ -189,9 +219,9 @@
 
 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.
-This transaction data gas cost is referred to as `calldataCost` and is subtracted from the `callGasLimit`
+This transaction data gas cost is referred to as `calldataCost` and is subtracted from the `validationGasLimit`
 before execution of the transaction.
-The transaction is considered INVALID if `callGasLimit` is smaller than `calldataCost`.
+The transaction is considered INVALID if `validationGasLimit` is smaller than `calldataCost`.
 
 ### Builder Fee
 
@@ -203,6 +233,21 @@
 
 This value is denominated in wei and is passed from the `sender` to the `coinbase` as part of the gas pre-charge.
 
+### Unused gas penalty charge
+
+Transactions of type `AA_TX_TYPE` that reserve a lot of gas for themselves using `validationGasLimit`,
+`paymasterGasLimit` and `callGasLimit` fields but do not use the reserved gas present a challenge for
+block builders. This is especially demanding in case a gas used by a transaction can be significantly different
+based on its position within a block, as such transactions may cause the block builder to iterate its algorithm
+many times until a fully utilized block is discovered.
+
+A penalty of `UNUSED_GAS_PENALTY` percent of the entire unused gas limit is charged from the
+transaction `sender` or `paymaster`.
+
+The total gas limit is calculated as `totalLimit = validationGasLimit + paymasterGasLimit + callGasLimit`.\
+The `totalGasUsed` is calculated as a sum of all gas used during the transaction.\
+The unused gas is calculated as `unusedGas = totalLimit - totalGasUsed`.
+
 ### Multiple execution frames for a single transaction
 
 All existing transaction types only have an implicit validation phase where balance, nonce, and signature are checked,
@@ -227,7 +272,7 @@
 
 In terms of block validity, all validation and execution frames may read and write any state when included in the block.
 However, the AA transactions in the mempool SHOULD be bound by storage access rules to avoid DoS on block builders.
 These rules are defined in EIP-9999.
 
 In all top-level frames, the global variables have the following meaning:
 
@@ -289,10 +334,10 @@
 
 ```
 
-The gas limit of this frame is set to `validationGasLimit - senderCreationGasUsed`.\
+The gas limit of this frame is set to `validationGasLimit - senderCreationGasUsed - calldataCost`.\
 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
 [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.
 
@@ -331,7 +376,7 @@
 
 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
 [Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).
 
 The frame must return a bytes array that is interpreted as:
 
@@ -351,7 +396,7 @@
 
 The `sender` address is invoked with `callData` input.
 
-The gas limit of this frame is set to `callGasLimit - calldataCost`.\
+The gas limit of this frame is set to `callGasLimit`.\
 Calculation of the `calldataCost` value is defined in the
 [Gas fees charged for transaction input](#gas-fees-charged-for-transaction-input) section.\
 The amount of gas used by this frame is referred to as `gasUsedByExecution`.
@@ -407,11 +452,12 @@
     if (sender.code.length == 0 && deployerData.length > 0) {
         assert deployerData.length > 20
         deployer := deployerData[0:20]
+        calldataCost := calculateCalldataCost(tx)
         retDeployer, error := evm.Call(
             from: AA_SENDER_CREATOR,
             to: deployer,
             input: deployerData[20:],
-            gas: validationGasLimit)
+            gas: validationGasLimit - calldataCost)
         assert error == nil
         assert sender.code.length > 0
     }
@@ -451,7 +497,7 @@
 ```
 
 In order to defend from DoS attack vectors, the block builders performing mempool transaction validation SHOULD consider
 the opcode banning and storage access rules described in EIP-9999.
 
 [Block validation](#execution-layer-block-validation) takes roughly the same amount of work as without AA transactions.
 In any case, validation must execute the entire block in order to verify the state change.
@@ -465,7 +511,7 @@
 
 Such transactions MUST NOT be propagated through the default transaction mempool as they will be rejected by the nodes
 and the sending node will be blocked as a spammer.
 They may be propagated in the alternative mempool that allows them explicitly as defined in EIP-9999.
 
 ### All validation state changes apply before all execution ones
 
@@ -477,9 +523,9 @@
 and all execution frames apply immediately after that.
 
 In theory, the validation frames can also invalidate each other, but we define ways to prevent that by applying
 certain rules for the mempool transactions in EIP-9999.
 
 A builder that chooses not to enforce the rules from EIP-9999 **must** take care to re-validate each transaction
 against the mid-block state at the position where it is being included into a block.
 Otherwise, the resulting block is likely to end up being invalid.
 
@@ -599,12 +645,11 @@
           break
         }
 
-        calldataCost := calculateCalldataCost(tx)
         retCall, error := evm.Call(
             from: AA_ENTRY_POINT,
             to: sender,
             input: callData,
-            gas: callGasLimit - calldataCost)
+            gas: callGasLimit)
 
         txIndex := j // transaction executed - no need to revisit in the outer loop
 
@@ -652,7 +697,7 @@
 
 * code: -32503 - Transaction out of time range.
 
 * code: -32504 - transaction rejected because `paymaster` is throttled or banned, as defined by EIP-9999.
 
 * code: -32505 - transaction rejected because `factory` is throttled or banned.