referrerpolicy=no-referrer-when-downgrade

Trait sp_runtime::traits::ValidateUnsigned

source ·
pub trait ValidateUnsigned {
    type Call;

    // Required method
    fn validate_unsigned(
        source: TransactionSource,
        call: &Self::Call,
    ) -> TransactionValidity;

    // Provided method
    fn pre_dispatch(call: &Self::Call) -> Result<(), TransactionValidityError> { ... }
}
Expand description

Provide validation for unsigned extrinsics.

This trait provides two functions pre_dispatch and validate_unsigned. The pre_dispatch function is called right before dispatching the call wrapped by an unsigned extrinsic. The validate_unsigned function is mainly being used in the context of the transaction pool to check the validity of the call wrapped by an unsigned extrinsic.

Required Associated Types§

source

type Call

The call to validate

Required Methods§

source

fn validate_unsigned( source: TransactionSource, call: &Self::Call, ) -> TransactionValidity

Return the validity of the call

This method has no side-effects. It merely checks whether the call would be rejected by the runtime in an unsigned extrinsic.

The validity checks should be as lightweight as possible because every node will execute this code before the unsigned extrinsic enters the transaction pool and also periodically afterwards to ensure the validity. To prevent dos-ing a network with unsigned extrinsics, these validity checks should include some checks around uniqueness, for example, checking that the unsigned extrinsic was sent by an authority in the active set.

Changes made to storage should be discarded by caller.

Provided Methods§

source

fn pre_dispatch(call: &Self::Call) -> Result<(), TransactionValidityError>

Validate the call right before dispatch.

This method should be used to prevent transactions already in the pool (i.e. passing validate_unsigned) from being included in blocks in case they became invalid since being added to the pool.

By default it’s a good idea to call validate_unsigned from within this function again to make sure we never include an invalid transaction. Otherwise the implementation of the call or this method will need to provide proper validation to ensure that the transaction is valid.

Changes made to storage WILL be persisted if the call returns Ok.

Object Safety§

This trait is not object safe.

Implementors§