Transaction versioning in the RuntimeVersion

[gavofyork]

This just adds the transaction_version field in the RuntimeVersion, which just tracks the compatibility of dispatchables, useful for hardware wallets.

Polkadot companion: paritytech/polkadot#987

[bkchr]

This needs to move to the bottom, or we brick everything^^

[bkchr]

Hmm that will not be enough. We need to change the version of the Core runtime api and make sure to put the changed_in attribute above the version function.

The old version function should have the old RuntimeVersion struct as return value.

[gavofyork]

Moved.

[xlc]

This is already a transaction version

substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs

Line 30 in 77fd258

const TRANSACTION_VERSION: u8 = 4;

And this could fix #3925 ?

[gavofyork]

They are quite different things; the TRANSACTION_VERSION constant refers to the version code placed in each transaction and is the version of the transaction's data format, taking into account any extensions it might have. Different versions imply that transactions cannot be decoded in the same way. The transaction_version field of the RuntimeVersion struct, OTOH, refers to the semantics of the dispatchables. Different versions here imply an specific incompatibility within the dispatchables. Generally this will be the removal of a module or a dispatchable within a module. It could also mean an alteration in the argument list.

The specific semantics are:

• When removing or changing a dispatchable/pallet (including reordering) that was available within the first released runtime of the current runtimes's transaction version, then transaction_version of the new release must be bumped.
• When adding a dispatchable/pallet, transaction_version need not be bumped.

In both cases, spec_version must be bumped. This implies that modules which are introduced into a runtime which is released after the first runtime of that transaction_version may actually be changed or removed without bumping the transaction_version. Bumping the transaction_version therefore amounts to "baking in the current set of dispatchables as the API".

[xlc]

I see. It should be possible to create some automation to detect if we need to bump transaction version by comparing metadata from wasm? Manually tracking it is error prone.

Also maybe we need a better name? because have two different thing with exact same name is confusing.

[gavofyork]

Yeah that should be possible to automate; you'd just need to check if there's an alteration/removal to existing pallets, dispatchables, including their docs.

[gnunicorn]

seems like tests need updating

[bkchr]

I added some test and also found a bug with these tests. I think we should test syncing Kusama and if that works it should be mergable.