Gas limit plan post Berlinterop

# Gas limit plan post Berlinterop In general, we are approaching the project from the perspective of OPCODE/Precompile benchmarking, State growth benchmarking and Security. We have currently omitted RPC benchmarks, but this will be integrated into the approaches over the next weeks. Areas of concern, These need to be addressed by Fusaka or by EOY to get to 100M: **For 45M:** - None **For 60M:** - Modexp repricing: [EIP-7883](https://eips.ethereum.org/EIPS/eip-7883) OR modexp implementations improved in clients to required benchmark numbers **For 100M:** - SSTORE with large trie depths (Solution and Problem space under active exploration) - Changing the devp2p limits for receipts: [EIP-XXXX](https://github.com/ethereum/EIPs/blob/5339c1d1b185dfb366ddb8cbecf9d73db8767f12/EIPS/eip-xxxx.md) - State growth based analysis, especially on sync times - RPC performance at 100M **Status at the end of the Berlinterop week:** 1. Clients have majorly improved their performance over the course of the week, with the worst case block times reducing significantly (Without MODEXP) ![](https://notes.ethereum.org/_uploads/B1m0mIxVll.png) 2. We still see a healthy improvement with MODEXP, the repricing should help mitigate this scenario ![](https://notes.ethereum.org/_uploads/BkgRvQIxVel.png) 3. ECRecover, Blake2f, Datacopy, BLS precompiles, MSTORE were all tested and found to be non-issues 4. BN256Add, BN256Pairing, BN256Mul were optimized by clients and not an issue at the end of the week 5. Graphed out the theoretical worst case EL and CL limits here: [Interactive website](https://ethpandaops.github.io/blocksize/) and [Source table](https://notes.ethereum.org/@pk910/max-block-size) **What we still need to do:** - Blocks can be 20% larger than gaslimit (@benaadams) EIP-7778, is this a good idea to push for Glamsterdam? - State growth and sync testing (unlikely a problem at 100M, but we need to start paying attention to it) - RPC performance testing tool is needed to first baseline benchmark performance, we also need to get realistic workloads from Quicknode and Alchemy - Try to meassure or model the longest execution time for a single block (this involves txs accesing very old random state data, and requires big state). - Lockstep-sync scenarios, e.g. how long can EL be down and CL is able to catch it up (siladu) - engine API encoding size / overhead (fjl)