Module frame_system::pallet

source ·
Expand description

The pallet module in each FRAME pallet hosts the most important items needed to construct this pallet.

The main components of this pallet are:

  • Pallet, which implements all of the dispatchable extrinsics of the pallet, among other public functions.
    • The subset of the functions that are dispatchable can be identified either in the dispatchables module or in the Call enum.
  • storage_types, which contains the list of all types that are representing a storage item. Otherwise, all storage items are listed among Type Definitions.
  • Config, which contains the configuration trait of this pallet.
  • Event and Error, which are listed among the Enums.

Modules

  • Default implementations of DefaultConfig, which can be used to implement Config.
  • Auto-generated docs-only module listing all defined dispatchables for this pallet.
  • Auto-generated docs-only module listing all (public and private) defined storage types for this pallet.

Structs

  • Can be used to configure the genesis state of this pallet.
  • The Pallet struct, the main type that implements traits and standalone functions within the pallet.

Enums

  • Contains a variant per dispatchable extrinsic that this pallet has.
  • Error for the System pallet
  • Event for the System pallet.

Traits

Type Definitions

  • The full account information for a particular account ID.
  • Map of block numbers to block hashes.
  • Map of block numbers to block shuffling seeds
  • Map of block numbers to block shuffling seeds
  • Stores the spec_version and spec_name of when the last runtime upgrade happened.
  • ModuleDeprecated
    Type alias to Pallet, to be used by construct_runtime.
  • Exposed trait-generic origin type.
  • Storage queue is used for storing transactions in blockchain itself. Main reason for that storage entry is fact that upon VER block N execution it is required to fetch & executed transactions from previous block (N-1) but due to origin substrate design blocks & extrinsics are stored in rocksDB database that is not accessible from runtime part of the node (see Substrate architecture) what makes it impossible to properly implement block execution logic. As an solution blockchain runtime storage was selected as buffer for txs waiting for execution. Main advantage of such approach is fact that storage state is public so its impossible to manipulate data stored in there. Storage queue is implemented as double buffered queue - to solve problem of rare occasions where due to different reasons some txs that were included in block N are not able to be executed in a following block N+1 (good example is new session hook/event that by design consumes whole block capacity).
  • Map of block numbers to block shuffling seeds