Title: EIP_7557__Block_level_Warming
Category: EIPs

Author: alex-forshtat-tbk
Date: 2023-11-14T16:27:42.547Z

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.


github.com/ethereum/EIPs








Add EIP: Block-level Warming with fair cost savings


master ← eth-infinitism:create_global_warming_eip_7557



          opened 06:24PM - 28 Feb 25 UTC




            forshtat
          



+388
-0






Reopening the old PR that I did not realise was not previously merged (https://g…ithub.com/ethereum/EIPs/pull/7968)

This proposal is significantly different from EIP-7863 (https://github.com/ethereum/EIPs/pull/9246), arguably presents a more complete and fair solution that is worth the extra complexity, and precedes it for more than a year.






Old PR link:


github.com/ethereum/EIPs








Add EIP: Block-level Warming


master ← eth-infinitism:global_warming_eip



          opened 04:12PM - 14 Nov 23 UTC




            forshtat
          



+370
-0






**ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN [ETHEREUM/ERCS](https://gith…ub.com/ethereum/ercs)**

--

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.

Author: Mani-T
Date: 2023-11-15T03:04:39.386Z

Could you please provide further elaboration on that?

Author: xinbenlv
Date: 2023-11-15T18:48:27.068Z

This sounds like an interesting direction, and economically makes sense! Love to collaborate if it helps

Author: alex-forshtat-tbk
Date: 2023-11-16T12:21:31.302Z

@Mani-T Sure, I updated the message with a link to the pull request with the EIP itself.
@xinbenlv thanks!

Author: Mani-T
Date: 2023-11-17T02:38:16.909Z

Great idea. Attempting to pave the way for a fairer system.

Author: sm-stack
Date: 2023-11-18T05:06:27.771Z

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?

Author: PixelCircuits
Date: 2023-11-28T21:06:45.885Z

I love this. I think it’s necessary and overall fair for smart contract wallets to survive.

Author: alex-forshtat-tbk
Date: 2025-02-28T18:49:22.106Z

Note that there is now a second EIP with the same title:




EIP-7863: Block-level Warming EIPs


    Discussion topic for EIP-7863 
Find an initial analysis of the EIP in the following: 

Update Log


2025-01-16 Initial Commit
External Reviews
None as of 2025-01-18. 
Outstanding Issues
2025-01-18: Clarify if block-level warming or directly move to multi-block warming 
2025-01-18: Clarity warm-warm-for-all vs. one-warms-and-gets-refunded (costs distributed among transactions or accesses)

Author: shemnon
Date: 2025-02-28T19:11:59.934Z

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.

Author: wminshew
Date: 2025-03-01T19:37:41.227Z

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?

Author: alex-forshtat-tbk
Date: 2025-03-03T00:02:52.318Z

wminshew:

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?

Author: alex-forshtat-tbk
Date: 2025-03-03T00:22:48.994Z

Thank you @shemnon
I tried to elaborate on some things in the EIP as well as here.



 shemnon:

Does execution follow the same costing rules as before?


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.



 shemnon:

When do the accounts get their re-imbursement? At the end of the block?


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.

Author: wminshew
Date: 2025-03-03T03:49:10.946Z

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

Author: alex-forshtat-tbk
Date: 2025-03-03T08:53:30.226Z

wminshew:

my instinct is that this is a very very rare edge case and worth accepting for the simpler execution


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.