extrinsics: Decode extrinsics from blocks

[lexnv]

This PR adds support to decode extrinsics from blocks.

The extrinsic is composed of:

• 1 byte to signal the version and if the payload is signed or not
• for a signed payload only:
  • Address
  • Signature
  • Extra
• Call data

The type IDs of the Address, Signature, Extra and Call data are dynamically extracted from the metadata.
This is used then during the raw decoding to skip over those fields.
Currently, the Signature and Extra fields are not exposed or tracked internally.

The interface exposes the ability to fetch bytes or decode on a custom type the

• Address signer of the extrinsic payload
• Call the raw function of the extrinsic

Output from the added example

 Block 0x3620a9782142e9d523f5aa8fa0a043e9824285130eb55df6e61a70544136eccf
  Extrinsic index 0
  Extrinsic call: Timestamp(set { now: 1682353806000 })
  Extrinsic index 1
  Extrinsic call: ParaInherent(enter { data: InherentData { bitfields: [UncheckedSigned { payload: AvailabilityBitfield(DecodedBits { .. } })
  Extrinsic index 2
  Extrinsic call: Balances(transfer { dest: Id(AccountId32([142, 175, 4, 21, 22, 135, 115, 99, 38, 201, 254, 161, 126, 37, 252, 82, 135, 97, 54, 147, 201, 18, 144, 156, 178, 38, 170, 71, 148, 242, 106, 72])), value: 1100000000 })
  Extrinsic address: Some(Ok(Id(AccountId32([212, 53, 147, 199, 21, 253, 211, 28, 97, 20, 26, 189, 4, 169, 159, 214, 130, 44, 133, 88, 133, 76, 205, 227, 154, 86, 132, 231, 165, 109, 162, 125]))))

Next Steps

• Custom metadata wrapper for ExtrinsicMetadata
• Introduce a StaticExtrinsic trait to identify pallets and variant index
• Decode using StaticExtrinsic after changes in codegen

[jsdw]

I was expecting all of this extrinsics stuff to end up coming from BlockBody, below, with the idea that:

• you get hold of a block, and then load the body with block.bocy().await?
• and then from the body you can iterate thorugh extrinsics already with body.extrinsics()
• and then each extrinsic you get back can be decoded (and that Extrinsic thing can have an interface that is inspired by EventDetails.

I don't think it really makes sense to have a separate top level extrinsics folder, because we already have a tx folder for constructing transactions (extrinsics) anyway, and then this blocks folder is all about getting and working with blocks, whose bodies are simply a list of extrinsics :)

So yeah I guess I'd probably:

• move the Extrinsic type defined already below into a separate file in this folder if it'll be getting quite big and then
• add to that type the logic for decoding them
• and then no need for eg an ExtrinsicsClient
• no need for this extrinsics method (that's what body() is for; downloading the block body which then contains the extrinsics)

[lexnv]

Have moved the extrinsic to the BlocksBody to iterate over them as extrinsics()

One other thing is that we still have the find apis that we want to mirror from the events.
Have added them with _extrinsic prefix as in find_extrisic, for extra clarity.

That makes me think that we could add something of the following:

struct BlockBody {
    fn extrinsics() -> Extrinsics
}

struct Extrinsics {
   fn find() ...
   fn find_first() ...
   fn iter() -> ExtrinsicDetails 
}

However, the Extrinsics struct from here would contain almost the same information as the BlockBody in this example.
Let me know what you think of it 🙏

[jsdw]

In block_types.rs we have a BlockBody and then an Extrinsic when we iter over the extrinsics.

The type IDs (ExteinsicIds are probably useful to get hold of once you load the BlockBody, so you're ready to iterate and decode extrinsics.

The hash we don't need, and then the actual bytes we could put in an Arc<[u8]> perhaps as we do with EventDetails (I'm not sure why it's a Vec<Arc..> here), in order that Extrinsic does not have any lifetime connecting it to BlockBody (same as why we did it in eventdetails).

Then, the methods in ExtrinsicDetails could be put onto that Extrinsic struct that already exists (or just replace it with this one; since we have EventDetails, ExtrinsicDetails is consistent name wise :))

[lexnv]

That makes sense!
The hash from the extrinsics is used to fetch the events in the implementation with OnlineClient

[jsdw]

Nit: maybe call this something more descriptive like call_type_variants?

[jsdw]

Looks great to me :)

[niklasad1]

another really solid PR, good stuff