Guides / running-a-miner.md

Running a miner

A miner compiles the cheapest circuit it can for the owner's model, publishes the recipe to HuggingFace, and commits the pointer on-chain. The chain/HF work runs in .venv; the optimization is shelled out to .venv-fhe.

Prerequisites

  • Both venvs built: make venvs
  • A registered hotkey on the subnet (btcli subnet register …)
  • A HuggingFace repo and a write token (https://huggingface.co/settings/tokens)
  • The task repo id (a HuggingFace repo, e.g. cifranet/cifra-task)

Configure

Put the secrets and repo in .env (they have no CLI flag — see configuration.md):

cp .env.example .env
# then set at least:
#   CIFRA_HF_REPO=your-username/cifra-recipes
#   CIFRA_HF_TOKEN=hf_...            # write token; gitignored, never logged

Run

.venv/bin/cifra miner run \
  --netuid <N> --network test \
  --wallet.name <coldkey> --wallet.hotkey <hotkey> \
  --task cifranet/cifra-task
# add --once to run a single optimize→publish→commit cycle and exit

What it does each round (roles/miner.py)

  1. Checks the hotkey is registered; fetches + caches the task.
  2. Runs the optimizer in .venv-fhe (python -m cifra.fhe.optimize): searches the compile space for the lowest-complexity circuit that still clears the accuracy floor and cap, self-checking with the same evaluator and same task-seeded gate the validator uses.
  3. If it found a strictly cheaper recipe than last time, uploads recipe.json to CIFRA_HF_REPO and commits {repo, rev} on-chain with set_commitment. Otherwise it keeps the existing commitment stable.

Writing a real optimizer

The shipped generate_candidates (fhe/optimize.py) is a demo: re-quantized logistic regressions at a few bit-widths. Replace it with your own strategy — bit-widths, quantization-aware training, rounding via the torch route, pruning, distillation. The scoring contract is fixed: your circuit must clear the accuracy gate against the owner's reference, and passing circuits are ranked by measured FHE execution latency (lower = better; weights are geometric down the leaderboard: 1, 1/3, 1/9, …). Because you self-evaluate with the exact validator code path, what you measure locally is what you are scored on (up to hardware differences — complexity is the portable proxy to optimize).

Tips:

  • Lower latency wins, but latencies within 3% count as a tie — and the earlier on-chain committer wins a tie. A marginal tweak to leapfrog the leader earns nothing; you must be genuinely >3% faster. Commit early.
  • Do not weaken the crypto for speed — you cannot. The validator forces 128-bit; a recipe's only compile knob is p_error, floored by the task.
  • Do not copy a rival's public recipe — copy-priority zeroes the later committer.