Thank you for responding.
Shouldn’t the cache format/function be standardized too then? Mainly as syncing will require a unique cache format for the sync. WDYT?
I agree with you that in theory it is easy to keep these cross-block caches consistent, but in practice it is very complicated, such as how to verify the correctness of these caches (such as adding a check hash in the block header, but how to deal with the time delay of verifying them).
For what is worth, COMB12 seems more appealing. Specially since the complexity of O4 is considerable and has the most uncertainty. Yet doesn’t really add much to consider worth it the cost to get COMB16.
In fact, the average O4 optimization per transaction is much higher than other optimizations, because the contract deployment (200 gas per byte, usually requires hundreds of thousands of gas) is usually much higher than the gas consumption of normal contract calls (small volume is the small volume of contract deployment contracts). With O4, most users can now deploy duplicate contracts with a single query of the 2600 gas bytecode hash (extcodecopy).
I also thought O4 was complicated at first, until I found that the current SSTORE directive uses such a paradigm that when SSTORE writes data, it will read the data first, and when the stored data and the written data are consistent, it doesn’t write and will only charge some read data of gas (see https://github.com/wolflo/evm-opcodes/blob/2b745ab5cbfac720967e87c2d545b2dbcec2856a/gas.md#a7-sstore). A potential advantage of O4 is to encourage people reuse the duplicated bytecode and reduce the state size.