Francisco Aguirre
e4dbd1aa7d
Moved from https://github.com/polkadot-fellows/xcm-format/pull/59. This RFC proposes a framework for specifying "execution hints", much like [window hints in GLFW](https://www.glfw.org/docs/3.3/window_guide.html#window_hints). The first one is `AssetClaimer`, that allows the user to specify who can claim trapped assets resulting from that program execution. That was an instruction already approved and targeted at XCMv5. This RFC proposes to move it to this hints mechanism. Another potential hint is `LeftoverAssetsDestination`, which, when set, would send all leftover assets to a particular location instead of trapping. This additional hint is not covered by the RFC. It could be proposed in a new one.
3.4 KiB
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 SetHints
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:
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
- Runtime devs
- Wallets
- dApps
Explanation
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.
In Rust, the new definitions would look as follows:
enum Instruction {
// ...snip...
SetHints(BoundedVec<Hint, NumVariants>),
// ...snip...
}
enum Hint {
AssetClaimer(Location),
// more can be added
}
type NumVariants = /* Number of variants of the `Hint` enum */;
Drawbacks
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
Hints 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 SetHint instructions.
Performance, Ergonomics, and Compatibility
Performance
None.
Ergonomics
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 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
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
None.
Future Directions and Related Material
None.