Skip to content

Allow configuration of worst case buy execution weight #7944

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

girazoki
Copy link
Contributor

Adds worst_case_buy_execution to the Config trait of pallet-xcm-benchmarks with a default implementation that mimics the code that existed previous to this PR.

Rationale: not allowing to set the WeightLimit and the FeeAsset might mean that we dont benchmark the worst case, as with WeightLimit::Unlimited the Trader does not even execute:

if let Some(weight) = Option::<Weight>::from(weight_limit) {

The new configurable function allows projects to customize the parameters with which the benchmark is run to make sure they account for the worst-case scenario

This is very likely the case of the assethub system chain, with several traders being analyzed and possibly several reads being made:

cumulus_primitives_utility::TakeFirstAssetTrader<

@girazoki girazoki requested a review from a team as a code owner March 17, 2025 12:48
@girazoki
Copy link
Contributor Author

CC I am re-opening this #2962. I think it is still valid as right now the buy_execution instruction is being benchmarked with the (Here) asset, which might not include the worst case.

CC @bkchr sorry for not answering before on the closed PR, I somehow missed it

@girazoki
Copy link
Contributor Author

I remember back in that PR there were a couple of things that needed to be analyzed:

  • do we want a default impl for the new helper?
  • what is the worst case for assethub? (in which case, I can add it)

@girazoki
Copy link
Contributor Author

CC @RomarQ

@acatangiu
Copy link
Contributor

cc @franciscoaguirre @bkontur

@girazoki
Copy link
Contributor Author

Any opinion on this?

the case where does not even need to go into the Trader. This PR allows
developers to set the worst-case scenario as they wish.
crates:
- name: pallet-xcm-benchmarks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- name: pallet-xcm-benchmarks
- name: pallet-xcm-benchmarks
- bump: major

It's major since you're adding a function with no default.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well.. shit! how are we gonna backport then?

I guess we'll have to limit "backport" to just 2503 which hasn't been published yet

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, nevermind, that's fine, we don't really need to backport this too far back

Copy link
Contributor Author

@girazoki girazoki Mar 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am actually adding a default value, unless you want me to change it. If I dont add a default value I need to put a worst case scenario in all runtimes, and I dont really know what is the worst case scenario in each of them. I can try to guess, but a few hints would be good

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you changed fee_asset, there's no default. Everyone needs to change that function so it's a breaking change.
If we don't need to backport then it's fine.

@girazoki
Copy link
Contributor Author

girazoki commented Mar 24, 2025

@franciscoaguirre I actually applied @bkontur suggestion and converted fee_asset into worst_case_trader, which now returns both the asset and the weight limit. For now I left everyting to 'Unlimited' because it was the case before. However I think the buyExecution benchmark should be benchmarked for a given weight value, otherwise it does not do anything:

let Some(weight) = Option::<Weight>::from(weight_limit) else { return Ok(()) };

If you want as part of this PR I can also add a weight value so that the benchmarking of the buyExecution instruction corresponds to worst case

@franciscoaguirre
Copy link
Contributor

@girazoki I think a Limited weight value makes sense for this PR. Changing fee_asset makes sense to reuse it both in BuyExecution and PayFees.

@franciscoaguirre franciscoaguirre added the T6-XCM This PR/Issue is related to XCM. label Mar 24, 2025
@girazoki
Copy link
Contributor Author

@girazoki I think a Limited weight value makes sense for this PR. Changing fee_asset makes sense to reuse it both in BuyExecution and PayFees.

This is done know. Now I think the only thing "left", but maybe that is for a separate PR, is to adjust assethub to its worst case scenario, which I believe is when you try to buy weight with an asset different than the parent.

I have an idea in mind for this, let me know guys if you want to make it as part of this PR.

@girazoki
Copy link
Contributor Author

@girazoki I think a Limited weight value makes sense for this PR. Changing fee_asset makes sense to reuse it both in BuyExecution and PayFees.

This is done know. Now I think the only thing "left", but maybe that is for a separate PR, is to adjust assethub to its worst case scenario, which I believe is when you try to buy weight with an asset different than the parent.

I have an idea in mind for this, let me know guys if you want to make it as part of this PR.

@franciscoaguirre do you have an opinion on this? should I adapt assetshub for its worst case? or should I leave it for another PR? because otherwise I think this PR is "ready"

@franciscoaguirre
Copy link
Contributor

@girazoki We can do it in a separate PR

the case where does not even need to go into the Trader. This PR allows
developers to set the worst-case scenario as they wish.
crates:
- name: pallet-xcm-benchmarks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you changed fee_asset, there's no default. Everyone needs to change that function so it's a breaking change.
If we don't need to backport then it's fine.

@bkontur bkontur added this pull request to the merge queue Apr 22, 2025
auto-merge was automatically disabled April 22, 2025 09:45

Pull Request is not mergeable

@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 22, 2025
@girazoki girazoki requested a review from a team as a code owner April 22, 2025 12:16
@girazoki
Copy link
Contributor Author

@acatangiu I fixed the errors from the merge queue I think, can you put it back?

@acatangiu acatangiu enabled auto-merge April 22, 2025 16:17
auto-merge was automatically disabled April 23, 2025 07:16

Head branch was pushed to by a user without write access

@bkontur bkontur enabled auto-merge April 23, 2025 08:50
@girazoki
Copy link
Contributor Author

Alright now apparently returns_status_for_pruned_blocks fails, but I dont think I touched anything related to that :(

@bkontur bkontur added this pull request to the merge queue Apr 23, 2025
Merged via the queue into paritytech:master with commit c800a0d Apr 23, 2025
236 of 243 checks passed
ordian added a commit that referenced this pull request Apr 28, 2025
* master: (120 commits)
  [CI] Improve GH build status checking (#8331)
  [CI/CD] Use original PR name in prdoc check for the backport PR's to the stable branches (#8329)
  Add new host APIs set_storage_or_clear and get_storage_or_zero (#7857)
  push to dockerhub (#8322)
  Snowbridge - V1 - Adds 2 hop transfer to Rococo (#7956)
  [AHM] Prepare `election-provider-multi-block` for full lazy data deletion (#8304)
  Check umbrella version (#8250)
  [AHM] Fully bound staking async (#8303)
  migrate parachain-templates tests to `gha` (#8226)
  staking-async: add missing new_session_genesis (#8310)
  New NFT traits: granular and abstract interface (#5620)
  Extract create_pool_with_native_on macro to common crate (#8289)
  XCMP: use batching when enqueuing inbound messages (#8021)
  Snowbridge - Tests refactor (#8014)
  Allow configuration of worst case buy execution weight (#7944)
  Fix faulty pre-upgrade migration check in pallet-session (#8294)
  [pallet-revive] add get_storage_var_key for variable-sized keys (#8274)
  add poke_deposit extrinsic to pallet-recovery (#7882)
  `txpool`: use tracing for structured logging (#8001)
  [revive] eth-rpc refactoring (#8148)
  ...
castillax pushed a commit that referenced this pull request May 12, 2025
Adds `worst_case_buy_execution` to the Config trait of
`pallet-xcm-benchmarks` with a default implementation that mimics the
code that existed previous to this PR.

Rationale: not allowing to set the `WeightLimit` and the `FeeAsset`
might mean that we dont benchmark the worst case, as with
`WeightLimit::Unlimited` the `Trader` does not even execute:
https://github.com/paritytech/polkadot-sdk/blob/c01dbebeaa6394691974de46dd2d41a582f6a4c2/polkadot/xcm/xcm-executor/src/lib.rs#L833

The new configurable function allows projects to customize the
parameters with which the benchmark is run to make sure they account for
the worst-case scenario

**This is very likely the case of the assethub system chain**, with
several traders being analyzed and possibly several reads being made:


https://github.com/paritytech/polkadot-sdk/blob/38d2fa859861005157ccb249dca1378f015e0b06/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs#L403

---------

Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Jun 18, 2025
Adds `worst_case_buy_execution` to the Config trait of
`pallet-xcm-benchmarks` with a default implementation that mimics the
code that existed previous to this PR.

Rationale: not allowing to set the `WeightLimit` and the `FeeAsset`
might mean that we dont benchmark the worst case, as with
`WeightLimit::Unlimited` the `Trader` does not even execute:
https://github.com/paritytech/polkadot-sdk/blob/c01dbebeaa6394691974de46dd2d41a582f6a4c2/polkadot/xcm/xcm-executor/src/lib.rs#L833

The new configurable function allows projects to customize the
parameters with which the benchmark is run to make sure they account for
the worst-case scenario

**This is very likely the case of the assethub system chain**, with
several traders being analyzed and possibly several reads being made:

https://github.com/paritytech/polkadot-sdk/blob/38d2fa859861005157ccb249dca1378f015e0b06/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs#L403

---------

Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
@bkontur bkontur moved this to To be released (SDK) in fellowship/runtimes integrations queue Jul 2, 2025
@bkontur bkontur moved this from Todo to Done in @bkontur's board Jul 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T6-XCM This PR/Issue is related to XCM.
Projects
Status: Done
Status: To be released (SDK)
Development

Successfully merging this pull request may close these issues.

5 participants