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.