polkadot_sdk_docs/reference_docs/glossary.rs
1//! # Glossary
2//!
3//! #### State
4//!
5//! The data around which the blockchain network wishes to come to consensus. Also
6//! referred to as "onchain data", "onchain storage" or sometimes just "storage". In UTXO based
7//! blockchains, is referred to as "ledger".
8//!
9//! **Synonyms**: Onchain data, Onchain storage, Storage, Ledger
10//!
11//! #### State Transition Function
12//!
13//! The WASM Blob that dictates how the blockchain should transition its state upon encountering new
14//! blocks.
15//!
16//! #### Host
17//!
18//! The environment that hosts and executes the [state transition function's WASM
19//! blob](#state-transition-function).
20//!
21//! #### Node
22//!
23//! The full software artifact that contains the [host](#host), but importantly also all the other
24//! modules needed to be part of a blockchain network, such as peer-to-peer networking, database and
25//! such.
26//!
27//! **Synonyms**: Client
28//!
29//! #### Light Node
30//!
31//! Same as [node](#nodes), but when capable of following the network only through listening to
32//! block headers. Usually capable of running in more constrained environments, such as an embedded
33//! device, phone, or a web browser.
34//!
35//! **Synonyms**: Light Client
36//!
37//! #### Offchain
38//!
39//! Refers to operations conducted outside the blockchain's consensus mechanism. They are essential
40//! for enhancing scalability and efficiency, enabling activities like data fetching and computation
41//! without bloating the blockchain state.
42//!
43//! #### Host Functions:
44//!
45//! Host functions are the node's API, these are functions provided by the runtime environment (the
46//! [host](#host)) to the Wasm runtime. These functions allow the Wasm code to interact with and
47//! perform operations on the [node](#node), like accessing the blockchain state.
48//!
49//! #### Runtime API:
50//!
51//! This is the API of the runtime, it acts as a communication bridge between the runtime and the
52//! node, serving as the exposed interface that facilitates their interactions.
53//!
54//! #### Dispatchable:
55//!
56//! Dispatchables are [function objects](https://en.wikipedia.org/wiki/Function_object) that act as
57//! the entry points in [FRAME](frame) pallets. They can be called by internal or external entities
58//! to interact with the blockchain's state. They are a core aspect of the runtime logic, handling
59//! transactions and other state-changing operations.
60//!
61//! **Synonyms**: Callable
62//!
63//! #### Extrinsic
64//!
65//! An extrinsic is a general term for a piece of data that is originated outside of the runtime,
66//! included into a block and leads to some action. This includes user-initiated transactions as
67//! well as inherents which are placed into the block by the block-builder.
68//!
69//! #### Pallet
70//!
71//! Similar to software modules in traditional programming, [FRAME](frame) pallets in Substrate are
72//! modular components that encapsulate distinct functionalities or business logic. Just as
73//! libraries or modules are used to build and extend the capabilities of a software application,
74//! pallets are the foundational building blocks for constructing a blockchain's runtime with frame.
75//! They enable the creation of customizable and upgradeable networks, offering a composable
76//! framework for a Substrate-based blockchain. Each pallet can be thought of as a plug-and-play
77//! module, enhancing the blockchain's functionality in a cohesive and integrated manner.
78//!
79//! #### Full Node
80//!
81//! It is a node that prunes historical states, keeping only recent finalized block states to reduce
82//! storage needs. Full nodes provide current chain state access and allow direct submission and
83//! validation of extrinsics, maintaining network decentralization.
84//!
85//! #### Archive Node
86//!
87//! An archive node is a specialized node that maintains a complete history of all block states and
88//! transactions. Unlike a full node, it does not prune historical data, ensuring full access to the
89//! entire blockchain history. This makes it essential for detailed blockchain analysis and
90//! historical queries, but requires significantly more storage capacity.
91//!
92//! #### Validator
93//!
94//! A validator is a node that participates in the consensus mechanism of the network.
95//! Its role includes block production, transaction validation, network integrity and security
96//! maintenance.
97//!
98//! #### Collator
99//!
100//! A collator is a node that is responsible for producing candidate blocks for the validators.
101//! Collators are similar to validators on any other blockchain but, they do not need to provide
102//! security guarantees as the Relay Chain handles this.
103//!
104//! #### Parachain
105//!
106//! Short for "parallelized chain" a parachain is a specialized blockchain that runs in parallel to
107//! the Relay Chain (Polkadot, Kusama, etc.), benefiting from the shared security and
108//! interoperability features of it.
109//!
110//! **Synonyms**: AppChain
111//!
112//! #### PVF
113//! The Parachain Validation Function (PVF) is the current runtime Wasm for a parachain that is
114//! stored on the Relay chain. It is an essential component in the Polkadot ecosystem, encapsulating
115//! the validation logic for each parachain. The PVF is executed by validators to verify the
116//! correctness of parachain blocks. This is critical for ensuring that each block follows the logic
117//! set by its respective parachain, thus maintaining the integrity and security of the entire
118//! network.
119//!
120//! **Synonyms**: Parachain Validation Function