Conversation
shawntabrizi
requested review from
acatangiu,
svyatonik and
tomusdrw
as code owners
| /// state update. Because of that, the submitter (relayer) has no benefit of not including | ||
| /// this data in the transaction, so reward confirmations lags should be minimal. | ||
| #[pallet::weight(T::WeightInfo::receive_messages_proof_weight(proof, *messages_count, *dispatch_weight))] | ||
| #[pallet::weight(T::WeightInfo::receive_messages_proof_weight(proof, *messages_count, dispatch_weight.computation()))] |
There was a problem hiding this comment.
this is surely wrong. the dispatch will also have a PoV component which should be added in, no?
There was a problem hiding this comment.
It is handled by the receive_messages_proof_weight. dispatch_weight argument means is a pure dispatch weight - e.g. for call it needs to be call.get_dispatch_info().weight.
There was a problem hiding this comment.
i see. is there some reason they're not being handled together?
There was a problem hiding this comment.
Dispatch weight is declared by the message sender when message is sent from the source (here: bridged) chain. Relay computes this argument by summing weights of all delivered messages. Why: originally we've been delivering encoded calls with prepaid (at the source chain) dispatch. Since we can't call call.get_dispatch_info().weight at the bridged chain (because it don't know the call type + it don't know weights of the other chain), it was provided by the message sender.
Other weight components (like cost of proof verification and others) depend on this chain (here: target) and are computed using regular auto benchmarks.
There's an open issue, related to this dispatch_weight argument and ongoing XCM integration. But overall, scheme will stay the same (separate argument for pure dispatch weight and auto-benchmarks for everything else).
| &proof, | ||
| messages_count, | ||
| dispatch_weight, | ||
| dispatch_weight.computation(), |
| 0 | ||
| }, | ||
| ); | ||
| actual_weight = |
There was a problem hiding this comment.
also here. we seem to be disregarding PoV weight.
|
|
||
| Ok(PostDispatchInfo { actual_weight: Some(actual_weight), pays_fee: Pays::Yes }) | ||
| Ok(PostDispatchInfo { | ||
| actual_weight: Some(Weight::from_computation(actual_weight)), |
| ump_max_individual_weight: 20 * WEIGHT_PER_MILLIS, | ||
| ump_max_individual_weight: Weight::new() | ||
| .set_computation(20 * WEIGHT_PER_MILLIS) | ||
| .set_bandwidth(5 * 1024 * 1024), |
There was a problem hiding this comment.
20 ms is ~1% of the 2s expected maximum. 50KB should be about the same proportion of the maximum PoV size.
| .set_bandwidth(5 * 1024 * 1024), | |
| .set_bandwidth(50 * 1024), |
| } | ||
| }); | ||
| T::DbWeight::get().reads_writes(1, 1) | ||
| Weight::from_computation(T::DbWeight::get().reads_writes(1, 1)) |
3 participants
paritytech/substrate#10918