A mechanism for a fair distribution of the gas costs associated with access to addresses and storage slots among multiple transactions with shared items in their accessList.
Old PR link:
2 Likes
Could you please provide further elaboration on that?
This sounds like an interesting direction, and economically makes sense! Love to collaborate if it helps
1 Like
@Mani-T Sure, I updated the message with a link to the pull request with the EIP itself.
@xinbenlv thanks!
1 Like
Great idea. Attempting to pave the way for a fairer system.
Great work! This will enhance the fairness of the whole Ethereum network, and also reduce gas cost significantly.
I have two questions here:
-
Is this inspired by zkSync fee refunds? I think there are slight differences, but the motivations seem to be similar.
-
In the pseudo code of reimbursement of priority fee, why do the two most expensive transactions have the same contribution to the reimbursement?
1 Like
I love this. I think it’s necessary and overall fair for smart contract wallets to survive.
Note that there is now a second EIP with the same title:
I think the specification needs to clarify the timing of the reimbursement, the impact on executing code, and the timing of funds availability.
-
Does execution follow the same costing rules as before? Cold cost is the same and the same 2929/2930 warming rules apply to that cost?
-
When do the accounts get their re-imbursement? At the end of the block? Durring the TX, right after the TX? I think the only safe place is after all TXes occur, collectively.
-
For transactions in the block after transaction, is the value that account holds going to remain the pre-reimbursement amount? This follows directly from depositing after all transactions, but the implications may need to be called out somewhere.
I don’t think there is a sensible way other than to keep current charging rules and re-imburse at the end. It would be possible to set up transactions that resolve differently if the marginal refund is done before the end of the block, and so a tx would resolve differently, and in ways that could impact the marginal share of warming.
2 Likes
seems I missed this eip/thread – cross-posting my thoughts from the other: EIP-7863: Block-level Warming - #16 by wminshew
@alex-forshtat-tbk in your proposal, what is the benefit of taking the priority fees into account vs the ~simpler gas reduction?
It seems to me that not taking the priority fee into consideration can create a set of problems in itself. This is of course only important when the priority fee can be a significant part of the transaction’s total gas price.
In this case, not considering the priority fee and simply dividing the nominal gas cost of an access by the number of accesses with that address/slot may create a situation where adding a cheap transaction in the end of the block reduces the total earnings of the block builder.
In this case block builders may prefer to leave more gas in a block unused to avoid splitting the cold access fees, or censor certain kinds of transactions they deem “unproductive”.
What are our options regarding the priority fee in your opinion?
Thank you @shemnon
I tried to elaborate on some things in the EIP as well as here.
Yes, nothing observably changes in the context of a transaction.
This helps us avoid potential problems, for example one transaction during its execution cannot “check” whether some other storage slot has already been touched in the current block by a different transaction.
Exactly. They are reimbursed as the last state change occurring in a block by a “system transaction”, and can only be observed in the next block. This prevents the refunds in one transaction affecting other transactions, which as you mentioned potentially creates a circular dependency.
In this case block builders may prefer to leave more gas in a block unused to avoid splitting the cold access fees, or censor certain kinds of transactions they deem “unproductive”.
without doing any kind of historical analysis, my instinct is that this is a very very rare edge case and worth accepting for the simpler execution
What are our options regarding the priority fee in your opinion?
tbh i haven’t thought about this nearly as much as you … will marinate on it a bit
Yes, it isn’t a significant concern for the Ethereum L1 right now, but this may theoretically change in the future or on some L2s. We didn’t want to add any additional constraints on the priority fee.
1 Like