Remove the prospective-parachains subsystem from collators #4471
Conversation
alindima
added
R0-silent
| rx.await.map_err(|_| FetchError::ProspectiveParachainsUnavailable) | ||
| } | ||
|
|
||
| // Request the min relay parent for a single para, directly using ChainApi. |
There was a problem hiding this comment.
This seem to return the leaf_number - allowed_ancestry_len no matter what para_id. Don't we have to constrain this to be the minimum between this value and the best backable parachain block relay parent ?
There was a problem hiding this comment.
This would complicate the code for collators, since they'll no longer have the prospective-parachains subsystem to track the backed candidates. Also, they don't receive backing statements. I guess we could use the persisted_validation_data runtime API which would return the relay chain block height of the last backed or included candidate.
I wouldn't bother with this for now, as it preserves the existing behaviour (which doesn't seem to cause issues) and the collator should anyway be smart enough to not produce collations that move the relay parents backwards.
There was a problem hiding this comment.
the name of the function though is not really correct
There was a problem hiding this comment.
changed the function name
There was a problem hiding this comment.
It looks like we only use the min relay parent for sanity checking before advertising collations, I would propose to remove this check instead and rely on validators rejecting it and disconnecting the collator.
There are two situations when this would happen:
- somebody writes a bad collator that authors on ancient relay parents which is a bug, and having a strong signal as getting disconnected/banned is better than relying on this sanity check as the effect is the same - parachain doesn't make progress at all
- the collator is so far behind in syncing the relay chain such that this check would not actually fail at all, and it will still be the validator rejecting the collation
|
I reran the original experiments from #4167 and this PR indeed fixes the issue! |
As discussed offline, we need to keep the implicit view on the collator side regardless of whether we query it before advertising. We still need to query the allowed ancestry so that collators are able to build and advertise collations that are built on older relay parents and for pruning these collations when the relay parents go out of scope. So we could at most remove one line of code, the one that re-checks the ancestry before advertising. But I don't think it's worth it. It's a sanity check that'll save us from advertising outdated collations |
…spective-parachains-from-collators
|
The CI pipeline was cancelled due to failure one of the required jobs. |
alindima
removed
the
R0-silent
alindima
deleted the
alindima/remove-prospective-parachains-from-collators
branch
Implements #4429 Collators only need to maintain the implicit view for the paraid they are collating on. In this case, bypass prospective-parachains entirely. It's still useful to use the GetMinimumRelayParents message from prospective-parachains for validators, because the data is already present there. This enables us to entirely remove the subsystem from collators, which consumed resources needlessly Aims to resolve #4167 TODO: - [x] fix unit tests
…h#4471) Implements paritytech#4429 Collators only need to maintain the implicit view for the paraid they are collating on. In this case, bypass prospective-parachains entirely. It's still useful to use the GetMinimumRelayParents message from prospective-parachains for validators, because the data is already present there. This enables us to entirely remove the subsystem from collators, which consumed resources needlessly Aims to resolve paritytech#4167 TODO: - [x] fix unit tests
…h#4471) Implements paritytech#4429 Collators only need to maintain the implicit view for the paraid they are collating on. In this case, bypass prospective-parachains entirely. It's still useful to use the GetMinimumRelayParents message from prospective-parachains for validators, because the data is already present there. This enables us to entirely remove the subsystem from collators, which consumed resources needlessly Aims to resolve paritytech#4167 TODO: - [x] fix unit tests
Implements #4429
Collators only need to maintain the implicit view for the paraid they are collating on.
In this case, bypass prospective-parachains entirely. It's still useful to use the GetMinimumRelayParents message from prospective-parachains for validators, because the data is already present there.
This enables us to entirely remove the subsystem from collators, which consumed resources needlessly
Aims to resolve #4167
TODO: