Provider Boosting implementation

[shannonwells]

Goal

Implement a Provider Boost feature, whereby token holders may support the network and a specific Provider by means of a custom staking model. Token holders lock up a certain amount of token, and receive a return in Frequency token for this support. The token holder chooses a Provider to receive some Capacity, which the Provider may use to pay for chain transactions.

Token holders may still stake for MaximizedCapacity and receive no token return. As before, the entire benefit for staking would go to the targeted Provider for this type.

Discussion

Support the new staking type, Provider Boost

1. The stake transaction now specifies the Staking Type of MaximizedCapacity which is stored with StakingTargetDetails.
2. There are 3 new extrinsics:
   • provider_boost which specifies ProviderBoost staking type.
   • claim_staking_rewards which mints and transfers all eligible rewards in token to the staker.
   • change_staking_target which basically swaps your Provider Boost staking target from one Provider to another.
3. The StakingType determines how much Capacity is generated for the targeted provider. For ProviderBoost type, 50% of the Capacity for MaximizedCapacity is generated when using provider_boost.
4. The StakingType also determines if there is a periodic return in token to the staker. For ProviderBoost type, there is a periodic return. For MaximizedCapacity type, there isn't.

Issue rewards to Provider Boost accounts

1. Rewards are a fixed amount based on the proportion of staked amount to total staked amount, and capped at 10% per year, or to ~0.0385% per Reward Era.
2. Individual Rewards are calculated based on the number of complete RewardEras that the token holder has staked.
3. A RewardEra is approximately two weeks of blocks.
4. Reward Pool size is a constant.
5. Rewards are are not compounded.
6. Rewards are minted when they are claimed. All available Rewards are paid out when the claim_staking_rewards extrinsic succeeds.
7. Rewards expire after 30 Reward Eras. This is the limit of the Reward Pool History storage and the limit of the individual Provider Boost History storage, so rewards cannot be claimed for earlier eras. With that said, if for example you ProviderBoost 10,000 FRQCY, and did nothing else for say 50 Reward Eras ("set and forget"), you would not lose everything. You would simply would not be paid out except for the last 30 Eras. Only the potential earnings for the 20 eras before that would be lost.

Allow a staking 'retarget'

A staker may change some or all of their staked token to target a different provider up to 16 times in a RewardEra without penalty. Otherwise, they must wait until the next RewardEra.

For more details, please see the Capacity Staking Rewards Implementation design doc, which links to the economic model for this feature.

Checklist

• Chain spec updated
• Custom RPC OR Runtime API added/changed? Updated js/api-augment.
• Design doc(s) updated
• Tests added
• Benchmarks added
• Weights updated

[codecov]

Codecov Report

Attention: Patch coverage is 92.80899% with 32 lines in your changes missing coverage. Please review.

Files	Patch %	Lines
pallets/capacity/src/lib.rs	94.80%	15 Missing ⚠️
...lets/capacity/src/migration/provider_boost_init.rs	0.00%	10 Missing ⚠️
pallets/capacity/src/types.rs	95.00%	7 Missing ⚠️

Files	Coverage Δ
common/primitives/src/capacity.rs	75.00% <100.00%> (+75.00%)	⬆️
pallets/capacity/src/types.rs	96.37% <95.00%> (+0.79%)	⬆️
...lets/capacity/src/migration/provider_boost_init.rs	0.00% <0.00%> (ø)
pallets/capacity/src/lib.rs	94.84% <94.80%> (-0.51%)	⬇️

[enddynayn]

Just leaving this as a note: we might want to consider using the new Poll hook instead of on_initialize. Here’s the relevant issue for reference: #2098.

[shannonwells]

Suggestions for better wording, or leave it out entirely?