Update EIP-8037: Proposal for Revising 8037#11570
Update EIP-8037: Proposal for Revising 8037#11570Carsons-Eels wants to merge 1 commit intoethereum:masterfrom
Conversation
github-actions
Bot
added
c-update
File
|
eth-bot
changed the title
|
The commit 8b4e1a7 (as a parent of 0081dbe) contains errors. |
|
Interesting, any chance you can provide a document where you motivate the different changes, relating to the complexity that is removed? |
jochem-brouwer
left a comment
jochem-brouwer
left a comment
There was a problem hiding this comment.
I left some comments.
The main problem I currently see with this is that (if I understand the gas mechanism here correctly, which I am not sure about: I see the original state before the transaction and the state after the transaction (without doing state check yet) and for all created state we charge the associated gas, and revert tx if it cannot be paid for).
The problem I have with this is that there are situations where it is clear that there is insufficient gas to pay for the creation, but only at the very end of the transaction this is checked: the user has executed a lot of compute opcodes and still has to pay for those. There is also a problem where if you call an unknown contract this could now spam state creation such that either the user has to pay a massive fee (if they provided a very high gas limit) or the tx reverts, causing the user to waste gas on computation.
Also note that this approach changes EIP-7702: in that EIP, the delegations are not rolled back in case the entire transaction reverts. This now seems to change, if there is insufficient gas then also do not create the accounts (or delegation code of 23 bytes)
| Gas, only Compute Gas | ||
|
|
||
| #### Transaction-level gas accounting (reservoir model) | ||
| At the end of the transaction, the user must pay for the State Gas which has been used. This operation succeeds if there is sufficient remaining total expenditure (`tx_gas_limit * gas_price`) available. This can result in user paying more than `(base_fee_per_gas + priority_fee_per_gas) * tx_gas_limit`; however, this protects users from running out of gas if the `cost_per_state_byte` has changed since they estimated their gas usage. |
There was a problem hiding this comment.
What is this tx_gas_limit? Is it the gas limit set by users or the "gas limit" set in EIP-7825? The explanation is hard to follow here because one can pay more than the original max (?) in fees and it is unclear where those funds come from (might be motivated later)
| - State Gas is charged at the end of the transaction based on the accumulated total of allocated state space | ||
| - There is no check for State Gas exhaustion during execution | ||
| - A full refund of State Gas occurs if there is a revert | ||
| - State Gas can be refunded liberally. A reverted call frame charges no State |
There was a problem hiding this comment.
I think an easier way to explain this is that one should keep a state journal of created state to track the state gas used (I also think this should be called state creation gas, as state update gas is not changed here). By reverts the created state naturally disappears from this journal. At the end one checks the amount of state created and then charges for this.
| #### ETH Transfer Transactions to New Accounts | ||
|
|
||
| The cost parameters introduced by this EIP map to validation phases as follows: | ||
| ETH transfer transactions cost `21000` Compute Gas. If the target of this |
There was a problem hiding this comment.
Note that EIP-2780 will lower this.
|
|
||
| The cost parameters introduced by this EIP map to validation phases as follows: | ||
| ETH transfer transactions cost `21000` Compute Gas. If the target of this | ||
| tansaction does not exist, State Gas **must** be charged. This is an unavoidable |
There was a problem hiding this comment.
Note, there are still ways to create state without paying state gas: withdrawals and coinbase payment, where coinbase does not exist beforehand.
There was a problem hiding this comment.
Or system contracts creating state
| tx_gas_used_after_refund = tx_gas_used_before_refund - tx_gas_refund | ||
| tx_gas_used = compute_gas_used + (state_gas_used * cost_per_state_byte) | ||
| tx_cost = (base_fee_per_gas + priority_fee_per_gas) * tx_gas_used | ||
| max_tx_expenditure = gas_limit * max_fee_per_gas |
There was a problem hiding this comment.
What is max_fee_per_gas?
Doesn´t this check equal adding compute gas and state together to see if this is below gas limit?
|
|
||
| ### Refunds | ||
|
|
||
| TODO What do we do for refunds when storage that was non-zero is set to zero |
There was a problem hiding this comment.
These refunds now are not super effective because of the 20% refund cap. Although removing refunds is maybe not the right signal because this would not incentivize to clean up state, I also think this is currently not taken into account by developers because of the 1/5 tx costs it can save one, plus if you thus massively start to cleanup space you will only be partially "paid back" because of this cap. Note that we cannot up the gas limit cap and keep the refunds as this will actually re-allow GasToken.
| | `GAS_NEW_ACCOUNT` | 25,000 | 112 | 0 (already has `GAS_CALL_VALUE` 9,000) | `CALL*` | | ||
| | `GAS_STORAGE_SET` | 20,000 | 32 | 2,900 (`GAS_STORAGE_UPDATE - GAS_COLD_SLOAD`) | `SSTORE` | | ||
| | `PER_EMPTY_ACCOUNT_COST` | 25,000 | 112 | 0 (included in `PER_AUTH_BASE_COST`) | EOA delegation | | ||
| | `PER_AUTH_BASE_COST` | 12,500 | 23 | 7,500 | EOA delegation | |
There was a problem hiding this comment.
Table does not include the re-delegation of an account (thus writing "code", 23 bytes)
|
|
||
| - State gas: `32 × cost_per_state_byte` is refunded directly to `state_gas_reservoir` (and `execution_state_gas_used` is decremented). The refund happens immediately at the X to 0 SSTORE, not via `refund_counter`. This ensures the full state gas amount is returned regardless of the 20% refund cap. | ||
| - Regular gas: `GAS_STORAGE_UPDATE - GAS_COLD_SLOAD - GAS_WARM_ACCESS` is added to `refund_counter`, subject to the 20% cap. | ||
| SELFDESTRUCT is deprecated. To reduce protocol complexity there are no refunds for SELFDESTRUCTed accounts or storage keys. |
There was a problem hiding this comment.
I disagree. Unless there's a dedicated opcode snippet, the CREATE/SELFDESTRUCT pattern is still useful for creating ephemeral contracts. For example, we could save 120 x cpsb by removing a CREATE3 proxy : https://etherscan.io/address/0xfe752dc15cc4cbaefe5308d6de740b10be48cb7a#code
Also, on Monad, gas consumption is gas limit, so refunding at the end of the transaction doesn't seem very efficient.
|
Would a fixed |
6 participants
This is an attempt by the STEEL team to reconcile issues within the existing definition of 8037, and the effects that were discovered during implementation and testing.
This draft is for discussion, we have left some TODOs and not fully specified all details. We intend to finish specifying the details over the course of the next week with your cooperation.