This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Wire up candidate backing, approval-voting to disputes #3348
Merged
Merged
Changes from 5 commits
Commits
Show all changes
29 commits
Select commit
Hold shift + click to select a range
fad7f5a
add a from_backing_statement to SignedDisputeStatement
rphmeier 0befef3
inform dispute coordinator of all backing statements
rphmeier 05bf089
add dispute coordinator message to backing tests
rphmeier 1e1d347
send positive dispute statement with every approval
rphmeier 604b191
issue disputes when encountering invalid candidates.
rphmeier 8554667
try to fix flaky test for CI (passed locally)
rphmeier 2d9234b
guide: keep track of concluded-positive disputes until pruned
rphmeier b5d2489
guide: block implications
rphmeier 73c478b
guide: new dispute inherent flow
rphmeier 8b201fd
mostly implement recency changes for dispute coordinator
rphmeier 88ac217
add a clock to dispute coordinator
rphmeier 6873516
adjust DB tests
rphmeier b394e97
fix and add new dispute coordinator tests
rphmeier 4e3f813
provisioner: select disputes
rphmeier 264826b
import all validators' approvals
rphmeier 38cf292
Merge branch 'master' into rh-wire-up-disputes
rphmeier 287c73f
address nit: refactor backing statement submission
rphmeier 87f3204
gracefully handle disconnected dispute coordinator
rphmeier 72f439a
remove `review` comment
rphmeier 1a101b0
Merge branch 'master' into rh-wire-up-disputes
rphmeier f29b7b7
fix up old_tests
rphmeier 6776c5a
Merge branch 'master' into rh-wire-up-disputes
rphmeier d56070d
fix approval-voting compilation
rphmeier 6ec43bc
fix backing compilation
rphmeier 4a1297b
Merge branch 'master' into rh-wire-up-disputes
rphmeier 3d830da
use known-leaves in WaitForActivation
rphmeier c886706
Merge branch 'master' into rh-wire-up-disputes
rphmeier b2170c3
follow-up test fixing
rphmeier 2229d3c
add back allow(dead_code)
rphmeier File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -30,9 +30,10 @@ use polkadot_primitives::v1::{ | |
BackedCandidate, CandidateCommitments, CandidateDescriptor, CandidateHash, | ||
CandidateReceipt, CollatorId, CommittedCandidateReceipt, CoreIndex, CoreState, Hash, Id as ParaId, | ||
SigningContext, ValidatorId, ValidatorIndex, ValidatorSignature, ValidityAttestation, | ||
SessionIndex, | ||
}; | ||
use polkadot_node_primitives::{ | ||
Statement, SignedFullStatement, ValidationResult, PoV, AvailableData, | ||
Statement, SignedFullStatement, ValidationResult, PoV, AvailableData, SignedDisputeStatement, | ||
}; | ||
use polkadot_subsystem::{ | ||
PerLeafSpan, Stage, SubsystemSender, | ||
|
@@ -41,7 +42,7 @@ use polkadot_subsystem::{ | |
AllMessages, AvailabilityDistributionMessage, AvailabilityStoreMessage, | ||
CandidateBackingMessage, CandidateValidationMessage, CollatorProtocolMessage, | ||
ProvisionableData, ProvisionerMessage, RuntimeApiRequest, | ||
StatementDistributionMessage, ValidationFailed | ||
StatementDistributionMessage, ValidationFailed, DisputeCoordinatorMessage, | ||
} | ||
}; | ||
use polkadot_node_subsystem_util::{ | ||
|
@@ -150,6 +151,8 @@ impl ValidatedCandidateCommand { | |
pub struct CandidateBackingJob { | ||
/// The hash of the relay parent on top of which this job is doing it's work. | ||
parent: Hash, | ||
/// The session index this corresponds to. | ||
session_index: SessionIndex, | ||
/// The `ParaId` assigned to this validator | ||
assignment: Option<ParaId>, | ||
/// The collator required to author the candidate, if any. | ||
|
@@ -768,12 +771,67 @@ impl CandidateBackingJob { | |
"Importing statement", | ||
); | ||
|
||
let candidate_hash = statement.payload().candidate_hash(); | ||
let import_statement_span = { | ||
// create a span only for candidates we're already aware of. | ||
let candidate_hash = statement.payload().candidate_hash(); | ||
self.get_unbacked_statement_child(root_span, candidate_hash, statement.validator_index()) | ||
}; | ||
|
||
// Dispatch the statement to the dispute coordinator. | ||
{ | ||
let validator_index = statement.validator_index(); | ||
let signing_context = SigningContext { | ||
parent_hash: self.parent, | ||
session_index: self.session_index, | ||
}; | ||
|
||
let validator_public = match self.table_context | ||
.validators | ||
.get(validator_index.0 as usize) | ||
{ | ||
None => { | ||
tracing::warn!( | ||
target: LOG_TARGET, | ||
session_index = ?self.session_index, | ||
relay_parent = ?self.parent, | ||
?validator_index, | ||
"Supposedly 'Signed' statement has validator index out of bounds." | ||
); | ||
|
||
return Ok(None); | ||
} | ||
Some(v) => v, | ||
}; | ||
|
||
let maybe_candidate_receipt = match statement.payload() { | ||
Statement::Seconded(receipt) => Some(receipt.to_plain()), | ||
Statement::Valid(candidate_hash) => { | ||
// Valid statements are only supposed to be imported | ||
// once we've seen at least one `Seconded` statement. | ||
self.table.get_candidate(&candidate_hash).map(|c| c.to_plain()) | ||
} | ||
}; | ||
|
||
let maybe_signed_dispute_statement = SignedDisputeStatement::from_backing_statement( | ||
statement.as_unchecked(), | ||
signing_context, | ||
validator_public.clone(), | ||
).ok(); | ||
|
||
if let (Some(candidate_receipt), Some(dispute_statement)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 |
||
= (maybe_candidate_receipt, maybe_signed_dispute_statement) | ||
{ | ||
sender.send_message( | ||
DisputeCoordinatorMessage::ImportStatements { | ||
candidate_hash, | ||
candidate_receipt, | ||
session: self.session_index, | ||
statements: vec![(dispute_statement, validator_index)], | ||
}.into() | ||
).await; | ||
} | ||
} | ||
rphmeier marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
let stmt = primitive_statement_to_table(statement); | ||
|
||
let summary = self.table.import_statement(&self.table_context, stmt); | ||
|
@@ -1199,6 +1257,7 @@ impl util::JobTrait for CandidateBackingJob { | |
let (background_tx, background_rx) = mpsc::channel(16); | ||
let job = CandidateBackingJob { | ||
parent, | ||
session_index, | ||
assignment, | ||
required_collator, | ||
issued_statements: HashSet::new(), | ||
|
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pepyakin I'd appreciate your input here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not being @pepyakin there are a definitely a few variants that I'd expect to trigger a dispute
BadParent
,PoVHashMismatch
,ParaHeadHashMismatch
,BadSignature
,CodeHashMismatch
,InvalidOutputs
,CodeDecompressionFailure
,PoVDecompressionFailure
,BadReturn
.ParamsTooLarge(u64)
,CodeTooLarge(u64)
, depends on the limits we set, but these should be checked when submitting i.e. a code update to avoid this upfront.the bigger question is regarding
Timeout
as discussed at the retreat which depends on hardware, and other errors, that depend on the particular impl details.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am myself not entirely sure and I would've approached you with the same questions. Here are my thoughts anyway,
In ideal world, internal errors should be extremely rare and only raise due to misconfiguration or hardware malfunction. That implies that such a failure should only happen in isolation. Given that, it would be fair from the protocol perspective to no-show in such a case. We could introduce logic that issues a dispute here. However, a rational even if honest validator will be incentivised to comment out this piece of code. I feel this is the case even if in presence of precedents of refunding such slashes. Nobody wants to snitch on themselves and get potentially slashed.
In the real world there are bugs though. Inclusion of a bad candidate can be really bad under some circumstances. Specifically, we assume that a bad candidate thanks to messaging (XCMP or bridges) taints everything it touches. Reverting a slash seems to be an easier task than reverting arbitrary changes made by a swarm of state machines. Some of those are out of our reach (i.e. bridges to other chains). I am not sure how realistic such an attack is, I don't have a scenario.
It seems that we should pick one of the options here. I am a bit more inclined to make those a slashing event and defer to the governance. Hopefully, the validators will be not so rational and there will be some friction due to the fact that this decision comes from the client devs and this is on by default.
Regarding the timeouts. After we have the PVF prechecking game, then we won't deal with timeouts by compilation. This leaves us only with timeouts by execution. I am not familiar enough with the t_good, t_bad, t_ugly model but I assume now it should solve the issue about difference in hardware and compiler versions. If I understand correctly, they have their own criteria about this and it depends on the exact amount of time spent on validation. This should be easy to get from the validation host.
I am not yet sure what's the best way to deal with this issue in the mean time.