fix(zk): source intermediate root interval from on-chain like TEE

[mw2000]

Summary

The ZK prover hardcoded DEFAULT_INTERMEDIATE_ROOT_INTERVAL = 10, but the on-chain AggregateVerifier may use a different value (e.g. 30 on Sepolia). This mismatch causes ZK challenge proofs to fail verification.

Fix

Collapse to a single source matching the TEE — chain → ProofRequest → BootInfo → executor:

• Validity binary reads INTERMEDIATE_BLOCK_INTERVAL on startup (DGF → impl → AggregateVerifier) and threads it into ProofRequest.intermediate_block_interval.
• Host preimage server answers boot key 9 with the on-chain value.
• Both the SP1 range program and the native WitnessExecutor now read the interval from BootInfo, the same channel the TEE enclave uses.
• Falls back to DEFAULT_INTERMEDIATE_ROOT_INTERVAL only when DGF is unset or the chain read fails.

Removed (now redundant)

• INTERMEDIATE_ROOT_INTERVAL env var
• SP1 stdin scalar (host write + guest read)
• Interval params on WitnessExecutor::run and WitnessGenerator::get_sp1_stdin

Notes

• Range ELF source changed → rebuild once and update range_vkey_commitment. The ELF then accepts any on-chain interval without rebuilding (interval is data, not code).
• Aggregation program is unchanged.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
base	Ignored	Preview	May 1, 2026 0:00am

[mw2000]

Attached to linear issue CHAIN-4080

[github-actions]

Pre-existing, but since you're touching this file: per workspace conventions (CLAUDE.md), each mod declaration should be grouped with its pub use re-export:

mod intermediate_interval;
pub use intermediate_interval::*;

rather than listing all mods then all pub uses. This applies to the entire file but is a pre-existing issue — flagging only because you're adding a new module here.

[jackchuma]

Generally looks good to me. Can we add enforcement somewhere that the range proof block intervals are always a multiple of the intermediate block interval?

[github-actions]

This divisibility check is vacuous when evm_gas_limit > 0 and range_proof_interval == 0 (the gas-based splitting mode): 0u64.is_multiple_of(x) is always true because 0 = 0·x.

In gas-based mode the actual range sizes are determined dynamically by EVM gas consumption, so there is no static range_proof_interval to validate. If those dynamically-computed ranges aren't multiples of intermediate_root_interval, proofs will still fail on-chain verification — exactly the scenario the error message warns about.

Consider either:

• Skipping this check when range_proof_interval == 0 with a comment explaining why gas-based ranges enforce the invariant elsewhere, or
• Requiring that the gas-based splitting logic aligns ranges to intermediate_root_interval boundaries (and documenting that guarantee here).

[github-actions]

Silent .max(1) clamp on an interval of 0 hides a misconfiguration that would produce proofs with the wrong sampling rate. The PR validates != 0 at the gRPC boundary and in RequesterConfig::validate(), but this executor is also reachable from WitnessGenerator::generate_witness_data (the native witness-gen path in traits.rs) which doesn't pass through either validation gate.

Consider replacing this with a hard error:

Suggested change

	let intermediate_block_interval = boot.intermediate_block_interval.max(1);
	let intermediate_block_interval = if boot.intermediate_block_interval == 0 {
	anyhow::bail!("intermediate_block_interval in BootInfo is 0; this indicates a misconfigured preimage server");
	} else {
	boot.intermediate_block_interval
	};

This is consistent with the PR's philosophy of refusing to proceed with a wrong interval.

[github-actions]

This divisibility check is vacuous when evm_gas_limit > 0 and range_proof_interval == 0 (gas-based splitting mode): 0u64.is_multiple_of(x) is always true because 0 = 0 * x.

In gas-based mode the actual range sizes are determined dynamically by EVM gas consumption, so there is no static range_proof_interval to validate against. If those dynamically-computed ranges aren't aligned to intermediate_root_interval boundaries, proofs will still fail on-chain verification -- exactly the scenario the error message warns about.

Consider either:

• Skipping this check when range_proof_interval == 0 with a comment explaining that gas-based range splitting enforces the invariant elsewhere, or
• Adding a guard in the gas-based splitting logic that snaps ranges to intermediate_root_interval boundaries (and documenting that guarantee here).

[github-actions]

Silent .max(1) clamp hides a misconfiguration that would produce proofs with the wrong sampling rate. The PR validates != 0 at the gRPC boundary and in RequesterConfig::validate(), but this executor is also reachable from WitnessGenerator::generate_witness_data (the native witness-gen path in traits.rs:77) which doesn't pass through either validation gate.

Consider replacing this with a hard error so a zero interval is caught regardless of entry point:

Suggested change

	let intermediate_block_interval = boot.intermediate_block_interval.max(1);
	let intermediate_block_interval = if boot.intermediate_block_interval == 0 {
	anyhow::bail!("intermediate_block_interval in BootInfo is 0; this indicates a misconfigured preimage server");
	} else {
	boot.intermediate_block_interval
	};

This is consistent with the PR's philosophy of refusing to proceed with a wrong interval.

[github-actions]

Per workspace conventions, dependencies should be sorted by line length (waterfall style). base-proof-contracts (22 chars) is longer than anyhow (6 chars) above it and longer than dotenv, serde, serde_json, and reqwest below it. Consider reordering so it sits among the other base-proof-* local crates (lines 25-29) where it fits naturally by both grouping and length.

Approved review 4205898775 from jackchuma is now dismissed due to new commit. Re-request for approval.

[github-actions]

This divisibility check is vacuous in gas-based splitting mode (evm_gas_limit > 0, range_proof_interval == 0): 0u64.is_multiple_of(x) is always true because 0 = 0 * x.

In that mode, actual range sizes are determined dynamically by EVM gas consumption, so there's no static range_proof_interval to validate. If those dynamically-computed ranges aren't aligned to intermediate_root_interval boundaries, proofs will still fail on-chain verification.

Consider either:

• Skipping this check when range_proof_interval == 0 (with a comment documenting that the gas-based splitting logic is responsible for alignment), or
• Ensuring the gas-based range splitting snaps to intermediate_root_interval boundaries.

[github-actions]

Silent .max(1) clamp hides a misconfiguration. This executor is reachable from WitnessGenerator::generate_witness_data (in traits.rs:77) which doesn't pass through the gRPC validation or RequesterConfig::validate() gates, so a zero intermediate_block_interval in BootInfo would silently produce proofs with interval 1.

Since the PR's goal is to refuse proceeding with a wrong interval, consider returning an error here instead:

Suggested change

	let intermediate_block_interval = boot.intermediate_block_interval.max(1);
	let intermediate_block_interval = if boot.intermediate_block_interval == 0 {
	anyhow::bail!("intermediate_block_interval in BootInfo is 0; this indicates a misconfigured preimage server");
	} else {
	boot.intermediate_block_interval
	};

[github-actions]

Review Summary

The overall design is sound — collapsing the intermediate root interval to a single on-chain source of truth (matching the TEE path) eliminates an important class of silent proof failures. The plumbing through gRPC, database, host, and executor is thorough.

Findings

1. Divisibility validation is vacuous in gas-based mode (config.rs:160-165)

When evm_gas_limit > 0 and range_proof_interval == 0 (gas-based splitting), 0u64.is_multiple_of(x) is always true. The actual range sizes are computed dynamically by gas consumption and aren't validated against intermediate_root_interval. Misaligned gas-based ranges would silently produce proofs that fail on-chain.

2. Silent .max(1) clamp on zero interval (executor.rs:144)

The executor is reachable from WitnessGenerator::generate_witness_data (traits.rs:77), which bypasses both gRPC validation and RequesterConfig::validate(). A zero intermediate_block_interval in BootInfo would be silently clamped to 1, producing proofs with the wrong sampling rate — exactly the failure mode this PR aims to prevent. Consider returning an error instead.

Both findings have inline comments with suggested fixes.