Issue 4804: Notify chain selection of concluded disputes directly (#6512)

* Setting up new ChainSelectionMessage * Partial first pass * Got dispute conclusion data to provisioner * Finished first draft for 4804 code * A bit of polish and code comments * cargo fmt * Implementers guide and code comments * More formatting, and naming issues * Wrote test for ChainSelection side of change * Added dispute coordinator side test * FMT * Addressing Marcin's comments * fmt * Addressing further Marcin comment * Removing unnecessary test line * Rough draft addressing Robert changes * Clean up and test modification * Majorly refactored scraper change * Minor fixes for ChainSelection * Polish and fmt * Condensing inclusions per candidate logic * Addressing Tsveto's comments * Addressing Robert's Comments * Altered inclusions struct to use nested BTreeMaps * Naming fix * Fixing inclusions struct comments * Update node/core/dispute-coordinator/src/scraping/mod.rs Add comment to split_off() use Co-authored-by: Marcin S. <marcin@bytedude.com> * Optimizing removal at block height for inclusions * fmt * Using copy trait Co-authored-by: Marcin S. <marcin@bytedude.com>
2026-04-30 09:37:55 +00:00 · 2023-01-18 18:06:34 -08:00
parent de7378efe7
commit 90aa798b76
12 changed files with 537 additions and 46 deletions
@@ -9,7 +9,11 @@ In particular the dispute-coordinator is responsible for:

 - Ensuring that the node is able to raise a dispute in case an invalid candidate
  is found during approval checking.
- Ensuring approval votes will be recorded.
+- Ensuring that backing and approval votes will be recorded on chain. With these 
+  votes on chain we can be certain that appropriate targets for slashing will be
+  available for concluded disputes. Also, scraping these votes during a dispute
+  is necessary for critical spam prevention measures.
+- Ensuring backing votes will never get overridden by explicit votes.
 - Coordinating actual participation in a dispute, ensuring that the node
  participates in any justified dispute in a way that ensures resolution of
  disputes on the network even in the case of many disputes raised (flood/DoS
@@ -17,15 +21,13 @@ In particular the dispute-coordinator is responsible for:
 - Ensuring disputes resolve, even for candidates on abandoned forks as much as
  reasonably possible, to rule out "free tries" and thus guarantee our gambler's
  ruin property.
- Provide an API for chain selection, so we can prevent finalization of any
+- Providing an API for chain selection, so we can prevent finalization of any
  chain which has included candidates for which a dispute is either ongoing or
  concluded invalid and avoid building on chains with an included invalid
  candidate.
- Provide an API for retrieving (resolved) disputes, including all votes, both
+- Providing an API for retrieving (resolved) disputes, including all votes, both
  implicit (approval, backing) and explicit dispute votes. So validators can get
  rewarded/slashed accordingly.
- Ensure backing votes are recorded and will never get overridden by explicit
-  votes.

 ## Ensuring That Disputes Can Be Raised

@@ -8,6 +8,7 @@ This subsystem needs to update its information on the unfinalized chain:
  * On every leaf-activated signal
  * On every block-finalized signal
  * On every `ChainSelectionMessage::Approve`
+  * On every `ChainSelectionMessage::RevertBlocks`
  * Periodically, to detect stagnation.

 Simple implementations of these updates do `O(n_unfinalized_blocks)` disk operations. If the amount of unfinalized blocks is relatively small, the updates should not take very much time. However, in cases where there are hundreds or thousands of unfinalized blocks the naive implementations of these update algorithms would have to be replaced with more sophisticated versions.
@@ -32,6 +33,10 @@ Gets all leaves of the chain, i.e. block hashes that are suitable to build upon

 If the required block is unknown or not viable, then return `None`. Iterate over all leaves in order of descending weight, returning the first leaf containing the required block in its chain, and `None` otherwise.

+### `ChainSelectionMessage::RevertBlocks`
+This message indicates that a dispute has concluded against a parachain block candidate. The message passes along a vector containing the block number and block hash of each block where the disputed candidate was included. The passed blocks will be marked as reverted, and their descendants will be marked as non-viable.
+
+
 ### Periodically

 Detect stagnant blocks and apply the stagnant definition to all descendants. Update the set of viable leaves accordingly.