Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Support returning custom header on the client side as well #881

Closed
bkchr opened this issue Dec 30, 2021 · 0 comments · Fixed by #882
Closed

Support returning custom header on the client side as well #881

bkchr opened this issue Dec 30, 2021 · 0 comments · Fixed by #882
Assignees

Comments

@bkchr
Copy link
Member

bkchr commented Dec 30, 2021

#825 brought support for returning a custom header as part of the validation phase on the relay chain. This can be used for example to switch to a different chain. The problem now is that we also send the expected header as part of the candidate descriptor when building the collation: https://github.com/paritytech/cumulus/blob/master/client/collator/src/lib.rs#L178
The relay chain checks that the candidate descriptor header matches the one being returned by the validation function. This means we now also need to ensure that if a custom header should be set, we also use this header when announcing the collation to the relay chain validators. This should be done in the following way:

  1. Bump the version of the CollationInfo runtime api to 2.
  2. Change the collect_collation_info to also take the header of the current block and change the return value to also return the head data.
  3. In the runtime we then check if a custom header should be set and if that is true, we return this custom header or we return the header that we got passed in through the runtime api function.
  4. Ensure that the code on the client side is backwards compatible. This can be done by checking the current runtime api version and calling the appropriate "old" function.

CC @NachoPal

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant