White paper ↔ DevNet alignment: delegation, encrypted test sets, resampling, commit-then-reveal, governance

[umeradl]

We've written up a working summary of the white paper with a gap/alignment checklist: Developer/design/whitepaper-summary.md (§8 is the checklist). Most items map cleanly onto the P3 design push (tracking issue #36), but a handful need a scope decision rather than just implementation.

cc @abrahamnash — as the paper's author, your call on which of these are load-bearing for DevNet 2.0 vs deliberately deferred would settle scope quickly.

Needs a decision

1. DPoS delegation (paper §8) — delegation with no delegator minimum, commissions, auto-compounding. Not implemented; current mechanism design parks it to P5+. In or out of P3 token-utility scope?
2. Encrypted test dataset + per-validator key mapping (paper §5.2.3b) — single encrypted CID, symmetric key K encrypted per-validator, mapping on-chain. The current auditor test-data flow (assignAuditTestDataset + model-owner services) should be compared against this; if it's effectively plaintext/centrally shared, do we adopt the paper's scheme in 2.0?
3. Test-set resampling (paper §5.2) — reserved ~40% pool, resampled half per round, full pool in the final round. Not visible in the current evaluation pipeline. Adopt for 2.0?
4. Commit-then-reveal between auditors (paper §5.2) — prevents validators copying each other's scores. Needs confirming as in-scope for P3 scoring hardening.
5. Non-coin-based voting credits (DPPs, paper §8) — the paper's anti-plutocratic governance stance. P3 ships only onlyOwner governance hooks; full DAO design (din-dao, Start DIN-DAO #23) should note this stance early.

For confirmation / documentation only

• Terminology: the paper's single "Validator" role is split into aggregator + auditor in DevNet — matches the paper's role-delineation rationale; we'll document the mapping in Documentation/public/.
• Random validator assignment — load-bearing for the threat model; we'll verify the current assignment path and open an issue if randomness is missing.
• Market-utility over Shapley valuation — already aligned (Developer/rejected-ideas/tknn-shapley.md); we'll cite the paper in the rationale.
• DIDs/verifiable credentials for Sybil resistance — staking-only today; noted as a future complement.
• Async FL orchestration (paper §9) — imported as requirements for the P4 dind daemon design.

[umeradl]

Thanks for the calls on these, Abraham — we're wiring them into the DIN P3 specs now.

[abrahamnash]

Thank you, @umermjd11