Implementer's guide: downward messages and HRMP, take 2

roadmap/implementers-guide/src/glossary.md

@@ -15,6 +15,7 @@ Here you can find definitions of a bunch of jargon, usually specific to the Polk
 - Module: A component of the Runtime logic, encapsulating storage, routines, and entry-points.
 - Module Entry Point: A recipient of new information presented to the Runtime. This may trigger routines.
 - Module Routine: A piece of code executed within a module by block initialization, closing, or upon an entry point being triggered. This may execute computation, and read or write storage.
+- MQC: (Message Queue Chain). A cryptographic data structure that resembles an append-only linked list which doesn't store original values but only their hashes. The whole structure is described by a single hash, referred as a "head". When a value is appended, it's contents hashed with the previous head creating a hash that becomes a new head.
 - Node: A participant in the Polkadot network, who follows the protocols of communication and connection to other nodes. Nodes form a peer-to-peer network topology without a central authority.
 - Parachain Candidate, or Candidate: A proposed block for inclusion into a parachain.
 - Parablock: A block in a parachain.

roadmap/implementers-guide/src/runtime/router.md

@@ -75,6 +75,14 @@ struct HrmpChannel {
     /// The total size in bytes of all message payloads in the channel.
     /// Invariant: should be less or equal to `limit_used_bytes`.
     used_bytes: u32,
+    /// A head of the Message Queue Chain for this channel. Each link in this chain has a form:
+	/// `(prev_head, B, H(M))`, where
+	/// - `prev_head`: is the previous value of `mqc_head`.
+	/// - `B`: is the [relay-chain] block number in which a message was appended
+	/// - `H(M)`: is the hash of the message being appended.
+	/// This value is initialized to a special value that consists of all zeroes which indicates
+	/// that no messages were previously added.
+    mqc_head: Hash,
 }
 ```
 HRMP related storage layout
@@ -164,6 +172,7 @@ Candidate Enactment:
     1. Locate or create an entry in ``HrmpChannelDigests`` for `HM.recipient` and append `sender` into the entry's list.
     1. Increment `C.used_places`
     1. Increment `C.used_bytes` by `HM`'s payload size
+	1. Append a new link to the MQC and save the new head in `C.mqc_head`. Note that the current block number as of enactment is used for the link.
 * `prune_hrmp(recipient, new_hrmp_watermark)`:
   1. From ``HrmpChannelDigests`` for `recipient` remove all entries up to an entry with block number equal to `new_hrmp_watermark`.
   1. From the removed digests construct a set of paras that sent new messages within the interval between the old and new watermarks.

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

@@ -145,9 +145,10 @@ struct LocalValidationData {
 	/// which case the code upgrade should be applied at the end of the signaling
 	/// block.
 	code_upgrade_allowed: Option<BlockNumber>,
-
-	// TODO: Does this look sensible?
-	hrmp_ingress: BTreeMap<ParaId /* sender */, Vec<InboundHrmpMessage>>,
+	/// The list of MQC heads for the inbound channels paired with the sender para ids. This
+	/// vector is sorted ascending by the para id and doesn't contain multiple entries with the same
+	/// sender.
+	hrmp_mqc_heads: Vec<(ParaId, Hash)>,
 }
 ```