How come SignedExtra satisfies SignedExtension trait bound in substrate runtime?

Question

In substrate runtime, https://github.com/paritytech/polkadot-sdk/blob/f60318f68687e601c47de5ad5ca88e2c3f8139a7/substrate/bin/node/runtime/src/lib.rs#L2106C10-L2106C21

pub type SignedExtra = (
    // all these structs implement the trait SignedExtension
    frame_system::CheckNonZeroSender<Runtime>,
    frame_system::CheckSpecVersion<Runtime>,
    frame_system::CheckTxVersion<Runtime>,
    frame_system::CheckGenesis<Runtime>,
    frame_system::CheckEra<Runtime>,
    frame_system::CheckNonce<Runtime>,
    frame_system::CheckWeight<Runtime>,
    pallet_asset_conversion_tx_payment::ChargeAssetTxPayment<Runtime>,
);

/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
    generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;

But when you check the signature of generic::UncheckedExtrinsic

pub struct UncheckedExtrinsic<Address, Call, Signature, Extra>
where
    Extra: SignedExtension,
{
    /// The signature, address, number of extrinsics have come before from
    /// the same signer and an era describing the longevity of this transaction,
    /// if this is a signed extrinsic.
    pub signature: Option<UncheckedSignaturePayload<Address, Signature, Extra>>,
    /// The function that should be called.
    pub function: Call,
}

It has trait bound for SignedExtension for type parameter Extra. How come the type SignedExtra be satisfying the trait bound? Assuming this is possible, what will happen when we call valid method for SignedExtra (from SignedExtension trait)?

Answer 1

This is a trick that we often deploy in the Polkadot SDK. It uses a crate called impl_trait_for_tuple. This crate aids with implementing a trait on a tuple type when all the tuple elements already implement the trait.

You can see it being used here for the impl SignedExtension for Tuple. This means that the tuple (T0, T1 ..) will implement SignedExtension when each T already implements SignedExtension. It is very useful, since we often need to aggregate multiple homogenous types into a tuple and not loose their trait implementations.