ACDT #98 · 200M gas limit Execution safety confirmed
AllCoreDevs - Testing #098 · 2026-09-28
200M gas blocks are safe, slow blocks were caused by debug logging
With the slow blocks on Devnet 8 confirmed to be caused by debug tracing, there was no disagreement on the conclusion that a 200M gas limit is safe from an execution time perspective. For the new block tag for the Fast Confirmation Rule (FCR), the name 'confirmed' was preferred, and the direction of introducing it as an optional feature without a hard fork was agreed.
Why it matters
As evidence accumulates that raising the gas limit to 200M is safe, mainnet moves a step closer to higher throughput and lower fees. Also, once the confirmed tag is introduced, bridges and L2s can use quickly confirmed blocks in a standard way without waiting for a hard fork.
Decisions
- 200M gas safe: There was no disagreement on the conclusion that a 200M gas limit is safe from an execution time perspective and that the slow blocks on Devnet 8 were caused by debug tracing. Whether to do gas repricing was left open until measurement results with tracing turned off are available.
- Tracing re-run: They decided to re-run the experiment with debug tracing turned off both now on Devnet 8 and in about 1.5 to 2 weeks on a mainnet shadow fork. This means verifying in both environments, not just one of them.
- confirmed tag: For the new block tag name, 'confirmed' was preferred over 'fast' or 'fcr'. The name to use when querying quickly confirmed blocks is effectively settled.
- No hard fork needed for FCR: There was no disagreement that the FCR block tag needs no hard fork and that only nodes running a compatible CL and EL combination opt in. This means most node operators do not need to change anything, and the implementation approach will be investigated further.
Discussion
Is the 200M gas limit really safe
On the last execution layer call (ACDE), the safety of the 200M gas limit was questioned based on slow blocks on Devnet 8, and this call shared the results of an in-depth analysis.
Outcome: Decision 00:19:34
New block tag for the Fast Confirmation Rule
Adoption has started, with Chainlink running FCR that day, but RPC providers are blocked by backward compatibility issues with the existing safe tag, so a proposal was made to create a new tag instead of reusing safe.
Outcome: Decision 00:33:25
JUMPDEST attack, the gap between devnet and benchmark
The same JUMPDEST analysis attack takes a worst case of 2.5 seconds in the Benchmark Core but about 5 seconds for a 100M gas block on Devnet 8, so the cause of the gap and the need for gas repricing were discussed.
Glossary
- FCR: Fast Confirmation Rule. A rule that treats a block as confirmed much earlier than finality
- Block tag: A label in RPC, such as latest, safe, or finalized, that points to a block in a particular state
- FCU: forkchoiceUpdated. An Engine API call in which the CL tells the EL about the chain head and the safe and finalized blocks
- JUMPDEST analysis: The process in which the EVM scans a contract for valid jump destinations before executing it. It was used in attacks that slow nodes down by forcing repeated loads of large code
- Debug tracing: A feature that records every step of block execution as JSON. Its gigabyte-scale output slows a node down significantly
- Shadow fork: A test that replicates the real network state to rehearse a fork in advance
- Benchmark Core: A benchmarking environment that runs only the EL, without a CL, on dedicated hardware to measure block execution time
- Devnet: A temporary development network for testing new fork features. The devnet-8 in this call is for Glamsterdam