Update EIP-8037: Calldata floor accounting alignment & call-frame refill clarification#11706
Conversation
|
✅ All reviewers have approved. |
| tx_state_gas = intrinsic_state_gas + tx_output.execution_state_gas_used | ||
|
|
||
| if calldata_floor_gas_cost >= tx_gas_used_after_refund: | ||
| tx_regular_gas = tx_gas_used - tx_state_gas |
There was a problem hiding this comment.
This looks strange to me,
block_output.block_regular_gas_used should not contain floor gas calculation, but tx_gas_used is max(tx_gas_used_after_refund, calldata_floor_gas_cost) so this does not compute for me.
| State-gas accounting for `CALL*` and `CREATE`/`CREATE2` operations is performed right before the respective call frame. If the respective call frame reverts or halts exceptionally, the charged state-gas is refilled back to the `state_gas_reservoir` and `execution_state_gas_used` decreases by the same amount. | ||
| State-gas accounting for `CALL*` and `CREATE`/`CREATE2` operations is performed right before the respective call frame. If the respective call frame reverts or halts exceptionally or if the operation is unsuccessful before entering the call frame (e.g., due to insufficient balance or due to the stack depth), the charged state-gas is refilled back to the `state_gas_reservoir` and `execution_state_gas_used` decreases by the same amount. | ||
|
|
||
| The same applies to top-level contract-creation transactions. If the transaction reverts or halts, the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` portion of `intrinsic_state_gas` is refilled back to `state_gas_reservoir` and `execution_state_gas_used` decreases by the same amount. |
There was a problem hiding this comment.
If the destination account of a valid created transaction is not empty (only if the balance > 0), so we shouldn't charge a fee or have to refill STATE_BYTES_PER_NEW_ACCOUNT × CPSB for it.
There was a problem hiding this comment.
I am not sure what you mean. This covers CALL and CREATE, not eth transfers
There was a problem hiding this comment.
What I mean is that an account that is the target of a create transaction is still valid if only its balance > 0 and everything else is 0 according to eip684. However, the cost of CREATE you provided is (STATE_BYTES_PER_NEW_ACCOUNT + L) × CPSB, in which case the expected cost is L x CPSB.
There was a problem hiding this comment.
Got it. It should be clarified now
…3719) * fix(eip-8037): apply EIP-7778 branching to block_regular_gas_used Replace `max(total_gas_spent - state_gas_spent, floor_gas)` with the conditional formula from EIP-8037 + EIP-7778 (PR ethereum/EIPs#11706): - Floor-dominant (floor_gas >= total_gas_spent - refunded): block_regular = tx_gas_used - state_gas_spent - Refund-dominant: block_regular = total_gas_spent - state_gas_spent (pre-refund, since refunds are excluded from block accounting) Floor gas no longer participates as a `max(...)` against the regular component; it only contributes through `tx_gas_used` when it dominates the post-refund total. * fix(eip-8037): exclude floor and refund from block_regular_gas_used Per EIP-8037 + EIP-7778, block-level regular gas accounting is the pre-refund regular component of execution. Refund and floor are scalar adjustments on the combined `state + regular` total and only affect the receipt's `tx_gas_used`, not the block-level split. block_regular_gas_used = total_gas_spent - state_gas_spent
|
@eth-bot rerun |
eth-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
Updates to EIP-8037 covering four changes:
CALL*/CREATE/CREATE2to cover cases where the operation is unsuccessful before entering the call frame (e.g., insufficient balance, stack depth limit), not only revert/exceptional halt inside the frame.