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	✅ 1/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	Apr 30, 2026 6:59am

[mw2000]

Attached to linear issue CHAIN-4080

[github-actions]

The proof_request DB model now carries intermediate_root_interval: Option<i64>, but this reconstruction discards it. Should be:

Suggested change

	intermediate_root_interval: None,
	intermediate_root_interval: proof_request.intermediate_root_interval.map(|v| v as u64),

Low severity since this only affects mock backend, but it's inconsistent with the goal of preserving the interval end-to-end. The mock build_mock_public_values doesn't use the interval today, but if it ever does (or if mock proof verification checks the field), this None would silently use the default.

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

[github-actions]

Review Summary

The direction is sound — collapsing to a single source-of-truth for intermediate_block_interval (on-chain AggregateVerifier → BootInfo → executor) eliminates the class of bugs where the ZK proposer disagrees with the contracts. The new WitnessParams struct, gRPC boundary validation, and database round-tripping are well done.

Findings

Medium — Vacuous validation in gas-based mode (config.rs:161)
0u64.is_multiple_of(x) is always true, so when evm_gas_limit > 0 and range_proof_interval == 0 (gas-based splitting), the divisibility check passes trivially. Dynamically-computed gas-based ranges could still violate the intermediate root boundary constraint without being caught here.

Medium — Silent .max(1) clamp in executor (executor.rs:144)
A zero intermediate_block_interval in BootInfo is silently clamped to 1 rather than producing a hard error. This executor path is reachable from WitnessGenerator::generate_witness_data which bypasses both the gRPC validation and RequesterConfig::validate(). Consistent with the PR philosophy, this should bail rather than silently produce proofs with an unexpected interval.

Low — Cargo.toml dependency ordering (validity/Cargo.toml:42)
base-proof-contracts is placed between anyhow and dotenv rather than grouped with the other base-proof-* local crates. This breaks the waterfall-by-length convention.

Note on stale comments from earlier revisions

Several existing inline comments from github-actions[bot] appear to be from earlier revisions and no longer apply to the current code:

• The "Bug: interval is never defined" comment — interval is properly bound on line 38
• The "ProveBlockRequestParams does not include intermediate_root_interval" comment — it now does (line 27)
• The "logic should be in library crate" comment — resolve_intermediate_root_interval is already in validity/src/intermediate_interval.rs
• The "on-chain value is not validated for > 0" comment — lines 39-42 check for zero
• The WitnessParams struct suggestion — the struct exists
• The url crate / reqwest::Url comments — no separate url dependency exists