Implementer's guide: notes on contextual execution #1525
Conversation
| @@ -63,6 +63,7 @@ All failed checks should lead to an unrecoverable error making the block invalid | |||
| 1. check that `scheduled` is sorted ascending by `CoreIndex`, without duplicates. | |||
| 1. check that there is no candidate pending availability for any scheduled `ParaId`. | |||
| 1. check that each candidate's `validation_data_hash` corresponds to a `(LocalValidationData, GlobalValidationData)` computed from the current state. | |||
| > NOTE: With contextual execution in place, local and global validation data will be obtained as of the state of the context block. However, only the current state will be used for a such query. | |||
There was a problem hiding this comment.
| > NOTE: With contextual execution in place, local and global validation data will be obtained as of the state of the context block. However, only the current state will be used for a such query. | |
| > NOTE: With contextual execution in place, local and global validation data will be obtained as of the state of the context block. However, only the current state will be used for such a query. |
However, only the current state will be used for such a query
I also don't understand this. What does this means?
There was a problem hiding this comment.
It means the current state needs to be able to provide LocalValidationData and GlobalValidationData for the last k ancestors.
Although, it can be done indirectly with a header-chain proof and a state proof from there.
There was a problem hiding this comment.
Well, it refers the same "current state" as the statement above. I.e. the current relay chain state. Stated differently: Let's only consider LocalValidationData. Currently, we have a function that looks roughly like this local_validation_data(para_id) that implicitly also takes the current relay-chain state. However, to support the contextual execution we will have to a function local_validation_data_at(para_id, ctx_block_num) where ctx_block_num is some past block. Note that this function also accepts the current relay-chain state implicitly. That basically translates that we need to be able to maintain required information around to be able to reconstruct that LocalValidationData.
Does it make sense now? If so, do you have an idea how to improve the wording?
UPD: ah @rphmeier beat me up to it
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
|
🙏 |
|
bot merge |
|
Trying merge. |
* master: Unalias Substrate Imports (#1530) Rewrite client handling (#1531) Integrate ChainApi with all messages (#1533) Add Rococo test network (#1363) Fix a typo parathreads -> parachains (#1529) Cleanup upcoming paras (#1527) Sudo wrapper for paras (#1517) Implementer's guide: notes on contextual execution (#1525) Companion for substrate/6782 (#1523) Sort out validation errors (#1516)
plus clarification that
validation_data_hashconsists of the global and local validation data.