Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New staking reward system #439

Closed
kianenigma opened this issue Dec 5, 2022 · 5 comments
Closed

New staking reward system #439

kianenigma opened this issue Dec 5, 2022 · 5 comments
Assignees
@Ank4n

Comments

@kianenigma
Copy link
Contributor

kianenigma commented Dec 5, 2022 •
edited by Ank4n
Loading

Objectives:

  1. Staking roles (ledger, etc.) to be entirely decoupled from reward-related logic.
  2. (probably not worth it) Rewards to be mire customizable on a per-nominator basis. e.g. one nominator not being paid out automatically.
  3. Rewards to be scalable: they should be payable in smaller chunks. probably requires multi-page exposure table.
  4. Once we have 3, it should be very simple to actually make rewards automatic. Even better, automatic for those who want it to be.

Some this might require us to make things seemingly less efficient, but if we do it multi-page, it will actually be more scalable.
@kianenigma
Copy link
Contributor Author

related: #473 #282

@burdges
Copy link

burdges commented Dec 5, 2022

I'll remark that availability and approval reward points flowing into the validator end up kinda nuanced, but they still have a (era,point) resolution in the end. https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/rkTzZX_8t

@Ank4n Ank4n linked a pull request Dec 26, 2022 that will close this issue
[do not merge] Decouple rewards from ledger paritytech/substrate#13023
Closed
5 tasks
This was referenced Jan 2, 2023
Closed
Closed
This was referenced Feb 28, 2023
Closed
Open
@kianenigma kianenigma mentioned this issue Aug 24, 2023
Open
@Ank4n
Copy link
Contributor

Ank4n commented Apr 2, 2023

I am tackling point 1 and 3 of the issue in the PR paritytech/substrate#13498.

Since the reward would be distributed in multiple pages, one of the objectives of this PR is to incentivise a validator to pay out all pages of the reward. My current approach is to distribute commission of the validator across pages proportional to the total stake of the page.

I had couple of great suggestions for improvement and I wanted to get some opinion from @kianenigma and @burdges as well on this before making changes.

Suggestion 1 (@gpestana):
Instead of commission proportional to page stake, it can be evenly distributed across all pages irrespective of page stake. We can extend this even further and pay the validator stake also evenly across pages. (Right now validator stake is paid out in 1st page).

Suggestion 2 (@rossbulat) :
We can reverse the order of rewards payout, so that the page with lowest stake is paid out first and the highest stake is paid out only at last incentivising validators to pay out all pages. There is still an option though to pay out a page explicitly instead of pallet choosing the order automatically.

I am leaning towards doing the Suggestion 1 which would make Suggestion 2 not needed. What do you guys think?

@kianenigma
Copy link
Contributor Author

I think all of these suggestions are coming the perspective of protecting small nominators who are in the lesser pages from not receiving their rewards. This is fair concern, but I would generally avoid designing systems too much with such a mindset in mind. The goal of the game theory involved in FRAME or blockchains is not necessarily to protect everyone at any cost, but rather be a system that is sound, sustainable, or foremost unstoppable.

I think if we are to solely make decisions from this perspective, then the existing model makes perfect sense; if the total stake in a page is so small that no one has an incentive to claim it, then it should not be claimed (recall that anyone can do the claims, not just the validator).

That all being said, I won't resist against tweaking this system such that we slightly protect nominators, in which case I like option 1 way better. It doesn't 100% solve the issue, but it will drastically reduce the chances of a page being left unpaid.

@juangirini juangirini transferred this issue from paritytech/substrate Aug 24, 2023
@Ank4n Ank4n mentioned this issue Aug 26, 2023
Merged
11 tasks
Ank4n added a commit that referenced this issue Nov 1, 2023
@Ank4n @pepoviola
[NPoS] Paging reward payouts in order to scale rewardable nominators (#…
00b85c5 
…1189)

helps #439.
closes #473.

PR link in the older substrate repository:
paritytech/substrate#13498.

# Context
Rewards payout is processed today in a single block and limited to
`MaxNominatorRewardedPerValidator`. This number is currently 512 on both
Kusama and Polkadot.

This PR tries to scale the nominators payout to an unlimited count in a
multi-block fashion. Exposures are stored in pages, with each page
capped to a certain number (`MaxExposurePageSize`). Starting out, this
number would be the same as `MaxNominatorRewardedPerValidator`, but
eventually, this number can be lowered through new runtime upgrades to
limit the rewardeable nominators per dispatched call instruction.

The changes in the PR are backward compatible.

## How payouts would work like after this change
Staking exposes two calls, 1) the existing `payout_stakers` and 2)
`payout_stakers_by_page`.

### payout_stakers
This remains backward compatible with no signature change. If for a
given era a validator has multiple pages, they can call `payout_stakers`
multiple times. The pages are executed in an ascending sequence and the
runtime takes care of preventing double claims.

### payout_stakers_by_page
Very similar to `payout_stakers` but also accepts an extra param
`page_index`. An account can choose to payout rewards only for an
explicitly passed `page_index`.

**Lets look at an example scenario**
Given an active validator on Kusama had 1100 nominators,
`MaxExposurePageSize` set to 512 for Era e. In order to pay out rewards
to all nominators, the caller would need to call `payout_stakers` 3
times.

- `payout_stakers(origin, stash, e)` => will pay the first 512
nominators.
- `payout_stakers(origin, stash, e)` => will pay the second set of 512
nominators.
- `payout_stakers(origin, stash, e)` => will pay the last set of 76
nominators.
...
- `payout_stakers(origin, stash, e)` => calling it the 4th time would
return an error `InvalidPage`.

The above calls can also be replaced by `payout_stakers_by_page` and
passing a `page_index` explicitly.

## Commission note
Validator commission is paid out in chunks across all the pages where
each commission chunk is proportional to the total stake of the current
page. This implies higher the total stake of a page, higher will be the
commission. If all the pages of a validator's single era are paid out,
the sum of commission paid to the validator across all pages should be
equal to what the commission would have been if we had a non-paged
exposure.

### Migration Note
Strictly speaking, we did not need to bump our storage version since
there is no migration of storage in this PR. But it is still useful to
mark a storage upgrade for the following reasons:

- New storage items are introduced in this PR while some older storage
items are deprecated.
- For the next `HistoryDepth` eras, the exposure would be incrementally
migrated to its corresponding paged storage item.
- Runtimes using staking pallet would strictly need to wait at least
`HistoryDepth` eras with current upgraded version (14) for the migration
to complete. At some era `E` such that `E >
era_at_which_V14_gets_into_effect + HistoryDepth`, we will upgrade to
version X which will remove the deprecated storage items.
In other words, it is a strict requirement that E<sub>x</sub> -
E<sub>14</sub> > `HistoryDepth`, where
E<sub>x</sub> = Era at which deprecated storages are removed from
runtime,
E<sub>14</sub> = Era at which runtime is upgraded to version 14.
- For Polkadot and Kusama, there is a [tracker
ticket](#433) to clean
up the deprecated storage items.

### Storage Changes

#### Added
- ErasStakersOverview
- ClaimedRewards
- ErasStakersPaged

#### Deprecated
The following can be cleaned up after 84 eras which is tracked
[here](#433).

- ErasStakers.
- ErasStakersClipped.
- StakingLedger.claimed_rewards, renamed to
StakingLedger.legacy_claimed_rewards.

### Config Changes
- Renamed MaxNominatorRewardedPerValidator to MaxExposurePageSize.

### TODO
- [x] Tracker ticket for cleaning up the old code after 84 eras.
- [x] Add companion.
- [x] Redo benchmarks before merge.
- [x] Add Changelog for pallet_staking.
- [x] Pallet should be configurable to enable/disable paged rewards.
- [x] Commission payouts are distributed across pages.
- [x] Review documentation thoroughly.
- [x] Rename `MaxNominatorRewardedPerValidator` ->
`MaxExposurePageSize`.
- [x] NMap for `ErasStakersPaged`.
- [x] Deprecate ErasStakers.
- [x] Integrity tests.

### Followup issues
[Runtime api for deprecated ErasStakers storage
item](#426)

---------

Co-authored-by: Javier Viola <javier@parity.io>
Co-authored-by: Ross Bulat <ross@parity.io>
Co-authored-by: command-bot <>
@kianenigma
Copy link
Contributor Author

kianenigma commented Feb 5, 2024 •
edited
Loading

@Ank4n @gupnik @gpestana this is all done, except the last item. Closing. Please make an issue about the proposal to use #[pallet::task] or on_idle for optional automatic rewards.

bgallois pushed a commit to duniter/duniter-polkadot-sdk that referenced this issue Mar 25, 2024
@Ank4n @pepoviola
[NPoS] Paging reward payouts in order to scale rewardable nominators (p…
870ce7f 
…aritytech#1189)

helps paritytech#439.
closes paritytech#473.

PR link in the older substrate repository:
paritytech/substrate#13498.

# Context
Rewards payout is processed today in a single block and limited to
`MaxNominatorRewardedPerValidator`. This number is currently 512 on both
Kusama and Polkadot.

This PR tries to scale the nominators payout to an unlimited count in a
multi-block fashion. Exposures are stored in pages, with each page
capped to a certain number (`MaxExposurePageSize`). Starting out, this
number would be the same as `MaxNominatorRewardedPerValidator`, but
eventually, this number can be lowered through new runtime upgrades to
limit the rewardeable nominators per dispatched call instruction.

The changes in the PR are backward compatible.

## How payouts would work like after this change
Staking exposes two calls, 1) the existing `payout_stakers` and 2)
`payout_stakers_by_page`.

### payout_stakers
This remains backward compatible with no signature change. If for a
given era a validator has multiple pages, they can call `payout_stakers`
multiple times. The pages are executed in an ascending sequence and the
runtime takes care of preventing double claims.

### payout_stakers_by_page
Very similar to `payout_stakers` but also accepts an extra param
`page_index`. An account can choose to payout rewards only for an
explicitly passed `page_index`.

**Lets look at an example scenario**
Given an active validator on Kusama had 1100 nominators,
`MaxExposurePageSize` set to 512 for Era e. In order to pay out rewards
to all nominators, the caller would need to call `payout_stakers` 3
times.

- `payout_stakers(origin, stash, e)` => will pay the first 512
nominators.
- `payout_stakers(origin, stash, e)` => will pay the second set of 512
nominators.
- `payout_stakers(origin, stash, e)` => will pay the last set of 76
nominators.
...
- `payout_stakers(origin, stash, e)` => calling it the 4th time would
return an error `InvalidPage`.

The above calls can also be replaced by `payout_stakers_by_page` and
passing a `page_index` explicitly.

## Commission note
Validator commission is paid out in chunks across all the pages where
each commission chunk is proportional to the total stake of the current
page. This implies higher the total stake of a page, higher will be the
commission. If all the pages of a validator's single era are paid out,
the sum of commission paid to the validator across all pages should be
equal to what the commission would have been if we had a non-paged
exposure.

### Migration Note
Strictly speaking, we did not need to bump our storage version since
there is no migration of storage in this PR. But it is still useful to
mark a storage upgrade for the following reasons:

- New storage items are introduced in this PR while some older storage
items are deprecated.
- For the next `HistoryDepth` eras, the exposure would be incrementally
migrated to its corresponding paged storage item.
- Runtimes using staking pallet would strictly need to wait at least
`HistoryDepth` eras with current upgraded version (14) for the migration
to complete. At some era `E` such that `E >
era_at_which_V14_gets_into_effect + HistoryDepth`, we will upgrade to
version X which will remove the deprecated storage items.
In other words, it is a strict requirement that E<sub>x</sub> -
E<sub>14</sub> > `HistoryDepth`, where
E<sub>x</sub> = Era at which deprecated storages are removed from
runtime,
E<sub>14</sub> = Era at which runtime is upgraded to version 14.
- For Polkadot and Kusama, there is a [tracker
ticket](paritytech#433) to clean
up the deprecated storage items.

### Storage Changes

#### Added
- ErasStakersOverview
- ClaimedRewards
- ErasStakersPaged

#### Deprecated
The following can be cleaned up after 84 eras which is tracked
[here](paritytech#433).

- ErasStakers.
- ErasStakersClipped.
- StakingLedger.claimed_rewards, renamed to
StakingLedger.legacy_claimed_rewards.

### Config Changes
- Renamed MaxNominatorRewardedPerValidator to MaxExposurePageSize.

### TODO
- [x] Tracker ticket for cleaning up the old code after 84 eras.
- [x] Add companion.
- [x] Redo benchmarks before merge.
- [x] Add Changelog for pallet_staking.
- [x] Pallet should be configurable to enable/disable paged rewards.
- [x] Commission payouts are distributed across pages.
- [x] Review documentation thoroughly.
- [x] Rename `MaxNominatorRewardedPerValidator` ->
`MaxExposurePageSize`.
- [x] NMap for `ErasStakersPaged`.
- [x] Deprecate ErasStakers.
- [x] Integrity tests.

### Followup issues
[Runtime api for deprecated ErasStakers storage
item](paritytech#426)

---------

Co-authored-by: Javier Viola <javier@parity.io>
Co-authored-by: Ross Bulat <ross@parity.io>
Co-authored-by: command-bot <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Ank4n Ank4n

Labels
None yet
Projects
(Nominated) Proof of Stake
Status: ✅ Done
Milestone
No milestone
3 participants
@burdges @kianenigma @Ank4n