Metadata V15: Enrich extrinsic type info for decoding #14123
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1210,14 +1210,14 @@ pub trait Block: Clone + Send + Sync + Codec + Eq + MaybeSerialize + Debug + 'st | |
| /// Something that acts like an `Extrinsic`. | ||
| pub trait Extrinsic: Sized { | ||
| /// The function call. | ||
| type Call: TypeInfo; | ||
|
|
||
| /// The payload we carry for signed extrinsics. | ||
| /// | ||
| /// Usually it will contain a `Signature` and | ||
| /// may include some additional data that are specific to signed | ||
| /// extrinsics. | ||
|
There was a problem hiding this comment. Instead of breaking most of the code we could just do There was a problem hiding this comment. Yep, I like this approach more! Thanks for the feedback! There was a problem hiding this comment. @bkchr What's your opinion on having the We should have enough type info by relying on:
The That is unless we'll break other things There was a problem hiding this comment. I have no idea if someone is using this. However, frankly speaking by only having the types you listed you don't know the encoding of the There was a problem hiding this comment. Good idea! I'll add the The type only contained the There was a problem hiding this comment. iirc the extrinsic type was quite useless anyway before; it mostly just said "hey we want to encode the extrinsic to some vec of bytes". It doesn't provide any useful information on how those bytes need to be formed etc. There are already a bunch of things we must just assume already about encoding extrinsics, ie the order of the signature stuff, how the not-really-scale Option for the signature is encoded (ie it has a version number The metadata, in my mind, only needs to provide the information that might vary from chain to chain (eg the actual additional params etc). This tx version can encode the actual format that this stuff is turned into an extrinsic. All of this to say, what would adding a There was a problem hiding this comment.
Good point.
Just because every body is currently using our |
||
| type SignaturePayload: SignaturePayload; | ||
|
|
||
| /// Is this `Extrinsic` signed? | ||
| /// If no information are available about signed/unsigned, `None` should be returned. | ||
|
|
@@ -1236,6 +1236,31 @@ pub trait Extrinsic: Sized { | |
| } | ||
| } | ||
|
|
||
| /// Something that acts like a [`SignaturePayload`](Extrinsic::SignaturePayload) of an | ||
| /// [`Extrinsic`]. | ||
| pub trait SignaturePayload { | ||
| /// The type of the address that signed the extrinsic. | ||
| /// | ||
| /// Particular to a signed extrinsic. | ||
| type SignatureAddress: TypeInfo; | ||
|
|
||
| /// The signature type of the extrinsic. | ||
| /// | ||
| /// Particular to a signed extrinsic. | ||
| type Signature: TypeInfo; | ||
|
|
||
| /// The additional data that is specific to the signed extrinsic. | ||
| /// | ||
| /// Particular to a signed extrinsic. | ||
| type SignatureExtra: TypeInfo; | ||
| } | ||
|
|
||
| impl SignaturePayload for () { | ||
| type SignatureAddress = (); | ||
| type Signature = (); | ||
| type SignatureExtra = (); | ||
| } | ||
|
|
||
| /// Implementor is an [`Extrinsic`] and provides metadata about this extrinsic. | ||
| pub trait ExtrinsicMetadata { | ||
| /// The format version of the `Extrinsic`. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh, it is being done already 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, a
type SignaturePayloadOf<E> = (<E as Extrinsic>::X, <E as Extrinsic>::Y, <E as Extrinsic>::Z)will help prevent potential error where the order of these 3 might be mistaken.