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

tdimitrov · 2023-04-29T15:30:25Z

Once we see byzantine threshold + 1 invalid votes for a dispute we can revert the chain to avoid building new blocks on top of it. Check #6950 for details

Addresses #6950

…1` invalid votes.

mrcnski · 2023-04-30T18:04:50Z

I'm not too familiar with the code, but can you please explain why https://github.com/paritytech/polkadot/blob/32b9138042/runtime/parachains/src/disputes.rs#L573-L583 and https://github.com/paritytech/polkadot/blob/32b9138042/node/core/dispute-coordinator/src/import.rs#L198-L208 don't need to change? Other than that, I think it looks good.

tdimitrov · 2023-04-30T19:22:45Z

This is a very good question. The way I understand the issue is that we don't want to change the disputes protocol altogether. We are just doing an implementation optimization.

From the implementor's gude:

Disputes conclude after ⅔ supermajority is reached in either direction.

For this reason we don't touch FOR_SUPERMAJORITY and AGAINST_SUPERMAJORITY. We still want the dispute to conclude after 2/3rds of the votes in one direction, not just f+1.

About CONFIRMED - a confirmed dispute is one dispute for which we have got f+1 votes. This means that at least one honest node sees this dispute as legit and it's not completely made up. Afaik this is an 'implementation' concept - we use it for spam protection. Note that it is just f+1 votes - they can't be f+1 invalid votes or f+1 valid votes. (Actually in this case there won't be a dispute because of the two opposing votes requirement).

So based on the above I think we shouldn't change the way disputes are handled altogether and hence - we shouldn't change the code you have mentioned.

But, if we have got f+1 INVALID votes for a dispute we can be pretty confident that this dispute will conclude as INVALID with very high probability. So at this point we better revert this for so that no additional candidates are built on top of it. This will be a wasted effort.

eskimor

I actually envisioned this to happen in the runtime - f+f invalid votes -> revert log -> done. Anyhow, node side is probably even better. As long as we do it both ways, it would probably make sense to keep them in sync - the very least to avoid confusion.

node/core/dispute-coordinator/src/import.rs

eskimor · 2023-05-03T08:47:56Z

node/core/dispute-coordinator/src/import.rs

+			Self::get_own_invalid_votes(self.old_state());
+
+		old_invalid_votes as usize <= byzantine_threshold &&
+			imported_invalid_votes as usize > byzantine_threshold


Why would we only check for newly imported invalid votes?

I want has_fresh_byzantine_threshold_against() to return true only once - when byzantine_threshold is reached. So I check if the invalid votes before import were below (or equal) the byzantine_threshold and at the same time they are above it after the import.
But you probably are asking something else?

Yeah, I understand that you want to trigger the message once the threshold is passed and not on every import, but you are comparing newly imported votes to the byzantine threshold - so any previously known votes are not taken into account. This would only trigger if we imported f+1 invalid votes all at once.

Got it, self.imported_invalid_votes() returns the votes from the last import, not all votes. This is totally messed up.

This should be fixed now, but I have to add more tests. The current ones didn't catch that error.

ordian · 2023-05-05T13:29:29Z

As long as we do it both ways, it would probably make sense to keep them in sync - the very least to avoid confusion.

Agree, we should also have this logic in the runtime.

tdimitrov · 2023-05-15T08:43:32Z

As long as we do it both ways, it would probably make sense to keep them in sync - the very least to avoid confusion.

Agree, we should also have this logic in the runtime.

Done: #7225

tdimitrov · 2023-05-17T18:29:01Z

bot merge

* master: (60 commits) Ensure all `StorageVersion`s on Rococo/Westend are correct and migration hooks pass (#7251) Try-runtime proper return types (#7146) Have OCW mined election once a week on Westend (#7248) Bump enumn from 0.1.5 to 0.1.8 (#7226) Companion to #14183: FRAME: Allow message ID to be mutated in `ProcessMessage` (#7262) Remove TODO comment (#7260) Fix build (#7261) Update syn (#7258) Use Message Queue pallet for UMP dispatch (#6271) Freeze chain if there are byzantine threshold + 1 invalid votes against a local candidate (#7225) Revert chain if at least f+1 validators voted against a candidate (#7151) Ensure all `StorageVersion`s on Polkadot/Kusama are correct (#7199) Forgotten pub reexport for `GlobalConsensusParachainConvertsFor` (#7238) PVF: Vote invalid on panics in execution thread (after a retry) (#7155) PVF: Remove `rayon` and some uses of `tokio` (#7153) [xcm] Foreign global consensus parachain LocationToAccountId converter (#7016) Update docs (#7230) Bump parity-db to 0.4.8 (#7231) Merge branch 'master' of https://github.com/paritytech/polkadot (#7224) Relax the watermark rule in the runtime (#7188) ...

…slashing-client * ao-past-session-slashing-runtime: (61 commits) Ensure all `StorageVersion`s on Rococo/Westend are correct and migration hooks pass (#7251) Try-runtime proper return types (#7146) Have OCW mined election once a week on Westend (#7248) Bump enumn from 0.1.5 to 0.1.8 (#7226) Companion to #14183: FRAME: Allow message ID to be mutated in `ProcessMessage` (#7262) Remove TODO comment (#7260) Fix build (#7261) Update syn (#7258) Use Message Queue pallet for UMP dispatch (#6271) Freeze chain if there are byzantine threshold + 1 invalid votes against a local candidate (#7225) Revert chain if at least f+1 validators voted against a candidate (#7151) Ensure all `StorageVersion`s on Polkadot/Kusama are correct (#7199) Forgotten pub reexport for `GlobalConsensusParachainConvertsFor` (#7238) PVF: Vote invalid on panics in execution thread (after a retry) (#7155) PVF: Remove `rayon` and some uses of `tokio` (#7153) [xcm] Foreign global consensus parachain LocationToAccountId converter (#7016) Update docs (#7230) Bump parity-db to 0.4.8 (#7231) Merge branch 'master' of https://github.com/paritytech/polkadot (#7224) Relax the watermark rule in the runtime (#7188) ...

tdimitrov added 3 commits April 29, 2023 20:55

Make issue_explicit_statement_with_index regular function

2a8da05

Make issue_backing_statement_with_index regular function

9d0a8da

Issue RevertBlocks as soon as a dispute has `byzantine threshold + …

344bbcb

…1` invalid votes.

tdimitrov force-pushed the tsv-disp-coord-byzantine-revert branch from 8490501 to 344bbcb Compare April 29, 2023 17:56

eskimor reviewed May 3, 2023

View reviewed changes

tdimitrov added 3 commits May 3, 2023 14:49

Remove a comment

6818357

Fix has_fresh_byzantine_threshold_against()

b055ccf

Extend informs_chain_selection_when_dispute_concluded_against test

369edf6

ordian approved these changes May 5, 2023

View reviewed changes

eskimor approved these changes May 5, 2023

View reviewed changes

Merge branch 'master' into tsv-disp-coord-byzantine-revert

abb3804

tdimitrov mentioned this pull request May 15, 2023

Freeze chain if there are byzantine threshold + 1 invalid votes against a local candidate #7225

Merged

paritytech-processbot bot merged commit 2b728eb into master May 17, 2023

paritytech-processbot bot deleted the tsv-disp-coord-byzantine-revert branch May 17, 2023 18:29

github-actions bot mentioned this pull request Jun 15, 2023

Update substrate/polkadot/cumulus from v0.9.40 to v0.9.43 moonbeam-foundation/moonbeam#2354

Closed

kiltbot mentioned this pull request Jun 21, 2023

1️⃣ [AUTOMATIC] Update Polkadot dependencies from 0.9.42 to 0.9.43 KILTprotocol/kilt-node#531

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

tdimitrov commented Apr 29, 2023 •

edited

Loading

mrcnski commented Apr 30, 2023

tdimitrov commented Apr 30, 2023

eskimor left a comment •

edited

Loading

eskimor May 3, 2023

tdimitrov May 3, 2023 •

edited

Loading

eskimor May 3, 2023

tdimitrov May 3, 2023

tdimitrov May 3, 2023

ordian commented May 5, 2023

tdimitrov commented May 15, 2023

tdimitrov commented May 17, 2023

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

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

Conversation

tdimitrov commented Apr 29, 2023 • edited Loading

mrcnski commented Apr 30, 2023

tdimitrov commented Apr 30, 2023

eskimor left a comment • edited Loading

Choose a reason for hiding this comment

eskimor May 3, 2023

Choose a reason for hiding this comment

tdimitrov May 3, 2023 • edited Loading

Choose a reason for hiding this comment

eskimor May 3, 2023

Choose a reason for hiding this comment

tdimitrov May 3, 2023

Choose a reason for hiding this comment

tdimitrov May 3, 2023

Choose a reason for hiding this comment

ordian commented May 5, 2023

tdimitrov commented May 15, 2023

tdimitrov commented May 17, 2023

tdimitrov commented Apr 29, 2023 •

edited

Loading

eskimor left a comment •

edited

Loading

tdimitrov May 3, 2023 •

edited

Loading