Increase xcm fees when busy #2342
Conversation
gilescope
added
A3-in_progress
| @@ -1069,7 +1085,7 @@ impl<T: Config> Pallet<T> { | |||
| match Self::host_configuration() { | |||
| Some(cfg) => | |||
| if message.len() > cfg.max_upward_message_size as usize { | |||
| return Err(MessageSendError::TooBig) | |||
| Self::increment_ump_fee_factor(); | |||
There was a problem hiding this comment.
This is the wrong place to put the increment. The condition here checks whether the individual message size is greater than the limit, and does not check for the queue size.
| @@ -1129,6 +1163,9 @@ impl<T: Config> XcmpMessageSource for Pallet<T> { | |||
|
|
|||
| <OutboundXcmpStatus<T>>::put(statuses); | |||
|
|
|||
| if !result.is_empty() { | |||
There was a problem hiding this comment.
It should check whether the number of messages in queue is less than the maximum limit.
| @@ -261,6 +264,9 @@ pub mod pallet { | |||
|
|
|||
| UpwardMessages::<T>::put(&up[..num]); | |||
| *up = up.split_off(num); | |||
| if num > 0 { | |||
There was a problem hiding this comment.
This should check whether the UMP queue is less than then max limit.
|
Please make sure there is an easy way to estimate XCM fee paritytech/polkadot-sdk#690 Also please consider the scenario that the XCM is triggered indirectly. For example, from a smart contract. The smart contract will pay for the XCM fee so it will need to know how much to charge from the user for the XCM fee. |
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
|
The CI pipeline was cancelled due to failure one of the required jobs. |
|
This just does not translate well from the polkadot dmp PR. The polkadot DMP pallet does not page, but holds a list of messages where as the xcmp-queue holds pages of messages. Establishing how many messages are in a page when it gets sent would require decoding all the page or keeping a tally separately, so it's probably nicer to bump the xcm fees based on the number of pages queued up which is readily available information. I.e. once one page is full then xcm messages get more expensive, and once two pages get full then the channel suspends while it clears down (2 pages is the current |
| @@ -475,7 +477,8 @@ impl cumulus_pallet_xcmp_queue::Config for Runtime { | |||
| >; | |||
| type ControllerOriginConverter = xcm_config::XcmOriginToTransactDispatchOrigin; | |||
| type WeightInfo = weights::cumulus_pallet_xcmp_queue::WeightInfo<Runtime>; | |||
| type PriceForSiblingDelivery = (); | |||
| type PriceForSiblingDelivery = | |||
| SiblingExponentialPrice<FeeAssetId, BaseDeliveryFee, TransactionByteFee, XcmpFeeFactor>; | |||
There was a problem hiding this comment.
when paritytech/polkadot#7005 and paritytech/polkadot#7585,
I am goging to reuse here lots of stuff from runtime/common e.g. ExponentialPrice / PriceForParachainDelivery ...
This is the corollary to paritytech/polkadot#6843 . Xcmp fees upwards and horizontally get exponentially more expensive as the queues increase.
TODO: