Stabilizing V16 Metadata

Tech Talk
1

Hot of the heels from stabilizing the V2 archive RPCs, I’d like to now propose that we stabilize V16 metadata (the last update on this in the forum is here).

Additions in V16 Metadata

Metadata V16 builds on V15 metadata, which primarily added information about the available Runtime APIs, and exposes the following additional information:

  • Details about the available Pallet View Functions (these are a bit like Runtime APIs but scoped to individual pallets). Original issue here, and original PR here. This information is sufficient to allow libraries like PAPI and Subxt to generate interfaces to them.

  • Pallet associated type names and type information. These are the associated types that appear in the Config for each pallet. Having this information allows us to, for instance, query what the “Hashing” type is in the “System” pallet to know what hasher a chain uses. It’s hoped that this type information will help libraries like PAPI and Subxt remove some hardcoded config and instead obtain it via the metadata.

  • Runtime API trait versions. This makes it easy for a client to detect which version of a given Runtime API is in use on a chain, in case they need to adjust the logic across different versions of some Runtime APIs.

  • A list of supported transaction versions for the chain. Previously this was just a single value, but with the introduction of V5 transactions, we can now see which are supported (currently out of V4 and V5 transactions).

  • Transaction extensions are also versioned in V5 transactions, and so the metadata provides a list of which transaction extensions are in use across different versions, allowing for the correct encoding and decoding of transactions once multiple extension versions exist.

  • Deprecation information (available on Runtime APIs and their individual methods, and pallets and their contents; calls, storage entries, events, constants, errors and view functions). This allows runtime developers to annotate deprecation notices across a runtime and its pallets, and then for libraries like PAPI and Subxt to capture and display this information when generating client interfaces.

Along with this new information, we also rename Signed Extensions to Transaction Extensions and some related bits, in line with the new nomenclature for V5 transactions.

See more information about each change introduced in V16 metadata in this issue.

Stabilizing V16 Metadata

As of frame-metadata 21.0.0, I hope that we have reached a point where the format can be stabilized.

To this end, I’d like to propose that, as with our archive APIs, we aim to stabilize V16 metadata in one month, or more precisely, on April 30st 2025.

Stabilizing V16 metadata will allow libraries like Subxt and PAPI to fully integrate and use it with confidence, and benefit from the new information available through it. Notably, information regarding V5 transactions is important to expose to ensure that they can be properly handled. Future changes can then be addressed in a V17 metadata.

It should be noted that one blocker to stabilization is the merging of Stabilize pallet view functions by re-gius · Pull Request #7960 · paritytech/polkadot-sdk · GitHub, which marks Pallet View Functions as stable and thus also means that the information about them that we expose in the metadata can be stabilized. I am hoping that this will merge without issue, but if any changes are required which would affect what we need to expose in the metadata, then we will postpone stabilization of V16 metadata too.

If there are any problems with stabilizing that you’re aware of, please comment in this issue to keep everything in one place, and we’ll do what we can to address them!

Thank you all!

2 Likes