-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Store validator approval-stakes in TargetList, use for ranking validators. #11013
Store validator approval-stakes in TargetList, use for ranking validators. #11013
Conversation
Co-authored-by: Zeke Mostov <[email protected]>
…ate into kiz-validators-in-bags
…ate into kiz-revamp-sorted-list-providers
…amp-sorted-list-providers
Co-authored-by: Zeke Mostov <[email protected]>
frame/bags-list/src/migrations.rs
Outdated
@@ -20,8 +20,8 @@ | |||
use frame_support::traits::OnRuntimeUpgrade; | |||
|
|||
/// A struct that does not migration, but only checks that the counter prefix exists and is correct. | |||
pub struct CheckCounterPrefix<T: crate::Config>(sp_std::marker::PhantomData<T>); | |||
impl<T: crate::Config> OnRuntimeUpgrade for CheckCounterPrefix<T> { | |||
pub struct CheckCounterPrefix<I: 'static, T: crate::Config<I>>(sp_std::marker::PhantomData<(I, T)>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the instance usually the second index?
…ithub.com:paritytech/substrate into kiz-revamp-sorted-list-providers-2-approval-stake
Co-authored-by: Shawn Tabrizi <[email protected]>
…ithub.com:paritytech/substrate into kiz-revamp-sorted-list-providers-2-approval-stake
Once #11357 is done, do you want to also add the staking part? |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
@ruseinov might take a stab at bringing this back to life as well. Once done, please close this and open a new PR. |
Note that this is a pretty much the last important piece of the puzzle in making Polkadot staking scalable. |
being worked at in a different PR |
This PR re-uses the bags-list pallet to sort validators candidates as well. This bags-list- instance is used to filter the top x validators to be considered for election, i.e. become electable. See here for more info on this.
The
Score
used in this instance of the bags-list is the approval stake of the validator. The approval stake of each validator is essentially the sum of the stake of any nominator who has nominated them (undivided), plus their self-stake.Maintaining approval stakes requires an update to the interface of the bags-list pallet. Previously, updates were reported to the bags-list only via:
In this function, the
score
is the new updated score ofid
. This won't work for approval stakes, because we don't store the approval stake of validators anywhere in the staking pallet. Instead, the bags-list pallet has been updated to store the last known score. With this, we can use two new functions, which actually get an auto-implementation given the existence of aget_score
:I will probably extract these changes into a separate PR and make it be in an upcoming release soon, because it will require a migration to add the score to the existing bags-list.
All in all, in the new staking system, we have to list providers:
VoterList
: something that gives us a sorted list of electing npos voters.TargetList
: something that gives us a sorted list of electable npos targets.Once we have this, in the staking pallet, we have to keep a detailed bookkeeping: every time a staker updates either their stake amount, or when they update their nomination/validation status, we need to react. Luckily most of this logic has now been placed in a handful of functions:
update_ledger
: called every time the active ledger of an account changes.TargetList
VoterList
.VoterList
.TargetList
.do_add_nominator
: called every time someone callsnominate
incoming
andoutgoing
(self-explanatory names) sets of their current and previous nominations, and update the approval stake inTargetList
.do_remove_nominator
: called every time a nominator is potentially removed (chill
,validate
,kill_stash
).do_add_validator
: called every time someone callsvalidate
.VoterList
.TargetList
.do_remove_validator
:A nuanced detail here is that now each nominator can potentially create up to 16 more storage maps. The reason for this is that if you nominate
vec![a, b, c, ..]
, we don't (and actually should not) check ifa, b, c
are actually validators.Moreover, this means that targets might be pulled out of the target list that are not even validators at the time of election. We need to take care of this by filtering them out and keep trying until we get enough electable targets.
PR is almost done, but needs a few more rounds of my self-review and elimination of TODOs.