Measure pallet timeouts in relay chain blocks, not parachain blocks

[ilchu]

Summary

Implements #233: every duration in pallet-storage-provider and the registry pallets — ChallengeTimeout, SettlementTimeout, RequestTimeout, checkpoint interval/grace, DeregisterAnnouncementPeriod, MaxNonceAge, agreement durations/extensions, drive expiry, replica min_sync_interval — is now measured in relay chain blocks instead of parachain blocks, so nothing silently rescales when the parachain moves to 2s blocks (#113 / #131).

Closes #233.

On-chain

• New Config::BlockNumberProvider on pallet-storage-provider; all block-number reads route through Pallet::current_anchor_block(). The drive/s3 registries reuse it via their Config supertrait — no new Config items there. Runtimes wire cumulus_pallet_parachain_system::RelaychainDataProvider; mocks wire System, so existing tests drive the clock unchanged.
• The pallet exposes the "anchor block" abstraction to off-chain consumers via two runtime APIs, so nothing outside the runtime needs to know which block notion the pallet uses (relay today, whatever later): current_anchor_block() (the clock) and anchor_block_time_millis() (its tick, backed by #[pallet::constant] Config::AnchorBlockTimeMillis, declared in each runtime right next to the BlockNumberProvider it describes; integrity_test rejects zero).
• Challenge slash sweep redesign (the one non-mechanical part, flagged in the issue comments): the old on_finalize(n) point-lookup breaks because relay numbers advance by a variable amount (including zero) between consecutive parachain blocks. Replaced with a drain-range sweep in on_initialize tracking a LastSweptChallengeBlock cursor. It drains only deadline keys strictly below the previous block's relay parent (provably unrespondable — the validation-data inherent hasn't run yet in on_initialize, and every later block's relay parent is ≥ that value), and returns the exact weight consumed instead of the old reserve-in-on_init / work-in-on_finalize split, which cannot be kept sound under the two-clock asymmetry. Two independent bounds protect the block budget: a 32-key span cap on probing, and a per-block slash budget of min(MaxChallengesPerDeadline, MAX_SWEEP_SLASH_BUDGET = 100) so one fully-loaded deadline cannot eat the block's PoV. On budget exhaustion the cursor parks below the partially drained key and carries over.
• Timing constants in both runtimes now derive from a new relay_time module anchored to RELAY_CHAIN_SLOT_DURATION_MILLIS rather than MILLISECS_PER_BLOCK — numerically identical today (6s == 6s), but Support for 3 async cores #131's 2s switch no longer touches them.
• Benchmarks advance both clocks (RelaychainDataProvider::set_block_number is available under runtime-benchmarks); the paseo runtime tests gained a set_clocks helper for the same reason.

Off-chain (same PR to keep e2e green)

• Provider node: chain_state.current_anchor_block tracks the pallet's clock at each finalized block via the current_anchor_block runtime API (raw state_call + manual decode, so the API needn't be in the node's metadata snapshot), so /negotiate's valid_until and the checkpoint window math stay consistent with the pallet.
• Rust SDK: ChallengerClient::analyze_provider measures last_checkpoint_age on the anchor clock (shared fetch_current_anchor_block helper in client/src/substrate.rs) instead of subtracting a relay-denominated checkpoint_block from the parachain head. Against a pre-anchor runtime this now errors loudly rather than producing a silently wrong Challenge/Monitor/Skip recommendation.
• JS SDK: new currentRelayBlock / waitForRelayBlock in @web3-storage/layer0. Demos and e2e suites snapshot the relay block for CommitmentPayload nonces (a System.Number nonce would be rejected as stale on any network where relay numbers dwarf parachain heights — e.g. Paseo) and wait out expiries/windows on the relay clock. The terms replay nonce is counter-based (ReplayWindow) and needed no change.
• UIs: the provider dashboard and s3-ui track anchorBlock$, refreshed per finalized block from the current_anchor_block runtime API via PAPI's getUnsafeApi() (live metadata — no descriptor regeneration; pre-anchor runtimes fall back to the parachain height, which is their pallet clock). All pallet-clock comparisons read it: agreement expiry and challenge status (whose previous source was additionally a never-fed subject, so both always compared against 0), checkpoint-overdue detection, the deregister cooldown, earnings progress, and the s3-ui challenge countdown. formatDuration converts anchor-denominated durations with AnchorBlockTimeMillis instead of Aura.SlotDuration, which would have silently skewed when Support for 3 async cores #131 changes the parachain tick.

Ordering vs #131

Not a hard prerequisite, but landing this first is the better order: #131's rebase then no longer needs to touch storage timing constants (its checkpoint-interval rework becomes unnecessary), off-chain consumers re-denominate once instead of twice, and shipping #131 to PreviewNet first would force a live-state migration here later.

Migration & deployment notes

Fresh chains need nothing (LastSweptChallengeBlock self-anchors on first block). Upgrading a live chain with in-flight state is NOT covered: existing parachain-denominated Challenges keys would sit below the cursor (never swept) and old expiries would read as long past — for testnets, reset; otherwise a one-shot OnRuntimeUpgrade re-inserting pending challenges at relay_now + ChallengeTimeout (and clearing their stranded NextChallengeIndex entries) is the minimum. On live networks the runtime and provider node must ship together: an old runtime with a new provider node 503s on /negotiate (missing runtime API), a new runtime with an old provider node signs instantly-expired terms.

Remaining follow-up per the issue: user-facing duration inputs (duration pickers, payment-per-block display), and a pnpm papi:generate descriptor refresh so the UIs can move from getUnsafeApi() to typed runtime-API calls.

Verified

• 243+ pallet tests (5 new sweep tests: range gap, span-cap carry-over, budget mid-key carry-over, same-block idempotence, cursor anchoring) plus registries, paseo runtime integration tests, provider-node, client — all green; runtime-benchmarks / try-runtime feature checks; clippy -D warnings; JS typecheck + unit tests.
• Live zombienet: just demo (all 8 steps — relay-denominated challenge deadlines, both defenses, expiry + payout), just fs-demo-ci, just s3-demo-ci.
• Post-review round (challenger fix, anchor_block rename, anchor-tick API, UI wiring): workspace clippy -D warnings, pallet/registry/client test suites, tsc -b + vitest for the provider and s3 UIs.

[danielbui12]

Since you dropped on_finalize in pallet/src/lib.rs. This should be updated as well

[danielbui12]

Make sure you wire client (rust + ts) with new changes. My assistance feedback:

1. client/src/challenger.rs:375-405 - Missed relay-clock wiring in the Rust SDK. analyze_provider computes last_checkpoint_age as parachain head minus snapshot.checkpoint_block, but the pallet now writes checkpoint_block on the relay clock. On Paseo the subtraction saturates to 0, so every provider reads as freshly checkpointed and the Challenge/Monitor/Skip recommendation runs on a fake age; on local zombienet the clocks nearly coincide so nothing fails. This also means the fetch_last_relay_block_number helper the PR added to client/src/substrate.rs:919 has zero callers in the repo (the provider node uses its own inlined copy per #275). 

Fix: swap the blocks().at_latest().number() read for fetch_last_relay_block_number, which simultaneously gives the helper a real caller. (flagged by 3 agents, all high confidence)

2. Provider dashboard and s3-ui compare parachain height against relay-denominated on-chain values in five places - this is the direct answer to your "missed client wiring" question. All silently pass on zombienet and all break on Paseo, and two of them misinform providers about penalty-bearing obligations:  - user-interfaces/provider/src/state/provider.state.ts:300-310 - checkpoint-overdue detection never fires, so the dashboard never warns about the window that now costs CheckpointMissPenalty.
  - user-interfaces/provider/src/pages/Overview.tsx:112,249 - deregister cooldown shows ~29M blocks remaining and the complete button never unlocks.
  - user-interfaces/provider/src/lib/chain-client.ts:343 - every agreement reads active forever, which also wrongly gates the deregister UI.
  - user-interfaces/provider/src/lib/chain-client.ts:502 - every challenge reads pending forever.
  - user-interfaces/s3-ui/src/components/CheckpointPanel.tsx:183-184 - challenge countdowns show tens of millions of blocks left and never expire.

Fix: add a relayBlockNumber$ (reading ParachainSystem.LastRelayChainBlockNumber, mirroring waitForRelayBlock) to each UI's chain state and use it for all pallet-clock comparisons. Same pattern fixes Earnings.tsx:32-34 (progress/earned-so-far clamps to 0 on Paseo).

[danielbui12]

I would prefer using bullet points and simple formula to describe this 🤯

[danielbui12]

I wonder if the MaxChallengesPerDeadline = 1000 reuse here could exhaust the PoV size.

@bkontur WDYT about splitting the constant? Keep MaxChallengesPerDeadline as it is, and add a separate MaxSweepSlashBudget (~100) for the sweep. In worst case, 1000 slashes spread over 10 blocks (~1 minute) instead of one block.

[bkontur]

I think probably correctly we should used different type here for AnchorBlockNumber, because for example fn challenges_at(block: BlockNumber) uses also BlockNumber, which is really parachain block.

in PolkadotSDK we use also types like:

// In our case AnchorBlockNumberFor<T>
type BlockNumberFor<T, I = ()> =
	<<T as pallet_treasury::Config<I>>::BlockNumberProvider as BlockNumberProvider>::BlockNumber;

but not sure if we need this also now, maybe?

[bkontur]

I think there are too many returns on the way, and this algo is getting complicated, maybe worth to extract to separate function(s)?

[bkontur]

@ilchu and the last thing, please, check if we need to adjust design mds around this current_anchor_block and blockNumber/deadlines/timeouts handling

[bkontur]

@ilchu nice, nice, I think it looks pretty good module please check the comments:
#268 (comment)
#268 (comment)
#268 (comment)

[bkontur]

Make sure you wire client (rust + ts) with new changes. My assistance feedback:

1. client/src/challenger.rs:375-405 - Missed relay-clock wiring in the Rust SDK. analyze_provider computes last_checkpoint_age as parachain head minus snapshot.checkpoint_block, but the pallet now writes checkpoint_block on the relay clock. On Paseo the subtraction saturates to 0, so every provider reads as freshly checkpointed and the Challenge/Monitor/Skip recommendation runs on a fake age; on local zombienet the clocks nearly coincide so nothing fails. This also means the fetch_last_relay_block_number helper the PR added to client/src/substrate.rs:919 has zero callers in the repo (the provider node uses its own inlined copy per #275). 

Fix: swap the blocks().at_latest().number() read for fetch_last_relay_block_number, which simultaneously gives the helper a real caller. (flagged by 3 agents, all high confidence)

2. Provider dashboard and s3-ui compare parachain height against relay-denominated on-chain values in five places - this is the direct answer to your "missed client wiring" question. All silently pass on zombienet and all break on Paseo, and two of them misinform providers about penalty-bearing obligations:  - user-interfaces/provider/src/state/provider.state.ts:300-310 - checkpoint-overdue detection never fires, so the dashboard never warns about the window that now costs CheckpointMissPenalty.
  - user-interfaces/provider/src/pages/Overview.tsx:112,249 - deregister cooldown shows ~29M blocks remaining and the complete button never unlocks.
  - user-interfaces/provider/src/lib/chain-client.ts:343 - every agreement reads active forever, which also wrongly gates the deregister UI.
  - user-interfaces/provider/src/lib/chain-client.ts:502 - every challenge reads pending forever.
  - user-interfaces/s3-ui/src/components/CheckpointPanel.tsx:183-184 - challenge countdowns show tens of millions of blocks left and never expire.

Fix: add a relayBlockNumber$ (reading ParachainSystem.LastRelayChainBlockNumber, mirroring waitForRelayBlock) to each UI's chain state and use it for all pallet-clock comparisons. Same pattern fixes Earnings.tsx:32-34 (progress/earned-so-far clamps to 0 on Paseo).

Thank you, should be fixed :)