Update EIP-2780: Clarify interactions with other EIPs#11332
Conversation
|
✅ All reviewers have approved. |
|
The commit 16f1ae9 (as a parent of ab83980) contains errors. |
| - **[EIP-2929](./eip-2929.md) (Gas cost increases for state access).** Refined by this EIP to price non-code cold touches at `500` and code-account cold touches at `2,600`. | ||
| - **[EIP-7702](./eip-7702.md) (Set EOA Code).** `TX_BASE_COST` remains `4,500` even if the sender temporarily assumes code for the transaction. Clients must not perform any disk code-load to determine sender type, since 7702 provides code inline. If the transaction executes code that reads or executes its own code, normal `COLD_ACCOUNT_COST_CODE` or `WARM_STATE_READ` costs apply at execution time as per the standard cold/warm model. | ||
| - **[EIP-7702](./eip-7702.md) (Set EOA Code).** `TX_BASE_COST` remains `4,500` even if the sender temporarily assumes code for the transaction. Clients must not perform any disk code-load to determine sender type, since 7702 provides code inline. If the transaction executes code that reads or executes its own code, normal `COLD_ACCOUNT_COST_CODE` or `WARM_STATE_READ` costs apply at execution time as per the standard cold/warm model. When `tx.to` is a 7702-delegated account, it is charged `COLD_ACCOUNT_COST_CODE = 2,600` at the intrinsic level. Resolving the delegation requires loading code from the delegation target, which incurs its own `COLD_ACCOUNT_COST_CODE = 2,600` if the target is cold, or `WARM_STATE_READ = 100` if already warm. This also applies to calls made to delegated accounts. | ||
| - **[EIP-7928](./eip-7928.md) (Block-Level Access Lists).** The two-tier cold-access model (`COLD_ACCOUNT_COST_NOCODE` vs `COLD_ACCOUNT_COST_CODE`) requires loading the account from disk before the correct charge can be determined. For cold accounts, at least `COLD_ACCOUNT_COST_NOCODE` gas must be available before account access is attempted; if unavailable, the operation fails with out-of-gas without accessing the account. Once an account access is attempted, the account is added to the transaction's accessed set for the BAL. Thereafter, if the account is found to have code, the account read remains in the BAL even if the available gas is less than `COLD_ACCOUNT_COST_CODE` and the call frame fails with out-of-gas. |
There was a problem hiding this comment.
This looks correct to me, but wanted to double check with @nerolation - do you see any issues with this?
| | ----------------------------------- | ---------------------------------------------------------------- | -------------------------:| | ||
| | (NOP) No-transfer to EOA | `TX_BASE_COST` | 4,500 | | ||
| | (NOP) No-transfer to empty account | `TX_BASE_COST` | 4,500 | | ||
| | (NOP) No-transfer to EOA | `TX_BASE_COST` + `COLD_ACCOUNT_COST_NOCODE` | 5,000 | |
There was a problem hiding this comment.
TX_BASE_COST already includes a COLD_ACCOUNT_COST_NOCODE for the sender. Can you explain why we are doing another charge for the receiver? In a no-transfer, is the receiver accessed?
There was a problem hiding this comment.
Yes. In the table, no-transfer to a contract charges TX_BASE_COST + COLD_ACCOUNT_COST_CODE. But we can't know if the account has code or not, without accessing it. This kind of forces us to load the account anyway which is why an additional charge for the EOA reciever is necessary
There was a problem hiding this comment.
Sorry, thinking a bit about this and it does not make sense to me now. I understand we need to load the account before knowing whether it is a CODE or NOCODE cost. However, that does not mean we are actually doing two cold reads from the account trie. We are still only doing 1 and then charging a different value based on whether the account has code or not. Or am I missing something?
There was a problem hiding this comment.
I'm not sure I understand. My thinking is that since we are forced to load the receiver account, we should either charge COLD_ACCOUNT_COST_NOCODE or COLD_ACCOUNT_COST_CODE depending on the account type (in addition to TX_BASE_COST).
There was a problem hiding this comment.
Right, the TX_BASE_COST only includes the sender access cost. Apologies, this is what I was missing. I will approve now
|
Also needs addition of LOG prices from EIP-7708 (which are currently free) |
# Conflicts: # EIPS/eip-2780.md
|
@misilva73 Could we merge these clarifications? |
|
The EIP should not make it unreasonable cheap to call EOA (no code), otherwise it impacts the worst-case BAL size and could lead to a new worst-case block size. |
@nerolation, we will use the new costs from 8038 for |
@gurukamath , I was going over the cost table again, and I am not 100% cure on this. It seems we are charginf 2 accesses to the account trie, when we should be charging just one. |
The 2 access charge applies to a receiver that has a 7702 delegation (One for the tx receiver and another for the delegated account). In other scenarios we apply a single account access charge. |
Might already be worth looking at the worst case BAL size for various account access costs, decide what is the acceptable minimum cost for BAL and then have that as the floor for the final 8038 numbers. |
eth-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
Clarify interactions with EIP-7702 and EIP-7928