Trait sp_inherents::ProvideInherent
source · [−]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> { ... }
}
Expand description
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 Error: Encode + IsFatalError
type Error: Encode + IsFatalError
The error returned by check_inherent
.
Associated Constants
The inherent identifier used by this inherent.
Required methods
fn create_inherent(data: &InherentData) -> Option<Self::Call>
fn create_inherent(data: &InherentData) -> Option<Self::Call>
Create an inherent out of the given InherentData
.
Provided methods
fn is_inherent_required(
_: &InherentData
) -> Result<Option<Self::Error>, Self::Error>
fn is_inherent_required(
_: &InherentData
) -> Result<Option<Self::Error>, Self::Error>
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. Theimpl_outer_inherent!
, will call this function from itscheck_extrinsics
. If the inherent is not present, it will returne
. -
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>
fn check_inherent(_: &Self::Call, _: &InherentData) -> Result<(), Self::Error>
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.