add relay parent to advertisement v3 by alindima · Pull Request #11393 · paritytech/polkadot-sdk

alindima · 2026-03-17T09:00:36Z

also fixes a bug, where for held off advertisements we would assume v3 descriptors are never used.

sandreim

Thanks @alindima, just a few questions & nit.

eskimor

Please let's leave the versioning. It is genuinely useful. E.g. if we had that, we would have had no strong need for a new protocol version to begin with.

eskimor · 2026-03-17T10:02:17Z

 		let candidate_descriptor_version =
 			collation.receipt.descriptor.version(per_scheduling_parent.v3_enabled);
+		// For V3 descriptors, send `Some(scheduling_parent)` so the validator knows this
+		// is a V3 candidate and can apply the scheduling parent validation rules.


Shouldn't be necessary since we also have the version? No strong opinion here, but just setting both to the relay parent for v1/v2 is less special casing, which is nice.

Actually I have a bit stronger opinion. There exists a possible future where every parachain adopted v3 and we deprecate the old versions ... then we have an Option that will always be Some, which is annoying - just complicating code.

There exists a possible future where every parachain adopted v3 and we deprecate the old versions ... then we have an Option that will always be Some, which is annoying - just complicating code.

That future is far in the future :) My expectation is we not gonna see anyone except us rolling it out this year. So scheduling parent will be None for most of parachain candidates. Also if it will become always Some in next 2 years is not something that has negative objective impact.

eskimor · 2026-03-17T10:13:41Z

 			parent_head_data_hash: Hash,
-			/// The version of the candidate descriptor.
-			candidate_descriptor_version: CandidateDescriptorVersion,
+			/// Optional scheduling parent, if the candidate is a v3 descriptor.


No please don't. While I can get on board in collation generation to just pass in an optional SchedulingParent and derive the descriptor version to use from that, I would really leave the version here and more importantly not make the scheduling parent optional.

That's just a much cleaner API:

Knowing the version in the advertisement is useful and sensible: E.g. if we had this, we would not have had a strong need to introduce a new version of the protocol at all for v3.

scheduling parent can always be provided, it just happens to be the same as the relay parent in v1 and v2: Having less code paths is always better!

(2) is really crucial: Once v1 is removed and the feature is always enabled, we don't need any special casing for v3 at all then: Just read scheduling session & scheduling parent - it will always give you the right information, no matter the descriptor version - they would no longer need to be Options either. This is by design, let's not break this.

I think this is fine. I like it explicit vs implicit. The actual data that collator protocol needs for filtering is not the version, but the RP and SP.

Then, when we fetch the collation we have the receipt which has all the information.

We don't really know how v4 is gonna look and what is gonna introduce. If it's something new we need in advertisement whatever we do here is not gonna help. It would only work if there is some semantics change on the very same information already provided now.

But this is exactly what a new candidate descriptor version does, no?

You all hated that I introduced a new collator protocol version - there would have bee no need, if we just had the descriptor version. And as said in chat, we already know an upcoming change where the version is handy too: Deprecating v1.

scope creeping a last minute protocol upgrade that will make us have more seamless protocol changes in the future is not a good idea now. It'd need proper thought and debate. I'd rather not rush it and maybe it's something we could design for all of our protocols going further.

collation protocol is the easiest one to upgrade really, as it's only being used for one subsystem, unlike the way we multiplex all message types on the validation protocol (which makes it a pain to upgrade)

scope creeping a last minute protocol upgrade that will make us have more seamless protocol changes in the future is not a good idea now. It'd need proper thought and debate. I'd rather not rush it and maybe it's something we could design for all of our protocols going further.

I like the idea of doing it for all protocols we use on the node. It is really painful to add a single change to validation protocol, a lot of code gets added every time.

Definitely needs design first.

An alternative is #810 which we never got to do.

Reverts commits 3f37f66 and 9efc73f to restore the original V3 AdvertiseCollation protocol definition before re-implementing with the correct design.

…parent-to-v3-advertisement

alindima · 2026-03-18T10:45:05Z

@sandreim @eskimor I rolled back the changes and added both the relay parent and the version to the advertisement, the PR should be ready, please review

sandreim

LGTM!

sandreim · 2026-03-18T11:49:20Z

 			/// The version of the candidate descriptor.
 			candidate_descriptor_version: CandidateDescriptorVersion,
+			/// The relay parent of the candidate.
+			relay_parent: Hash,


I'd move this after scheduling parent, they are both parents :)

eskimor

Nice! :-)

See discussion here: #11306 (comment) also fixes a bug, where for held off advertisements we would assume v3 descriptors are never used. (cherry picked from commit f02ad9e)

paritytech-release-backport-bot · 2026-03-18T17:11:39Z

Successfully created backport PR for stable2603:

[stable2603] Backport #11393 #11421

Backport #11393 into `stable2603` from alindima. See the [documentation](https://github.com/paritytech/polkadot-sdk/blob/master/docs/BACKPORT.md) on how to use this bot.  --------- Co-authored-by: Alin Dima <alin@parity.io> Co-authored-by: eskimor <robert@gonimo.com> Co-authored-by: Egor_P <egor@parity.io>

add relay parent to advertisement v3

3f37f66

alindima added T0-node This PR/Issue is related to the topic “node”. T8-polkadot This PR/Issue is related to/affects the Polkadot network. T20-low-latency for issues and PRs related to Low Latency work labels Mar 17, 2026

alindima requested review from AlexandruCihodaru and eskimor March 17, 2026 09:00

fmt

9efc73f

sandreim reviewed Mar 17, 2026

View reviewed changes

Comment thread polkadot/node/network/collator-protocol/src/collator_side/mod.rs Outdated

Comment thread polkadot/node/network/collator-protocol/src/collator_side/mod.rs Outdated

Comment thread polkadot/node/network/collator-protocol/src/validator_side/collation.rs Outdated

eskimor reviewed Mar 17, 2026

View reviewed changes

Revert V3 collation protocol changes

72f64d7

Reverts commits 3f37f66 and 9efc73f to restore the original V3 AdvertiseCollation protocol definition before re-implementing with the correct design.

pgherveou added this to [preview] release tracker Mar 18, 2026

github-project-automation Bot moved this to Todo in [preview] release tracker Mar 18, 2026

sandreim mentioned this pull request Mar 18, 2026

Consider simplifying the upgrade/extension of validation and collation protocols #11412

Open

alindima added 2 commits March 18, 2026 12:43

add the new impl

b359f19

Merge remote-tracking branch 'origin/master' into alindima/add-relay-…

3e9e5f1

…parent-to-v3-advertisement

alindima added the A4-backport-stable2603 Pull request must be backported to the stable2603 release branch label Mar 18, 2026

prdoc

9885d4d

sandreim approved these changes Mar 18, 2026

View reviewed changes

eskimor approved these changes Mar 18, 2026

View reviewed changes

alindima added this pull request to the merge queue Mar 18, 2026

Merged via the queue into master with commit f02ad9e Mar 18, 2026
249 of 252 checks passed

alindima deleted the alindima/add-relay-parent-to-v3-advertisement branch March 18, 2026 17:11

github-project-automation Bot moved this from Todo to Done in [preview] release tracker Mar 18, 2026

paritytech-release-backport-bot Bot mentioned this pull request Mar 18, 2026

[stable2603] Backport #11393 #11421

Merged

pgherveou removed this from [preview] release tracker Mar 19, 2026

pgherveou added this to [preview] release tracker Mar 31, 2026

github-project-automation Bot moved this to Done in [preview] release tracker Mar 31, 2026

Conversation

alindima commented Mar 17, 2026

Uh oh!

sandreim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

eskimor left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alindima commented Mar 18, 2026

Uh oh!

sandreim left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eskimor left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

paritytech-release-backport-bot Bot commented Mar 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants