Revert chain if at least f+1 validators voted against a candidate

[eskimor]

For maximum security and minimizing effects on the network we should probably revert a chain as soon as f+1 validators voted against a candidate. This should mostly be irrelevant, except if under attack and an attacker manages to prolong full dispute resolution. By reverting as early as possible (f+1 against) we:

1. Make it even harder to get a bad candidate finalized via DoS attacks and thus strengthen the security of the network*).
2. Also improve liveness: By reverting earlier, we have less wasted effort/thrown away blocks.

*) This is defense in depth, this should not be possible even without this change, but if it was because of some bug for example, it would certainly get harder this way.

[mrcnski]

What is f?

[mrcnski]

I guess the byzantine threshold? Looking at the code it looks like we already set relevant flags once we hit the thresholds, but I suppose this does not trigger reversion? Where does that happen?

Edit: I see now in the code above that the "against" vote is actually triggered by a supermajority and not f + 1. This would need to change.

[sandreim]

If I understand correctly, right now it is triggered by dispute coordinator concluding a dispute against a candidate, which means it needs supermajority. Chain selection subsystem is responsible of doing the reversion.

I think it is a good idea, it for sure would save additional work if disputes are concluding slow and we revert with 1/2 of votes against.

[mrcnski]

Cool, so I think this also would need to be changed. (Looks like there is some duplication with the runtime code linked above which maybe can be extracted out, to keep the logic in sync.)

https://github.com/paritytech/polkadot/blob/32b9138042/node/core/dispute-coordinator/src/import.rs#L198-L208

[eskimor]

@sandreim raised a good point. For spam resilience we only take into account participation for either confirmed disputes or for ones where we have seen candidates included/backed on the non-finalized chain and a few blocks behind finality.

The dispute for the candidate which reached f+1 votes should conclude eventually in all cases, since the dispute is confirmed. Hence we should be able to get that 100% slash through. In case there are more invalid candidates on the reverted chain, then the risk of not being able to slash those offenders is slightly increased as the fork is abandoned and can fall behind finality. In case participations have not been queued, validators will no longer participate once that fork fell behind finality by 10 blocks.

Mitigation:

1. Assuming we get at least one 100% slash through, even when heavily loaded, then the gambler's ruin property should be maintained - also queuing participations is fast.
2. We could evaluate increasing DISPUTE_CANDIDATE_LIFETIME_AFTER_FINALIZATION more. This needs to be balanced with spam considerations.