Dispute Coordinator Subsystem #3150
Conversation
rphmeier
added
A3-in_progress
Co-authored-by: André Silva <[email protected]>
Co-authored-by: André Silva <[email protected]>
rphmeier
added
A0-please_review
rphmeier
added
the
D5-nicetohaveaudit ⚠️
as of #3222 we can do most of the work within the approval voting subsystem
|
|
||
| // It would be nice to draw this from the chain state, but we have no tools for it right now. | ||
| // On Polkadot this is 1 day, and on Kusama it's 6 hours. | ||
| const DISPUTE_WINDOW: SessionIndex = 6; |
There was a problem hiding this comment.
but we have no tools for it right now
could you elaborate why can't we use SessionInfo::dispute_period from the runtime like we did previously?
There was a problem hiding this comment.
There is no dispute_period in struct SessionInfo. That is exactly what I mean by 'no tools for it' - we'd need to change the type definition or add a new runtime API.
There was a problem hiding this comment.
Sorry, I meant in HostConfiguration.
There was a problem hiding this comment.
But we can probably rely on the fact that session_info will store sessions based on dispute_period?
There was a problem hiding this comment.
#3227 <- We need to expose it, and that's beyond scope here IMO
This reverts commit 9cd615e.
Co-authored-by: Bernhard Schuster <[email protected]>
Co-authored-by: Bernhard Schuster <[email protected]>
| /// When inspecting a new import notification, updates the session info cache to match | ||
| /// the session of the imported block. | ||
| /// | ||
| /// this only needs to be called on heads where we are directly notified about import, as sessions do |
There was a problem hiding this comment.
| /// this only needs to be called on heads where we are directly notified about import, as sessions do | |
| /// This only needs to be called on heads where we are directly notified about import, as sessions do |
| /// this only needs to be called on heads where we are directly notified about import, as sessions do | ||
| /// not change often and import notifications are expected to be typically increasing in session number. | ||
| /// | ||
| /// some backwards drift in session index is acceptable. |
There was a problem hiding this comment.
| /// some backwards drift in session index is acceptable. | |
| /// Some backwards drift in session index is acceptable. |
| Err(SessionsUnavailable { | ||
| kind, | ||
| info: Some(SessionsUnavailableInfo { | ||
| window_start: latest +1, |
There was a problem hiding this comment.
| window_start: latest +1, | |
| window_start: fresh_start, |
There was a problem hiding this comment.
AFAIU this could also be window_start since that's what we wanted the full window to be, but we only started requesting from fresh_start and so that's the only data that we're missing.
| let update = SessionWindowUpdate::Advanced { | ||
| prev_window_start: old_window_start, | ||
| prev_window_end: old_window_end, | ||
| new_window_start: window_start, |
There was a problem hiding this comment.
We should use earliest_session from below here to account for the edge case described.
| /// The indices of validators who have already voted on this candidate. | ||
| voted_indices: Vec<ValidatorIndex>, |
There was a problem hiding this comment.
Not sure this will be needed.
| // Add variants here as needed, `{ cnt += 1; }` for those that need to be | ||
| // notified, `unreachable!()` for those that should not. | ||
| } | ||
| } | ||
| assert_eq!(cnt, EXPECTED_COUNT); |
| } | ||
| } | ||
|
|
||
|
|
|
|
||
| // TODO [after https://github.com/paritytech/polkadot/issues/3160]: chain rollbacks |
There was a problem hiding this comment.
| // TODO [after https://github.com/paritytech/polkadot/issues/3160]: chain rollbacks |
I guess this won't be happening anymore as we'll go with using SelectChain instead.
Closes #3166
The dispute coordinator keeps track of all votes received on all candidates in a rolling window of sessions. It uses these to detect disputes between validators. It also provides interfaces to inform the provisioner about what to include in the chain.
More information can be found in the implementers' guide: https://w3f.github.io/parachain-implementers-guide/node/disputes/dispute-coordinator.html
This does not yet implement chain rollbacks or integrate the subsystem into the overseer. That will require a parachains-db version upgrade and will be done in a follow-on pull request.