commit_weights

Call v151 → current #96

Commits a hash of weights for later reveal.

View calls on chain

Click items to navigate. Pan and zoom to explore.

Used by: validatorsdevelopers

The Big Picture

Commit-reveal prevents weight copying. Without it, validators could wait to see others' weights and copy them. With commit-reveal, you first submit a hash (commit), then reveal the actual weights later. Since you can't change weights after committing, and can't see others' commits, everyone must evaluate miners independently. This ensures honest consensus.

Why This Matters

If validators can copy weights, lazy validators profit from others' work. Commit-reveal forces everyone to do their own evaluations. The hash locks you in before anyone sees your choices.

Example Scenario

Subnet 18 requires commit-reveal. After evaluating miners, you compute hash = sha256(weights + salt). Call commit_weights(netuid=18, commit_hash=hash). Wait for the reveal window (usually next epoch). Then call reveal_weights with your actual weights and salt. The chain verifies hash(weights, salt) == your commit.

Common Questions

What happens if I don't reveal in time?
Your commitment expires, and you miss that epoch's weight update. No penalty beyond lost opportunity, but your weights won't affect miner rankings.
What's the salt for?
Randomness. Without salt, someone could try hashing common weight patterns to guess your weights from the hash. Salt makes this impossible.
How long between commit and reveal?
Subnet-configurable. Typically one epoch (360 blocks / ~72 minutes). Check CommitRevealPeriod for the subnet.

Use Cases

  • Submit weight evaluations on subnets requiring commit-reveal
  • Prevent weight copying by other validators
  • Participate in MEV-resistant consensus mechanisms
  • Ensure fair weight aggregation without front-running

From Chain Metadata

- Used to commit a hash of your weight values to later be revealed.

Input Parameters

#NameTypeDescription
0
netuid
u16 Subnet/network identifier (0-65535)
1
commit_hash
H256 commit_hash (H256)

Permissions

Origin
Signed
Required Role
Hotkey
Authorization Checks
  • Hotkey must be registered on the target subnet

Requirements

  • Caller is registered validator on subnet
  • Commit-reveal enabled for subnet
  • Valid commitment hash provided

Effects

Events Emitted

WeightsCommitted

Storage Modified

WeightCommitsLastTxBlock

Postconditions

  • Weight commitment recorded
  • Commit timestamp recorded

Side Effects

  • Must reveal weights before commitment expires

Possible Errors

NotEnoughStakeToSetWeightsWeightVecNotEqualSizeNotSettingEnoughWeightsWeightVecLengthIsLowMaxWeightExceededSettingWeightsTooFastIncorrectWeightVersionKeyCanNotSetRootNetworkWeightsNoWeightsCommitFoundWeightsCommitNotAllowedExpiredWeightCommitCommittingWeightsTooFastAdminActionProhibitedDuringWeightsWindow

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 });

// Build commit_weights call
const netuid = 1;
const commit_hash = 0 as any /* H256 */;

const call = api.tx[stringCamelCase("SubtensorModule")][stringCamelCase("commit_weights")](
  netuid,
  commit_hash
);

On-Chain Activity

Usage Frequency
●●●○○○ Moderate 10K–100K extrinsics

Occasional use

#36 most used call

Success Rate Challenging

20–50% of submissions succeed

As of block 7,429,232

Runtime Info

View Source
Pallet Index
7
Call Index
96
First Version
v151
Current Version
v393
Back to SubtensorModule Calls