paritytech
collator-protocol: only accept advertisements built on top of backed parablocks
Part of #5054
Should be done on top of #5740
We should only fetch & second collations that are either built on top of the root of some fragment tree or have a parent which is backed. We could relax this somewhat to fetch & second collations that are built on top of a Seconded candidate which we've validated locally, but that'd be more complex and the 'backed' rule should work OK although it's not as efficient.
With #5824 GetHypotheticalDepth returns Seconded/Backed statuses of parent nodes in a fragment tree.
TBD:
- Should we start fetching a collation if there exists some backed parent? 1.1. If yes, what should we do in backing with the rest parent-sedonded placements? https://github.com/paritytech/polkadot/blob/rh-async-backing-feature/node/core/backing/src/lib.rs#L1197-L1217
- How to update pending advertisements on view-change? Requesting hypothetical depth for each advertisement from each deactivated leaf for each activated may turn to be slow
Spam protection should also be taken into account, so that collators don't actually distribute 5 collations for each relay parent (e.g. building 5 different candidates on top of most recent para head)
Should we start fetching a collation if there exists some backed parent?
Yes
If yes, what should we do in backing with the rest parent-sedonded placements?
I'm not sure what is meant here - I don't think logic here needs to change (it's fine to accept seconded statements from peers about candidates that we haven't seen the parent backed on, because this doesn't remove our ability to second something different).
If you mean that we need some control flow to return back to the validator-side of the collator protocol in case it's not secondable, then yes, that'll need some alterations. That's a low-level detail which seems very solvable.
How to update pending advertisements on view-change? Requesting hypothetical depth for each advertisement from each deactivated leaf for each activated may turn to be slow
I think we will need to request hypothetical depths for all advertisements. If it's slow, then we just need to optimize. But let's not optimize before we have something functional. This is all in-memory so it should be acceptably fast
https://github.com/paritytech/polkadot/pull/6225 ensures the candidate is recognised by some fragment tree and doesn't conflict with already seconded by validator.
There's a leftover that the path in the fragment tree must only contain backed candidates
https://github.com/paritytech/polkadot/pull/5824#issuecomment-1241368306