Will Fault Proof Proposer support RANGE_PROOF_EVM_GAS_LIMIT for gas-based splitting?

[googgoog]

The validity proposer supports gas-based range splitting via RANGE_PROOF_EVM_GAS_LIMIT, which dynamically splits proof ranges based on EVM gas consumption. However, this feature is not available in the fault proof proposer.

Current Behavior

The fault proof proposer uses RANGE_SPLIT_COUNT to split ranges into a fixed number of segments (1-16), regardless of actual gas consumption per block.

For example, with PROPOSAL_INTERVAL_IN_BLOCKS=3600 and RANGE_SPLIT_COUNT=8:

• Low-load blocks (1 tx/block): splits into 8 segments of 450 blocks each ✅
• High-load blocks (100 tx/block): also splits into 8 segments of 450 blocks each ❌

In the high-load case, each segment may contain significantly more gas, potentially causing proof generation to fail or timeout.

Feature Comparison

Feature	Validity Proposer	Fault Proof Proposer
Gas-based splitting	✅ RANGE_PROOF_EVM_GAS_LIMIT	❌ Not supported
Block-based splitting	✅ RANGE_PROOF_INTERVAL	✅ PROPOSAL_INTERVAL_IN_BLOCKS
Fixed segment splitting	❌	✅ RANGE_SPLIT_COUNT (1-16)

Questions

1. Why doesn't the fault proof proposer support RANGE_PROOF_EVM_GAS_LIMIT currently?
2. Are there plans to add this feature in the future?

Thanks!

[Farhad-Shabani]

Hey @googgoog, thanks for the question!

We actually experimented with EVM gas-based splitting for fault proofs when building this feature. When we originally implemented gas-based splitting for the validity proposer, the assumption that EVM gas correlates with proving cost seemed strong—not perfect, but good enough. However, our recent experiments showed this correlation is less reliable. It also depends on factors EVM gas doesn't capture. For example, blocks heavy on cryptographic ops can have moderate EVM gas but very high proving cost. Since this can vary significantly across chains and workloads, we opted for a predictable static approach rather than a heuristic that may not reflect actual proving costs.

Our recommendation: tune your blocks interval + split count conservatively to handle your traffic patterns including spikes. Even with gas-based splitting on the validity side, tuning is still necessary.