Module frame_system::pallet::storage_types

Auto-generated docs-only module listing all (public and private) defined storage types for this pallet.

Warning: Doc-Only

Members of this module cannot be used directly and are only provided for documentation purposes.

To see the actual storage type, find a struct with the same name at the root of the pallet, in the list of Type Definitions.

Structs

• Account
  The full account information for a particular account ID.
• AllExtrinsicsLen
  Total length (in bytes) for all extrinsics put together, for the current block.
• BlockHash
  Map of block numbers to block hashes.
• BlockSeed
  Map of block numbers to block shuffling seeds
• BlockWeight
  The current weight for the block.
• DidStoreTxs
  Map of block numbers to block shuffling seeds
• Digest
  Digest of the current block, also part of the block header.
• EventCount
  The number of events in the Events<T> list.
• EventTopics
  Mapping between a topic (represented by T::Hash) and a vector of indexes of events in the <Events<T>> list.
• Events
  Events deposited for the current block.
• ExecutionPhase
  The execution phase of the block.
• ExtrinsicCount
  Total extrinsics count for the current block.
• ExtrinsicData
  Extrinsics data for the current block (maps an extrinsic’s index to its data).
• LastRuntimeUpgrade
  Stores the spec_version and spec_name of when the last runtime upgrade happened.
• Number
  The current block number being processed. Set by execute_block.
• ParentHash
  Hash of the previous block.
• StorageQueue
  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).
• TxPrevalidation
  Map of block numbers to block shuffling seeds
• UpgradedToTripleRefCount
  True if we have upgraded so that AccountInfo contains three types of RefCount. False (default) if not.
• UpgradedToU32RefCount
  True if we have upgraded so that type RefCount is u32. False (default) if not.