feat: staking payout refactor

[wischli]

fixes KILTProtocol/ticket#1930

Follow-up PRs

• refactor: separate runtime api from custom rpc #413
• feat(staking): write delegator state migration #414

TLDR Description

• Refactors staking payouts to not happen automatically
  • Instead, a counter (similar to the Substrate staking pallet participation points) is incremented for each authored block
  • The counter can be consumed and converted into rewards
• Adds extrinsic claim_rewards which enables any signed origin to trigger a payout for themselves

Lengthy Description

The proposed solution goes more into the direction of Substrate staking. Every time a collator authors a block, their rewards counter is incremented. The counter can be consumed to increment accumulated rewards. The rewards need to be actively claimed by the new claim_rewards_for extrinsic.

There are a lot of events which automatically consume the RewardCounter and increment the accumulated rewards since the last actively requested payout:

• Collator changes stake (more, less)
• A delegator changes stake (more, less)
• A delegator removes delegation
• A delegator is replaced
• A collator leaves
• The inflation configuration changes

Background

The main reason for this refactor is that the current solution is not highly scalable as it inherently emits a Rewarded event for each address that gets rewarded. For the current configuration of delegators, this is rather unproblematic.

Moreover, we currently enforce the taxable Rewarded event onto all stakers and it occurs very frequently. Therefore, it is quite a challenge to summarize all such events.

TODO

• More thorough description
• Add claiming extrinsic
• Refactor yearly inflation adjustment
• Unit tests
• Benchmarks

Extrinsics

• set_inflation
• force_remove_candidate
• init_leave_candidates
• candidate_stake_more
• candidate_stake_less
• join_delegators
• delegate_another_candidate
• leave_delegators
• revoke_delegation
• delegator_stake_more
• delegator_stake_less

Checklist:

• I have verified that the code works
  • No panics! (checked arithmetic ops, no indexing array[3] use get(3), ...)
• I have verified that the code is easy to understand
  • If not, I have left a well-balanced amount of inline comments
• I have left the code in a better state
• I have documented the changes (where applicable)

[ntn-x2]

It will probably look much easier to follow and understand once refactored, so we are on the right path 🙂

[ntn-x2]

Any specific reason why we would allow anyone to trigger a payout for anyone else? I still don't understand what would be the use case for this, if I want to have control over when I would claim my rewards. If I want to delegate, I could set up a proxy,

[wischli]

IMO, the main reason would be to cleanup storage and consume tiny rewards that have not been claimed by potentially exited users. I understand that's a very unlikely scenario and each user has an incentive to claim their rewards.

Moreover, in frame staking this is also possible by triggering a payout for a validator which rewards their nominators as well.

[wischli]

I am completely fine changing this and would be interested in @weichweich 's opinion.

[ntn-x2]

Yeah I think Parity does that because otherwise users would just forget and keep piling up stuff, I think. Which would be fine in our case if that is the assumption. But of course the downside is that I can't simply decide to trigger my reward at any time, because someone else inside my delegation pool might do it for me.

[weichweich]

Let's first start with the more restrictive version. We might be able to change that later if we feel the need for it.

[wischli]

By more restrictive you are referring to Antonio's proposal, e.g. origins can only claim for themselves?

[wischli]

420170d

[ntn-x2]

I have one main question about the rewards for delegators. It seems to me they are incentivised to jump onboard right before some other event is supposed to happen (like a stake change or an inflation change). Is my understanding correct? Is that by design? Or am I missing something?

[ntn-x2]

LGTM!

[wischli]

@weichweich Please review when you have the time, thanks!

[weichweich]

Looks good. I would say we can merge it as it is. I just have a few naming suggestions and the RewardCounter is a bit hard to understand. Maybe my suggestion could make this part a bit easier to understand?

The yearly inflation config update is moved from on_initialize to a call that can be called by anyone? Is there a reason for that?

[weichweich]

LGTM very beautiful PR. Love the links to the commits. Nice comments.