Voting Power EMA #2240
Voting Power EMA #2240
Conversation
|
Enabled the CI process, to check if EVM test is runnable for PR. |
can we try again? |
|
|
||
| // Only remove if they previously had voting power ABOVE threshold and it decayed below. | ||
| // This allows new validators to build up voting power from 0 without being removed. | ||
| if new_ema < min_stake && previous_ema >= min_stake { |
There was a problem hiding this comment.
If the new validator has just built the previous_ema above min_stake and new_ema dropped below min_stake because of noise, the ema will be reset to 0. Is that desired behavior?
There was a problem hiding this comment.
Didn’t thought of this edge case
I guess we can then decide to reset to 0 when it gets below 90% of required threshold?
konrad0960
force-pushed
the
voting-power-feature
branch
from
2a22ace to
e541d53
Compare
| StakeWeight::<T>::insert(netuid, stake_weight); | ||
|
|
||
| // Update voting power EMA for all validators on this subnet | ||
| Self::update_voting_power_for_subnet(netuid, output); |
There was a problem hiding this comment.
Great update! Please one little change here: Call this function before (or after) calling persist_netuid_epoch_terms in epoch_with_mechanisms to avoid confusion that persist_netuid_epoch_terms also updates voting power.
| let new_ema = Self::calculate_voting_power_ema(current_stake, previous_ema, alpha); | ||
|
|
||
| // Use 90% of min_stake as removal threshold (hysteresis to prevent noise-triggered removal) | ||
| let removal_threshold = min_stake.saturating_mul(9) / 10; |
There was a problem hiding this comment.
Please use safe_div(10u64) or CI will fail
|
|
||
| // Only remove if they previously had voting power ABOVE threshold and decayed significantly below. | ||
| // This allows new validators to build up voting power from 0 without being removed. | ||
| if new_ema < removal_threshold && previous_ema >= min_stake { |
There was a problem hiding this comment.
If alpha is slow enough, we'll probably never hit this condition.
There was a problem hiding this comment.
So far the requirements didn't specify how fast removal should happen in case stake is drastically dropped.
Hard rules on having voting power removed immediately if stake drops below threshold could be easily gamed by dropping stake just near the threshold.
Probably assymetric EMA could solve this? Introducing alpha_up and alpha_down whereas alpha_down should default to faster decay in example 0.5?
| // Iterate over epoch output using pre-calculated values | ||
| for (hotkey, terms) in epoch_output.iter() { | ||
| // Only validators (with vpermit) get voting power, not miners | ||
| if terms.new_validator_permit { |
There was a problem hiding this comment.
What happens if a neuron gets deregistered? We don't have it in epoch terms, but we've got to garbage-collect their voting power at some point, probably not immediately.
There was a problem hiding this comment.
we got clear_voting_power_for_deregistered_hotkeys() just at the end of this function
3 participants
Description
Voting power feature
Purpose: Track validator voting power using an Exponential Moving Average (EMA) of their stake over time, preventing sudden stake changes from immediately affecting governance weight.
Key Components:
Extrinsics: enable_voting_power_tracking, disable_voting_power_tracking, sudo_set_voting_power_ema_alpha
Storage: VotingPower, VotingPowerTrackingEnabled, VotingPowerDisableAtBlock, VotingPowerEmaAlpha
Type of Change
Checklist
./scripts/fix_rust.shto ensure my code is formatted and linted correctlyAdditional Notes
I’ve attempted to run the VotingPower precompile EVM tests locally but encountered multiple Node.js compatibility issues with the polkadot-api dependencies.
Being unable to resolve them I want to give CI a try
That being said the unit tests written cover the core logic.