Crate frame_system

source ·
Expand description

§System Pallet

The System pallet provides low-level access to core types and cross-cutting utilities. It acts as the base layer for other pallets to interact with the Substrate framework components.

§Overview

The System pallet defines the core data types used in a Substrate runtime. It also provides several utility functions (see Pallet) for other FRAME pallets.

In addition, it manages the storage items for extrinsic data, indices, event records, and digest items, among other things that support the execution of the current block.

It also handles low-level tasks like depositing logs, basic set up and take down of temporary storage entries, and access to previous block hashes.

§Interface

§Dispatchable Functions

The System pallet provides dispatchable functions that, with the exception of remark, manage low-level or privileged functionality of a Substrate-based runtime.

  • remark: Make some on-chain remark.
  • set_heap_pages: Set the number of pages in the WebAssembly environment’s heap.
  • set_code: Set the new runtime code.
  • set_code_without_checks: Set the new runtime code without any checks.
  • set_storage: Set some items of storage.
  • kill_storage: Kill some items from storage.
  • kill_prefix: Kill all storage items with a key that starts with the given prefix.
  • remark_with_event: Make some on-chain remark and emit an event.
  • do_task: Do some specified task.
  • authorize_upgrade: Authorize new runtime code.
  • authorize_upgrade_without_checks: Authorize new runtime code and an upgrade sans verification.
  • apply_authorized_upgrade: Provide new, already-authorized runtime code.
§A Note on Upgrades

The pallet provides two primary means of upgrading the runtime, a single-phase means using set_code and a two-phase means using authorize_upgrade followed by apply_authorized_upgrade. The first will directly attempt to apply the provided code (application may have to be scheduled, depending on the context and implementation of the OnSetCode trait).

The authorize_upgrade route allows the authorization of a runtime’s code hash. Once authorized, anyone may upload the correct runtime to apply the code. This pattern is useful when providing the runtime ahead of time may be unwieldy, for example when a large preimage (the code) would need to be stored on-chain or sent over a message transport protocol such as a bridge.

The *_without_checks variants do not perform any version checks, so using them runs the risk of applying a downgrade or entirely other chain specification. They will still validate that the code meets the authorized hash.

§Public Functions

See the Pallet struct for details of publicly available functions.

§Signed Extensions

The System pallet defines the following extensions:

  • CheckWeight: Checks the weight and length of the block and ensure that it does not exceed the limits.
  • CheckNonce: Checks the nonce of the transaction. Contains a single payload of type T::Nonce.
  • CheckEra: Checks the era of the transaction. Contains a single payload of type Era.
  • CheckGenesis: Checks the provided genesis hash of the transaction. Must be a part of the signed payload of the transaction.
  • CheckSpecVersion: Checks that the runtime version is the same as the one used to sign the transaction.
  • CheckTxVersion: Checks that the transaction version is the same as the one used to sign the transaction.

Look up the runtime aggregator file (e.g. node/runtime) to see the full list of signed extensions included in a chain.

Re-exports§

Modules§

  • Block resource limits configuration structures.
  • Migrate the reference counting state.
  • Provide types to help defining a mock environment when testing pallets.
  • Module helpers for off-chain calls.
  • The pallet module in each FRAME pallet hosts the most important items needed to construct this pallet.
  • Prelude to be used alongside pallet macro, for ease of use.
  • Autogenerated weights for frame_system

Structs§

  • Information of an account.
  • Check for transaction mortality.
  • Genesis hash check to provide replay protection between different networks.
  • Check for transaction mortality.
  • Check to ensure that the sender is not the zero address.
  • Nonce check and increment to give replay protection for transactions.
  • Ensure the runtime version registered in the transaction is the same as at present.
  • Ensure the transaction version registered in the transaction is the same as at present.
  • Block resource (weight) limit check.
  • Information needed when a new runtime binary is submitted and needs to be authorized before replacing the current runtime.
  • Event handler which registers a consumer when created.
  • Always fail.
  • Ensure the origin is None. i.e. unsigned transaction.
  • Ensure the origin is Root.
  • Ensure the origin is Root and return the provided Success value.
  • Ensure the origin is any Signed origin.
  • Ensure the origin is Signed origin from the given AccountId.
  • Ensure the origin is provided Ensure origin and return the provided Success value.
  • Record of an event happening.
  • Stores the spec_version and spec_name of when the last runtime upgrade happened.
  • Event handler which registers a provider when created.
  • Event handler which registers a self-sufficient when created.

Enums§

  • Some resultant status relevant to decrementing a provider/self-sufficient reference.
  • Some resultant status relevant to incrementing a provider/self-sufficient reference.
  • A phase of a block’s execution.
  • Origin for the System pallet.
  • Reference status; can be either referenced or unreferenced.

Traits§

  • Numeric limits over the ability to add a consumer ref using inc_consumers.
  • Do something when we should be setting the code.

Functions§

  • Ensure that the origin o represents an unsigned extrinsic. Returns Ok or an Err otherwise.
  • Ensure that the origin o represents the root. Returns Ok or an Err otherwise.
  • Ensure that the origin o represents a signed extrinsic (i.e. transaction). Returns Ok with the account that signed the extrinsic or an Err otherwise.
  • Ensure that the origin o represents either a signed extrinsic (i.e. transaction) or the root. Returns Ok with the account that signed the extrinsic, None if it was root, or an Err otherwise.
  • Compute the trie root of a list of extrinsics.
  • Compute the trie root of a list of extrinsics.
  • Split an option into two constituent options, as defined by a splitter function.
  • Returns a 32 byte datum which is guaranteed to be universally unique. entropy is provided as a facility to reduce the potential for precalculating results.

Type Aliases§