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

introduce a method for fetching relay chain header to RelayChainInterface #2794

Merged
merged 3 commits into from
Jul 4, 2023
Merged

introduce a method for fetching relay chain header to RelayChainInterface #2794

merged 3 commits into from
Jul 4, 2023

Conversation

seunlanlege
Copy link
Contributor

This is particularly useful for fetching arbitrary relay chain headers within inherents.

seunlanlege added a commit to polytope-labs/ismp-substrate that referenced this pull request Jun 28, 2023
@BradleyOlson64
Copy link
Contributor

Looks like @rphmeier introduced a method with the same intent and a slightly different signature here.

Perhaps your version could be used instead.

@seunlanlege
Copy link
Contributor Author

Yeah my use case requires block numbers

@@ -110,6 +111,9 @@ pub trait RelayChainInterface: Send + Sync {
/// Get the hash of the current best block.
async fn best_block_hash(&self) -> RelayChainResult<PHash>;

/// Fetch the block header of a given height
async fn header(&self, block_id: BlockId) -> RelayChainResult<Option<PHeader>>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use PHash. No new BlockId in public interfaces anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But i specifically need to query using BlockNumber, any reason for this?

No new BlockId in public interfaces anymore

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Block numbers should only be used in places where there is no other way around them. Block numbers are not ambiguous. Some interfaces (like RPC/CLI) still require block numbers, but most "internal code" can be rewritten in a way to use hashes. E.g. get the header of block X and then go back using parent_hash().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But i specifically need to query using BlockNumber, any reason for this?

The use case here is on-chain code which wishes to read the relay chain, they signal a request given a specific relay chain height (parachains don't have access to the relay chain blockhashes). So hence the BlockId here.

Doesn't seem like there's any alternatives here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And how does the parachain validates the relay chain headers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't need the header, it has the state_root from PersistedValidationData

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use case here is on-chain code which wishes to read the relay chain, they signal a request given a specific relay chain height (parachains don't have access to the relay chain blockhashes).

You say it signals which relay chain header it wants to read. So you are just wanting to get the header to get the storage root?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, when we got: https://github.com/paritytech/cumulus/issues/303

This can be changed.

@@ -110,6 +111,9 @@ pub trait RelayChainInterface: Send + Sync {
/// Get the hash of the current best block.
async fn best_block_hash(&self) -> RelayChainResult<PHash>;

/// Fetch the block header of a given height
async fn header(&self, block_id: BlockId) -> RelayChainResult<Option<PHeader>>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, when we got: https://github.com/paritytech/cumulus/issues/303

This can be changed.

@bkchr bkchr added B0-silent Changes should not be mentioned in any release notes A0-please_review Pull request needs code review. C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit labels Jul 4, 2023
@bkchr bkchr merged commit 931eb70 into paritytech:master Jul 4, 2023
17 of 18 checks passed
@seunlanlege seunlanlege deleted the seun/relay-chain-interface branch July 4, 2023 14:29
@rphmeier
Copy link
Contributor

rphmeier commented Jul 5, 2023

This shouldn't have been merged as-is - the interface was changed to Option<Header> but the implementations still wrapped it in opaque errors for BlockNumber

@bkchr
Copy link
Member

bkchr commented Jul 5, 2023

By "opaque error" you mean that it is a string error?

@seunlanlege
Copy link
Contributor Author

Will do a follow up

@seunlanlege
Copy link
Contributor Author

follow up: #2830

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants