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: Bastian Köcher <bkchr@users.noreply.github.com>

* Incorporate rphmeier's suggestion.

Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>

polkadot/roadmap/implementers-guide/src/runtime/inclusion.md

@@ -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 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. 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.

polkadot/roadmap/implementers-guide/src/types/candidate.md

@@ -77,7 +77,7 @@ struct CandidateDescriptor {
 	relay_parent: Hash,
 	/// The collator's sr25519 public key.
 	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.
 	validation_data_hash: Hash,
 	/// 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
 
 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: message queue watermarks (first downward messages, then XCMP channels)