Client

Client

Clients (model trainees) are the network's data holders — the reason DIN exists. They train the current global model on their own private data and contribute only the resulting local model back. The raw data never leaves their device; that is the protocol's founding constraint, not a feature flag.

Unlike Auditors and Aggregators, clients are not staked validators: participating requires only a wallet and a dataset. Their contributions are quality-controlled from the other side — every submitted local model is scored by auditors before it can enter aggregation.

How a contribution works

Each Global Iteration, while the Local Model Submission (LMS) window is open:

1. Fetch — dincli downloads the current global model (genesis model in GI 1) and the model's training service code from IPFS, by CID.
2. Train locally — the model owner's client.py training function runs on the client's dataset inside a sandboxed Worker Node container. One command does it all:

   dincli client train-lms <model_id> --submit

3. Submit — the trained local model is uploaded to IPFS and its CID recorded on-chain in DINTaskAuditor (one submission per client per GI). dincli client lms show-models <model_id> verifies it landed.
4. Get audited — auditors score the submission against test data; if it passes eligibility and the score threshold, it is approved and aggregated into the next global model.

The client's dataset must be placed at the path dincli expects (<CACHE_DIR>/<network>/model_<model_id>/dataset/clients/<address>/data.pt); its required format, preprocessing, and training hyperparameters are defined per model by the model owner — see the model's client instructions (for the reference MNIST-style model: a list of (tensor, label) tuples, full spec).

What protects the client

Trust here runs in both directions, and both are enforced mechanically:

• The network never sees the data. Only trained weights (as IPFS CIDs) are submitted. Optionally, a model can enable differential privacy — configured in the model's manifest (dp block) and applied inside the client's local training — so even the submitted weights carry calibrated noise limiting what they reveal.
• The client never trusts the model owner's code. The training function is the model owner's Python, so it runs in the Worker Node sandbox: no network access, resource-capped, no wallet or secrets — it cannot exfiltrate the very data it is training on.

What protects the network from a client

A malicious client can submit garbage or poisoned weights — which is exactly what the audit phase is for: every submission is scored by multiple independent staked auditors against held-out test data, needs an eligibility majority and a passing average score, and anything below threshold simply never reaches aggregation. Submission is also capped (one per client per GI) to keep spam bounded.

Further reading

• Client command reference — commands, dataset path, workflow
• Client instructions (reference model) — dataset format & hyperparameters for the MNIST-style example
• Task Contracts — where LMS and evaluation live on-chain
• Auditor — the role that scores client submissions