Runtime

As the core part of Substrate, the runtime for a Substrate node contains all of the business logic for executing transactions, saving state transitions, and interacting with the outer node. Substrate provides all of the tools required to build common blockchain components so you can focus on developing the runtime logic that defines the blockchain behavior.

State transitions and the runtime

At the most basic level, every blockchain is essentially a ledger or record of each change that takes place on-chain. In Substrate-based chains, these changes to state are recorded in the runtime. Because the runtime handles this operation, the runtime is sometimes described as providing the state transition function.

Substrate runtime determines which transactions are valid and invalid and how the chain state is changed in response to transactions.

Runtime interfaces

The outer node is responsible for handling peer discovery, transaction pooling, block and transaction gossiping, consensus, and answering RPC calls from the outside world. These tasks frequently require the outer node to query the runtime for information or to provide information to the runtime. The runtime API facilitates this kind of communication between the outer node and the runtime.

In Substrate, sp_api crate provides an interface to implement a runtime API. It is designed to give you flexibility in defining your own custom interfaces using impl_runtime_apis macro. However, every runtime must implement the Core and Metadata interfaces. In addition to these required interfaces, most Substrate nodes -- like the node template -- implement the following runtime interfaces:

  • BlockBuilder for the functionality required to build a block.

  • TaggedTransactionQueue for validating transactions.

  • OffchainWorkerApi for enabling off-chain operations.

  • AuraApi for block authoring and validation using a round-robin method of consensus.

  • SessionKeys for generating and decoding session keys.

  • GrandpaApi for block finalization into the runtime.

  • AccountNonceApi for querying transaction indices.

  • TransactionPaymentApi for querying information about transactions.

  • Benchmark for estimating and measuring execution time required to complete transactions.

Core primitives

Substrate also defines the core primitives that the runtime must implement. Substrate framework makes minimal assumptions about what your runtime must provide to the other layers of Substrate. However, there are a few data types that must be defined and must fulfill a particular interface to work within the Substrate framework.

These core primitives are:

  • Hash: A type which encodes a cryptographic digest of some data. Typically just a 256-bit quantity.

  • DigestItem: A type which must be able to encode one of a number of "hard-wired" alternatives relevant to consensus and change-tracking as well as any number of "soft-coded" variants, relevant to specific modules within the runtime.

  • Digest: A series of DigestItems. This encodes all information that is relevant for a light-client to have on hand within the block.

  • Extrinsic: A type to represent a single piece of data external to the blockchain that is recognized by the blockchain. This typically involves one or more signatures, and some sort of encoded instructions (e.g. for transferring ownership of funds or calling into a smart contract).

  • Header: A type which is representative (cryptographically or otherwise) of all information relevant to a block. It includes the parent hash, the storage root and the extrinsics trie root, the digest and a block number.

  • Block: Essentially just a combination of Header and a series of Extrinsics, together with a specification of the hashing algorithm to be used.

  • BlockNumber: A type which encodes the total number of ancestors any valid block has. Typically a 32-bit quantity.

CESS Pallet construction

Developers can customize and build pallets to achieve desired functionality. The current Substrate framework provides many predefined pallets, such as frame_system, frame_support and other basic pallets, as well as some functional extension pallets, such as pallets that support smart contracts pattet_contracts, managing cryptocurrency pallets_balances etc.

Add custom pallets or predefine pallets to the runtime construct_ runtime! In macro:


construct_runtime!(
	pub enum Runtime where
		Block = Block,
		NodeBlock = opaque::Block,
		UncheckedExtrinsic = UncheckedExtrinsic
	{
		// Basic stuff
		System: frame_system = 0,
		RandomnessCollectiveFlip: pallet_randomness_collective_flip = 1,
		Timestamp: pallet_timestamp = 2,
		...
		
		// CESS pallets
		FileBank: pallet_file_bank = 60,
		TeeWorker: pallet_tee_worker = 61,
		Audit: pallet_audit = 62,
		Sminer: pallet_sminer = 63,
		StorageHandler: pallet_storage_handler = 64,
		SchedulerCredit: pallet_scheduler_credit = 65,
		Oss: pallet_oss = 66,
		Cacher: pallet_cacher = 67,
	}

CESS customized pallets starts from index 60.

The functions of each are:

FileBank - manages the meta information of files in the network, with two types of files (idle and active).

TeeWorker - TEEWorker is part of the CESS network, with a trusted environment responsible for calculating file tags and verification work. This pallet is responsible for managing TEEWorker information.

Audit - Audit pallet, responsible for checking whether files in the network are correctly stored, initiating challenges at random times, collecting storage certificates, assigning verification tasks to storage certificates, and processing verification results.

Sminer - Storage node is one of CESS roles, used to store user data and provide storage computing power for the network. This pallet is responsible for managing the information of storage nodes and rewarding or punishing them.

StorageHandler - manages the storage and computing power of the network and is responsible for information updating. It stores the current total idle, total active space, and space purchased by users on the network. It provide transaction interfaces for users to purchase, renew, and expand space. It allows user to inquire the expiration storage space through Hooks.

SchedulerCredit - TEEWorker's credit module, providing an interface for other pallets to increase or decrease the credits of TEEWorker.

Oss - DeOss is part of the CESS network, used to provide users with convenient data upload services. This pallet is responsible for managing information related to DeOss and providing external interfaces for user authorization or revocation of DeOss.

Cache - Manage the cache of miners' information and the related cache orders.

PreviousForkless UpgradeNextDistributed Storage