Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

V14 metadata doesn't provide enough information to decode extrinsic #12929

Closed
2 tasks done
eldargab opened this issue Dec 14, 2022 · 3 comments · Fixed by #14123
Closed
2 tasks done

V14 metadata doesn't provide enough information to decode extrinsic #12929

eldargab opened this issue Dec 14, 2022 · 3 comments · Fixed by #14123
Assignees
Labels
J2-unconfirmed Issue might be valid, but it’s not yet known.

Comments

@eldargab
Copy link

Is there an existing issue?

  • I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

  • This is not a support question.

Description of bug

To properly decode extrinsic one needs to know

  1. The type of Address
  2. The type of Signature
  3. The type of Call.

While all the above types are included in the .lookup.types, there is no way to know which one is which.

At Subsquid we look at paths and type parameters .

Polkadot.js uses its own set of hardcoded assumptions none of which is guaranteed to hold.

This is practical issue which hardens the maintenance of our stack.

Steps to reproduce

No response

@github-actions github-actions bot added the J2-unconfirmed Issue might be valid, but it’s not yet known. label Dec 14, 2022
@bkchr
Copy link
Member

bkchr commented Dec 14, 2022

3. The type of Call.

Yeah the call was always there, but more implicit by giving you all pallets and all their calls. We should probably revisit now as we have scale-info.

@jsdw
Copy link
Contributor

jsdw commented May 10, 2023

We actually use the metadata already to decode extrinsics:

https://github.com/paritytech/subxt/blob/3f16bb8d521031c7e13749d41711f54f490bb84c/subxt/src/blocks/extrinsic_types.rs#L205

To get the address, call, signature and extra details needed, we do this:

https://github.com/paritytech/subxt/blob/3f16bb8d521031c7e13749d41711f54f490bb84c/subxt/src/blocks/extrinsic_types.rs#L483

Currently this means that we do rely on the metadata.extrinsic.ty containing specific generics (in other words, that it's an UncheckedExtrinsic type).

Perhaps we should expose those type IDs directly under metadata.extrinsic though, which would ensure that they exist (and make it easier to get at them). ie have:

pub struct ExtrinsicMetadata<T: Form = MetaForm> {
	/// The type of the extrinsic.
	pub ty: T::Type,
	/// Extrinsic version.
	pub version: u8,
        /// Type of the outermost Call enum.
        pub call_ty: T::Type,
        /// Type of the address.
        pub address_ty: T::Type,
        /// Type of the extrinsic signature.
        pub signature_ty: T::Type,
	/// The signed extensions in the order they appear in the extrinsic.
	pub signed_extensions: Vec<SignedExtensionMetadata<T>>,
}

Does that sound good? In the absense of anything saying otherwise, we'll aim to get this in to V15 metadata, because it seems like a sensible addition to me.

@Polkadot-Forum
Copy link

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

https://forum.polkadot.network/t/stablising-v15-metadata/2819/1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J2-unconfirmed Issue might be valid, but it’s not yet known.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants