WeightCommits

Storage Re-added Map v151 → v202, v205 → current

Committed weight hashes awaiting reveal.

Queried by: validatorssubnet ownersdevelopers

The 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

Query Keys

#	Name	Type	Description
1	key1	u16	key1 (u16)
2	key2	AccountId	key2 (AccountId) (hex -> SS58)

Stored Value

Vec<(H256, u64, u64, u64)> Vec

Value in RAO (÷10⁹ for TAO)

Relationships

Modified By

batch_commit_weights batch_reveal_weights commit_mechanism_weights commit_weights reveal_mechanism_weights reveal_weights

Code Examples

import { ApiPromise, WsProvider } from "@polkadot/api";
import { stringCamelCase } from "@polkadot/util";

const provider = new WsProvider("wss://entrypoint-finney.opentensor.ai:443");
const api = await ApiPromise.create({ provider });

// Query WeightCommits storage
const key1 = 0;
const key2 = "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY";

const result = await api.query
  [stringCamelCase("SubtensorModule")]
  [stringCamelCase("WeightCommits")](
  key1,
  key2
);

console.log("WeightCommits:", result.toHuman());

On-Chain Activity

Write Frequency

●●●●●○ High 1M–10M est. writes

1M–10M estimated writes

#24 most written storage item

Write Source User Extrinsics

Modified via user-submitted extrinsics

As of block 7,429,232

Version History

Version:

v151 block 3,157,274 Added

v205 block 4,209,446 Re-added Current

Runtime Info

View Source

Pallet: SubtensorModule
Storage Kind: Map
First Version: v151
Current Version: v393

Back to SubtensorModule Storage