Unverified Commit b8d0c59b authored by Sergey Pepyakin's avatar Sergey Pepyakin Committed by GitHub
Browse files

Implementer's guide: notes on contextual execution (#1525)



* Add notes about contextual execution

* Clarify that `validation_data_hash` consists of global and local data

* Update roadmap/implementers-guide/src/runtime/inclusion.md
Co-authored-by: default avatarBastian Köcher <bkchr@users.noreply.github.com>

* Incorporate rphmeier's suggestion.
Co-authored-by: default avatarBastian Köcher <bkchr@users.noreply.github.com>
parent 1155adee
Pipeline #102659 canceled with stages
in 6 minutes and 5 seconds
...@@ -63,6 +63,7 @@ All failed checks should lead to an unrecoverable error making the block invalid ...@@ -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 `scheduled` is sorted ascending by `CoreIndex`, without duplicates.
1. check that there is no candidate pending availability for any scheduled `ParaId`. 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. 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 state of the current block can be used for such a query.
1. If the core assignment includes a specific collator, ensure the backed candidate is issued by that collator. 1. If the core assignment includes a specific collator, ensure the backed candidate is issued by that collator.
1. Ensure that any code upgrade scheduled by the candidate does not happen within `config.validation_upgrade_frequency` of `Paras::last_code_upgrade(para_id, true)`, if any, comparing against the value of `Paras::FutureCodeUpgrades` for the given para ID. 1. Ensure that any code upgrade scheduled by the candidate does not happen within `config.validation_upgrade_frequency` of `Paras::last_code_upgrade(para_id, true)`, if any, comparing against the value of `Paras::FutureCodeUpgrades` for the given para ID.
1. Check the collator's signature on the candidate data. 1. Check the collator's signature on the candidate data.
......
...@@ -77,7 +77,7 @@ struct CandidateDescriptor { ...@@ -77,7 +77,7 @@ struct CandidateDescriptor {
relay_parent: Hash, relay_parent: Hash,
/// The collator's sr25519 public key. /// The collator's sr25519 public key.
collator: CollatorId, collator: CollatorId,
/// The blake2-256 hash of the validation data. These are extra parameters /// The blake2-256 hash of the local and global validation data. These are extra parameters
/// derived from relay-chain state that influence the validity of the block. /// derived from relay-chain state that influence the validity of the block.
validation_data_hash: Hash, validation_data_hash: Hash,
/// The blake2-256 hash of the pov-block. /// The blake2-256 hash of the pov-block.
...@@ -120,6 +120,12 @@ This choice can also be expressed as a choice of which parent head of the para w ...@@ -120,6 +120,12 @@ This choice can also be expressed as a choice of which parent head of the para w
Para validation happens optimistically before the block is authored, so it is not possible to predict with 100% accuracy what will happen in the earlier phase of the [`InclusionInherent`](../runtime/inclusioninherent.md) module where new availability bitfields and availability timeouts are processed. This is what will eventually define whether a candidate can be backed within a specific relay-chain block. Para validation happens optimistically before the block is authored, so it is not possible to predict with 100% accuracy what will happen in the earlier phase of the [`InclusionInherent`](../runtime/inclusioninherent.md) module where new availability bitfields and availability timeouts are processed. This is what will eventually define whether a candidate can be backed within a specific relay-chain block.
Design-wise we should maintain two properties about this data structure:
1. The `LocalValidationData` should be relatively lightweight primarly because it is constructed during inclusion for each candidate.
1. To make contextual execution possible, `LocalValidationData` should be constructable only having access to the latest relay-chain state for the past `k` blocks. That implies
either that the relay-chain should maintain all the required data accessible or somehow provided indirectly with a header-chain proof and a state proof from there.
> TODO: determine if balance/fees are even needed here. > TODO: determine if balance/fees are even needed here.
> TODO: message queue watermarks (first downward messages, then XCMP channels) > TODO: message queue watermarks (first downward messages, then XCMP channels)
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment