Investigate: can the tip type be detected via metadata or Runtime?

[haerdib]

Currently, it has to be manually chosen which type of tips are used in the runtime (AssetTip, PlainTip). That's a hassle. Shouldn't it be possible to determine that via the metadata?

[haerdib]

Or maybe via Runtime (via PR #340) as Rust does not like type determination during runtime.

[haerdib]

I have investigated a little - and got to the following result:

• I think, it is not possible to deduct the Tip type via the Runtime. The AdditionalSigned is too generic. However, it is possible to get the SignedExtensions type from the Runtime:

pub struct SignedExtraWrapper<Runtime>
where
	Runtime: GetRuntimeBlockType + frame_system::Config,
	<Runtime::RuntimeBlock as Block>::Extrinsic: ExtrinsicMetadata,
{
	pub extra: <<Runtime::RuntimeBlock as Block>::Extrinsic as ExtrinsicMetadata>::SignedExtensions, 
	//  ^^^ That's the Extra which implements the Trait SignedExtension, e.g. the function:
	fn additional_signed(&self) -> Result<Self::AdditionalSigned, TransactionValidityError>;
}

And that might be enough. The compose macors would need to be adapted.

• Getting the Tip Type via metadata might be possible. What's certainly possible though, is retrieving the AddtionalSigned type, with the SignedExtensionMetadatatype.

Useful substrate locations:

• https://github.com/paritytech/substrate/blob/master/primitives/runtime/src/traits.rs#L1056
• https://github.com/paritytech/substrate/blob/master/primitives/runtime/src/generic/unchecked_extrinsic.rs

[haerdib]

Related issue : paritytech/substrate#12929

Via metadata (V14) it can be detected if the pallet_asset_tx_payment is imported into the runtime. And I believe, with quite some certainty, one can say if that's the case, then the fees will be paid with that pallet and so will the tips be. But I guess that not 100% sure, because one could simply define that pallet but not use it at all.
This might be better once V15 is published.

Conclusion: I think it's not worth to invest too much time to this. Let's wait for V15 and hope for a better world. If that takes too long, #406 might be a reasonable solution.

[clangenb]

You can't because encointer does not use the pallet_asset_tx_payment, but we use CommunityIdentifier as asset id, which is not exposed in the metadata AFAIK.

[haerdib]

Happy news: Metadata v15 incoming soon! (checkout: paritytech/substrate#13287) 🥳

[haerdib]

Metadata v15 is released, so this might not be blocked anymore.

[haerdib]

I've looked into it once again and came to the following conclusion: Yes, it would be possible to detect the tip during runtime with the metadata, but that would complicate a lot of things:

• Type safety: To allow generic tips, without allocating the tip type during compilation time, we would need to remove type safety during compilation.
• While we can detect the "standard" tips according to their identifiers (ChargeTransactionPayment, ChargeAssetTxPayment, ..), I don't see how we can do that with self defined pallet tips (as long as the order of the SignedExtra is not fixed, which it is not AFAIK). So users having their own tip-pallet would have to set something before compilation, either way.

So long it's not a pressing user issue which has actual use cases, I don't see enough benefit on setting the Tip during runtime.
What we could easily do however is to check the set config against the metadata and if there's a mismatch we can print an error or warning.

[haerdib]

@masapr what do you think?

[clangenb]

At some point, there might be some relevant information in this issue: leonardocustodio/polkadart#359

[masapr]

@masapr what do you think?

I agree. It sounds like too much of a hassle.

@haerdib have you checked @clangenb's comment? Is this of any help?

[haerdib]

According to my understanding, they solve the problem by adding the extra input customSignedExtensions which may be the assetId or something else:

    final payloadWithCustomSignedExtension = SigningPayload(
      method: encodedCall,
      specVersion: specVersion,
      transactionVersion: transactionVersion,
      genesisHash: genesisHash,
      blockHash: blockHash,
      blockNumber: blockNumber,
      eraPeriod: 64,
      nonce: 0, // Supposing it is this wallet first transaction
      tip: 0,
      customSignedExtensions: <String, dynamic>{
        'PrevalidateAttests': 0, // A custom Signed Extensions
      },
    );

I'm not sure if that's easier than adapting the Config. However, it might be an extension possibility: Add a dynamic signing option for the users. Not sure about the use case though, as long as there's no cli. What I also like is the dynamic setting of the additional signed - not like our hardcoded part here:

substrate-api-client/primitives/src/extrinsics/extrinsic_params.rs

Line 58 in 839ba6f

pub type GenericAdditionalSigned<Hash> = ((), u32, u32, Hash, Hash, (), (), ());

I believe we could start by adding sensible runtime checks against the metadata and print warnings if there's a mismatch. That way, the users will know what to adapt without first investigating some strange runtime errors.

[masapr]

Yes, I think giving good warnings is probably the best in this case. Before we make it too complicated.

[haerdib]

Closing this issue in favour of the two follow-up issues #730 and #731. Please reopen if you disagree.