Client

Client

🚧 This wiki describes DevNet 2.0, soon to be launched. It follows the contracts and dincli on the develop branch; the currently running DevNet may still use older contracts and commands. Pre-launch discussion: #102.

Clients (model trainees) are the network's data holders, and the reason DIN exists. They train the current global model on their own private data and contribute only the resulting local model. 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 needs only a wallet and a dataset. Quality control comes from the other side: auditors score every submitted local model before it can enter aggregation. Clients whose models are approved earn the largest share of each round's rewards.

How a contribution works

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

1. Fetch. dincli downloads the current global model (the 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.
3. Submit. The trained local model is uploaded to IPFS and its CID is recorded on-chain in DINTaskAuditor. Each client gets one submission per GI.
4. Get audited. Auditors score the submission against encrypted test data. It is approved and aggregated into the next global model if at least 2 auditors vote it eligible and its median score meets the GI's pass score.

dincli client create-client-dataset-dir <model_id>   # creates the expected dataset folder
dincli client train-lms <model_id>                    # train locally
dincli client submit-lm <model_id>                    # upload and record on-chain
dincli client lms show-models <model_id>              # verify it landed

The client's dataset goes at the path dincli expects: <CACHE_DIR>/<network>/model_<model_id>/dataset/clients/<address>/data.pt. The model owner defines the required format, preprocessing and training hyperparameters for each model, in the model's client instructions. For the reference MNIST-style model, the dataset is a list of (tensor, label) tuples (full spec).

Rewards

When the GI ends, 60% of its reward pool goes to clients, shared in proportion to the median score of each approved local model. Rewards are pulled on-chain: call claimReward(gi) on the model's DINTaskAuditor, then claimRewards() to withdraw. dincli doesn't have a claim command yet.

What protects the client

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

• The network never sees the data. Only trained weights are submitted, as IPFS CIDs. A model can also enable differential privacy in its manifest's dp block. By default it adds calibrated noise after training (post_training_gaussian), so even the submitted weights reveal less.
• 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, capped resources, no wallet or secrets. It can't exfiltrate the data it trains 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 several independent staked auditors against held-out test data.
• It needs an eligibility majority and a passing median score.
• Anything below the threshold never reaches aggregation, and earns nothing.
• Submissions are capped at one per client per GI, which keeps spam bounded.

Further reading

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