# Repricing session Focused on repricings, not on EVM improvements ## Glamsterdam - [EIP-8007: Glamsterdam Gas Repricings](https://eips.ethereum.org/EIPS/eip-8007) 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 - Modexp: 3x ? Maybe unnecessary after Fusaka - Point evaluation (kzg): 3x - Keccak: 2x - G1Add: 1.5x, Blake 1.5x, ecAdd 1.5x, g2Add 1.5x, Ecrecover, EcPairing - Targeting ~3 threads with BALs ### 8037 - Seperates state growth and state access - multi-dimensional metering - 16MGas tx limit for burst resources - cost per state byte dependent on gas limit ### 7778 - Remove refunds from gas calculation, otherwise worst case block can use ~20% more gas than gaslimit ### Calldata & AL - Need to reprice calldata - Also need eth/70 to go beyond 75MGas/block, otherwise receipts can exceed the 10MB network limit ## Benchmarks - Comprehensive Benchmarking suite from EF: https://github.com/ethereum/execution-specs/tree/forks/amsterdam/tests/benchmark - Benchmarkoor for executing tests, being released in the next few weeks ## H-Star - Work on block chunking to pass the 10MB limit for execution payload - Repricings for more operations, making things cheaper
Last changed by  
 
Marius van der Wijden
110

Read more

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
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

6/16/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