Use canonical Denim timestamps for proof schedule pinning

[0x00101010]

• Derive the proof schedule timestamp from the canonical Denim-aware block-number mapping.
• Keep malformed-config failures strict while preserving existing saturating timestamp APIs.

[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 0 Sum 1

[github-actions]

Review Summary

PR: Use canonical Denim timestamps for proof schedule pinning

This PR adds a checked_l2_block_timestamp method to RollupConfig that computes the whole-second L2 block timestamp using checked arithmetic (returning Option<u64> instead of saturating), and is Denim-aware. It then replaces the inline, Denim-unaware timestamp calculation in BootInfo::load with this new method.

Analysis:

• The new checked_l2_block_timestamp correctly mirrors the existing l2_block_timestamp_millis logic but with checked arithmetic and Option return. The u128 intermediate in the Denim path prevents overflow during the millis-to-seconds conversion.
• The old BootInfo::load code computed blocks_since_genesis * block_time + l2_time which ignores the Denim subsecond cadence — post-Denim blocks would have been pinned using an incorrect (pre-Denim) timestamp. This was a real bug.
• Guard chain in BootInfo::load ensures schedule_l2_block_number >= genesis.l2.number before checked_l2_block_timestamp is called, so the checked_sub inside never returns None in practice.
• The block_time == 0 early return in checked_l2_block_timestamp prevents reaching denim_activation_block_number() which panics on zero block time.
• Test coverage is thorough: Denim cadence consistency with the saturating variant, overflow rejection, pre-genesis rejection, and the boot.rs integration test covers pre-Denim, post-Denim, and Zenith-rejection scenarios.

No findings. The changes are correct and well-tested.

[github-actions]

Base Std historical fork tests

Fork	Result	Passed	Failed	Skipped	base/base	base-anvil	base-std
Beryl	pass	616	0	13	04d8b29d	8d0f5b8a	4658f1b7
Cobalt	pass	721	0	14	04d8b29d	9df661bc	e30b3421

View run

[github-actions]

Tip

Nice, this PR improves performance. 3 benchmark(s) faster by more than 10% beyond the noise band: tx_selection_predicate_index/parked=100000_state=unique (-15.6%), tx_selection_predicate_index/parked=10000_state=unique (-15.7%), tx_selection_predicate_index/parked=1000_state=unique (-15.6%).

Benchmark results (advisory)

Median time on the PR head versus the base branch, measured on the same host. Wall-clock, so a change is only flagged when it clears ±10% and the confidence intervals do not overlap. Only benchmarks past the ±10% threshold (plus new or dropped ones) are listed. This check never blocks a merge.

Benchmark	Base	Head	Δ median
tx_selection_predicate_index/parked=100000_state=unique	90.5 ns	76.4 ns	-15.6% ✅ faster
tx_selection_predicate_index/parked=10000_state=unique	90.5 ns	76.3 ns	-15.7% ✅ faster
tx_selection_predicate_index/parked=1000_state=unique	90.5 ns	76.3 ns	-15.6% ✅ faster

46 benchmark(s) within ±10% omitted.

View run · Re-run benchmarks