feat: network-wide consensus config with validation and override protection (A-1168)

[spalladino]

Summary

Identifies and enforces the configuration values that must be identical across all nodes of a network (A-1168), sourcing per-network values from the generated network config. Prevents operators from overriding them unless a new ALLOW_OVERRIDING_NETWORK_CONFIG flag is set.

Also:

• Adds a validation step in CI for the generated network configs.
• Fixes a parse error for per-block allocation multipliers.
• Enshrines max blocks per checkpoint as a consensus-wide config entry, checking it is sound wrt block times.

Network-wide consensus values

stdlib/src/config/network-consensus-config.ts defines NETWORK_CONSENSUS_ENV_VARS, the env vars required to be the same for every node of a network, in three categories:

• Timing/protocol consensus: ETHEREUM_SLOT_DURATION, AZTEC_SLOT_DURATION, AZTEC_EPOCH_DURATION, SEQ_BLOCK_DURATION_MS, MAX_BLOCKS_PER_CHECKPOINT, CHECKPOINT_PROPOSAL_SYNC_GRACE_SECONDS.
• Network identity / L1-posted deployment params: chain id, committee size, lags, staking thresholds, mana target, proving cost, governance/slashing contract params, slash amounts.
• Node-side slashing offense params (SLASH_*): validators must agree on these to reach slashing quorum.

Per-network values live in spartan/environments/network-defaults.yml (the source of cli/src/config/generated/networks.ts). This PR adds the two missing ones — MAX_BLOCKS_PER_CHECKPOINT: 10 and CHECKPOINT_PROPOSAL_SYNC_GRACE_SECONDS: 12 — to the shared prodlike section, and makes devnet's AZTEC_SLASHING_QUORUM: 17 / AZTEC_GOVERNANCE_PROPOSER_QUORUM: 151 explicit (values match the Solidity vm.envOr defaults, so deployment behavior is unchanged). maxBlocksPerCheckpoint is an explicit network value rather than derived per node, so nodes with different operational budgets cannot diverge on checkpoint geometry; mainnet/testnet/devnet geometry (72s slots, 12s L1 slots, 6s blocks) derives exactly 10.

NetworkConsensusConfig is composed by Picking fields from L1ContractsConfig and SequencerConfig, and getConsensusConfigFromNetworkEnv derives env names and parsing from the canonical config mappings, so each field is parsed exactly as the node's config layer would parse it.

Enforcement layers

• Compile time: chain_l2_config.ts asserts (via satisfies) that every generated network config defines every consensus-critical var; a @ts-expect-error compile gate in the test file proves the assertion actually rejects configs missing a var.
• CI: cli/src/config/chain_l2_config.test.ts validates each generated network config with validateNetworkConsensusConfig, which requires MAX_BLOCKS_PER_CHECKPOINT to be exactly what a ProposerTimetable at the production default budgets derives, plus basic geometry soundness (slot multiples, sub-slot fits in slot, etc.).
• Startup (cli path): enrichEnvironmentWithChainName calls the pure checkConsensusEnvOverrides before enriching: a consensus var already set in the env to a value diverging from the network config makes startup throw, unless ALLOW_OVERRIDING_NETWORK_CONFIG=1 is set (then it warns and keeps the operator value). The check returns canonical rewrites for numerically-equal-but-noncanonical values (e.g. 6e3, which parseInt-based config parsing would read as 6), which the cli enrichment layer applies to the env.
• Startup (node): AztecNodeService verifies the rollup contract reports the same aztecSlotDuration/aztecEpochDuration the node is configured with, and throws on mismatch. These are the only L1-timing fields the node config carries that the rollup exposes; the other rollup params (committee size, lags, proof submission epochs, mana limit) are read from L1 directly rather than from config.

Where maxBlocksPerCheckpoint applies

• Proposer: the sequencer's ProposerTimetable computes the locally achievable count from operational budgets and clamps it down to the network value when the network value is lower; sub-slot selection never starts a block past the effective count. When local budgets compute more than the network allows, the timetable warns through an injected logger.
• Gossip validation: proposal_validator.ts rejects (and penalizes peers for) block proposals with indexWithinCheckpoint >= min(maxBlocksPerCheckpoint, MAX_ATTESTABLE_BLOCKS_PER_CHECKPOINT).
• Attestation: proposal_handler.ts refuses to attest to checkpoint proposals with more blocks than the configured value; checkpoint_builder.ts caps the blocks it assembles.
• Gossipsub scoring: peer-rate thresholds are sized from the network config value directly; the gossip layer now uses a plain ConsensusTimetable and no longer depends on proposer operational budgets (which were also dropped from P2PConfig).

Also in this PR

• MIN_PER_BLOCK_ALLOCATION_MULTIPLIER = 1.2 / MIN_PER_BLOCK_DA_ALLOCATION_MULTIPLIER = 1.5 live in @aztec/constants; the sequencer rejects multipliers below the minimum, and SEQ_PER_BLOCK_ALLOCATION_MULTIPLIER switched from numberConfigHelper (parseInt truncated 1.5 to 1) to floatConfigHelper (mirrors fix(gas)!: client fallback limits track network per-block budget (A-1154) #23947; deliberate copy, conflicts to be resolved when either lands).
• Removed the redundant checkpointProposalSyncGraceSeconds defaulting in node createAndSync; every consumer (archiver factory, sequencer, p2p timetable) has its own fallback.

Spartan deployments

Existing spartan networks that intentionally diverge from the generated defaults keep deploying: devnet.env (36s slots, committee size 1) and testnet.env (slashing round size 2 epochs) now set ALLOW_OVERRIDING_NETWORK_CONFIG=true, plumbed through deploy_network.sh into both the deploy-rollup-contracts job env and every aztec-image helm release (new global.allowOverridingNetworkConfig rendered by the shared aztec-node pod template). AZTEC_SLOT_DURATION/AZTEC_EPOCH_DURATION are also passed through to node pods so devnet nodes carry the real deployed 36s value and pass the rollup cross-check instead of inheriting the generated 72s default. mainnet/staging/next-net set no conflicting consensus vars and are untouched, so enforcement stays loud by default.

Known limitations

• MIN_PER_BLOCK_DA_ALLOCATION_MULTIPLIER documents the network minimum only; its operator knob and runtime enforcement land with fix(gas)!: client fallback limits track network per-block budget (A-1154) #23947.
• The remote network_config.json enrichment runs before enrichEnvironmentWithChainName, so a consensus value pushed via the networks repo that diverges from the binary's generated defaults will also be refused at startup (the live JSON sets no consensus values today).
• ethereumSlotDuration cannot be cross-checked against the rollup contract (no getter); it is enforced via env only on named networks.