blockchain node
At a high level, all blockchain nodes require the following core components:
Data storage for the state changes recorded as a result of transactions. Peer-to-peer networking for decentralized communication between nodes. Consensus methodology to protect against malicious activity and ensure the ongoing progress of the chain. Logic for ordering and processing incoming transactions. Cryptography for generating hash digests for blocks and for signing and verifying the signatures associated with transactions. Why Substrate?
Substrate isn't a perfect fit for every use case, application, or project. However, Substrate might be the perfect choice if you want to build a blockchain that is:
tailored to a very specific use case able to connect and communicate with other blockchains customizable with predefined composable modular components able to evolve and change with upgrades over time
Flexible - modular blockchain framework, decoupled blockchain components
Open - open source and community driven
Interoperable - all substrate-based blockchains can interoperate with the other blockchains through cross-consensus messaging (XCM)
Substrate Node - high level abstraction
Outer Node - handles network activity such as peer discovery, managing transaction requests, reaching consensus with peers, and responding to RPC calls Storage - persists the evolving state of a Substrate blockchain using a simple and highly efficient key-value storage layer P to P network - utilize libp2p network stack to communicate with other network participants consensus - communicate with other nodes to reach agreement RPC API - accepts inbound HTTP and WebSocket requests to allow blockchain users to interact with the chain Telemetry - collects and provides access to node metrics Execution environment - responsible for selecting the execution environment—WebAssembly or native Rust—for the runtime to use then dispatching calls to the runtime selected communication with runtime was done through Runtime - contains all of the business logic for executing the state transition function of the blockchain responsible for validating transactions controls how transaction are included in blocks substrate runtime is designed to compile to webAssembly (WASM) byte code support for forkless upgrades multi-platform compatibility validation proofs for relay chain consensus mechanism runtime use host functions to communicate with the outer node and outside world Light Client nodes
simplied version of substrate node only provides the runtime & current state allows users to connect ot a substrate runtime direcctly using a browser, browser extension, mobile devices... use RPC endpoints to connect to WebAssembly execution environment to read block headers, submit transactions, and view the results of transaction
Network Types
private networks - limit access to a restricted set of nodes Solo chains - implement own security protocol and don’t connect or communicate with any other chains Relay chains - provide decentralized security and communication for other chain that connect to them Parachains - built to connect to a relay chain and have the ability to communicate with other chains that use the same relay chain Node Types
full nodes - store all block headers and most recent 256 blocks Archive nodes - store past blocks light client nodes - no storage, only runtime and access to current state FRAME - framework for runtime aggregation of Modularized Entities
encompass a number of modules and support libraries that simplify runtime development (staking, consensus, governance, and other common activities modules are called pallets
Consensus
block authorizing - process to create new blocks block finalization - process to handle fork and choose canonical chain probabilistic finality + finality mechanism → Deterministic finality Aura - provides a slot-based block authoring mechanism. In Aura a known set of authorities take turns producing blocks GRNADPA - provides block finalization; listens to gossip about blocks that have been produced by block authoring nodes. GRANDPA validators vote on chains, not blocks Transactions and block basics
Transaction Types
Unsigned Transaction - no signature required so no economic deterrent to prevent spam or replay attack Inherent Transaction - a special type of unsigned transaction; block authoring nodes can add information directly to a block. Inherent transactions can only be inserted into a block by the block authoring node that calls them Substrate Block
Transaction Lifecycle - how signed transaction gets validated and executed
Transaction Pool
periodically checks the validity of each transaction ( method) ordering of valid transactions placed in a transaction queue
Executive module
orchestrates how transactions are executed to produce a block calls function in the runtime modules and executes those functions in specific order system on_initialize execute first remaining pallets in construct_runtime! macro executing the transactions to be included in a block each valid transaction is executed in order of transaction priority state changes are written directly to storage during execution → if a transaction were to fail mid-execution, any state changes that took place before the failure would not be reverted & events are also written to storage finalizing block building remaining pallets in construct_runtime! macro on_idle and on_finalize system on_finalize execute last
Block authoring and block imports
So far, you have seen how transactions are included in a block produced by the local node. If the local node is authorized to produce blocks, the transaction lifecycle follows a path like this:
The local node listens for transactions on the network. Each transaction is verified. Valid transactions are placed in the transaction pool. The transaction pool orders the valid transactions in the appropriate transaction queue and the executive module calls into the runtime to begin the next block. Transactions are executed and state changes are stored in local memory. The constructed block is published to the network.
Public and Private keys
public key can be used to generate multiple public addresses and address format for an account using base-58 encoding using subkey inspect command and —network option or using Subscan to look up the chain-specific address for a public key
