P3 scoring: BlockFLow validation (P3-SCR), on-chain median, scenario-driven scoring redesign

[umeradl]

Part of the P3 mechanism-design push (#36).

Summary

Two workstreams before scoring can safely drive rewards and slashing:

1. Validate the shipped BlockFLow-inspired scoring (WP 2.2 ✅) empirically — P3-SCR. High correctness risk in the subtle properties (sequential fold-in, permutation averaging).
2. Scenario-driven scoring redesign — separate eligibility from utility instead of one test shard / one accuracy number / one average threshold (issues/scoring-mechanism.md).

Scope (from MECHANISM_DESIGN §6)

• P3-SCR validation: poison detection (label-flip, sign-flip, scaling, garbage), duplicate discounting via fold-in, cosine-to-consensus / norm-bound / marginal-gain gates at multiple ε values; pytest integration tests for permutation averaging and sequential fold-in
• Compute the median across the auditor batch on-chain at finalizeEvaluation so the canonical per-model score exists on-chain as both the S3 slashing reference and the reward basis (today eligibility voting exists but no canonical score is derived)
• Eligibility: median ≥ passScore gates T1 aggregation; below ⇒ rejected, zero reward
• S3 deviation threshold: start wide, warning-only shadow mode for the first weeks of DevNet 2.0, then tighten (avoid punishing honest variance from heterogeneous audit test sets)

Threat coverage

In scope: crude poisoning, Sybil clients (spam costs compute, earns nothing below pass score), score inflation (median-bounded). Out of scope for 2.0: backdoors (RES-2), >50% auditor collusion.

Design sources

MECHANISM_DESIGN §6 · issues/scoring-mechanism.md · whitepaper-summary §4.4, §8 gap items 3, 11, 14 · rejected-ideas/tknn-shapley.md

Roadmap anchors: P3-SCR (validation), WP 2.2 (implementation, shipped)