task_240826_10 — Real Encrypted Test-Data Key Distribution + Dispute Resolution (Robbert)

[umermjd11]

cc @robertocarlous
Assigned now that PR #63 has merged. Full spec: Developer/tasks/task_240826_10.md

The task file has the full specification — exact scope, open questions, and the deliverables checklist. This post is just the summary and assignment notice.

Summary

This is Part 1 of finishing the encrypted-test-data-key thread that came out of PR #63's re-review (issue #40): PR #63 shipped encryptedTestDataKey/testDataCID as on-chain plumbing only, explicitly scoped with no real encryption — assignAuditTestDataset writes b"" placeholder keys for every auditor, and testDataCID still points at plaintext IPFS content. Three follow-up review comments on #63 worked out what the real version needs to look like; this task turns that into a build.

In scope:

• §0 — Auditor public-key registration (prerequisite, not explicit in the PR feat(auditing): commit-then-reveal scoring, encrypted test-data keys, resampling policy #63 thread): mapping + a registerEncryptionKey-style function so there's something to encrypt K to. Location (DinValidatorStake vs DINTaskAuditor) and key type are Open Question 1 — ask, don't guess.
• §A — Real content-secrecy + address-secrecy encryption: per-batch symmetric key K, test file encrypted before IPFS upload, encryptedCID = SymmetricEncrypt(K, Sign(ownerSK, rawCID)) replacing the plain public testDataCID, real per-auditor encryptedKeys[i] replacing the b"" placeholders — model-owner side (cache_model_0/services/modelowner.py, dincli/cli/modelownerd/auditor_batches.py) and auditor side (dincli/cli/auditor.py, cache_model_0/services/auditor.py).
• §B — Test-data dispute resolution: an on-chain commitment bound to gi/batchId/keccak256(K) (not just the plaintext hash, per Robbert's own refinement on PR feat(auditing): commit-then-reveal scoring, encrypted test-data keys, resampling policy #63), a stake-gated disputeTestData(gi, batchId) with staged resolution — Stage 0 (free: empty-key check), Stage 1 (stake: signature check), Stage 2 (stake: content-hash + round-binding check).

Explicitly out of scope: zkVM-based private dispute resolution (Robbert's own call on PR #63 — track as a separate Phase 2/3 issue), any economic-penalty redesign beyond what Stage 2's losing outcome needs, and mandating a specific ECIES/X25519 library (build one, but which primitive isn't dictated).

Open questions to resolve before/while building (see task file for full detail — ask rather than guess per repo convention):

1. Where does auditor public-key registration live, and what key type (chain key vs separate X25519)?
2. What actually happens to the model owner when a Stage 2 dispute resolves against them — they're explicitly outside the stake/slash system per MECHANISM_DESIGN.md §1's role matrix.
3. Dispute bond size and challenge-window length — no numbers given yet; MECHANISM_DESIGN.md §4's P3-4.3 design is the closest existing pattern.
4. Batch reassignment mechanics after a losing model-owner outcome.

Reference material

• Developer/tasks/task_240826_10.md — full spec, deliverables checklist
• The three source comments on PR feat(auditing): commit-then-reveal scoring, encrypted test-data keys, resampling policy #63: 5382717784 (encryption design), 5383065186 (dispute-resolution failure modes), 5385033910 (Robbert's own refinement + zkVM follow-up call)
• Developer/design/MECHANISM_DESIGN.md §4 (dispute resolution), §1 (role matrix)
• Issue #40 — the tracking issue this task implements against
• PR feat(auditing): commit-then-reveal scoring, encrypted test-data keys, resampling policy #63 (feature/auditor-commit-reveal) — merged into develop 2026-08-27, everything this task builds on top of (commitAuditScore/revealAuditScore, encryptedTestDataKey, assignAuditTestDataset) is live

Post progress updates, questions, and PR links here as the task moves — same convention as prior task-tracking discussions (e.g. #49, #76). If anything in the task spec doesn't feel right, is ambiguous, or needs clarification — comment here and cc @umeradl.

[robertocarlous]

Q1 — Where does auditor public-key registration live, and what key type?

The task needs a mapping + registration function so there's something to encrypt K to. The two options as I see them:

DinValidatorStake — makes sense since it's validator-identity-scoped and spans models, but adds crypto key storage to a contract that currently only knows about stake amounts
DINTaskAuditor — simpler, but means auditors re-register their encryption key per model deployment
And separately: is this a dedicated X25519 key (cleaner separation between signing and encryption) or do we encrypt to the auditor's existing chain signing key (one less registration step, more complex crypto)?

Q2 — What happens to the model owner when Stage 2 resolves against them?

The role matrix in MECHANISM_DESIGN.md §1 is explicit that model owners don't stake and can't be slashed. The three PR #63 comments use "slashed" loosely for the losing side, which is fine for the auditor's false-dispute case (that maps cleanly to the existing stake system) — but for the model-owner losing case, there's nothing to slash. Options I can think of: forfeit their GI reward deposit, block the model from progressing until they reassign the batch with fresh data, or some combination. What's the intended outcome?

Q3 — Dispute bond size and challenge-window length?

MECHANISM_DESIGN.md §4 describes a bond-forfeited-if-frivolous / returned+bounty-if-upheld pattern for P3-4.3. Should I reuse those numbers directly, or is there a separate sizing recommendation for this mechanism specifically?

Q4 — Batch reassignment mechanics after a losing model-owner outcome?

Comment 5383065186 says "batch reassigned with fresh data and a fresh K" but doesn't specify the state machine. Does the GI pause/block until the model owner re-calls assignAuditTestDataset with corrected data? Or does it auto-skip the disputed batch and continue? And who triggers the re-assignment — is it owner-initiated or does the contract enforce a re-assignment window?

cc:@umeradl

[umermjd11]

@robertocarlous — answers to Q1–Q4 below, plus how the whole thing chains together end-to-end once built.

Q1 — Registration location + key type: DinValidatorStake, dedicated X25519 key.

DinValidatorStake already has mapping(address => ValidatorInfo) public validators — validator identity there is stake-scoped and spans models, which is exactly the shape a registered-once encryption key wants. DINTaskAuditor is a task-level contract redeployed per model owner (per this repo's platform/task-contract split), so a key registered there would need re-registering on every model deployment — real friction for no benefit. The "adds crypto key storage to a stake contract" concern is minor; it's an additive mapping, doesn't touch stake accounting logic.

Dedicated X25519 over reusing the chain signing key: using one keypair for two different cryptographic purposes (ECDSA signing + ECIES encryption) is a known anti-pattern — cross-protocol attacks exist against that kind of key reuse, and secp256k1 ECIES isn't as battle-tested/well-tooled as X25519 (which has solid off-the-shelf support, e.g. PyNaCl's Box). One extra one-time registerEncryptionKey call is cheap next to that.

Fuller justification (why this isn't just a style call):

1. Different curves — not optional. Ethereum keys are secp256k1; X25519 is Curve25519. You cannot do ECDH between a secp256k1 key and an X25519 key — they're different groups. "Reuse the Ethereum key" necessarily means implementing secp256k1-based ECIES, not X25519. There's no single canonical secp256k1-ECIES the way there's one well-defined X25519+XSalsa20-Poly1305 box (PyNaCl's Box) — different secp256k1-ECIES libraries (eciespy, eth-crypto, hand-rolled) make different KDF/MAC/padding choices that don't interoperate, which is real interop risk between the model-owner encryptor and the auditor decryptor.
2. "One less registration step" isn't actually true. An Ethereum address is a hash of the public key, not the key itself — the raw pubkey point generally isn't available on-chain unless the account has sent a signed message it can be recovered from (Solidity's ecrecover only returns an address, not the full point). In practice, reusing the chain key still needs an explicit one-time step to publish the real pubkey on-chain — so the registration cost is the same either way; the only thing actually saved is a second keypair, not a transaction.
3. Domain separation / blast radius. The auditor's chain key signs routine, frequent transactions (score commits/reveals, batch registration) — a hot operational key. Encrypting long-lived secrets (K, and transitively the test data) to that same key means every routine signing operation shares fate with that secrecy guarantee. A dedicated X25519 key can be handled more conservatively (rotated independently, kept off whatever signs routine txs) without touching the auditor's on-chain identity at all.
4. Tooling fit. dincli is Python + web3.py for chain signing; PyNaCl (libsodium bindings) is the natural fit for encryption, and PyNaCl's public-key box is X25519, not secp256k1. Reusing the chain key means hand-rolling or importing a less-common secp256k1-ECIES library instead of the well-audited primitive that already fits this stack.

Net: the apparent "savings" from reusing the chain key are smaller than they look (registration cost is unchanged), and the cost is real (non-standard crypto construction, key-reuse risk).

Q2 — Stage 2 loss outcome for the model owner: forfeit a slice of their GI reward deposit, and block that batch until reassigned (this also answers Q4 — not an either/or).

Model owners have no stake to slash (§1's role matrix is explicit — "loses fees/deposit on abandonment" is the only existing at-risk-capital precedent). Their totalDepositedRewards GI deposit is that capital. Forfeiting a bounded slice on a losing Stage 2 outcome mirrors §4's resolved slashed-stake split (50% burn / 50% treasury) conceptually, applied to deposit instead of stake — funds the dispute bounty/treasury side the same way a validator slash would. Doesn't require a new penalty system, reuses the deposit mechanism that already exists.

Q3 — Bond size / challenge window: reuse P3-4.3's shape as-is rather than inventing new numbers — bond forfeited if frivolous, returned + treasury bounty if upheld, both DAO-settable parameters (same pattern as minStake/slash-fraction elsewhere in §3/§4). Window: one GI, matching §4's example — keeps the Stage 2 disclosure-cost bound (Robbert's own point in comment 5385033910) symmetric with the dispute window itself.

Q4 — Reassignment mechanics: owner-initiated, not auto-skip. A losing Stage 2 outcome blocks that batch (not the whole GI) until the model owner re-calls assignAuditTestDataset with fresh data and a fresh K. Auto-skipping would let a bad-faith or broken owner get fewer batches scored for free — worse incentive than requiring them to redo it. If they never reassign, that's the same already-out-of-scope liveness gap as dispute #6 (§B) / the tracked slashAggregators-wedged-GI question — no new mechanism needed for that edge, just don't let it block this task.

---

End-to-end workflow if implemented per this spec

Setup (once per auditor, not per model/GI)

1. Auditor generates an X25519 keypair locally and calls registerEncryptionKey on DinValidatorStake (Q1) to publish their public key. One-time — the same key is reused across every model/GI the auditor participates in, since it lives on the validator-identity-scoped contract rather than a per-model task contract.

Happy path — per GI, per batch

Off-chain, model-owner side (cache_model_0/services/modelowner.py, dincli/cli/modelownerd/auditor_batches.py):

1. createAuditorsBatches (unchanged) groups the GI's registered auditors into batches.
2. Model owner samples the batch's test-data file.
3. Generates a fresh, random per-batch symmetric key K — never reused across batches or GIs.
4. Encrypts the test file with K, uploads the ciphertext to IPFS → this yields rawCID (the ciphertext's own CID; the content behind it is already unreadable without K).
5. Builds encryptedCID = SymmetricEncrypt(K, Sign(ownerSK, rawCID)) — this, not the bare rawCID, is what goes on-chain as testDataCID. A leaked/observed testDataCID now reveals neither the location nor the content.
6. For each batch.auditors[i], looks up that auditor's registered X25519 public key (from Setup) and encrypts K to it → real encryptedKeys[i].
7. Computes the commitment keccak256(abi.encodePacked(gi, batchId, keccak256(K), keccak256(plaintext_test_data))).

On-chain, one call: assignAuditTestDataset(gi, batchId, encryptedCID, encryptedKeys) — same signature PR #63 already shipped — plus the new commitment gets stored alongside it (the one real Solidity addition beyond what #63 has).

Off-chain, auditor side (dincli/cli/auditor.py, cache_model_0/services/auditor.py):

8. Auditor reads back testDataCID (= encryptedCID) and their own encryptedTestDataKey[gi][batchId][msg.sender].
9. Decrypts the key entry with their private X25519 key → recovers K.
10. Decrypts encryptedCID with K → recovers (rawCID, signature).
11. Verifies signature against the model owner's known public key — only proceeds if it checks out.
12. Fetches the ciphertext from IPFS via rawCID, decrypts it with K → plaintext test data.
13. Hands the plaintext to Score_model_by_auditor, same as today — everything downstream of that call is unchanged.

If nothing is disputed, this is the entire lifecycle for that batch — no on-chain dispute logic ever runs.

Dispute path — disputeTestData(gi, batchId)

Any staked party (auditor or otherwise) can open a dispute inside the challenge window. Resolution is staged, cheapest check first:

Stage	Cost	Check	Fail →	Pass →
0	Free	encryptedTestDataKey[gi][batchId][auditor].length > 0?	—	Empty → auditor wins immediately (dispute #2: no key delivered), no stake ever at risk
1	Bond (Q3)	Disputer reveals K; anyone decrypts encryptedCID, checks Sign(ownerSK, rawCID) against the owner's known pubkey	Bad signature → model owner loses (below)	→ Stage 2
2	(same bond)	Fetch ciphertext via rawCID, decrypt with K, recompute keccak256(gi, batchId, keccak256(K), keccak256(plaintext)), compare to the stored commitment	Mismatch → model owner loses (bad or stale/reused data — round-binding catches the stale case even with byte-identical content to a prior round)	Match → dispute was false, disputer's bond is forfeited instead

Model-owner-loses outcome (Q2 + Q4, same outcome from either Stage 1 or Stage 2): a bounded slice of the owner's GI reward deposit is forfeited (burn/treasury split, mirroring §4's resolved 50/50 pattern for validator slashes), and that batch — not the whole GI — is blocked from finalizing until the owner re-calls assignAuditTestDataset for it with fresh data and a fresh K (owner-initiated, no auto-skip). Every other batch in the GI proceeds unaffected in the meantime.

False-dispute outcome: disputer's bond is forfeited (same burn/treasury split as any other slash destination in §4), nothing else changes — the batch's original (encryptedCID, K) stands as valid.

---

Sources: Comment 5382717784, 5383065186, 5385033910 on PR #63; Developer/design/MECHANISM_DESIGN.md §1/§3/§4; foundry/src/DinValidatorStake.sol and foundry/src/DINTaskAuditor.sol as of current develop.

[umermjd11]

Closing — merged to develop.

PR #110 merged 2026-09-09 (18166f7). Covers every deliverable in this task's checklist:

• Auditor public-key registration: X25519 keys in DinValidatorStake (registerEncryptionKey/getEncryptionKey), resolving Open Question 1.
• Model-owner side real encryption: per-batch AES-256-GCM key K, content encrypted before IPFS upload, encryptedCID = AES-256-GCM(K, rawCID || eth_sign(ownerSK, rawCID)), real per-auditor key encryption via PyNaCl Box replacing the old b"" placeholders.
• Auditor side decryption: reads encryptedTestDataKey, recovers K, verifies the owner's signature before trusting the CID, decrypts content before scoring.
• On-chain: testDataCommitments[gi][batchId] (round-and-key-bound), disputeTestData/resolveDispute staged three-stage resolution (cheapest check first), stake bond handling.
• Tests: 13 Foundry tests (EncryptedTestData.t.sol, all 3 stages + false-dispute forfeiture + stale-round-binding + expired-window rejection) + 19 Python tests (test_encrypted_testdata.py) — both green, confirmed present and passing on current develop.
• PR description explicitly answers all 4 Open Questions from the task spec (key-registration location/type, model-owner penalty mechanism, bond/window sizing, reassignment mechanics).

This is explicitly Part 1 of the larger encrypted test-data effort — the zkVM-based private dispute follow-up (Stage 2 currently makes disputed test data public) is out of scope here by design, tracked as a separate future task/issue per this task's own Notes section, not a gap in this one's completion.