feat(L1): fork-gate AggregateVerifier proposal intervals for Cobalt

[0xth4nh]

What changed?

AggregateVerifier now carries both sets of proposal intervals and selects between them per game, instead of a single immutable pair.

• The two pairs are named for the block cadence they are calibrated to, not for the fork: SLOW_BLOCK_INTERVAL / SLOW_INTERMEDIATE_BLOCK_INTERVAL (600/30 at 2s) and FAST_BLOCK_INTERVAL / FAST_INTERMEDIATE_BLOCK_INTERVAL (6,000/300 at 200ms). Both spans are the same 20 minutes, which is the point.
• New IntervalConfig constructor struct: slowBlockInterval, slowIntermediateBlockInterval, fastBlockInterval, fastIntermediateBlockInterval (replaces the two loose uint256 params).
• New _firstFastBlock(), extracted from _l2Timestamp() so the fork boundary is derived in exactly one place from the existing ProtocolVersions schedule (FAST_BLOCK_UPGRADE_INDEX = 13). _l2Timestamp() behaviour is unchanged. _legacyL2Timestamp() becomes _slowL2Timestamp().
• Public view intervalsForStartingBlock(uint256) drives the two fork-sensitive call sites — the UnexpectedBlockNumber check in initializeWithInitData, and the sequence numbers in _getStartingIntermediateRootAndL2SequenceNumbers — and lets the proposer and challenger resolve a game's intervals without a clone. initializeWithInitData resolves _firstFastBlock() once and threads it into both its interval selection and _l2Timestamp, so it reads PROTOCOL_VERSIONS.getSchedule() once rather than twice.
• New error MismatchedIntermediateRootCount. The constructor requires both pairs to yield the same intermediate root count.
• Semver 0.1.0 → 0.2.0; ABI and semver-lock snapshots regenerated.
• Deploy plumbing: the config keys become multiproofSlowBlockInterval / multiproofSlowIntermediateBlockInterval / multiproofFastBlockInterval / multiproofFastIntermediateBlockInterval across DeployConfig, SystemDeploy, and deploy-config/local.json; the two dev deploy virtuals collapse into one _intervalConfig(). Interval validation lives only in the constructor — SystemDeploy does not restate it, because a partial copy there would read as full validation while skipping the ratio check.
• SeedGames.s.sol reads the block interval and intermediate root count off the deployed implementation instead of hardcoding 600/30, which would otherwise seed unopenable games on a devnet with Cobalt active. generate-roots.sh has no L1 RPC to read from, so its two intervals became env-overridable with the slow-cadence values as defaults; seeding aborts on a mismatched roots file rather than creating bad games.

⚠️ Breaking: BLOCK_INTERVAL() and INTERMEDIATE_BLOCK_INTERVAL() are gone from the 0.2.0 ABI

They are SLOW_BLOCK_INTERVAL() and SLOW_INTERMEDIATE_BLOCK_INTERVAL() now. This is deliberate rather than incidental: a consumer that calls BLOCK_INTERVAL() on a fast-cadence game today gets a plausible-but-wrong number, and a missing method is a better failure mode than a wrong answer. It turns the migration to intervalsForStartingBlock() — which the offchain follow-ups below already require — into a compile error instead of a silent miscalculation.

In-flight 0.1.0 clones keep exposing the old names, so tooling needs both paths during the transition regardless.

Cobalt is now named in exactly one place in the contract, on FAST_BLOCK_UPGRADE_INDEX (ProtocolVersions index 12), which is the only spot pinned to a specific hardfork. A later cadence change is a new index and a new interval pair, not new machinery.

Why?

Cobalt drops the L2 block time from 2s to 200ms. To keep the proposal range at 20 minutes, the block interval goes 600 → 6,000 and the intermediate interval 30 → 300. Those are immutable today, so the fork would need a contract swap timed to the activation.

Carrying both sets on one implementation means we deploy and upgrade before Cobalt and nothing has to happen during the fork. This is section 1 of the proof config switchover doc.

Two design points, both reviewed and now documented in-code:

1. Selection is on the game's starting block, not its ending block. Selecting on the end block would break the chain invariant end == parent.end + blockInterval for the game spanning the activation. Selecting on the start block keeps the chain contiguous and produces exactly one straddling game — the one whose range contains the activation block — proven under the slow-block 600-interval. That is correct because provers apply fork rules per block by timestamp, not per game. This was the doc's open decision; it is resolved as acceptable.

   Note the deliberate asymmetry this creates inside initializeWithInitData: intervals are selected from the starting block while scheduleId is pinned from the ending block. That is what makes the straddling game work — it spans the slow-block interval its start selects, while pinning the post-Cobalt schedule its end falls under, so the prover knows Cobalt is active for the blocks past the boundary. There is now a comment saying so.

2. The activation block is re-derived live rather than pinned into storage. This is safe in both directions:

   • A game that selected the fast-block intervals starts at or past the activation, so the activation is in the past, and ProtocolVersions._assertNotFrozen rejects every mutation of a passed activation — from setTimestamp and delayTimestamp alike. That selection can never be revoked.
   • A game that selected the slow-block intervals cannot be pulled across the boundary either, including by the owner moving the activation earlier rather than delaying it. initializeWithInitData rejects a game whose ending L2 timestamp L1 has not yet reached, so every initialized game satisfies startingTimestamp < endingTimestamp <= block.timestamp, while any new activation must clear block.timestamp + MIN_NOTICE.

   It also keeps the diff free of a new storage slot — AggregateVerifier is at 20,346 / 24,576 bytes (82.8%) after this change, up from 20,059.

The intermediate root count is 20 on both sides (600/30 = 6000/300), so intermediateOutputRootsCount(), INITIALIZE_CALLDATA_SIZE, and every CWIA extraData offset are byte-identical across the fork. The constructor enforces this rather than assuming it — otherwise parsing extraData would need the root count, which would need the interval, which would need the starting block, which lives in extraData.

How to test?

cd contracts
just deps                # or: forge install
forge build
forge test               # 1232 passed, 0 failed, 1 skipped

The FFI-backed suites (test/libraries/trie/*, test/libraries/Hashing.t.sol, test/L1/OptimismPortal2.t.sol) need the Go helper built first, otherwise they fail on a missing binary unrelated to this change:

cd scripts/go-ffi && go build -o go-ffi . && cd -

Targeted run for this change:

forge test --match-path 'test/L1/proofs/AggregateVerifier.t.sol' -vv

New tests, all in test/L1/proofs/AggregateVerifier.t.sol (test fixtures use 100/10 slow and 1000/100 fast, same 10:1 ratio):

Test	Asserts
test_intervalsForStartingBlock_selectsOnFirstFastBlock_succeeds	Activation at L2 block 50: block 49 → (100, 10); blocks 50 and 51 → (1000, 100).
test_intervalsForStartingBlock_speedupUnscheduled_succeeds	No Cobalt entry in the schedule → slow-cadence intervals for every starting block.
test_initialize_fastIntervals_succeeds	Activation at genesis: a game ending at block 100 reverts UnexpectedBlockNumber(1000, 100); a game ending at 1000 initializes.
test_initialize_straddlingGame_usesSlowInterval_succeeds	Activation at block 50, inside the first game's [0, 100) range: ending at 1000 reverts UnexpectedBlockNumber(100, 1000); ending at 100 initializes.
test_challenge_fastIntermediateInterval_succeeds	Activation at genesis: challenging intermediate root 0 of a fast-block game hands the ZK verifier a journal covering [0, 100), not [0, 10).
test_challenge_straddlingGameUsesSlowIntermediateInterval_succeeds	Activation at block 50: the straddling game's sub-ranges stay slow-block sized — root 0 covers [0, 10).
test_constructor_mismatchedIntermediateRootCount_reverts	(100, 10, 1000, 200) → MismatchedIntermediateRootCount(10, 5).
test_constructor_invalidFastBlockIntervals_reverts	fastIntermediateBlockInterval = 0 → InvalidBlockInterval(1000, 0).

The two test_challenge_* cases cover _getStartingIntermediateRootAndL2SequenceNumbers, the second fork-sensitive call site and the one whose output goes into the journal the prover signs — a stale interval there makes a valid challenge unconstructable rather than reverting loudly. They assert by matching the exact IVerifier.verify call, since the mock verifier accepts any payload; both fail if the opposite interval is substituted.

Snapshot and lint checks (just recipes, expanded so they run without just):

forge fmt --check $(git diff --name-only origin/main -- '*.sol')
forge build --force --skip "/**/test/**" --skip "/**/scripts/**"
go run ./scripts/autogen/generate-snapshots .
go run scripts/autogen/generate-semver-lock/main.go
git diff --exit-code snapshots/     # clean

Two repo checks fail on main as well as here, neither involving AggregateVerifier: go run ./scripts/checks/interfaces (IERC721, IDisputeGameFactory, FeeDisburser, BalanceTracker) and go run ./scripts/checks/test-validation.

Follow-ups (not in this PR)

The zero-arg interval views can no longer answer without game context, and the old names are gone. Offchain consumers must move to intervalsForStartingBlock():

• base/base crates/proof/contracts/src/aggregate_verifier.rs — the generated bindings. These will fail to compile against the new ABI, which is the intended forcing function.
• base/base crates/proof/challenge/src/scanner.rs resolve_intermediate_block_interval() — caches the interval per implementation address, so once one implementation serves both sides it returns a single value for all games. The doc lists GameScanner as already correct; it is not, and the doc needs correcting.
• Proposer must pick the interval for the game it is about to create.

Per the doc's sequencing, the proposer and challenger changes must be deployed before this implementation is swapped in, even though this PR can merge first.

---

Update — retargeted to Cobalt

FAST_BLOCK_UPGRADE_INDEX was 13 (Denim). It is now 12 (Cobalt), per review. The Base mainnet ProtocolVersions schedule is 13 entries long with schedule[12] = 0, so at index 13 _firstFastBlock() was always short-circuiting on the schedule.length <= FAST_BLOCK_UPGRADE_INDEX guard and returning type(uint256).max — the speedup could never activate. Also folded the early-genesis branch of _firstFastBlock into an early return, and renamed the remaining Denim mentions under scripts/multiproof.

The branch name still says denim; renaming it would close and reopen the PR, so it stays.

[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

[0x00101010]

We need to change this to 12 now to target Cobalt

[0xth4nh]

Fixed in fa0584d: FAST_BLOCK_UPGRADE_INDEX is now 12, and the doc comment names Cobalt. Confirmed against test/L1/ProtocolVersions.t.sol — the Base mainnet schedule is 13 entries with schedule[12] = 0 (Cobalt unscheduled), so at 13 _firstFastBlock was hitting the schedule.length <= FAST_BLOCK_UPGRADE_INDEX guard and returning type(uint256).max unconditionally. Also renamed the remaining Denim mentions in scripts/multiproof.

[0xth4nh]

Following up on this one — the change is in (FAST_BLOCK_UPGRADE_INDEX = 12), but I want to flag something before it merges, because I think index 12 and the node disagree about which fork carries the speedup.

In base/base, the 200ms cadence is gated on Denim, not Cobalt, in ~26 production call sites:

• RollupConfig::l2_block_timestamp_millis switches to NATIVE_SUBSECOND_BLOCK_INTERVAL_MILLIS = 200 at denim_activation_block_number() — crates/common/genesis/src/rollup.rs:369,409-427
• the sequencer's block interval: if self.rollup_config.is_denim_active(...) { Duration::from_millis(NATIVE_SUBSECOND...) } — crates/consensus/service/src/actors/sequencer/actor.rs:345
• payload builder, engine API, execution consensus, builder multiplex all branch on is_denim_active_at_timestamp
• BaseTime predeploy is staged behind Denim — crates/common/evm/src/base_time.rs:107

Cobalt in the node is a different fork entirely — EIP-8130 system accounts (crates/common/evm/src/cobalt.rs:51) and B-20 permit metering (#4891). Nothing in it touches block time.

So as written, this contract switches proposals to FAST_BLOCK_INTERVAL / FAST_INTERMEDIATE_BLOCK_INTERVAL when Cobalt activates, while L2 is still producing 2s blocks until Denim. That's 6,000 blocks × 2s ≈ 3.3-hour game ranges over the whole Cobalt→Denim window, instead of the intended 20 minutes.

Two ways to read it, and I don't know which is right:

1. The speedup really has moved from Denim to Cobalt at the protocol level. Then this constant is correct and base/base needs its Denim gate re-pointed at Cobalt — a much bigger change that the node folks would own.
2. The concern was that index 13 doesn't exist yet — test/L1/ProtocolVersions.t.sol:1145 pins the Base mainnet schedule at 13 entries ending with schedule[12] = 0 // Cobalt is unscheduled, so at 13 _firstFastBlock() hits the schedule.length <= FAST_BLOCK_UPGRADE_INDEX guard and returns type(uint256).max. Worth noting that's fail-safe rather than broken: it just means the fast cadence can't activate until Denim is registered, which per the rollout plan happens before the timestamp is ever scheduled.

Which is it? Happy to move it back to 13 if it's (2), or leave it at 12 and get the node-side re-gating filed if it's (1) — but I don't think we want them pointing at different forks either way.

[0x00101010]

nit, prefer it like this:

Suggested change

	uint256 blocksUntilFast;
	if (fastActivationTimestamp > L2_GENESIS_TIMESTAMP) {
	blocksUntilFast = FixedPointMathLib.divUp(fastActivationTimestamp - L2_GENESIS_TIMESTAMP, L2_BLOCK_TIME);
	}
	return L2_GENESIS_BLOCK_NUMBER + blocksUntilFast;
	}
	if (fastActivationTimestamp <= L2_GENESIS_TIMESTAMP) {
	return L2_GENESIS_BLOCK_NUMBER;
	}
	return L2_GENESIS_BLOCK_NUMBER + FixedPointMathLib.divUp(fastActivationTimestamp - L2_GENESIS_TIMESTAMP, L2_BLOCK_TIME);
	}

[0xth4nh]

Fixed in fa0584d: applied, with the return wrapped to stay inside the line limit.