safe multi-era slashing for NPoS

[rphmeier]

Based on https://research.web3.foundation/en/latest/polkadot/slashing/npos/

This PR implements safe multi-era slashing for NPoS. The fundamental problem that this tries to solve is that any particular validator or nominator's stake is largely shared across many eras. However, those participants are liable for up to 100% of their stake in each era. When performing multi-era slashing, we have a careful balance of ensuring that 100% slashes from multiple eras don't overslash (i.e. punish more than the validator or nominator was ever on the hook for in that period of time) without placing too low of a cap on the amount of stake that can be slashed.

For the purposes of the economic model, it is easiest to think of each validator
of a nominator which nominates only its own identity.

The act of nomination signals intent to unify economic identity with the validator - to take part in the
rewards of a job well done, and to take part in the punishment of a job done badly.

There are 3 main difficulties to account for with slashing in NPoS:

• A nominator can nominate multiple validators and be slashed via any of them.
• Until slashed, stake is reused from era to era. Nominating with N coins for E eras in a row
  does not mean you have N*E coins to be slashed - you've only ever had N.
• Slashable offences can be found after the fact and out of order.

The algorithm implemented in this module tries to balance these 3 difficulties.

First, we only slash participants for the maximum slash they receive in some time period,
rather than the sum. This ensures a protection from overslashing.

Second, we do not want the time period (or "span") that the maximum is computed
over to last indefinitely. That would allow participants to begin acting with
impunity after some point, fearing no further repercussions. For that reason, we
automatically "chill" validators and withdraw a nominator's nomination after a slashing event,
requiring them to re-enlist voluntarily (acknowledging the slash) and begin a new
slashing span.

Typically, you will have a single slashing event per slashing span. Only in the case
where a validator releases many misbehaviors at once, or goes "back in time" to misbehave in
eras that have already passed, would you encounter situations where a slashing span
has multiple misbehaviors. However, accounting for such cases is necessary
to deter a class of "rage-quit" attacks.

major TODOs:

• Better description :)
• Rewards to reporters
• Pruning of slashing-related metadata
• integration of the new slashing logic
• Testing

[rphmeier]

this is something that's fairly likely to change in the near future. what's the typical approach in SRML for making storage entries versionable?

[kianenigma]

oh, if it is deployed then it needs manual, one-time migration code on_initialised.

[kianenigma]

This https://github.com/paritytech/substrate/pull/3947/files should make it at least less of an annoyance.

[rphmeier]

One of the later additions to this PR is that slashes are immediately computed and not-so-immediately applied. Slashes are deferred in a FIFO queue (by era of detection) where any root origin can intervene and prevent the slash from actually being applied for SlashDeferDuration eras by calling Staking::cancel_deferred_slash(era, indices: Vec<u32>).

[gavofyork]

where any root origin

there's only one :)

but it would be good to get this done with EnsureOrigin so that the original can be configured as part of the config trait. see treasury pallet for a simple example of how this can be done

[rphmeier]

it would be good to get this done with EnsureOrigin so that the original can be configured as part of the config trait

Done - I set this in node-runtime to be supermajority of council.

[gavofyork]

👍

[gavofyork]

at least the slash-deferring logic seems reasonable.

[andresilva]

very light review, but lgtm.