The new update is a lower number, this is confusing. I will drop my comments in the other thread.
Has there been any analysis on how much gas this would save in practice? Would be quite easy to simulate the last 3 months of transactions with vs without 7863 and see how much gas would blocks used.
Imo this EIP would be worth considering iff we were to reduce gas used by at least 50%, i.e. 2x in throughput. Otherwise, as others pointed out, the complexity is not worth it when compared to the 10x-100x block size increase we are aiming for the next 5 years.
Where do you see the complexity here?
Clients already pre-warm storage slots today and this EIP would just adjust the pricing to account for that.
The positive impact on gas used depends on the number of blocks we allow storage to remain warm. One could think of having a rolling window of 5-10 blocks for pre-warming. See some initial stats here:
This EIP would work better as the gas saves are applied if state/storage used in prior block.
From a UX point of view if applied in same block then it is a capricious saving (person has a agreed to price and randomly they get a cheaper price due to other transactions they cannot be aware of)
However if its savings from state/storage used in (most) recent block(s); then is deterministic, predictable and behaviour modifying so then it works
Agree yeah, right now the EIP wouldn’t work as-is. I’m planning to revamp it such that the BALs of the prev blocks are used for prewarming instead of the BAL of the current block.
Hiya, just saw EIP-8212 (block scoped transient storage) and my initial response on that EIP was that this introduces something which makes transactions not parallelizable anymore, unless we add items to the BAL to track the transient storage.
Then I realized that current BAL is basically a transient storage tracker: we can use the BAL to figure out if the slot is warm on block level. We can go multiple ways but for now lets keep things analogous to EIP-2929 where now, if at the end of the transaction a slot is warm, it stays warm during the block (and the transaction does not OOG).
This means all subsequent transactions will also have the slot “warm”. An UX problem with this is that the first transaction pays for it, which could be seen as not “fair”. If we have a frontrun on a slot by the (MEV) builder, however, then the builder will pay (“sponsor” might be a better word here) warming the slot.
This means that if a builder chooses transactions which write to the same slot (e.g. “pack” transactions together, for instance ERC20 transfers to the same address: the target slot is warm on block level so now we can fit more transactions in.
Although the builder would not directly get more fees via this strategy, it will mean that after these 2 transactions there is more block gas left and therefore more gas left for any kind of MEV or other strategy.
We can also try to subsidize the builder to promote packing these transactions. The idea here is that if you have multiple blocks but group the transactions together which read the same state, the work done itself is less (less intermediate trie nodes) and this should be promoted.
Note that if we would not change anything but realize that if the slot is warmed in a transaction before (it is in the BAL either as read or write → if it is a write, we know that even at the end of the transaction the slot is warm in the EIP-2929 context, which we cannot claim if the storage is only read (could be OOG and therefore marking as read), we do not have to do extra work in those later transactions because the storage slot is loaded anyways (due to the entry in BAL).
If we would assume this slot is warm in the new transactions then COLD_SLOAD_COST (2100) changes to WARM_STORAGE_READ_COST (100) and therefore 2000 gas is freed, which we can use. What we could do here is that the transaction still pays the old cost as if all slots at the start of the transaction are cold, but that not all this gas is deducted from the block gas counter.
For instance, if we would do this for the 100% version then the transaction would pay 2100 gas, but the actual gas deducted from the block is 100 gas. This means that the builder gets 2000*priorityGas as subsidy.
Note: have to figure out / play with what happens to the burned fees here.