polkadot runtime/disputes: slashing

This PR implements runtime logic for dispute slashing.

Validator who voted that a valid (decided by a supermajority) candidate (parachain block) is invalid will be slashed 1% of their stake (including nominators). This can happen to very slow validators that timeout during a PVF execution.
Validator who voted that a invalid (decided by a supermajority) candidate (parachain block) is valid will be slashed 100% of their stake (including nominators) and kicked out of the validator set. This can happen to malicious validators or validators that are >3x faster than the supermajority (we have 2s timeout for backing and 6s for approval-voting).

Implementation

The implementation uses the offences pallet and looks like a hybrid of im-online and grandpa slashing impls. Meaning, we submit offences for the concluded disputes about the current session candidate directly from the runtime. If, however, the dispute is about past session, we record pending slashes on chain, without FullIdentification of the offenders. Later on, a block producer can submit an unsigned transaction with KeyOwnershipProof of an offender and submit it to the runtime to produce an offence.

The reason for this separation is that even though it's currently technically possible to get FullIdentification of the past session validators, we don't want to rely on this information to be available on chain for the past sessions because it's heavy.

Open questions:

[x] Initial numbers for slashing. Seems like 100% and 1% is OK.
[x] Do we need exponential slashing? Punt on for now. Might not be needed in the future.
[x] Slashing for inconclusive disputes. Punt on for now.
[x] How do we want disabling to work exactly. Using type Disabled from session is probably fine.

TODOs:

[x] resolve open questions
[x] fix remaining TODOs in code
[x] simplify the traits/generics
[x] zombienet test (only a check for offences)
[x] benchmarks/weights

Follow-up work:

staging APIs for disabled validators and pending slashes
client changes to submit unsigned transactions

Closes #3161.

May 16 '22 12:05 ordian

Do we need exponential slashing?

From an implementation complexity side, it would probably be easier without. 1% is already a pretty high deterrent and client bugs are not unlikely at this stage. From a theoretical perspective we'd probably want exponential slashing kicking in after a certain threshold % of validators and maxing out at 100% at around 1/3-1 of validators, because that can actually pose a risk to finality. In the near term I don't think it matters much.

How do we want disabling to work exactly?

Disabling should apply to validators who vote for invalid blocks. When a validator advocates an invalid block within an era, other validators should ignore all backing messages originating by them for the rest of the era. We should never disable more than f validators within an era and should use a ring-buffer to accomplish that. This means that validators:

Get to try to attack the network only a small number of times per day (as many backed candidates as they can get in before getting slashed)
Succeed only with 1/N probability, where N is a large number like 10 milliion or 1 billion.
Get slashed 100% every time they fail.

May 18 '22 20:05 rphmeier

Thank you for the feedback.

From an implementation complexity side, it would probably be easier without.

It doesn't have to be exponential, we can do simply multiplier * base_slash (1%), where multiplier is capped at e.g. 5, at which point we also disable a validator. The main concern here is that we seem to slash a max and not a sum for a period of time if I'm not mistaken, so additional misbehaviors would "free" if we don't disable or escalate.

When a validator advocates an invalid block within an era, other validators should ignore all backing messages originating by them for the rest of the era.

That would require keeping track of session key rotations. For starters, I'd implement ignoring for the rest of the session. They will be kicked out of the validator set in the next session anyway.

Is it okay to use type DisableValidators from Session that would include other slashes (GRANDPA and BABE), or do we want exclusively disputes here? https://github.com/paritytech/polkadot/blob/c81fb04560c843fdc58892f663a111fcdd314b97/runtime/kusama/src/lib.rs#L270

We should never disable more than f validators within an era and should use a ring-buffer to accomplish that.

If I'm not mistaken staking/offences forces new era if enough validators are disabled: https://github.com/paritytech/substrate/pull/9448.

May 18 '22 20:05 ordian

For starters, I'd implement ignoring for the rest of the session. They will be kicked out of the validator set in the next session anyway.

Yes, this seems fine. It only makes the attack ~4x less expensive which still leads to gambler's ruin quite quickly.

Is it okay to use type DisableValidators from Session that would include other slashes (GRANDPA and BABE), or do we want exclusively disputes here?

Including other slashes is fine as long as the same principle applies: no more than 1/3 of validators may be disabled at any time.

May 18 '22 20:05 rphmeier

Note that in the current form it doesn't enable slashing on Kusama, only on Westend. Still waiting for reviews.

Jul 28 '22 16:07 ordian

I believe all feedback apart from HostConfiguration configuration and bounded cleanup is addressed. Both of these can be addressed as a follow-up. Please take another look.

Aug 05 '22 10:08 ordian

The rewards are implemented in #5862

Aug 05 '22 12:08 ordian

/cmd queue -c bench-bot $ pallet westend-dev runtime_parachains::disputes::slashing

Aug 31 '22 12:08 ordian

@ordian https://gitlab.parity.io/parity/mirrors/polkadot/-/jobs/1793574 was started for your command "$PIPELINE_SCRIPTS_DIR/bench-bot.sh" pallet westend-dev runtime_parachains::disputes::slashing. Check out https://gitlab.parity.io/parity/mirrors/polkadot/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment /cmd cancel 37-fdaf9945-ccd7-48e0-81b2-ba949f0ac651 to cancel this command or /cmd cancel to cancel all commands in this pull request.