Trait sp_inherents::ProvideInherent[−][src]

pub trait ProvideInherent {
    type Call;
    type Error: Encode + IsFatalError;

    const INHERENT_IDENTIFIER: InherentIdentifier;

    fn create_inherent(data: &InherentData) -> Option<Self::Call>;

    fn is_inherent_required(
        _: &InherentData
    ) -> Result<Option<Self::Error>, Self::Error> { ... }

    fn check_inherent(
        _: &Self::Call, 
        _: &InherentData
    ) -> Result<(), Self::Error> { ... }
}

A pallet that provides or verifies an inherent extrinsic.

The pallet may provide the inherent, verify an inherent, or both provide and verify.

Associated Types

type Call[src]

The call type of the pallet.

type Error: Encode + IsFatalError[src]

The error returned by check_inherent.

Loading content...

Associated Constants

const INHERENT_IDENTIFIER: InherentIdentifier[src]

The inherent identifier used by this inherent.

Loading content...

Required methods

fn create_inherent(data: &InherentData) -> Option<Self::Call>[src]

Create an inherent out of the given InherentData.

Loading content...

Provided methods

fn is_inherent_required(
    _: &InherentData
) -> Result<Option<Self::Error>, Self::Error>[src]

Determines whether this inherent is required in this block.

  • Ok(None) indicates that this inherent is not required in this block. The default implementation returns this.

  • Ok(Some(e)) indicates that this inherent is required in this block. The impl_outer_inherent!, will call this function from its check_extrinsics. If the inherent is not present, it will return e.

  • Err(_) indicates that this function failed and further operations should be aborted.

CAUTION: This check has a bug when used in pallets that also provide unsigned transactions. See https://github.com/paritytech/substrate/issues/6243 for details.

fn check_inherent(_: &Self::Call, _: &InherentData) -> Result<(), Self::Error>[src]

Check whether the given inherent is valid. Checking the inherent is optional and can be omitted by using the default implementation.

When checking an inherent, the first parameter represents the inherent that is actually included in the block by its author. Whereas the second parameter represents the inherent data that the verifying node calculates.

Loading content...

Implementors

Loading content...