mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-04-27 10:27:59 +00:00

Files

T

Svyatoslav Nikolsky feefc34567 Squashed 'bridges/' changes from b2099c5..23dda62 (#3369 )

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

2021-06-25 13:45:02 +00:00

4.6 KiB

Raw Blame History

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, 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:

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) to filter events of call dispatch module at the target chain and actually see what has happened with his message;
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.

4.6 KiB Raw Blame History

Call Dispatch Module

4.6 KiB

Raw Blame History