-
Notifications
You must be signed in to change notification settings - Fork 709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expose the last relay chain block number as an API from parachain-system #1761
Conversation
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: |
#[pallet::storage] | ||
#[pallet::getter(fn last_relay_block_number)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given this, we probably should implement a dedicated function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree with basti about removing the macro getter and just implementing a simple public function
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-release-analysis-v1-3-0/4614/1 |
…tem (paritytech#1761) re: https://forum.polkadot.network/t/blocknumber-vs-timestamps-should-we-abandon-blocktimes-altogether/4077 This exposes the `LastRelayChainBlockNumber` storage member of `cumulus-pallet-parachain-system` with a getter and alters the behavior of this storage item to only be updated in `on_finalize` to ensure a consistent value throughout `on_initialize` and within transactions. Parachains, especially with features such as asynchronous backing and agile coretime, should not use the parachain block number as a clock. Any feature of Polkadot intended to optimize core utilization and parachain coretime consumption is likely to worsen this clock as it is practically applied.
re: https://forum.polkadot.network/t/blocknumber-vs-timestamps-should-we-abandon-blocktimes-altogether/4077
This exposes the
LastRelayChainBlockNumber
storage member ofcumulus-pallet-parachain-system
with a getter and alters the behavior of this storage item to only be updated inon_finalize
to ensure a consistent value throughouton_initialize
and within transactions.Parachains, especially with features such as asynchronous backing and agile coretime, should not use the parachain block number as a clock. Any feature of Polkadot intended to optimize core utilization and parachain coretime consumption is likely to worsen this clock as it is practically applied.