tadeohepperle
commented
1 year ago @jsdw I looked into this a bit, but cannot find the ChargeAssetTxPayment signed extension in the extrinsic extensions in the metadata returned for Polkadot and Assethub (wss://rpc.polkadot.io and wss://dot-rpc.stakeworld.io). Also retrieved the signed extensions for a build of polkadot from the current master branch and they also do not contain ChargeAssetTxPayment:
[
SignedExtensionMetadata {
identifier: "CheckNonZeroSender",
extra_ty: 830,
additional_ty: 34,
},
SignedExtensionMetadata {
identifier: "CheckSpecVersion",
extra_ty: 831,
additional_ty: 4,
},
SignedExtensionMetadata {
identifier: "CheckTxVersion",
extra_ty: 832,
additional_ty: 4,
},
SignedExtensionMetadata {
identifier: "CheckGenesis",
extra_ty: 833,
additional_ty: 12,
},
SignedExtensionMetadata {
identifier: "CheckMortality",
extra_ty: 834,
additional_ty: 12,
},
SignedExtensionMetadata {
identifier: "CheckNonce",
extra_ty: 836,
additional_ty: 34,
},
SignedExtensionMetadata {
identifier: "CheckWeight",
extra_ty: 837,
additional_ty: 34,
},
SignedExtensionMetadata {
identifier: "ChargeTransactionPayment",
extra_ty: 838,
additional_ty: 34,
},
SignedExtensionMetadata {
identifier: "PrevalidateAttests",
extra_ty: 839,
additional_ty: 34,
},
]Am I doing something wrong?
jsdw
ChargeAssetTxPaymentis generic over the asset ID type. On the kitchensink runtime it'su32, and so that's what was implemented (actually this was done a while ago). On Asset Hub, it'sMultiLocation.Subxt decides which signed extensions from the provided ones to use based on their names. Since the name is the same here and yet the types/encoding is different, we can't just add some other signed extension which supports MultiLocations to the list.
Instead, we can use the metadata in the
ChargeAssetTxPaymentextension to see what the asset ID type is, and have special handling foru32orMultiLocation. If other chains use different parameters for the extension, then those won't be supported and they will have to implement their own version.Alternative
The alternative option is to add an
AssetIdor something to theConfig, and then use this to determine the type in theChargeAssetTxPaymentsigned extension impl. This would generally be cleaner, but has the downsides of:Configa little more complex; one more type to know how to configureConfigimpl to be used across these different chains, rather than one config that will work with both.Advantages though would be:
MultiLocation(and then ignore one or the other. It's more "correct".There might be a middle ground option too wherein we provide only one API to add an Asset ID, and accept some type which impls
EncodeAsType, and then use the signed extension metadata to try to encode it appropriately, or error otherwise. No extra Config type or extra API needed, but the downside that it's much easier to provide invalid types.I'm going back and forth on which option is best here.