This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Remove candidate selection #3148
Merged
Conversation
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
Lldenaurois
added
A3-in_progress
Lldenaurois
force-pushed
the
remove-candidate-selection
branch
2 times, most recently
from
cb5138d to
5fb63d2
Compare
burdges
reviewed
May 31, 2021
| Several approaches have been discussed, but all have some issues: | ||
|
|
||
| - The current approach is very straightforward. However, that protocol is vulnerable to a single collator which, as an attack or simply through chance, gets its block candidate to the node more often than its fair share of the time. | ||
| - It may be possible to do some BABE-like selection algorithm to choose an "Official" collator for the round, but that is tricky because the collator which produces the PoV does not necessarily actually produce the block. |
There was a problem hiding this comment.
We already have a de facto selection algorithm if collators produce blocks via Aura, BABE, or in future Sassafras, not sure why anyone else could submit the block for them in those cases.
burdges
reviewed
May 31, 2021
| - The current approach is very straightforward. However, that protocol is vulnerable to a single collator which, as an attack or simply through chance, gets its block candidate to the node more often than its fair share of the time. | ||
| - It may be possible to do some BABE-like selection algorithm to choose an "Official" collator for the round, but that is tricky because the collator which produces the PoV does not necessarily actually produce the block. | ||
| - We could use relay-chain BABE randomness to generate some delay `D` on the order of 1 second, +- 1 second. The collator would then second the first valid parablock which arrives after `D`, or in case none has arrived by `2*D`, the last valid parablock which has arrived. This makes it very hard for a collator to game the system to always get its block nominated, but it reduces the maximum throughput of the system by introducing delay into an already tight schedule. | ||
| - A variation of that scheme would be to randomly choose a number `I`, and have a fixed acceptance window `D` for parablock candidates. At the end of the period `D`, count `C`: the number of parablock candidates received. Second the one with index `I % C`. Its drawback is the same: it must wait the full `D` period before seconding any of its received candidates, reducing throughput. |
There was a problem hiding this comment.
I'd worry about us building DoS attacks against ourselves, ala #2203 Races sound dangerous.
We've one grant applicant with storage ideas similar to my mixnet incentives design. Initially, they wanted their proof-of-useful-storage to actually produce blocks, I suggested they use Aura, etc. but run a sampling procedure that rewards storage separately, which seems easier to control.
Lldenaurois
force-pushed
the
remove-candidate-selection
branch
3 times, most recently
from
6e76d3a to
cff297a
Compare
Lldenaurois
force-pushed
the
remove-candidate-selection
branch
from
cff297a to
855ab51
Compare
ordian
reviewed
Jun 7, 2021
roadmap/implementers-guide/src/node/collators/collator-protocol.md
Outdated
Show resolved
Hide resolved
roadmap/implementers-guide/src/node/collators/collator-protocol.md
Outdated
Show resolved
Hide resolved
ordian
added
A0-please_review
bkchr
reviewed
Jun 8, 2021
|
|
||
| notify_candidate_selection(ctx, collator_id, relay_parent, para_id).await; | ||
| let future = async move { | ||
| ((id, pending_collation), rx.timeout(COLLATION_FETCH_TIMEOUT).await) |
There was a problem hiding this comment.
We already have a timeout in the request-response system. That is 1 second currently. So, we don't really need this?
There was a problem hiding this comment.
Ah, you're right
Yes, it can be removed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This diff removes the candidate selection subsystem and implements the same RunJob based logic as in the candidate selection subsystem via a FuturesUnordered construction. Therefore, collations are submitted directly to the validator side of the protocol. The validator side then awaits collations on a separate futures stream and subsequently backs the first candidate it receives for each relay parent.
In the future, we plan to expand on the candidate selection algorithm.