Substrate: Metadata call Multisig.asMulti fifth argument

[emielvanderhoek]

The metadata definition for the fifth argument of the call: multisig.asMulti should get the following type definition: Box<Call>.
The Metadata currently defines the fifth argument as a Vec<u8> (Bytes).

https://github.com/paritytech/substrate/blob/cf7432a5ebef122ab685e0b9256a15c722661116/frame/multisig/src/lib.rs#L360

This prevents external systems such as Polkascan (https://polkascan.io/polkadot-cc1/transaction/0x603b68bb8b6bbd2b845d1096f2a043ddda4aa5ddc804041812f48282d1e939a9) and Polkadot JS Apps (https://polkadot.js.org/apps/#/explorer/query/357567) to properly interpret the data.

Example:
The following screen will allow the composition of a call if this gets corrected.

[emielvanderhoek]

@gavofyork could you get this addressed?

[CodeForcer]

This is also the source of current problems in our kusama-utils and kusama-api libraries. Unfortunately the library wont be able to complete trades for users until this is resolved due to the failing of the as_multi encoding

[emielvanderhoek]

I recommend this to be part of a checklist for runtime upgrades. Nested calls should always be defined as Call or Box< Call>.

[jacogr]

This does not prohibit sending txs at all. So not sure why the libs are broken - it does work, it is just helpful having it as a Call type.

[gavofyork]

The use of an opaque data type was intentional. Encoding and decoding a call can itself be a potentially exponentially heavy operation. Determining and charging for its weight is impractical. Passing only opaque data keeps everything simple, easier to weigh and harder to attack.

[emielvanderhoek]

Yeah it breaks some assumption we have for decoding ‘internal’ (nested) calls we have in our harvester. I’d still prefer a new type such as ‘OpaqueCall’ to be able to deal with this in a more elegant way. That type definition could map to a Vec< u8> in turn of course.

That would solve your problem and mine.