-
Notifications
You must be signed in to change notification settings - Fork 1.2k
prospective-parachains: respond with multiple backable candidates #3160
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
Changes from 1 commit
9bfdc59
a1f208d
d4f38bd
baf0fd0
cfada9a
b5c1584
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
|
|
@@ -763,43 +763,106 @@ impl FragmentTree { | |||
| /// The intention of the `required_path` is to allow queries on the basis of | ||||
| /// one or more candidates which were previously pending availability becoming | ||||
| /// available and opening up more room on the core. | ||||
| pub(crate) fn select_child( | ||||
| pub(crate) fn select_children( | ||||
| &self, | ||||
| required_path: &[CandidateHash], | ||||
| count: u32, | ||||
| pred: impl Fn(&CandidateHash) -> bool, | ||||
| ) -> Option<CandidateHash> { | ||||
| ) -> Vec<CandidateHash> { | ||||
| let base_node = { | ||||
| // traverse the required path. | ||||
| let mut node = NodePointer::Root; | ||||
| for required_step in required_path { | ||||
| node = self.node_candidate_child(node, &required_step)?; | ||||
| if let Some(next_node) = self.node_candidate_child(node, &required_step) { | ||||
| node = next_node; | ||||
| } else { | ||||
| return vec![] | ||||
| }; | ||||
| } | ||||
|
|
||||
| node | ||||
| }; | ||||
|
|
||||
| // TODO [now]: taking the first selection might introduce bias | ||||
| // TODO: taking the first best selection might introduce bias | ||||
| // or become gameable. | ||||
| // | ||||
| // For plausibly unique parachains, this shouldn't matter much. | ||||
| // figure out alternative selection criteria? | ||||
| match base_node { | ||||
| self.select_children_inner(base_node, count, count, &pred, &mut vec![]) | ||||
| } | ||||
|
|
||||
| // Try finding a candidate chain starting from `base_node` of length `expected_count`. | ||||
| // If not possible, return the longest we could find. | ||||
| // Does a depth-first search, since we're optimistic that there won't be more than one such | ||||
| // chains. Assumes that the chain must be acyclic. | ||||
|
||||
| //! # Cycles |
I also documented the performance considerations. Cycles are not an issue because we are limited by the core count anyway so we won't loop indefinitely
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.
Is this to be solved in this PR ?
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.
no, this was here beforehand
It could be solved by randomising the order in which we visit a node's children, but that would make tests harder to write.
Since validators don't favour particular collators when requesting collations, the order of potential forks in the fragment tree should already be somewhat "random" based on network latency (unless collators find a way to censor/DOS other collators)