Implementer's Guide: Flesh out more details for upward messages (#1556)

* Take 2 at the upward messages

* Trying to restore stuff from unsuccesful rebase

* Fix whitespace

* Clean up

* Change rustdoc to comment

* Pivot to a less stricter, w.r.t. to acceptance, model

* Rename `max_upward_message_num_per_candidate`

* Update docs for DownwardMessage

* Apply suggestions from code review

Co-authored-by: Robert Habermeier <rphmeier@gmail.com>

* Rephrase "Dispatchable objects ready to ..."

* Finish the sentence

* Add a note about imprecision of the current weight formula

* Elaborate on potential use-cases for the upward message kinds.

* s/later/below

Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
This commit is contained in:
Sergei Shulepov
2020-08-14 16:03:30 +02:00
committed by GitHub
parent 950bcece16
commit 56bb796244
6 changed files with 106 additions and 31 deletions
@@ -17,9 +17,7 @@ digraph {
}
```
Downward Message Passing (DMP) is a mechanism for delivering messages to parachains from the relay chain. Downward
messages may originate not from the relay chain, but rather from another parachain via a mechanism
called HRMP (Will be described later).
Downward Message Passing (DMP) is a mechanism for delivering messages to parachains from the relay chain.
Each parachain has its own queue that stores all pending inbound downward messages. A parachain
doesn't have to process all messages at once, however, there are rules as to how the downward message queue
@@ -28,16 +26,19 @@ The downward message queue doesn't have a cap on its size and it is up to the re
that prevent spamming in place.
Upward Message Passing (UMP) is a mechanism responsible for delivering messages in the opposite direction:
from a parachain up to the relay chain. Upward messages are dispatched to Runtime entrypoints and
typically used for invoking some actions on the relay chain on behalf of the parachain.
from a parachain up to the relay chain. Upward messages can serve different purposes and can be of different
kinds.
> NOTE: It is conceivable that upward messages will be divided to more fine-grained kinds with a dispatchable upward message
being only one kind of multiple. That would make upward messages inspectable and therefore would allow imposing additional
validity criteria for the candidates that contain these messages.
One kind of message is `Dispatchable`. They could be thought of similarly to extrinsics sent to a relay chain: they also
invoke exposed runtime entrypoints, they consume weight and require fees. The difference is that they originate from
a parachain. Each parachain has a queue of dispatchables to be executed. There can be only so many dispatchables at a time.
The weight that processing of the dispatchables can consume is limited by a preconfigured value. Therefore, it is possible
that some dispatchables will be left for later blocks. To make the dispatching more fair, the queues are processed turn-by-turn
in a round robin fashion.
Semantically, there is a queue of upward messages queue where messages from each parachain are stored. Each parachain
can have a limited number of messages and the total sum of pending messages is also limited. Each parachain can dispatch
multiple upward messages per candidate.
Other kinds of upward messages can be introduced in the future as well. Potential candidates are channel management for
horizontal message passing (XCMP and HRMP, both are to be described below), new validation code signalling, or other
requests to the relay chain.
## Horizontal Message Passing