Weight Management
ConsensusSubmission and storage of validator weight vectors, including commit-reveal (CRV3) for privacy.
Weight Submission Flow
Weight Management
- Validator submits set_weights or commit_crv3_mechanism_weights
- Reveal period triggers weight reveal
Click items to navigate to their reference pages.
The Big Picture
Weight management is how validators express their opinions about miners. Weights drive Yuma Consensus — without accurate weights, emission goes to the wrong miners. CRV3 commit-reveal prevents weight copying by keeping weights private until the reveal period, forcing validators to evaluate independently.
Why This Matters
Weights are the "votes" that determine miner rewards. As a validator, your weight strategy directly affects your trust score and dividends. The CRV3 scheme adds a strategic element: commit early, reveal on time.
Example Scenario
On a CRV3-enabled subnet, a validator computes weights [0.5, 0.3, 0.2] for 3 miners. They hash the weights (blake2b) and submit the commit in epoch N. In epoch N+1 (reveal period), they submit the actual weights. If they miss the reveal window, the weights are discarded.
Common Questions
- Why commit-reveal instead of just encrypting?
- Commit-reveal is simpler and doesn't require key management. The hash proves you chose your weights before seeing others' reveals.
- What if a validator copies revealed weights?
- They can't — by the time weights are revealed, the commitment deadline for the next epoch has passed. Copiers are always one epoch behind.
Use Cases
- Setting validator weights on subnets
- Implementing CRV3 commit-reveal flow
- Monitoring weight update frequency
- Debugging weight normalization issues
Validators score miners by setting weight vectors. These weights drive Yuma Consensus and determine how emissions are distributed. Weight submission can be direct (set_weights) or use the commit-reveal scheme (CRV3) where weights are committed as hashes first, then revealed later.
Rate limits prevent rapid weight changes. Weights are normalized and clipped before storage.
Triggers
- Validator submits set_weights or commit_crv3_mechanism_weights
- Reveal period triggers weight reveal
Inputs (4)
| Item | Type | Role |
|---|---|---|
| set_weights SubtensorModule | call | Direct weight submission |
| commit_crv3_mechanism_weights SubtensorModule | call | Commit weight hash (CRV3) |
| reveal_weights SubtensorModule | call | Reveal committed weights (CRV3) |
| WeightsSetRateLimit SubtensorModule | storage | Minimum blocks between weight updates |
Outputs (3)
| Item | Type | Role |
|---|---|---|
| WeightsSet SubtensorModule | event | Emitted when weights are set |
| Weights SubtensorModule | storage | Validator weight vectors |
| CRV3WeightCommits SubtensorModule | storage | Pending weight commits |
Source Files
pallets/subtensor/src/subnets/weights.rs pallets/subtensor/src/coinbase/reveal_commits.rs Formulas
Weight Max-Upscaling
Submitted weights are max-upscaled so the maximum value equals u16::MAX (65535) before storage.
max_val = max(raw_weights) scaled[i] = raw_weights[i] * 65535 / max_val
Rate Limit Check
Validators cannot set weights more frequently than WeightsSetRateLimit blocks.
blocks_since_last = current_block - last_set_block assert blocks_since_last >= WeightsSetRateLimit