mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-04-27 13:57:58 +00:00
Svyatoslav Nikolsky
feefc34567
23dda62 Rococo <> Wococo messages relay (#1030) bcde21d Update the wasm builder to substrate master (#1029) a8318ce Make target signer optional when sending message. (#1018) f8602e1 Fix insufficient balance when send message. (#1020) d95c0a7 greedy relayer don't need message dispatch to be prepaid if dispatch is supposed to be paid at the target chain (#1016) ad5876f Update types. (#1027) 116cbbc CI: fix starting the pipeline (#1022) 7e0fadd Add temporary `canary` job (#1019) 6787091 Update types to contain dispatch_fee_payment (#1017) 03f79ad Allow Root to assume SourceAccount. (#1011) 372d019 Return dispatch_fee_payment from message details RPC (#1014) 604eb1c Relay basic single-bit message dispatch results back to the source chain (#935) bf52fff Use plain source_queue view when selecting nonces for delivery (#1010) fc5cf7d pay dispatch fee at target chain (#911) 1e35477 Bump Substrate to `286d7ce` (#1006) 7ad07b3 Add --only-mandatory-headers mode (#1004) 5351dc9 Messages relayer operating mode (#995) 9bc29a7 Rococo <> Wococo relayer balance guard (#998) bc17341 rename messages_dispatch_weight -> message_details (#996) 95be244 Bump Rococo and Wococo spec versions (#999) c35567b Move ChainWithBalances::NativeBalance -> Chain::Balance (#990) 1bfece1 Fix some nits (#988) 334ea0f Increase pause before starting relays again (#989) 7fb8248 Fix clippy in test code (#993) d60ae50 fix clippy issues (#991) 75ca813 Make sure GRANDPA shares state with RPC. (#987) da2a38a Bump Substrate (#986) 5a9862f Update submit finality proof weight formula (#981) 69df513 Flag for rejecting all outbound messages (#982) 14d0506 Add script to setup bench machine. (#984) e74e8ab Move CI from GitHub Actions to GitLab (#814) c5ca5dd Custom justification verification (#979) 643f10d Always run on-demand headers relay in complex relay (#975) a35b0ef Add JSON type definitions for Rococo<>Wococo bridge (#977) 0eb83f2 Update cargo.deny (#980) e1d1f4c Bump Rococo/Wococo spec_version (#976) deac90d increase pause before starting relays (#974) 68d6d79 Revert to use InspectCmd, bump substrate `6bef4f4` (#966) 66e1508 Avoid hashing headers twice in verify_justification (#973) a31844f Bump `environmental` dependency (#972) 2a4c29a in auto-relays keep trying to connect to nodes until connection is established (#971) 0e767b3 removed stray file (#969) b9545dc Serve multiple lanes with single complex relay instance (#964) 73419f4 Correct type error (#968) bac256f Start finality relay spec-version guards for Rococo <> Wococo finality relays (#965) bfd7037 pass source and target chain ids to account_ownership_proof (#963) 8436073 Upstream changes from Polkadot repo (#961) e58d851 Increase account endowment amount (#960) git-subtree-dir: bridges git-subtree-split: 23dda6248236b27f20d76cbedc30e189cc6f736c
64 lines
4.6 KiB
Markdown
64 lines
4.6 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);
|
|
- `MessageDispatchPaymentFailed` event is emitted if the message submitter has selected to pay
|
|
dispatch fee at the target chain, but has failed to do that;
|
|
- `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.
|