Metadata V16: Features to include in V16

[lexnv]

Raising this issue to discuss about the features that are needed by the community in the next metadata version.

These features will be initially exposed under a metadata unstable versioning (u32::max), that will stabilize into v16.

I've compiled a possibly incomplete list of requested features that we may want to add to v16:

### Requested features V16
- [ ] https://github.com/paritytech/polkadot-sdk/issues/4519
- [ ] https://github.com/paritytech/polkadot-sdk/issues/4098
- [ ] https://github.com/paritytech/polkadot-sdk/issues/349
- [ ] https://github.com/paritytech/polkadot-sdk/issues/3594
- [ ] https://github.com/paritytech/polkadot-sdk/issues/3238
- [ ] https://github.com/paritytech/polkadot-sdk/issues/5285
- [ ] https://github.com/paritytech/polkadot-sdk/issues/5347

cc @jsdw @niklasad1 @bkchr @paritytech/subxt-team @xlc @josepot

[bkchr]

https://github.com/polkadot-fellows/RFCs/pull/99 with we would need to change the metadata to return multiple sets of transaction/signed extensions indexed by the version.

[josepot]

IMO an absolute must have of metadata v16 is a dedicated top-level entry named "hasher" (right after the "extrinsic" entry for instance, or at least at the same level), which should have 2 different properties:

• "name": the name of the hashing function
• "runtimeApi": a path to a runtime-api which just implements the hasher (E.g: Core_hash)

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/metadata-v16-updates/9557/1

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/metadata-v16-updates/9557/7

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/8

[gui1117]

Metadata v16 doesn't explicitly specify the transaction extensions used by signed extrinsics. Signed extrinsics don't support multiple versions of transaction extensions. Currently, it dispatches with version 0, and we can consider that version 0 is always the version used by signed extensions.

I think it is ok to have implicit as it is deprecated in the long term, but otherwise, we could add the version used by signed extensions in the metadata.

[jsdw]

We have just one thing left to add before our V16 impl is "done"; https://github.com/paritytech/polkadot-sdk/issues/7352 (which @re-gius is going to look into).

After that, we should:

1. Release latest frame-metadata and use it in polkadot-sdk so that the "unstable" metadata handed back from the Runtime API Metadata_metadata_at_version is our latest V16 impl.
2. Subxt, PAPI and PJS to try out latest unstable V16 and uncover any shortcomings.
3. Write a forum post describing the new metadata and asking for feedback.
4. 4. If everybody is happy (noting that low prio things can be added in V17), aim to stabilise V16 in 1-2 months (basically, expose it as version 16 rather than u32::MAX)

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/stabilizing-v16-metadata/12352/1