Update EIP-2780: precompile target and account-warming charge changes#11735
Update EIP-2780: precompile target and account-warming charge changes#11735rakita wants to merge 8 commits into
Conversation
github-actions
Bot
added
c-update
File
|
Have to special case this for ETH transfers emit log anyway? |
|
To clarify self-transfer is already special cased in Eip-7708 to not emit a log (as no ETH moves); so why do we charge for LOG + transfer if neither happens? |
That makes sense and will change the PR. The intention was to remove the gas discount. I don't have a strong stance, but I would feel better if it is priced the same. |
Address review feedback: EIP-7708 does not emit a transfer log when caller == to, so the intrinsic and CALL value-moving accounting should not charge TRANSFER_LOG_COST in that case.
Drop the self-transfer guard around TRANSFER_LOG_COST and the "to a different account" qualifier. Price every value-bearing transfer uniformly; the slight overcharge on self-transfer NOPs is preferable to the spec complexity of carving them out.
- Remove access-list warming shortcut for tx.to (and, for 7702 delegated targets, the delegation target). The transaction target is always charged at the cold rate at the intrinsic level. - Drop the standalone 'Warmth discovered through an access list...' bullet and replace with an explicit 'tx.to is always charged cold' statement. - Update the EIP-2930 and EIP-7702 interactions bullets accordingly. - Tighten test case 4 and remove test 6 (Warmth and access list interplay); execution-level CALL warming via EIP-2929 is unchanged.
|
In the case of a self-transfer, if the value is > 0, will the log still be emitted correctly? This is similar to a self-transfer in ERC20. |
|
You are still charging for transfer logs even when they aren't emitted |
No log is emitted for self-transfers as per https://eips.ethereum.org/EIPS/eip-7708 |
So, should we update EIP-7708 to remove the case where log is not emitted for self-transfer? This would reduce the number of test branches and accurately reflect the behavior of ERC-20. |
Don't see why, EIP-7708 is live on devnets and has active tests. Its motivation is to surface balance changes and self-transfer isn't a balance transfer. ERC20 have custom transfer implementations (could be fee-on-transfer) so a self-transfer isn't necessarily idempotent |
I believe the protocol is overcomplicating things with minor interface details while simultaneously cutting meaningful incentives for the same reason. For example, retaining self-transfer verification branches while reducing the transaction access list discount. We're wasting effort on something the interface can handle instead of prioritizing transaction performance. |
Charging the same gas for self and other transfers make sense to me from a design simplicity perspective. Yes, that means we end up charging an extra emit log costs for self transfers where a log never gets emitted. But I think self-transfers are too niche to carve out an exception for. Perhaps we should just explicitly document this trade-off in the EIP text to make it clear that this is a deliberate call that has been made. |
I agree there shouldn't be any discount for self-transfer, but could we still maintain emitting for it? We would make the implementation even simpler if we eliminated that exception. |
EIP-7981 repricing makes access lists not sensible to use other than in their original justification (which was unbricking some contracts) https://eips.ethereum.org/EIPS/eip-7981 They are essentially deprecated; also they add no value to |
Yes, that example is not reasonable ; it would be more appropriate to compare using precompiled contracts. However, I see one aspect of this EIP that isn't optimized for ETH to compete with ERC-20: the |
Again that is controlled by EIP-8038 rather than this EIP; so |
Restore the self-transfer carve-out: when caller == to, charge neither TRANSFER_LOG_COST nor a value-transfer leaf write, since EIP-7708 emits no log for self-transfers and the balance is unchanged. Internal self-CALL with value is now CALL_VALUE_COST = 0.
…ways cold Remove the warm/cold difference for the transaction-level accounts. tx.sender, tx.to, and any EIP-7702 delegation target are always charged at the cold rate; access-list membership never warms them or reduces their per-account cost. Clarify warmth policy, EIP-2930 interaction, and the 7702 access-list test vector accordingly.
rakita
changed the title
6 participants
Refinements to EIP-2780's account-access and value-transfer accounting. All changes are confined to
EIPS/eip-2780.md. They fall into four groups.1. Precompile target normalization
A precompile
tx.tois now metered like any other account — all precompile carve-outs were removed:to"warm at tx start, charged zero" rule.is_precompilecheck from the intrinsic-gas pseudocode.A value-bearing transaction to a precompile now follows the standard
tx.torules.2. Transaction-level accounts always charged cold
tx.sender,tx.to, and any EIP-7702 delegation target are now always charged at the cold rate; access-list membership no longer warms them or reduces their per-account cost.WARM_STATE_READ = 100from the gas table and the warm delegation-target reduction.The general EIP-2929 cold/warm model still applies to other accounts touched during execution and to internal
CALLs.3. Self-transfer / self-
CALLis a true no-opA self-transfer (
from == to) or self-CALLwith value no longer requires any extra write:CALLwith value:CALL_VALUE_COST = 0(previouslySTATE_UPDATE = 1,000) — balance is unchanged, no leaf write, and EIP-7708 emits no transfer log.TX_BASE_COST.CALLcases.4.
CALL_VALUE_COST/STATE_UPDATEclarificationstoaccount (the caller's leaf already updates via the fee):CALL_VALUE_COST = STATE_UPDATE + TRANSFER_LOG_COST.STATE_UPDATEis charged once when an account's nonce or balance changes in a transition.Linters pass locally (
markdownlint-cli2with repo config,eipwwithconfig/eipw.toml).