-
Notifications
You must be signed in to change notification settings - Fork 709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove slashed validators from active authority set for rest of era #2577
Comments
One question is also with regards to Beefy liveness, whether we need a separate system for Beefy disabling than the rest or is it "ok" if Beefy keys are dropped, because a validator voted invalid on a valid candidate? We are limiting the disabled validators to 1/3 of the network and the plan is to re-enable lowest offenders once we would overstep that limit. But even if disabling a full third were ok for Beefy - we would then need to re-instantiate the keys of those lowest offenders. |
If we did remove disabled validator's keys, we wouldn't make the threshold 2/3 of the total validiator set size, but 2/3 of the keys we have in the list. But it still means that if we disbable 1/3 of validators who are honest, then we need no more than 2/9 of the validator set to be dishonest then. Or make our already bad parameters worse. It would be better to keep keys for validators who we have disabled, might be honest, and we didn't slash much. |
So something like:
Should do the trick then. |
Cherry-picked fix from upcoming #4494 --------- Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: command-bot <>
Cherry-picked fix from upcoming paritytech#4494 --------- Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: command-bot <>
Cherry-picked fix from upcoming paritytech#4494 --------- Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: command-bot <>
There is existing work disabling validators to account for parachain consensus. Conclusion for Beefy was that plain disabling does not work in bridges case, because the other chain that does not care. The only thing that works is removing beefy keys. As of the current design, disabling will only prevent block authorship, backing and triggering of disputes. Everything else stays unaffected: Approval voting, grandpa, beefy.
For BEEFY we can either have:
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.
Originally posted by @AlistairStewart in #1961 (comment)
The text was updated successfully, but these errors were encountered: