mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-04-26 13:27:57 +00:00
fewensa
4ccf7a2f5a
* message dispatch support multiple instances * Move pallet-bridge-dispatch types to primitives * remove pallet-bridge-dispatch dependency * Update cargo.lock (remove pallet-bridge-dispatch in substrate-relay) * remove extra dependencies
62 lines
4.4 KiB
Markdown
62 lines
4.4 KiB
Markdown
# Call Dispatch Module
|
|
|
|
The call dispatch module has a single internal (only callable by other runtime modules) entry point
|
|
for dispatching encoded calls (`pallet_bridge_dispatch::Module::dispatch`). Every dispatch
|
|
(successful or not) emits a corresponding module event. The module doesn't have any call-related
|
|
requirements - they may come from the bridged chain over some message lane, or they may be crafted
|
|
locally. But in this document we'll mostly talk about this module in the context of bridges.
|
|
|
|
Every message that is being dispatched has three main characteristics:
|
|
- `bridge` is the 4-bytes identifier of the bridge where this message comes from. This may be the
|
|
identifier of the bridged chain (like `b"rlto"` for messages coming from `Rialto`), or the
|
|
identifier of the bridge itself (`b"rimi"` for `Rialto` <-> `Millau` bridge);
|
|
- `id` is the unique id of the message within the given bridge. For messages coming from the
|
|
[messages module](../messages/README.md), it may worth to use a tuple
|
|
`(LaneId, MessageNonce)` to identify a message;
|
|
- `message` is the `bp_message_dispatch::MessagePayload` structure. The `call` field is set
|
|
to the (potentially) encoded `Call` of this chain.
|
|
|
|
The easiest way to understand what is happening when a `Call` is being dispatched, is to look at the
|
|
module events set:
|
|
|
|
- `MessageRejected` event is emitted if a message has been rejected even before it has reached the
|
|
module. Dispatch then is called just to reflect the fact that message has been received, but we
|
|
have failed to pre-process it (e.g. because we have failed to decode `MessagePayload` structure
|
|
from the proof);
|
|
- `MessageVersionSpecMismatch` event is emitted if current runtime specification version differs
|
|
from the version that has been used to encode the `Call`. The message payload has the
|
|
`spec_version`, that is filled by the message submitter. If this value differs from the current
|
|
runtime version, dispatch mechanism rejects to dispatch the message. Without this check, we may
|
|
decode the wrong `Call` for example if method arguments were changed;
|
|
- `MessageCallDecodeFailed` event is emitted if we have failed to decode `Call` from the payload.
|
|
This may happen if the submitter has provided incorrect value in the `call` field, or if source
|
|
chain storage has been corrupted. The `Call` is decoded after `spec_version` check, so we'll never
|
|
try to decode `Call` from other runtime version;
|
|
- `MessageSignatureMismatch` event is emitted if submitter has chose to dispatch message using
|
|
specified this chain account (`bp_message_dispatch::CallOrigin::TargetAccount` origin),
|
|
but he has failed to prove that he owns the private key for this account;
|
|
- `MessageCallRejected` event is emitted if the module has been deployed with some call filter and
|
|
this filter has rejected the `Call`. In your bridge you may choose to reject all messages except
|
|
e.g. balance transfer calls;
|
|
- `MessageWeightMismatch` event is emitted if the message submitter has specified invalid `Call`
|
|
dispatch weight in the `weight` field of the message payload. The value of this field is compared
|
|
to the pre-dispatch weight of the decoded `Call`. If it is less than the actual pre-dispatch
|
|
weight, the dispatch is rejected. Keep in mind, that even if post-dispatch weight will be less
|
|
than specified, the submitter still have to declare (and pay for) the maximal possible weight
|
|
(that is the pre-dispatch weight);
|
|
- `MessageDispatched` event is emitted if the message has passed all checks and we have actually
|
|
dispatched it. The dispatch may still fail, though - that's why we are including the dispatch
|
|
result in the event payload.
|
|
|
|
When we talk about module in context of bridges, these events are helping in following cases:
|
|
|
|
1. when the message submitter has access to the state of both chains and wants to monitor what has
|
|
happened with his message. Then he could use the message id (that he gets from the
|
|
[messages module events](../messages/README.md#General-Information)) to filter events of
|
|
call dispatch module at the target chain and actually see what has happened with his message;
|
|
|
|
1. when the message submitter only has access to the source chain state (for example, when sender is
|
|
the runtime module at the source chain). In this case, your bridge may have additional mechanism
|
|
to deliver dispatch proofs (which are storage proof of module events) back to the source chain,
|
|
thus allowing the submitter to see what has happened with his messages.
|