Time-Lock Encryption
Time-lock encryption is the cryptographic technique that lets a value be encrypted so it cannot be decrypted until a future point, which is what allows Bittensor’s commit-reveal weight scheme to hide validator weights until their reveal time. The Glossary: Drand / Time-Lock Encryption entry describes the drand-based scheme used to time-lock committed weights.
What It Does
Time-lock encryption encrypts a committed value against a future condition so that no one, including the committer, can read it before that condition is met. In commit-reveal, a validator’s weight vector is time-locked when committed and becomes readable only at reveal (Commit Reveal).
It is the cryptographic primitive behind the hidden window, not the policy that sets the window’s length. How long weights stay hidden is governed by the commit-reveal period, while time-lock encryption is what makes the hiding enforceable (Subnet Hyperparameters).
Drand as the Time Source
The documented scheme relies on drand, a publicly verifiable randomness beacon, as the external time reference. Committed weights are encrypted so they can only be decrypted once drand publishes the value tied to the reveal round, which gives the subnet a trust-minimized clock rather than relying on any single party to release the data (Glossary: Drand / Time-Lock Encryption).
Because the decryption condition is external and public, no validator can reveal early and no operator has to be trusted to hold and release the weights at the right moment.
Distinction from Commit Reveal
Commit-reveal is the overall weight-setting scheme — commit now, reveal later — while time-lock encryption is the cryptographic mechanism that enforces the “reveal later” part. One is the protocol; the other is the primitive it depends on (Commit Reveal, Glossary: Commit Reveal).
- Commit reveal — the commit-then-reveal weight scheme.
- Time-lock encryption — the crypto that keeps committed weights unreadable until reveal.
Distinction from Weight Copying
Weight copying is the behavior time-lock encryption is meant to deter: a validator reading another’s weights and resubmitting them without independent evaluation. Time-lock encryption removes the fresh plaintext a copier would need by keeping committed weights encrypted until reveal (Glossary: Weight Copying).
- Weight copying — riding another validator’s revealed weights.
- Time-lock encryption — hiding weights so there is nothing fresh to copy.
Why It Matters for Consensus
Time-lock encryption matters because it makes weight privacy enforceable without a trusted releaser. A subnet using commit-reveal can keep validator weights confidential during the sensitive window, then have them revealed automatically when the drand condition is met (Commit Reveal).
For readers, time-lock encryption is the cryptographic foundation that makes commit-reveal credible. The commit-reveal period decides how long weights stay hidden, but time-lock encryption is what guarantees they actually stay hidden for that long (Yuma Consensus).
Distinction from Standard Encryption
Time-lock encryption differs from ordinary encryption in what unlocks it. Standard encryption is unlocked by whoever holds the decryption key, so the holder can decrypt at any time. Time-lock encryption is unlocked by a future public condition — in Bittensor, a drand round — so not even the committer can read the value before that condition is met (Glossary: Drand / Time-Lock Encryption).
That property is exactly what the commit-reveal scheme needs. If a validator could decrypt its own committed weights early, it could selectively reveal or adapt them; because time-lock encryption ties decryption to an external drand round rather than a held key, the concealment applies equally to everyone, including the committer, until reveal (Commit Reveal).
- Standard encryption — unlocked by holding the decryption key.
- Time-lock encryption — unlocked by a future public condition, not by any key holder.
Distinction from Commit Reveal Period
The commit reveal period is the CommitRevealPeriod hyperparameter that sets how many tempos pass
before committed weights are revealed. Time-lock encryption is the cryptographic primitive that
keeps committed weights unreadable across that window
(Subnet Hyperparameters,
Commit Reveal).
- Commit reveal period — how many tempos committed weights stay hidden.
- Time-lock encryption — the crypto that enforces that concealment for the full period.
Distinction from Drand Time-Lock Encryption
Time-lock encryption names the general idea that ciphertext unlocks only after a scheduled future time or round. Drand time-lock encryption is Bittensor’s form for Commit Reveal: decryption is bound to a specific future Drand round from the League of Entropy beacon rather than an arbitrary unlock schedule (Glossary: Drand / Time-Lock Encryption, Commit Reveal).
- Time-lock encryption — generic delayed-decryption pattern for any chosen unlock time or round.
- Drand time-lock encryption — Bittensor’s Drand-beacon form used to conceal validator weights until reveal.
Distinction from Yuma Consensus
Time-lock encryption names encryption that cannot be decrypted until a future point, which is what lets validators commit weights without revealing them early in a commit-reveal round. It belongs to the commit-reveal privacy layer, not to the tempo mechanism that settles incentives from revealed weights (Commit Reveal, Glossary: Drand / Time-Lock Encryption).
- Time-lock encryption — timed-release encryption for commit-reveal weights.
- Yuma Consensus — on-chain settlement that turns validator weights into emission shares. Time-lock encryption names weight disclosure timing; Yuma processes validator weights into rewards (Yuma Consensus: Validator emissions).
- Commit reveal — scheme that hides weights until their reveal window.
Only after reveal does Yuma treat those weights as readable inputs for consensus clipping and emission mapping on the subnet, so time-lock encryption names the privacy step while Yuma names the settlement step that follows (Commit Reveal, Implementation of the Yuma Consensus Epoch).
Reader Boundary
Time-lock encryption should not be read as the commit-reveal policy itself or as proof that a subnet’s weights are currently hidden. It names the drand-based cryptographic primitive that makes committed weights unreadable until reveal (Glossary: Drand / Time-Lock Encryption, Commit Reveal).
Whether commit-reveal is enabled and how long the concealment window lasts are separate hyperparameter questions for the selected netuid (Subnet Hyperparameters).