From d1fdc53f68203b40bf58a0e44524288d7c572a0e Mon Sep 17 00:00:00 2001 From: Francisco Aguirre Date: Tue, 23 Jul 2024 13:39:42 +0200 Subject: [PATCH 1/3] feat(xcm-remove-fees-mode): add RFC for removing XCM fees mode --- text/0106-xcm-remove-fees-mode.md | 69 +++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 text/0106-xcm-remove-fees-mode.md diff --git a/text/0106-xcm-remove-fees-mode.md b/text/0106-xcm-remove-fees-mode.md new file mode 100644 index 000000000..3be50b387 --- /dev/null +++ b/text/0106-xcm-remove-fees-mode.md @@ -0,0 +1,69 @@ +# RFC-0106: Remove XCM fees mode + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | 23 July 2024 | +| **Description** | Remove the `SetFeesMode` instruction and `fees_mode` register from XCM | +| **Authors** | Francisco Aguirre | + +## Summary + +The `SetFeesMode` instruction and the `fees_mode` register allow for the existence of JIT withdrawal. +JIT withdrawal complicates the fee mechanism and leads to bugs and unexpected behaviour. +The proposal is to remove said functionality. +Another effort to simplify fee handling in XCM. + +## Motivation + +The JIT withdrawal mechanism creates bugs such as not being able to get fees when all assets are put into holding and none left in the origin location. +This is a confusing behavior, since there are funds for fees, just not where the XCVM wants them. +The XCVM should have only one entrypoint to fee payment, the holding register. +That way there is also less surface for bugs. + +## Stakeholders + +- Runtime Users +- Runtime Devs +- Wallets +- dApps + +## Explanation + +The `SetFeesMode` instruction will be removed. +The `Fees Mode` register will be removed. + +## Drawbacks + +Users will have to make sure to put enough assets in `WithdrawAsset` when previously some things might have been charged directly from their accounts. +This leads to a more predictable behaviour though so it will only be a drawback for the minority of users. + +## Testing, Security, and Privacy + +Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. + +## Performance, Ergonomics, and Compatibility + +### Performance + +Performance will be improved since unnecessary checks will be avoided. + +### Ergonomics + +The removal of JIT withdrawal simplifies code for developers and results in a more predictable behaviour for users. + +### Compatibility + +For backwards-compatibility, there should be a version of XCM in between the approval of this RFC and the actual removal of the instruction, to give time to the +ecosystem to adapt. + +## Prior Art and References + +The previous RFC PR on the xcm-format repo, before XCM RFCs were moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/57. + +## Unresolved Questions + +None. + +## Future Directions and Related Material + +None. From deda2ae76ebad8c6027ab1baf3deb6fa345779d3 Mon Sep 17 00:00:00 2001 From: Francisco Aguirre Date: Tue, 30 Jul 2024 17:10:52 +0200 Subject: [PATCH 2/3] Update text/0106-xcm-remove-fees-mode.md Co-authored-by: Adrian Catangiu --- text/0106-xcm-remove-fees-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0106-xcm-remove-fees-mode.md b/text/0106-xcm-remove-fees-mode.md index 3be50b387..9b10132d6 100644 --- a/text/0106-xcm-remove-fees-mode.md +++ b/text/0106-xcm-remove-fees-mode.md @@ -66,4 +66,4 @@ None. ## Future Directions and Related Material -None. +The [new generic fees mechanism](https://github.com/polkadot-fellows/RFCs/pull/105) is related to this proposal and further stimulates it as the JIT withdraw fees mechanism will become useless anyway. From 1a598a787324c46b8c12ed719e61491c06d8dfc7 Mon Sep 17 00:00:00 2001 From: Francisco Aguirre Date: Tue, 30 Jul 2024 17:25:04 +0200 Subject: [PATCH 3/3] doc(xcm-remove-fees-mode): add more comments on compatibility --- text/0106-xcm-remove-fees-mode.md | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/text/0106-xcm-remove-fees-mode.md b/text/0106-xcm-remove-fees-mode.md index 9b10132d6..acc7042be 100644 --- a/text/0106-xcm-remove-fees-mode.md +++ b/text/0106-xcm-remove-fees-mode.md @@ -34,12 +34,15 @@ The `Fees Mode` register will be removed. ## Drawbacks -Users will have to make sure to put enough assets in `WithdrawAsset` when previously some things might have been charged directly from their accounts. -This leads to a more predictable behaviour though so it will only be a drawback for the minority of users. +Users will have to make sure to put enough assets in `WithdrawAsset` when +previously some things might have been charged directly from their accounts. +This leads to a more predictable behaviour though so it will only be +a drawback for the minority of users. ## Testing, Security, and Privacy -Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. +Implementations and benchmarking must change for most existing pallet calls +that send XCMs to other locations. ## Performance, Ergonomics, and Compatibility @@ -49,12 +52,18 @@ Performance will be improved since unnecessary checks will be avoided. ### Ergonomics -The removal of JIT withdrawal simplifies code for developers and results in a more predictable behaviour for users. +JIT withdrawal was a way of side-stepping the regular flow of XCM programs. +By removing it, the spec is simplified but now old use-cases have to work with +the original intended behaviour, which may result in more implementation work. + +Ergonomics for users will undoubtedly improve since the system is more predictable. ### Compatibility -For backwards-compatibility, there should be a version of XCM in between the approval of this RFC and the actual removal of the instruction, to give time to the -ecosystem to adapt. +Existing programs in the ecosystem will break. +The instruction should be deprecated as soon as this RFC is approved +(but still fully supported), then removed in a subsequent XCM version +(probably deprecate in v5, remove in v6). ## Prior Art and References