Update EIP-8037: unfair allocation of EIP-7702 overcharges#11778
Update EIP-8037: unfair allocation of EIP-7702 overcharges#11778lu-pinto wants to merge 1 commit into
Conversation
github-actions
Bot
added
c-update
File
|
eth-bot
changed the title
lu-pinto
force-pushed
the
eip-8037-auth-intrinsic-gas
branch
from
c8a9183 to
862d5a0
Compare
Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
lu-pinto
force-pushed
the
eip-8037-auth-intrinsic-gas
branch
from
862d5a0 to
6bc58e7
Compare
jochem-brouwer
left a comment
jochem-brouwer
left a comment
There was a problem hiding this comment.
Since EIP-8037 will make these authorizations rather expensive (23 * CPSB = 23 * 1530 = 35190 state gas + ACCOUNT_WRITE gas depending on EIP-8038) it does make sense to take a look into the gas schedule.
Note that in EIP-7702 the gas is added to the refund counter in case that the account already exists (it is thus not made available as regular gas). Adding it to refund counter is likely a safety mechanism, so we should be careful here.
Actually if I think about this, invalid EIP-7702 authorizations might be used to preload state reservoir which is below the EIP-7825 limit, which is not the intended use case for EIP-7702.
One more comment which changes the gas cost schedule of EIP-7702 which I think we should not do.
Thanks for opening this PR, we should discuss more (I'll open a thread about this on execution-dev on R&D)
| Intrinsic gas charges the worst-case state-gas cost (`(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`) for each authorization. However, an authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations. Therefore, per authorization adjustments are applied while processing the authorization list. | ||
| Intrinsic gas charges the worst-case gas cost for each authorization, and this worst-case amount is included in `intrinsic_state_gas` and `intrinsic_regular_gas`. An authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations, thus, per authorization adjustments must be applied while processing the authorization list. | ||
|
|
||
| The adjustments enforce a single invariant: the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB + ACCOUNT_WRITE` account-leaf portion is charged at most once per authority and only when the account did not exist before the transaction, and the `STATE_BYTES_PER_AUTH_BASE × CPSB` delegation-indicator portion is charged at most once per authority and only when the authority ends the transaction delegated having started it undelegated. |
There was a problem hiding this comment.
This makes the calculation of the intrinsic gas cost more expensive, because we now are forced to ecrecover all authorizations on the list to account for multiple authorizations for the same address. This is much more expensive than simply doing the authorization count times the possible cost of state creation.
Although I get that this severely overprices authorizations to the same account, I do not see what the use case of doing multiple delegations in the same transaction to the same account: the end result will be a change of the delegation, or no change, and the extra delegations are paid for anyways (in gas cost of at least 12.5k currently).
In order to protect the mempool for authorization-heavy transactions I would stick with the original rule of each transaction having base intrinsic cost which can be refunded. The refund mechanism is something we can change though.
CC @lightclient who might also have some extra thoughts on this one.
AFAIK what is being refunded is not because you are clearing state, but what you overcharged at the start with the worst case, or am I missing something? If we were refunding like SSTORE from clearing slots than I would agree with you, but to me these are all overcharges that are corrected after processing so IMO they make sense to go into intrinsic gas. |
|
I think we can close this Pr now, right, @lu-pinto ? |
Not sure what you mean by closing? Merging? I can see that the text still reads "refill state_reservoir..." even with the latest refund to source changes to this EIP. I feel we already got some input from other core devs in the last ACDT so i think it should be good to merge? |
4 participants
In EIP-8037 worst cases are charged for EIP-7702 authorization processing before actually processing them, so the user has to commit a lot more gas even if their authorization list does not incur the worst case. This is fine as it prevents compute grieving attacks.
These overcharges are later corrected while processing the delegations but they are allocated to the state gas pool or refund counter, e.g., they cannot be used for compute any longer. This doesn't feel like an efficient allocation of gas for the transaction and plays against what the user initially set.
My main point here is that these are overcharges and should be corrected inline (against
intrinsic_*_gas), not thrown into the state reservoir of refund counter. As a simple example, If a user has supplied agas limit < TX_MAX_GAS_LIMIT + EIP-7702worst case meaning that it intends to mostly do compute, it will see some of the gas available for compute move into the state reservoir if a non worst case authorization list is supplied. This is the normal, happy path, while updating delegations, not some sort of edge case.https://hackmd.io/@yLS7PKbzTHyB7H_THgC9Cg/ByN9odTgMg