From a4daf4efa12ebf3d8d70af779a6a1966fdf3c1df Mon Sep 17 00:00:00 2001 From: Francisco Aguirre Date: Tue, 23 Jul 2024 14:03:22 +0200 Subject: [PATCH 1/3] feat(xcm-execution-hints): add RFC for an XCM execution hints mechanism --- text/0107-xcm-execution-hints.md | 93 ++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 text/0107-xcm-execution-hints.md diff --git a/text/0107-xcm-execution-hints.md b/text/0107-xcm-execution-hints.md new file mode 100644 index 000000000..a1cddabfa --- /dev/null +++ b/text/0107-xcm-execution-hints.md @@ -0,0 +1,93 @@ +# RFC-0107: XCM Execution hints + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | 23 July 2024 | +| **Description** | Add a mechanism for configuring particular XCM executions | +| **Authors** | Francisco Aguirre | + +## Summary + +A previous XCM RFC (https://github.com/polkadot-fellows/xcm-format/pull/37) introduced a `SetAssetClaimer` instruction. +This idea of instructing the XCVM to change some implementation-specific behavior is useful. +In order to generalize this mechanism, this RFC introduces a new instruction `SetExecutionHints` +and makes the `SetAssetClaimer` be just one of many possible execution hints. + +## Motivation + +There is a need for specifying how certain implementation-specific things should behave. +Things like who can claim the assets or what can be done instead of trapping assets. +Another idea for a hint: +- `LeftoverAssetsDestination`: for depositing leftover assets to a destination instead of trapping them + +## Stakeholders + +- Runtime devs +- Wallets +- dApps + +## Explanation + +A new instruction, `SetExecutionHints`, will be added. +This instruction will take a single parameter of type `ExecutionHint`, an enumeration. +The first variant for this enum is `AssetClaimer`, which allows to specify a location that should be able to claim trapped assets. +This means the instruction `SetAssetClaimer` would also be removed, in favor of this. + +In Rust, the new definitions would look as follows: + +```rust +enum Instruction { + // ...snip... + SetExecutionHints(BoundedVec), + // ...snip... +} + +enum ExecutionHint { + AssetClaimer(Location), + // more can be added +} + +type NumVariants = /* Number of variants of the `ExecutionHint` enum */; +``` + +## Drawbacks + +The `SetExecutionHints` instruction might be hard to benchmark, since we should look into the actual hints being set to know how much weight to attribute to it. + +## Testing, Security, and Privacy + +`ExecutionHint`s are specified on a per-message basis, so they have to be specified at the beginning of a message. +If they were to be specified at the end, hints like `AssetClaimer` would be useless if an error occurs beforehand and assets get trapped before ever reaching the hint. + +The instruction takes a bounded vector of hints so as to not force barriers to allow an arbitrary number of `SetExecutionHint` instructions. + +## Performance, Ergonomics, and Compatibility + +### Performance + +None. + +### Ergonomics + +The `SetExecutionHints` instruction provides a better integration with barriers. +If we had to add one barrier for `SetAssetClaimer` and another for each new hint that's added, barriers would need to be changed all the time. +Also, this instruction would make it easy to write XCM programs. +You only need to specify the hints you want in one single instruction at the top of your program. + +### Compatibility + +None. + +## Prior Art and References + +The previous RFC PR in the xcm-format repository before XCM RFCs moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/59. + +## Unresolved Questions + +`SetLeftoverAssetsDestination` is an idea of a hint that could be added. +What more are there? +This RFC creates a convenience for a pattern that was identified. Should we try to hinder that pattern instead? + +## Future Directions and Related Material + +None. From 598a0c4627063f9a4be1fa3b0b8d5de4ed680c36 Mon Sep 17 00:00:00 2001 From: Francisco Aguirre Date: Fri, 16 Aug 2024 17:26:41 +0200 Subject: [PATCH 2/3] doc(0107): rename ExecutionHint to just Hint --- text/0107-xcm-execution-hints.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/text/0107-xcm-execution-hints.md b/text/0107-xcm-execution-hints.md index a1cddabfa..643b28143 100644 --- a/text/0107-xcm-execution-hints.md +++ b/text/0107-xcm-execution-hints.md @@ -10,7 +10,7 @@ A previous XCM RFC (https://github.com/polkadot-fellows/xcm-format/pull/37) introduced a `SetAssetClaimer` instruction. This idea of instructing the XCVM to change some implementation-specific behavior is useful. -In order to generalize this mechanism, this RFC introduces a new instruction `SetExecutionHints` +In order to generalize this mechanism, this RFC introduces a new instruction `SetHints` and makes the `SetAssetClaimer` be just one of many possible execution hints. ## Motivation @@ -28,8 +28,8 @@ Another idea for a hint: ## Explanation -A new instruction, `SetExecutionHints`, will be added. -This instruction will take a single parameter of type `ExecutionHint`, an enumeration. +A new instruction, `SetHints`, will be added. +This instruction will take a single parameter of type `Hint`, an enumeration. The first variant for this enum is `AssetClaimer`, which allows to specify a location that should be able to claim trapped assets. This means the instruction `SetAssetClaimer` would also be removed, in favor of this. @@ -38,28 +38,28 @@ In Rust, the new definitions would look as follows: ```rust enum Instruction { // ...snip... - SetExecutionHints(BoundedVec), + SetHints(BoundedVec), // ...snip... } -enum ExecutionHint { +enum Hint { AssetClaimer(Location), // more can be added } -type NumVariants = /* Number of variants of the `ExecutionHint` enum */; +type NumVariants = /* Number of variants of the `Hint` enum */; ``` ## Drawbacks -The `SetExecutionHints` instruction might be hard to benchmark, since we should look into the actual hints being set to know how much weight to attribute to it. +The `SetHints` instruction might be hard to benchmark, since we should look into the actual hints being set to know how much weight to attribute to it. ## Testing, Security, and Privacy -`ExecutionHint`s are specified on a per-message basis, so they have to be specified at the beginning of a message. +`Hint`s are specified on a per-message basis, so they have to be specified at the beginning of a message. If they were to be specified at the end, hints like `AssetClaimer` would be useless if an error occurs beforehand and assets get trapped before ever reaching the hint. -The instruction takes a bounded vector of hints so as to not force barriers to allow an arbitrary number of `SetExecutionHint` instructions. +The instruction takes a bounded vector of hints so as to not force barriers to allow an arbitrary number of `SetHint` instructions. ## Performance, Ergonomics, and Compatibility @@ -69,7 +69,7 @@ None. ### Ergonomics -The `SetExecutionHints` instruction provides a better integration with barriers. +The `SetHints` instruction provides a better integration with barriers. If we had to add one barrier for `SetAssetClaimer` and another for each new hint that's added, barriers would need to be changed all the time. Also, this instruction would make it easy to write XCM programs. You only need to specify the hints you want in one single instruction at the top of your program. From 22f9eb7328e800b1757c5ea28e5343f5b319bd1b Mon Sep 17 00:00:00 2001 From: Francisco Aguirre Date: Fri, 16 Aug 2024 17:30:54 +0200 Subject: [PATCH 3/3] doc(0107): mention another possible hint and remove unresolved questions --- text/0107-xcm-execution-hints.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/text/0107-xcm-execution-hints.md b/text/0107-xcm-execution-hints.md index 643b28143..b95cad177 100644 --- a/text/0107-xcm-execution-hints.md +++ b/text/0107-xcm-execution-hints.md @@ -18,6 +18,7 @@ and makes the `SetAssetClaimer` be just one of many possible execution hints. There is a need for specifying how certain implementation-specific things should behave. Things like who can claim the assets or what can be done instead of trapping assets. Another idea for a hint: +- `AssetForFees`: to signify to the executor what asset the user prefers to use for fees. - `LeftoverAssetsDestination`: for depositing leftover assets to a destination instead of trapping them ## Stakeholders @@ -71,7 +72,7 @@ None. The `SetHints` instruction provides a better integration with barriers. If we had to add one barrier for `SetAssetClaimer` and another for each new hint that's added, barriers would need to be changed all the time. -Also, this instruction would make it easy to write XCM programs. +Also, this instruction would make it simpler to write XCM programs. You only need to specify the hints you want in one single instruction at the top of your program. ### Compatibility @@ -84,9 +85,7 @@ The previous RFC PR in the xcm-format repository before XCM RFCs moved to fellow ## Unresolved Questions -`SetLeftoverAssetsDestination` is an idea of a hint that could be added. -What more are there? -This RFC creates a convenience for a pattern that was identified. Should we try to hinder that pattern instead? +None. ## Future Directions and Related Material