mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-05-31 13:21:01 +00:00
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:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user