Skip to content

Conversation

JohnReedV
Copy link
Contributor

@JohnReedV JohnReedV commented Jun 26, 2025

Description

This upgrade makes the epoch ignore weights that point to a miner which registered during the current commit-reveal period when commit-reveal is enabled. The result is that only miners that were registered before the last reveal can receive incentive.

Also bounds reveal_period to [1, 100] to prevent owners from indefinitely excluding new miners via excessive values.

Motivation

Bad actors could snipe a freshly-vacated UID because unrevealed weights still target that UID, instantly collecting rank & rewards for work they never did. Masking weights that reference de-registered miners closes this exploit and aligns rewards with actual effort.

Related Issue(s)

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):

@JohnReedV JohnReedV added the skip-cargo-audit This PR fails cargo audit but needs to be merged anyway label Jul 3, 2025
@JohnReedV JohnReedV marked this pull request as ready for review July 9, 2025 22:12
@JohnReedV JohnReedV changed the title Commit-Reveal neuron dereregistration Commit-Reveal Weight Inheritance Jul 14, 2025
don't block new weight senders block new receivers
let safe_epoch =
reg_epoch.saturating_add(Self::get_reveal_period(netuid).saturating_mul(2));

Self::get_first_block_of_epoch(netuid, safe_epoch)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the reveal period is not tied to the epoch timing, then the check here should be to get the next epoch from the block after the reveal period ends.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So maybe last block of epoch +1, or next epoch, with just the reveal period end block

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the check here should be to get the next epoch from the block after the reveal period ends.

This is what the current implementation already does

  • safe_epoch = reg_epoch + (reveal_period * 2) -> first block of that epoch is the block after the 2-period window.
  • The extra period shields against unrevealed commits made during the deregistration period that still target the vacated UID. Dropping it would remove that protection.
  • reveal_period is in epochs.

@sam0x17 sam0x17 merged commit b7ac269 into devnet-ready Jul 16, 2025
59 of 62 checks passed
This was referenced Jul 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip-cargo-audit This PR fails cargo audit but needs to be merged anyway
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants