# Derisking 100MGas The following should act as a braindump of things we need to investigate before giving an okay to 100MGas. All worst cases are collected in geth via statetests. The fuzzers used for finding these are not sophisticated and this analysis should be replicated in a less time constrained manner. ## Hard requirements - Modexp repricing: the worst cases we see are around 6 seconds per block (addressed in Fusaka) - BN256Add repricing: the worst cases are around 4.7 seconds per block - BN256Pairing repricing: the worst cases are around 2+ seconds per block - BN256Mul repricing: worst case around 2+ seconds per block - LOG repricing or changing the devp2p limits for receipts - SSTORE with large trie depths/XEN contract solution ## To investigate - Blocks can be 20% larger than gaslimit (@benaadams) EIP-7778 - Higher tx throughput => higher storage churn => more compaction => more housekeeping work => slower IO (raulk) - State growth outpacing sync speed (fjl): this will likely not be a problem with 100M,but we will have to deal with this at > 100M. - higher bandwidth competition with everything else (CL and EL mempool) - All Opcodes in tight loops - Create & Call chains - Big stacks - Predeployed contracts (deposit, withdrawal queue) - Storage requirements, storage load on datasets - KZG Precompile - BN256Mul precompile - 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). - Check the block filled with the following CL requests (MarekM) - deposits - consolidations - withdrawals/exits - 7702 - Jumpdest analysis - how does mevboost block building timing change? (transcribed by raulk) - Lockstep-sync scenarios, e.g. how long can EL be down and CL is able to catch it up (siladu) - upstream network constraints, missed proposals (j.florentine) - largest possible blocks stuffing call data to saturate gas limit? (raulk) - engine API encoding size / overhead (fjl) - deterioration vs. recovery (and time to recovery) when operating near the limit: I’m not sure we have the mechanisms to recover instead of deteriorate further once a series of large blocks kicked things off-balance, or after some Internet-wide event hits even for a short period (cskiraly) ## Already investigated - ECRecover: not an issue - Blake2f: worst case around 1 sec - Datacopy: not an issue - All BLS precompiles: around 500ms - MStore: memory size around 7MB - Random SStores
Last changed by  
 
Marius van der Wijden
752

Read more

Repricing session

Focused on repricings, not on EVM improvements Glamsterdam EIP-8007: Glamsterdam Gas Repricings meta EIP containing all repricings for Glamsterdam, numbers are subject to significant change Compute Repricings We need to target the worst case on L1, not so important on L2 Targeting 60MGas/s We have ~3s for execution in the worst case on L1 Repricing candidates:Mulmod, Smod, mod: 3x

2/3/2026
Modexp

Background Modexp currently runs at ~12MGas/s Grafana. After repricing that goes up to ~31.4MGas Grafana. At 45Mgas a worst case block would take ~3s at 60Mgas it would take ~4 seconds before Fusaka repricing. We would like to raise the gas limit to 60Mgas before Fusaka ideally. I don't think anyone will realistically send these transactions to grieve the network, but it would be good to improve nonetheless. Solutions

8/21/2025
A way forward for Holesky

Holesky has not been finalizing for a couple of days now. We need a healthy chain for staking pools to test their setups and it is pretty clear that it will take Holesky longer to finalize again. A solution to this is to do a shadowfork of holesky in order to allow staking pools to test on Pectra. Note that pools can not test their setups on Sepolia, since Sepolia uses a permissioned validator set. Since we are still collecting a lot of useful information from Holesky, we do not want client teams to stop their nodes over there. It is a good experiment to see what happens to the network when so many validators leak out or get mass-slashed. The Plan We do a shadow fork of the chain before the Pectra fork, and gothrough the transition The network would be run by PandaOps, with ~1.5M keys We use the validator set of Holesky before the Pectra fork as the new genesis set and replace the public keys of all client teams with keys owned by PandaOps.

3/4/2025
Untitled

BLS G1 MSM exploration Input: 0x000000000000000000000000000000000f89ff59d6cdf6a80a4bd2ef847d7328cdda8153f9119dc8252cba7cbc065e7ce635d2eb538044387eea8db2219537a9000000000000000000000000000000000a3468224c7a9d4df13ab6a64fe7fd3eb6ecb716156646f0eced5708f69f994061bba0a3a4b741bc4f9c23ba69ef061ec1828e413dd0b08fdbb04763c308d2a013df3c193dd49d3a9633745f01c88eb70000000000000000000000000000000014c03a472acfd2837196af16b56a9c1519b443792aa8f14b100feab759c0b6b1938e126127f3d173495086dd50cedbd30000000000000000000000000000000002c20dcc4e6297a90b616c15dacae186a7c1cdd6d8fcd966cb73d02bc05ec242ea6d8aa9bef1af14a147c6a2b267b1393c40185d7f2594cb94d67ca0b72133e84869482dd62fd960879056142304d42a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e40e1db8fcbf3dbb91727e166ce0ec04bb2f18767b3448bee52e27ea1bababff00000000000000000000000000000000051d1dab66442184421fcb55a61c20c6923d156554229b4955668c7dffb3a78174e681472f0c162a6567ec5219e60f820000000000000000000000000000000018a1f5c6e281acc223e3f01d3a57831a3385be683887d035902ae6fc7b6e42c995553b7e1c66a43055400b0308c50bf69324ac82a05b52103cc501da438c983630b00b5b214f7329bcb332df877a740d0000000000000000000000000000000013529240d0dd34047826b80c7efe64af519fc3546ea1eaa11ba3cb2d34fcc5599d192d933137562f18852310676b5b3000000000000000000000000000000000056cea5afa7af7fc45a918727e19ed2c09f40352bd975af75cb3e369da2088fa1d596f584399046532401e40b32e01684f9f0ab9972051f489993ff43f551124ee6aca7644b3b159d2957a03b3ab8bab0000000000000000000000000000000006558d2dffd0361e5eb65fbe8b7244d2ecdfb5602a0be94f2dfbd3b5186a2ef105f24289e671d55a88754cdd4acc83b3000000000000000000000000000000001410a4c89d2cd95c2cc3b887bc46d32f779d935b5678234f22212bae81da8e78dfd3b6bc34b1aaaab2e235ee64c76c1f1c61cf76958db68e901b9b53298b684ccd1db78a3e9ff2ada5666b76217c92dd000000000000000000000000000000000cb01d33935474a2b4ea10afb5c657d2d48f418d81604f33531778300bdecc7140b3c2baa8811aff436576938a227066000000000000000000000000000000000ae4fceb8677d4d7fbdb1a07932648edffe82543fba4caf18b98508e1bc079f65dd066a1efa8baea4fd682c82d223cd6aa39b6b9978d9c743c5333dc3771fe5ce6e48f073b90b62d18ac14b7da956d32000000000000000000000000000000000d3306579eb93622e67fef53d8bb839f03651af8c8694bc22b5efbb7529f82dcd25bd30cdea21c489c9ff37490abea8900000000000000000000000000000000095a82b42b7551d947c0c5237d29b268bdc6563fec3adb6b38888c8e29f7e9590fd0e1bfd728c8301be6f47ead55ac5363fe50f3bc82261da2c96158247eb47b2131608386e7b094eac2e172d9a5fa0c000000000000000000000000000000000d3aff0f3b2e6f4878f15a81eabab5d8c9f765bc93ae0a2f0da5ed1941b4924bca4516661600c41a74beeb243695b52d0000000000000000000000000000000016ce48c345cce7cd395692cecbb8704bcb29645135c8ac366c4e5c40dead3c218814904df7d4c92cbb9aa956bbb1deabc03d1856de9cf1e3403fb4278b85c65685c1723eb5d0a2437769ef423476cb11 Output: 0000000000000000000000000000000011ed5c29653e93c0d6f3e39e82cd916958e091eefc94659b3a08fc2df138e8f1b9eb8ba7f7370d72a66195b8e7cf39f80000000000000000000000000000000012c3e6183bb3094f71b7b8e9ec4b73e4b9f71cf244a41739f148cc5f92e4b8bd7a00a0b29113fe5100d332af974e3ebb

3/3/2025
Read more from Marius van der Wijden
Published on HackMD