Implementer's guide: downward messages and HRMP, take 2 (#1503)

* First stab at downward messages. That also includes a notion of horizontal messages. * Add some structure to the router. * Update `ValidationOutputs` * Add `processed_downward_messages` to `ValidationOutputs`. Forgot to check that in. * s/AccountId/ParaId * DownwardMessage::ParachainSpecfic * s/ensure_horizontal_messages_fits/ensure_horizontal_messages_fit * Clarify that Router called for each candidate * Update the preamble for Router. * Rewrite the relay-chain extrinsic routines * Update gloassary * Add DMP to the glossary * If the queue is empty, `processed_downward_messages` can be 0 * WIP * Add condemned list * Pivot to message-storing channel based HRMP * Finished draft * Tidy up * Remove a duplicate glossary entry * Fix typo * Fix wording to emphasize that the channel is unidirectional * Proper decrement `HrmpOpenChannelRequestCount` * Add a comment for `HrmpOpenChannelRequestCount`. * Remove old configuration values. * Be more specific about the para{chain,thread} hrmp chan limits. * Fix indentation so the lists are rendendered properly * "to answer **the**" question instead of "a" * Add a missing call to `check_processed_downward_messages` * Clean more stuff during offboarding * Fix typo * Fix typo for the config * Add a call to `prune_dmq` * Add explicit invariants for ingress/egress indexes * Add comments for the sender/reciever deposit config fields * Document various fields and structs in Router module * More docs * Missing docs in Candidate.md * Tabs to spaces in router.md * Apply Rob's suggestion * Add the hrmp_ prefix to the router messages * Those are entry points * Use SessionIndex type for the `age` field * Use a struct to represent `HrmpChannelId` * Put only MQCs into the LocalValidationData * Close request can be initiated by the runtime directly * Close request can be initiated by the runtime directly * tabs/spaces * Maintain the list of the outgoing paras in Router * Update roadmap/implementers-guide/src/runtime/inclusion.md Co-authored-by: Robert Habermeier <rphmeier@gmail.com> * fix typo * Remove an unnecessary pair of code quotes Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
2026-06-16 07:21:07 +00:00 · 2020-08-06 17:29:05 +02:00
parent 8729fb7d4b
commit 877a5059aa
7 changed files with 294 additions and 4 deletions
@@ -7,12 +7,15 @@ Here you can find definitions of a bunch of jargon, usually specific to the Polk
 - Backed Candidate: A Backable Candidate noted in a relay-chain block
 - Backing: A set of statements proving that a Parachain Candidate is backable.
 - Collator: A node who generates Proofs-of-Validity (PoV) for blocks of a specific parachain.
+- DMP: (Downward Message Passing). Message passing from the relay-chain to a parachain.
 - Extrinsic: An element of a relay-chain block which triggers a specific entry-point of a runtime module with given arguments.
 - GRANDPA: (Ghost-based Recursive ANcestor Deriving Prefix Agreement). The algorithm validators use to guarantee finality of the Relay Chain.
+- HRMP: (Horizontally Relay-routed Message Passing). A mechanism for message passing between parachains (hence horizontal) that leverages the relay-chain storage. Predates XCMP.
 - Inclusion Pipeline: The set of steps taken to carry a Parachain Candidate from authoring, to backing, to availability and full inclusion in an active fork of its parachain.
 - 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.
@@ -26,8 +29,11 @@ Here you can find definitions of a bunch of jargon, usually specific to the Polk
 - Runtime API: A means for the node-side behavior to access structured information based on the state of a fork of the blockchain.
 - Secondary Checker: A validator who has been randomly selected to perform secondary approval checks on a parablock which is pending approval.
 - Subsystem: A long-running task which is responsible for carrying out a particular category of work.
+- UMP: (Upward Message Passing) A vertical message passing mechanism from a parachain to the relay chain.
 - Validator: Specially-selected node in the network who is responsible for validating parachain blocks and issuing attestations about their validity.
 - Validation Function: A piece of Wasm code that describes the state-transition function of a parachain.
+- VMP: (Vertical Message Passing) A family of mechanisms that are responsible for message exchange between the relay chain and parachains.
+- XCMP (Cross-Chain Message Passing) A type of horizontal message passing (i.e. between parachains) that allows secure message passing directly between parachains and has minimal resource requirements from the relay chain, thus highly scalable.

 Also of use is the [Substrate Glossary](https://substrate.dev/docs/en/knowledgebase/getting-started/glossary).