pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-30 21:01:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge commit '392447f5c8f986ded2559a78457f4cd87942f393' into update-bridges-subtree-r/w

Browse Source
This commit is contained in:
antonio-dropulic
2021-12-01 09:46:14 +01:00
parent e16f71b7b6 392447f5c8
commit 5228731ae8
321 changed files with 28385 additions and 10466 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/bridges/modules/messages/README.md
+11 -1
View File
@@ -354,7 +354,7 @@ Both conditions are verified by `pallet_bridge_messages::ensure_weights_are_corr
`pallet_bridge_messages::ensure_able_to_receive_messages` functions, which must be called from every
runtime's tests.
### Post-dispatch weight refunds of the `receive_messages_proof` call
#### Post-dispatch weight refunds of the `receive_messages_proof` call
Weight formula of the `receive_messages_proof` call assumes that the dispatch fee of every message is
paid at the target chain (where call is executed), that every message will be dispatched and that
@@ -388,6 +388,7 @@ The weight formula is:
Weight = BaseWeight + MessagesCount * MessageConfirmationWeight
+ RelayersCount * RelayerRewardWeight
+ Max(0, ActualProofSize - ExpectedProofSize) * ProofByteDeliveryWeight
+ MessagesCount * (DbReadWeight + DbWriteWeight)
```
Where:
@@ -403,6 +404,15 @@ Where:
| `ExpectedProofSize` | `EXTRA_STORAGE_PROOF_SIZE` | Size of proof that we are expecting |
| `ProofByteDeliveryWeight` | `(receive_single_message_proof_16_kb - receive_single_message_proof_1_kb) / (15 * 1024)` | Weight of processing every additional proof byte over `ExpectedProofSize` limit. We're using the same formula, as for message delivery, because proof mechanism is assumed to be the same in both cases |
#### Post-dispatch weight refunds of the `receive_messages_delivery_proof` call
Weight formula of the `receive_messages_delivery_proof` call assumes that all messages in the proof
are actually delivered (so there are no already confirmed messages) and every messages is processed
by the `OnDeliveryConfirmed` callback. This means that for every message, we're adding single db read
weight and single db write weight. If, by some reason, messages are not processed by the
`OnDeliveryConfirmed` callback, or their processing is faster than that additional weight, the
difference is refunded to the submitter.
#### Why we're always able to craft `receive_messages_delivery_proof` transaction?
There can be at most `<PeerRuntime as pallet_bridge_messages::Config>::MaxUnconfirmedMessagesAtInboundLane`