Glossary¶
Key definitions, concepts, and terminology specific to the Polkadot ecosystem are included here.
Additional glossaries from around the ecosystem you might find helpful:
Authority¶
The role in a blockchain that can participate in consensus mechanisms.
- GRANDPA - the authorities vote on chains they consider final
- Blind Assignment of Blockchain Extension (BABE) - the authorities are also block authors
Authority sets can be used as a basis for consensus mechanisms such as the Nominated Proof of Stake (NPoS) protocol.
Authority Round (Aura)¶
A deterministic consensus protocol where block production is limited to a rotating list of authorities that take turns creating blocks. In authority round (Aura) consensus, most online authorities are assumed to be honest. It is often used in combination with GRANDPA as a hybrid consensus protocol.
Learn more by reading the official Aura consensus algorithm wiki article.
Blind Assignment of Blockchain Extension (BABE)¶
A block authoring protocol similar to Aura, except authorities win slots based on a Verifiable Random Function (VRF) instead of the round-robin selection method. The winning authority can select a chain and submit a new block.
Learn more by reading the official Web3 Foundation BABE research document.
Block Author¶
The node responsible for the creation of a block, also called block producers. In a Proof of Work (PoW) blockchain, these nodes are called miners.
Byzantine Fault Tolerance (BFT)¶
The ability of a distributed computer network to remain operational if a certain proportion of its nodes or authorities are defective or behaving maliciously.
Note
A distributed network is typically considered Byzantine fault tolerant if it can remain functional, with up to one-third of nodes assumed to be defective, offline, actively malicious, and part of a coordinated attack.
Byzantine Failure¶
The loss of a network service due to node failures that exceed the proportion of nodes required to reach consensus.
Practical Byzantine Fault Tolerance (pBFT)¶
An early approach to Byzantine fault tolerance (BFT), practical Byzantine fault tolerance (pBFT) systems tolerate Byzantine behavior from up to one-third of participants.
The communication overhead for such systems is O(n²), where n is the number of nodes (participants) in the system.
Call¶
In the context of pallets containing functions to be dispatched to the runtime, Call is an enumeration data type that describes the functions that can be dispatched with one variant per pallet. A Call represents a dispatch data structure object.
Chain Specification¶
A chain specification file defines the properties required to run a node in an active or new Polkadot SDK-built network. It often contains the initial genesis runtime code, network properties (such as the network's name), the initial state for some pallets, and the boot node list. The chain specification file makes it easy to use a single Polkadot SDK codebase as the foundation for multiple independently configured chains.
Collator¶
An author of a parachain network. They aren't authorities in themselves, as they require a relay chain to coordinate consensus.
More details are found on the Polkadot Collator Wiki.
Collective¶
Most often used to refer to an instance of the Collective pallet on Polkadot SDK-based networks such as Kusama or Polkadot if the Collective pallet is part of the FRAME-based runtime for the network.
Consensus¶
Consensus is the process blockchain nodes use to agree on a chain's canonical fork. It is composed of authorship, finality, and fork-choice rule. In the Polkadot ecosystem, these three components are usually separate and the term consensus often refers specifically to authorship.
See also hybrid consensus.
Consensus Algorithm¶
Ensures a set of actors—who don't necessarily trust each other—can reach an agreement about the state as the result of some computation. Most consensus algorithms assume that up to one-third of the actors or nodes can be Byzantine fault tolerant.
Consensus algorithms are generally concerned with ensuring two properties:
- Safety - indicating that all honest nodes eventually agreed on the state of the chain
- Liveness - indicating the ability of the chain to keep progressing
Consensus Engine¶
The node subsystem responsible for consensus tasks.
For detailed information about the consensus strategies of the Polkadot network, see the Polkadot Consensus blog series.
See also hybrid consensus.
Coretime¶
The time allocated for utilizing a core, measured in relay chain blocks. There are two types of coretime: on-demand and bulk.
On-demand coretime refers to coretime acquired through bidding in near real-time for the validation of a single parachain block on one of the cores reserved specifically for on-demand orders. They are available as an on-demand coretime pool. Set of cores that are available on-demand. Cores reserved through bulk coretime could also be made available in the on-demand coretime pool, in parts or in entirety.
Bulk coretime is a fixed duration of continuous coretime represented by an NFT that can be split, shared, or resold. It is managed by the Broker pallet.
Development Phrase¶
A mnemonic phrase that is intentionally made public.
Well-known development accounts, such as Alice, Bob, Charlie, Dave, Eve, and Ferdie, are generated from the same secret phrase:
Many tools in the Polkadot SDK ecosystem, such as subkey, allow you to implicitly specify an account using a derivation path such as //Alice.
Digest¶
An extensible field of the block header that encodes information needed by several actors in a blockchain network, including:
- Light clients for chain synchronization
- Consensus engines for block verification
- The runtime itself, in the case of pre-runtime digests
Dispatchable¶
Function objects that act as the entry points in FRAME pallets. Internal or external entities can call them to interact with the blockchain’s state. They are a core aspect of the runtime logic, handling transactions and other state-changing operations.
Events¶
A means of recording that some particular state transition happened.
In the context of FRAME, events are composable data types that each pallet can individually define. Events in FRAME are implemented as a set of transient storage items inspected immediately after a block has been executed and reset during block initialization.
Executor¶
A means of executing a function call in a given runtime with a set of dependencies. There are two orchestration engines in Polkadot SDK, WebAssembly and native.
-
The native executor uses a natively compiled runtime embedded in the node to execute calls. This is a performance optimization available to up-to-date nodes
-
The WebAssembly executor uses a Wasm binary and a Wasm interpreter to execute calls. The binary is guaranteed to be up-to-date regardless of the version of the blockchain node because it is persisted in the state of the Polkadot SDK-based chain
Existential Deposit¶
The minimum balance an account is allowed to have in the Balances pallet. Accounts cannot be created with a balance less than the existential deposit amount.
If an account balance drops below this amount, the Balances pallet uses a FRAME System API to drop its references to that account.
If the Balances pallet reference to an account is dropped, the account can be reaped.
Extrinsic¶
A general term for data that originates outside the runtime, is included in a block, and leads to some action. This includes user-initiated transactions and inherent transactions placed into the block by the block builder.
It is a SCALE-encoded array typically consisting of a version number, signature, and varying data types indicating the resulting runtime function to be called. Extrinsics can take two forms: inherents and transactions.
For more technical details, see the Polkadot spec.
Fork Choice Rule/Strategy¶
A fork choice rule or strategy helps determine which chain is valid when reconciling several network forks. A common fork choice rule is the longest chain, in which the chain with the most blocks is selected.
FRAME (Framework for Runtime Aggregation of Modularized Entities)¶
Enables developers to create blockchain runtime environments from a modular set of components called pallets. It utilizes a set of procedural macros to construct runtimes.
Visit the Polkadot SDK docs for more details on FRAME.
Full Node¶
A node that prunes historical states, keeping only recently finalized block states to reduce storage needs. Full nodes provide current chain state access and allow direct submission and validation of extrinsics, maintaining network decentralization.
Genesis Configuration¶
A mechanism for specifying the initial state of a blockchain. By convention, this initial state or first block is commonly referred to as the genesis state or genesis block. The genesis configuration for Polkadot SDK-based chains is accomplished by way of a chain specification file.
GRANDPA¶
A deterministic finality mechanism for blockchains that is implemented in the Rust programming language.
The formal specification is maintained by the Web3 Foundation.
Header¶
A structure that aggregates the information used to summarize a block. Primarily, it consists of cryptographic information used by light clients to get minimally secure but very efficient chain synchronization.
Hybrid Consensus¶
A blockchain consensus protocol that consists of independent or loosely coupled mechanisms for block production and finality.
Hybrid consensus allows the chain to grow as fast as probabilistic consensus protocols, such as Aura, while maintaining the same level of security as deterministic finality consensus protocols, such as GRANDPA.
Inherent Transactions¶
A special type of unsigned transaction, referred to as inherents, that enables a block authoring node to insert information that doesn't require validation directly into a block.
Only the block-authoring node that calls the inherent transaction function can insert data into its block. In general, validators assume the data inserted using an inherent transaction is valid and reasonable even if it can't be deterministically verified.
JSON-RPC¶
A stateless, lightweight remote procedure call protocol encoded in JavaScript Object Notation (JSON). JSON-RPC provides a standard way to call functions on a remote system by using JSON.
For Polkadot SDK, this protocol is implemented through the Parity JSON-RPC crate.
Keystore¶
A subsystem for managing keys for the purpose of producing new blocks.
Kusama¶
Kusama is a Polkadot SDK-based blockchain that implements a design similar to the Polkadot network.
Kusama is a canary network and is referred to as Polkadot's "wild cousin."
As a canary network, Kusama is expected to be more stable than a test network like Westend but less stable than a production network like Polkadot. Kusama is controlled by its network participants and is intended to be stable enough to encourage meaningful experimentation.
libp2p¶
A peer-to-peer networking stack that allows the use of many transport mechanisms, including WebSockets (usable in a web browser).
Polkadot SDK uses the Rust implementation of the libp2p networking stack.
Light Client¶
A type of blockchain node that doesn't store the chain state or produce blocks.
A light client can verify cryptographic primitives and provides a remote procedure call (RPC) server, enabling blockchain users to interact with the network.
Metadata¶
Data that provides information about one or more aspects of a system. The metadata that exposes information about a Polkadot SDK blockchain enables you to interact with that system.
Nominated Proof of Stake (NPoS)¶
A method for determining validators or authorities based on a willingness to commit their stake to the proper functioning of one or more block-producing nodes.
Oracle¶
An entity that connects a blockchain to a non-blockchain data source. Oracles enable the blockchain to access and act upon information from existing data sources and incorporate data from non-blockchain systems and services.
Origin¶
A FRAME primitive that identifies the source of a dispatched function call into the runtime. The FRAME System pallet defines three built-in origins. As a pallet developer, you can also define custom origins, such as those defined by the Collective pallet.
Pallet¶
A module that can be used to extend the capabilities of a FRAME-based runtime. Pallets bundle domain-specific logic with runtime primitives like events and storage items.
Parachain¶
A parachain is a blockchain that derives shared infrastructure and security from a relay chain. You can learn more about parachains on the Polkadot Wiki.
Paseo¶
Paseo TestNet provisions testing on Polkadot's "production" runtime, which means less chance of feature or code mismatch when developing parachain apps. Specifically, after the Polkadot Technical fellowship proposes a runtime upgrade for Polkadot, this TestNet is updated, giving a period where the TestNet will be ahead of Polkadot to allow for testing.
Polkadot¶
The Polkadot network is a blockchain that serves as the central hub of a heterogeneous blockchain network. It serves the role of the relay chain and provides shared infrastructure and security to support parachains.
Relay Chain¶
Relay chains are blockchains that provide shared infrastructure and security to the parachains in the network. In addition to providing consensus capabilities, relay chains allow parachains to communicate and exchange digital assets without needing to trust one another.
Rococo¶
A parachain test network for the Polkadot network. The Rococo network is a Polkadot SDK-based blockchain with an October 14, 2024 deprecation date. Development teams are encouraged to use the Paseo TestNet instead.
Runtime¶
The runtime represents the state transition function for a blockchain. In Polkadot SDK, the runtime is stored as a Wasm binary in the chain state. The Runtime is stored under a unique state key and can be modified during the execution of the state transition function.
Slot¶
A fixed, equal interval of time used by consensus engines such as Aura and BABE. In each slot, a subset of authorities is permitted, or obliged, to author a block.
Sovereign Account¶
The unique account identifier for each chain in the relay chain ecosystem. It is often used in cross-consensus (XCM) interactions to sign XCM messages sent to the relay chain or other chains in the ecosystem.
The sovereign account for each chain is a root-level account that can only be accessed using the Sudo pallet or through governance. The account identifier is calculated by concatenating the Blake2 hash of a specific text string and the registered parachain identifier.
SS58 Address Format¶
A public key address based on the Bitcoin Base-58-check encoding. Each Polkadot SDK SS58 address uses a base-58 encoded value to identify a specific account on a specific Polkadot SDK-based chain
The canonical ss58-registry provides additional details about the address format used by different Polkadot SDK-based chains, including the network prefix and website used for different networks
State Transition Function (STF)¶
The logic of a blockchain that determines how the state changes when a block is processed. In Polkadot SDK, the state transition function is effectively equivalent to the runtime.
Storage Item¶
FRAME primitives that provide type-safe data persistence capabilities to the runtime. Learn more in the storage items reference document in the Polkadot SDK.
Substrate¶
A flexible framework for building modular, efficient, and upgradeable blockchains. Substrate is written in the Rust programming language and is maintained by Parity Technologies.
Transaction¶
An extrinsic that includes a signature that can be used to verify the account authorizing it inherently or via signed extensions.
Transaction Era¶
A definable period expressed as a range of block numbers during which a transaction can be included in a block. Transaction eras are used to protect against transaction replay attacks if an account is reaped and its replay-protecting nonce is reset to zero.
Trie (Patricia Merkle Tree)¶
A data structure used to represent sets of key-value pairs and enables the items in the data set to be stored and retrieved using a cryptographic hash. Because incremental changes to the data set result in a new hash, retrieving data is efficient even if the data set is very large. With this data structure, you can also prove whether the data set includes any particular key-value pair without access to the entire data set.
In Polkadot SDK-based blockchains, state is stored in a trie data structure that supports the efficient creation of incremental digests. This trie is exposed to the runtime as a simple key/value map where both keys and values can be arbitrary byte arrays.
Validator¶
A validator is a node that participates in the consensus mechanism of the network. Its roles include block production, transaction validation, network integrity, and security maintenance.
WebAssembly (Wasm)¶
An execution architecture that allows for the efficient, platform-neutral expression of deterministic, machine-executable logic.
Wasm can be compiled from many languages, including the Rust programming language. Polkadot SDK-based chains use a Wasm binary to provide portable runtimes that can be included as part of the chain's state.
Weight¶
A convention used in Polkadot SDK-based blockchains to measure and manage the time it takes to validate a block. Polkadot SDK defines one unit of weight as one picosecond of execution time on reference hardware.
The maximum block weight should be equivalent to one-third of the target block time with an allocation of one-third each for:
- Block construction
- Network propagation
- Import and verification
By defining weights, you can trade-off the number of transactions per second and the hardware required to maintain the target block time appropriate for your use case. Weights are defined in the runtime, meaning you can tune them using runtime updates to keep up with hardware and software improvements.
Westend¶
Westend is a Parity-maintained, Polkadot SDK-based blockchain that serves as a test network for the Polkadot network.
| Created: October 2, 2024