Update EIP-7623: Clarify the gas refunds handling #9227
Conversation
Previously, the `evm_gas_used` (now renamed to `execution_gas_used`) was not specified. This lead to two different interpretations whenever the `execution_gas_used` was the value after or before applying refunds. We argue that the interpretation that `execution_gas_used` don't have refunds subtracted is incorrect because it would make the "current" formula for the `tx.gasUsed` incomplete and confusing as the total gas used by a transaction would actually be `tx.gasUsed - refunds`. Using this reasoning, this change clarifies the specification by following the interpretation that the `execution_gas_used` is the value after the refunds are applied.
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
There was a problem hiding this comment.
Cannot re-approve since this is already merged, but have given this some thought since EthJS applied the refund after applying the formula. I now believe this is incorrect:
I indeed agree that it makes more sense to apply the execution refund before applying the max formula. Otherwise it is possible to somewhat "game" the gas system by getting refunds and then getting cheaper calldata txs.
The simplest way to do this (assuming EIP 7702 is included) is to send an authorization tx together with the calldata, where the authorization fields delegate accounts which already exists. This (currently) yields 12500 refund, so packing these two together with the calldata tx will give 12500 "refund" on the calldata gas when it should definitely not be applied (the floor price of the calldata gas should be paid).
Apply the [EIP-7685 update] included in [pectra-devnet-5]. [EIP-7685 update]: ethereum/EIPs#8989 [pectra-devnet-5]: https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 This requires a fix in tests for calldata repricing logic according to ethereum/EIPs#9227
Previously, the
evm_gas_used(now renamed toexecution_gas_used) was not specified. This lead to two different interpretations whenever theexecution_gas_usedwas the value after or before applying refunds.We argue that the interpretation that
execution_gas_useddon't have refunds subtracted is incorrect because it would make the "current" formula for thetx.gasUsedincomplete and confusing as the total gas used by a transaction would actually betx.gasUsed - refunds.Using this reasoning, this change clarifies the specification by following the interpretation that the
execution_gas_usedis the value after the refunds are applied.