WeightCommits
Storage Map v151 → v411 · 1 shape change Changed in v411Committed weight hashes awaiting reveal.
Explore chainThe Big Picture
Commit-reveal prevents validators from seeing each other's weights before submitting. You commit a hash of your weights first, wait, then reveal. WeightCommits stores the committed hashes awaiting reveal - ensuring no one can cheat by seeing weights early.
Why This Matters
If weights were instantly visible, validators could copy others or front-run. Commit-reveal forces independence - commit your hash blind, then reveal later.
Example Scenario
Query WeightCommits(netuid=1, uid=5) returns the hash of weights this validator committed. During reveal, the actual weights must hash to this value or the reveal is rejected.
Common Questions
- How does commit-reveal work?
- 1) Hash your weights and submit the hash (commit). 2) Wait the required period. 3) Submit actual weights (reveal). Hash must match commit or it's rejected.
- What if I don't reveal?
- Uncommitted weights aren't counted. You need to complete the reveal step for weights to take effect. Check subnet rules for reveal deadlines.
- Is commit-reveal mandatory?
- Depends on subnet configuration. Some subnets require it for fairness, others don't. Check CommitRevealWeightsEnabled for the subnet.
Use Cases
- Check if you have pending weight commits to reveal
- Verify commit-reveal timing for compliance
- Build commit-reveal workflow tools
- Debug failed weight reveals
- Research weight commitment patterns
From Chain Metadata
MAP (netuid, who) --> VecDeque<(hash, commit_block, first_reveal_block, last_reveal_block)> | Stores a queue of commits for an account on a given netuid.
Purpose & Usage
Purpose
Support commit-reveal scheme for weight privacy - prevents front-running attacks.
Common Query Patterns
- Check if a validator has pending commits
- Validate reveal against commitment
- Track commit-reveal status for validators
Migration Notes
value type changed from (H256, u64) to Vec<(H256, u64, u64, u64)>
Update decoders: SCALE encoding is positional, so any signature change (added, removed, or type-changed fields, or storage shape changes) shifts byte offsets and existing decoders will misparse this item. Re-derive types from the new metadata.
Query Keys
Stored Value
VecDeque<(hash, (Vec<(H256, u64, u64, u64)>)
Relationships
Modified By
Code Examples
import { createClient, Binary } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws";
import { sub } from "@polkadot-api/descriptors"; // generated by: npx papi add sub -w wss://entrypoint-finney.opentensor.ai:443
const client = createClient(getWsProvider("wss://entrypoint-finney.opentensor.ai:443"));
const api = client.getTypedApi(sub);
// Query WeightCommits storage
const netuid = 1;
const who = "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY";
const result = await api.query.SubtensorModule.WeightCommits.getValue(netuid, who);
console.log("WeightCommits:", result);On-Chain Activity
1M–10M estimated writes
#24 most written storage item
Modified via user-submitted extrinsics
As of block 7,429,232
Version History
- value :
(H256, u64)→Vec<(H256, u64, u64, u64)>
Runtime Info
View Source- Pallet
- SubtensorModule
- Storage Kind
- Map
- First Version
- v151
- Current Version
- v411