Add storage bounds for pallet staking
#6445
Conversation
| /// Ideally, it should be `BondingDuration::get() + 1` to include all eras in the interval | ||
| /// [current_era - BondingDuration::get(), current_era]. | ||
| #[pallet::constant] | ||
| type MaxBondedEras: Get<u32>; |
There was a problem hiding this comment.
we should have an integrity test ensuring MaxBondedEras >= BondingDuration + 1
There was a problem hiding this comment.
Added in tests
assert_eq!(MaxBondedEras::get(), (BondingDuration::get() as u32) + 1);
| pub type ErasStakersPaged<T: Config> = StorageNMap< | ||
| _, | ||
| ( | ||
| NMapKey<Twox64Concat, EraIndex>, | ||
| NMapKey<Twox64Concat, T::AccountId>, | ||
| NMapKey<Twox64Concat, Page>, | ||
| ), | ||
| ExposurePage<T::AccountId, BalanceOf<T>>, | ||
| ExposurePage<T::AccountId, BalanceOf<T>, T::MaxExposurePageSize>, |
There was a problem hiding this comment.
@gpestana should we reduce MaxExposurePageSize before we do this? What would be the ideal number? 64/128?
To give context, once we make this bounded, reducing it would need (large) migration. Alternatively, we can make it WeaklyBoundedVec.
There was a problem hiding this comment.
Using WeakBoundedVec in c066632
| _, | ||
| Twox64Concat, | ||
| EraIndex, | ||
| EraRewardPoints<T::AccountId, <T::ElectionProvider as ElectionProviderBase>::MaxWinners>, |
There was a problem hiding this comment.
Actually this is not correct. The storage ValidatorCount is the right value.
We can potentially turn it into a config item but that has the implication that increasing validator count would always require runtime upgrade and cannot happen via governance. To fix that, you will have to also turn it into a dynamic parameter (see here).
| _, | ||
| BoundedVec< | ||
| (u32, OffenceSeverity), | ||
| <T::ElectionProvider as ElectionProviderBase>::MaxWinners, |
There was a problem hiding this comment.
Same as above.
Also, consider using WeaklyBoundedVec since we expect validator numbers to change over time. An increase in the value is not an issue but for some reason if we decrease it, it can lead to decode issues with BoundedVec.
There was a problem hiding this comment.
Actually, DisabledValidators would be a much smaller number than the actual validator set, and it depends on the DisablingStrategy, which is currenctly 1/3rd of the set. This can also be a new config value.
| self.invulnerables.len() as u32 <= T::MaxInvulnerables::get(), | ||
| "Too many invulnerable validators at genesis." | ||
| ); | ||
| <Invulnerables<T>>::put(BoundedVec::truncate_from(self.invulnerables.clone())); |
There was a problem hiding this comment.
The stakers param in GenesisConfig itself can be BoundedVec, right?
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
This is part of #6289 and necessary for the Asset Hub migration.
Building on the observations and suggestions from #255 .
Changes
MaxInvulnerablesto boundInvulnerablesVec.westend).MaxWinnersfrompallet-election-provider-supportto boundDisabledValidatorsVec andEraRewardPoints.individualBTreeMap.ErasStakersandErasStakersClipped(see Tracker issue for cleaning up old non-paged exposure logic in staking pallet #433 )MaxExposurePageSizeto boundErasStakersPaged->ExposurePage.othersVecMaxBondedErasto boundBondedErasVecBondingDuration::get() + 1everywhere to include both time interval endpointsMaxRewardPagesPerValidatorto boundClaimedRewardsVec of pagesWeakBoundedVecTO DO
Slashing storage items will be bounded in another PR.
UnappliedSlashesSlashingSpans