Simplify creating and signing extrinsics

[jsdw]

• Reduce our reliance on substrate traits and move the transaction encoding logic into one place.
• Simplify the process of defining the additional and extrinsic parameters that are needed for your node, and allow them to be provided to the main entry point methods (sign_and_submit/sign_and_submit_then_watch), adding _default versions of these methods to handle the current case of falling back to default params.
• In turn, make it possible to provide a tip and mortality for Polkadot/Substrate like transactions at runtime, and add an example (balance_transfer_with_params) to do this.
• update examples/SCALE to be against Polkadot 0.9.18 to make sure they are working against latest Polkadot.

[lexnv]

Nice! This does make more sense when following the code logic!

[jsdw]

I am wondering how this single DefaultExtra seems to work for both polkadot (in the examples) and substrate (in the tests), because the former just expects a Compact<u128> for the tip section in the extra params, and the latter expects a (Compact<u128>, Option<u32>), which is what this provides via ChargeTransactionPayment. Am I missing something or did we get lucky somehow with that extra 0 byte for the Option<u32> = None being put into the transaction extras in our examples?

[ascjones]

ChargeTransactionPayment comes last, so I guess that the node will successfully decode the Compact<u128> and ignore the subsequent data. This data isn't included in AdditionalSigned so won't affect the signature.

[jsdw]

I'd have thought that decoding the call data which comes next would be naffed up in that case! It's a mystery to me at the moment; I'd have to experiment a bit!

[jsdw]

(Also, the "extra" data is a part of the payload that is signed, so the signature would be different too?)

[ascjones]

Not sure what's going on here then...

[ascjones]

Not sure whether this is possible/desirable, but did you consider adding a builder style method onto SubmittableExtrinsic which allows setting the params, and would use the default if not specified e.g.

let hash = api
        .tx()
        .balances()
        .transfer(dest, 123_456_789_012_345)
        .params(tx_params)
        .sign_and_submit(&signer)

It would avoid the requirement of the _default method equivalents, on the other hand would be less explicit if adding params is the common case.

[jsdw]

Ooh interesting! I didn't consider that offhand, no.

One thing I like about having the _default and the param-taking methods is that it's up to the user whether the params actually do implement Default at all or not; the Default constraint is only on those _default methods now, so if for some reason somebody could not or did not want a default set of params for their chain, that'd work just fine.

[jsdw]

I say that but actually I think I left a Default clause somewhere I shouldn't have, so this is a good pointer to remove that! done!

[ascjones]

LGTM, a big improvement.

A next step refactoring might be to extract the extrinsic construction in create_signed out of client, which would also allow for "offline" extrinsic construction and also easier unit testing of this critical part of code.