Staking Payout Creates Controller

[shawntabrizi]

Fixes #6415

This is a small update to the staking pallet that allows a staking payout to create a controller account. Note that this only works if the reward is greater than the existential deposit. If it is not, then the payout will be rounded down to zero and the account will not be created.

[rphmeier]

In practice, how much would someone need to be staked in order for this to not trash their rewards? Also, my understanding of the rewards system that nobody can hold off on claiming their rewards until they exceed the existential deposit, because anyone can trigger the semi-lazy payout of all nominators per (validator, era) pair.

[burdges]

If you want this, then maybe avoid the footgun by permitting staked accounts to own one account below the existential deposit. I'd expect doing requires more logic than it's worth though.

[xlc]

The existential deposit on Polkadot is 0.01 DOT. According to polkadot apps, currently it will require > 18 DOT to have profit more than 0.01 DOT per era.

[shawntabrizi]

In practice, how much would someone need to be staked in order for this to not trash their rewards? Also, my understanding of the rewards system that nobody can hold off on claiming their rewards until they exceed the existential deposit, because anyone can trigger the semi-lazy payout of all nominators per (validator, era) pair.

You are correct here. If someone specifically wanted to greif another user in this way, they could try claiming the rewards before they hit the existential deposit. That being said, I dont see this as a practical attack. The user doing this attack would be paying fees to trigger the claims, the user loosing the payout would be losing less than one existential deposit, and as Bryan mentioned, would already need an relatively low amount of tokens to get into that reward zone.

This PR is more trying to repair a scenario that should work, rather than trying to fix for all scenarios handling of payments. Just like we limit payouts to top 64, i think it is perfectly fair to say that some payouts are smaller than the computation that would be required on chain to execute the payout, and in that case we should drop it. I feel like that is what is happening here.

And of course, the best solution when transactions are unlocked, is to simply not have a dead controller.

[shawntabrizi]

I benchmarked this PR, and validated the old benchmark.

Running payouts with a live controller, the worst case scenario is RewardDestination::Staked. Here are the results:

Model:
Time ~=    103.9
    + n    54.47
              µs

This matches what is currently in master.

Now with a dead controller, we try RewardDestination::Controller:

Model:
Time ~=    120.8
    + n    41.95
              µs

So we see that actually creating a new account is less computation per nominator than updating their staking balance.

The base time has increased to 120, which is something I can reflect in this PR.

So I will update base to 120, and keep per nominator increase at 54.