[Feature] Configurable Tempo & Owner-Triggered Epochs by evgeny-s · Pull Request #2638 · opentensor/subtensor

evgeny-s · 2026-05-06T11:36:12Z

Description

Implementation of the specification.

Demo (non-technical): https://dynamic-tempo-non-technical.netlify.app/
Demo (technical): https://dynamic-tempo-technical.netlify.app/#1

Related Issue(s)

Closes #[issue number]

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation update
Other (please describe):

Breaking Change

Check the 11. Breaking changes & compatibility section.

Checklist

I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

Simulations (miner rewards Events):

Trigger epoch:

Set tempo:

gztensor · 2026-05-06T20:57:21Z

+    /// stateful scheduler (period `tempo + 1`, anchored on `LastEpochBlock`). Used by the
+    /// admin-freeze-window predicate and external tooling. Returns `u64::MAX` when
+    /// `tempo == 0` (legacy defensive short-circuit).
    pub fn blocks_until_next_epoch(netuid: NetUid, tempo: u16, block_number: u64) -> u64 {


"Period is tempo + 1: next firing at last + tempo + 1." comment and the code below is not anymore correct.

Updated the function name and the comment to avoid the confusion: ad7ba80

evgeny-s · 2026-05-13T09:47:15Z

Hey, @basfroman , we have a bunch of tests that failed on the SDK side.
The main reason is now we have a stateful calculation for the next epoch block, because the tempo is dynamic.
So, here you can just call the new runtime API - get_next_epoch_start_block.

# Conflicts: # pallets/subtensor/src/utils/rate_limiting.rs

# Conflicts: # pallets/subtensor/src/coinbase/run_coinbase.rs # pallets/subtensor/src/macros/dispatches.rs # pallets/subtensor/src/macros/events.rs # pallets/subtensor/src/macros/hooks.rs # pallets/subtensor/src/tests/migration.rs # pallets/subtensor/src/tests/mod.rs # pallets/subtensor/src/utils/rate_limiting.rs

- Updated reveal/commit logic based on stateful epoch index - Updated migration for CR-v2 storage item

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-09T12:46:43Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits is live user-controlled commit-reveal storage, and this runtime upgrade collects the entire double map into a Vec before rewriting any entries. A large enough live commit set can make the upgrade allocate excessive Wasm memory or exceed block limits before the migration can complete, which is a chain-upgrade safety risk. Rewrite this as a bounded/streaming migration, for example with translate/paged cursor state or by otherwise bounding the number of entries processed per upgrade step.

github-actions · 2026-06-09T12:46:56Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-09T14:44:20Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

This runtime migration still calls WeightCommits::<T>::iter().collect() before rewriting entries. WeightCommits is live user-controlled commit-reveal storage, so a sufficiently large set of entries can force the runtime upgrade to allocate an unbounded vector in Wasm memory and risk trapping/bricking the chain during on_runtime_upgrade. Rewrite this as a bounded/streaming migration pattern, or split it behind a bounded cursor/kill-and-reinsert strategy whose per-block weight and memory are capped.

github-actions · 2026-06-09T14:44:30Z

🔄 AI review updated — Skeptic: VULNERABLE

…lock

# Conflicts: # pallets/subtensor/src/macros/hooks.rs

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-11T11:16:28Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every CR-v2 commit queue in the runtime Wasm heap during on_runtime_upgrade. This storage is user-populated and can grow across all subnets/accounts, so a large live state can make the upgrade exceed memory/weight and abort or brick the chain before the rewrite completes. Iterate and translate entries incrementally, or use a bounded/multi-block migration with progress state instead of collecting the full map first.

github-actions · 2026-06-11T11:16:37Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-11T14:09:36Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

This runtime migration still loads every WeightCommits entry into a single Vec before rewriting them. WeightCommits is live user-controlled commit-reveal storage across subnet/mechanism/hotkey keys, so a sufficiently large state can make the upgrade allocate excessive Wasm memory or exceed the block during on_runtime_upgrade, risking a failed runtime upgrade. Rewrite this as a bounded/streaming migration pattern that does not materialize the entire map at once, with explicit weight accounting for the processed entries.

github-actions · 2026-06-11T14:09:48Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-11T20:23:59Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every live CR-v2 commit entry into a Vec during on_runtime_upgrade. This storage is user-growth dependent, so a large live commit set can exhaust runtime Wasm memory or make the upgrade block fail before any bounded rewrite happens. Iterate and rewrite entries without collecting the full map first, or split the migration into a bounded cursor-based upgrade path with explicit per-block limits.

github-actions · 2026-06-11T20:24:11Z

🔄 AI review updated — Skeptic: VULNERABLE

# Conflicts: # pallets/subtensor/src/benchmarks.rs # pallets/subtensor/src/weights.rs

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-12T10:30:50Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every live CR-v2 commit queue into Wasm memory during the runtime upgrade. WeightCommits is user-populated storage, so a sufficiently large live state can exceed the runtime memory/weight budget and abort the upgrade. Rewrite this as a streaming/key-by-key migration, or otherwise bound the number of entries processed per upgrade path, and account for each processed DB read/write without holding all entries at once.

github-actions · 2026-06-12T10:31:01Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-12T10:38:10Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every live CR-v2 commit entry before rewriting any of them during on_runtime_upgrade. This storage is user-populated across hotkeys/subnets, so a large live set can exhaust Wasm memory or make the runtime upgrade block fail before the migration writes progress. Rewrite entries in a streaming/draining pass, or bound/chunk the migration so each block has a hard upper limit and durable progress state.

github-actions · 2026-06-12T10:38:20Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-06-15T09:29:19Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

This runtime migration executes during upgrade, and WeightCommits::<T>::iter().collect() loads every CR-v2 commit entry, including each account's commit queue, into one Wasm Vec before rewriting. That storage is live chain state and this migration has no batching/cursor bound, so a sufficiently large state can exhaust Wasm memory or make the upgrade overweight and brick the chain. Rewrite this as a bounded/streaming storage translation, or split it into cursor-based migration steps with version state.

github-actions · 2026-06-15T09:29:28Z

🔄 AI review updated — Skeptic: VULNERABLE

evgeny-s added 2 commits May 6, 2026 12:55

Dynamic tempo implementation

d30a76f

clippy + fmt

42b3e29

evgeny-s added the skip-cargo-audit This PR fails cargo audit but needs to be merged anyway label May 6, 2026

evgeny-s changed the title ~~Dynamic tempo implementation~~ [Feature] Configurable Tempo & Owner-Triggered Epochs May 6, 2026

clean up

c6567e2

gztensor requested changes May 6, 2026

View reviewed changes

evgeny-s added 17 commits May 7, 2026 11:29

Renamed function + updated comment

ad7ba80

wrap set tempo + cycle reset with a helper function

df184e3

tests

b2e4658

clippy

02f43ee

Merge branch 'devnet-ready' into feature/dynamic-tempo

40f2773

fixed test from devnet

c3fa417

Merge branch 'devnet-ready' into feature/dynamic-tempo

dca9f44

- disable dynamic tempo for subnets with CR enabled.

73d1ab4

- update migration - do not clamp tempos

1ba4a3d

fix migration test

215f13b

Added benchmarks for new extrinsics

577d62b

Merge branch 'devnet-ready' into feature/dynamic-tempo

ff61eb3

fix for e2e test

e15d749

- Increase timeout

7a1d7a3

- updated name + timeout

4c06820

increase MAX_EPOCHS_PER_BLOCK for fast-runtime

82ae882

Added runtime API to get the next epoch start block

bcfe012

open-junius reviewed May 13, 2026

View reviewed changes

Comment thread pallets/subtensor/src/utils/misc.rs

evgeny-s added 3 commits May 15, 2026 14:07

Merge branch 'devnet-ready' into feature/dynamic-tempo

34bcc41

# Conflicts: # pallets/subtensor/src/utils/rate_limiting.rs

- fix test after dev merge

b5b4184

github-actions Bot mentioned this pull request May 21, 2026

Ai reviewer #2668

Merged

4 tasks

- Added stateful SubnetEpochIndex

1fc3e88

- Updated reveal/commit logic based on stateful epoch index - Updated migration for CR-v2 storage item

- Fixed rpc call for activity cutoff

14631b9

github-actions Bot reviewed Jun 9, 2026

View reviewed changes

- fixed tests for activity_cutoff + added cutoff_factor

08c4d32

github-actions Bot reviewed Jun 9, 2026

View reviewed changes

github-actions Bot mentioned this pull request Jun 9, 2026

Add min_childkey_take_per_subnet hyperparameter #2734

Open

13 tasks

basfroman mentioned this pull request Jun 10, 2026

Dynamic tempo support latent-to/bittensor-drand#71

Open

evgeny-s added 2 commits June 11, 2026 13:12

- Defer the reveal if the block has deferred because of MaxEpochsPerB…

bf98537

…lock

Merge branch 'devnet-ready' into feature/dynamic-tempo

43b63fa

# Conflicts: # pallets/subtensor/src/macros/hooks.rs

github-actions Bot reviewed Jun 11, 2026

View reviewed changes

thewhaleking mentioned this pull request Jun 11, 2026

Update for configurable tempo and owner triggered epochs latent-to/btcli#1000

Open

- Disable epoch trigger for CR enabled subnets

0c6f0df

github-actions Bot reviewed Jun 11, 2026

View reviewed changes

basfroman mentioned this pull request Jun 11, 2026

Support dynamic tempo latent-to/bittensor#3383

Open

3 tasks

- Added config params for tempo and activity cutoff boundaries

eaa4f62

github-actions Bot reviewed Jun 11, 2026

View reviewed changes

Merge branch 'devnet-ready' into feature/dynamic-tempo

c89796d

# Conflicts: # pallets/subtensor/src/benchmarks.rs # pallets/subtensor/src/weights.rs

github-actions Bot reviewed Jun 12, 2026

View reviewed changes

Fix for clippy

4e08638

github-actions Bot reviewed Jun 12, 2026

View reviewed changes

- Fixed eco tests

da942cf

github-actions Bot reviewed Jun 15, 2026

View reviewed changes

github-actions Bot mentioned this pull request Jun 16, 2026

Adds min_childkey_take to hyperparams v3 #2761

Open

13 tasks

Conversation

evgeny-s commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issue(s)

Type of Change

Breaking Change

Checklist

Screenshots (if applicable)

Additional Notes

Simulations (miner rewards Events):

Uh oh!

Uh oh!

gztensor May 6, 2026

Choose a reason for hiding this comment

Uh oh!

evgeny-s May 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

evgeny-s commented May 13, 2026

Uh oh!

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 9, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 9, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 9, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 9, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 11, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 11, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 11, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 12, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 12, 2026

Uh oh!

github-actions Bot left a comment

evgeny-s commented May 6, 2026 •

edited

Loading