(This is messy, I just want to start an informal discussion)
Considering cold/hot accesses (for storage, or accounts) in the context of a block, instead of the context of a transaction.
Cons:
- probably hard to implement, since it breaks many assumptions and the clients would have to add a bunch of complexity
- whoever lands first in the block, pays the cold load for everyone else (but, that’s a “fairness” con, since they’re already paying for it)
Pros:
- cheaper gas for users. more reasonable gas pricing, more aligned with the costs
Uniswap has been using big routers to do things, and now there’s permit2
. Permit2 is arguably healthy for the protocol (less bytecode on new deployed tokens). But it’s punished by the gas pricing, since users have to do more cold accesses.
(making up numbers now) let’s say that in most blocks there are 20 redundant permit2 cold accesses. The execution clients are benefiting from less cache misses, due to interacting with this contract, so there’s a pricing mismatch here.
Obviously, this occurs with way more things:
- delegating calls to highly used contracts (Safe, Blur)
- most relevant rollups are, even when they ossify, delegating calls
Is this worthwhile to implement, or is this too difficult and unpractical for execution clients?