Guide Update with all considerations

[eskimor]

• How disabling works
• Not affecting consensus
• Has to be robust even in case of determinism issues (malicious nodes must not be able to gain an advantage by getting honest guys slashed/disabled):
  • Sacrificing a node (100% slash) has to be made so you lose more than you gain (in terms of share of the network).
  • Voting invalid on valid candidate nodes, should only be very carefully slashed if at all -> 0% slash + losing out on rewards for an entire era, should be punishment enough -> Re-election is ensured.
• No chilling of nodes: Even a slashed node must be up for re-election as long as it has enough stake.
• ... more?

[eskimor]

0% slashes for voting invalid on valid to avoid nodes not getting re-elected in the honest case. (Related to the no chilling, as otherwise no chilling would not be enough.): #1962

[eskimor]

Handling of disabling threshold: #2226 (comment) -> Guide should have an argument, for the handling we picked. Significant implementation complexity is such an argument, but I would like to have it described: Why and how is it complicating matters?

[eskimor]

Summary of today's call:

• No chilling
• Deferred slashes for small slashes (big ones can happen immediately )- that is fine, because of Slash approval voters on approving invalid blocks - dynamically #635 - attacker can not take more guys with him, than he sacrifices himself.
• Beefy needs its own handling of offenses - unrelated to what we are doing. "Normal" disabling will not affect beefy
• Disabling does: No backing, no block production, no dispute participation - all else is unaffected
• With deferred small slashes, we can introduce slashes for voting invalid on valid up to that threshold without risk.
• No force new era anymore
• only disabling highest offenders on hitting the 1/3 target will be a followup.
• Disabling block authoring is needed, because equivocations can be used for attacking approval voting.

[eskimor]

Node side disabling algorithm for dispute participation: #784 (comment)

Explanation on 0% slashes and disabling issues in disputes around era boundaries: #784 (comment)

[AlistairStewart]

For BEEFY we can either have:

1. BEEFY slashing means kicking out of the validator set or
2. Have a strong enough notion of disabling that means that the BEEFY key is left out of the list of BEEFY keys for the remaining sessions in this era.

We probably don't want to have disabling that we suspect might reach a significant fraction of validators with the wrong bug trigger 2 though, as we also need to be worried about BEEFY liveness. A liveness of safety violation in BEEFY can brick bridges on chains without governance like Ethereum.

On the other hand validators who are completely slashed can attack BEEFY for free. So having either 1 or 2 beng the result of a large slash but not apply to things with small slashes, like raising disputes.

With random sampling, BEEFY security relies on cryptoeconomics like backing security. When we have BEEFY with BLS and SNARKS, then disabling or slashing need not affect BEEFY and we can all sleep easier.

[acatangiu]

When we have BEEFY with BLS and SNARKS, then disabling or slashing need not affect BEEFY and we can all sleep easier.

Why is this? Slashed validators can still attack BEEFY "for free".

Or you mean that with BLS the number of slashed validators attacking BEEFY is much less impactful? aka unless we're up to a third of total validators, we can sleep easy?

[AlistairStewart]

Or you mean that with BLS the number of slashed validators attacking BEEFY is much less impactful? aka unless we're up to a third of total validators, we can sleep easy?

With BLS and SNARKS, as long as we have 2/3 honest validators, then it does not matter that dishonest validators have their keys removed. But we don't want to accidentally remove too many honest keys - so we should just give all validator's keys irrespective of disabling and minor offences.

Why is this? Slashed validators can still attack BEEFY "for free".

With random sampling BEEFY, as with backing, there is a small chance that invalid claims will suceed. However the initial claim includes a validator's signature so we can slash that validator. However if that validator has already been slashed 100% on Polkadot, signing invalid claims will not cost them any more so the attack is free.

Thus a large slash, whether from BEEFY or from something like backing that we don't expect honest validators to be affected by too much should result in the validator being removed from future authority keys or at least the BEEFY validator list until the next election.

It used to be that slashes did result in getting kicked out of the validator set and so not be in the list of authority keys, until the recent introduction of disabling as an alternative.