Readings

Writings

个人成长

Tech Learning

Web3 Industry Report

Startup Ideas

Useful Link Cache

Explore

Web3 Stack

Polkadot学习

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 APIs⁠

⁠

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

list of

FRAME pallets available⁠

⁠

Consensus

Consensus in two phases

block authorizing - process to create new blocks

block finalization - process to handle fork and choose canonical chain

Deterministic finality

probabilistic finality + finality mechanism → Deterministic finality

default consensus model

Aura - provides a slot-based block authoring mechanism. In Aura a known set of authorities take turns producing blocks

BABE

Proof of work

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

Signed Transaction

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

Block height

Parent Hash

Transaction Root

State Root ??

Digest ???

Transaction Lifecycle - how signed transaction gets validated and executed

⁠

Transaction Pool

periodically checks the validity of each transaction (

validate_transaction⁠

method)

ordering of valid transactions placed in a transaction queue

ready queue

future 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

operations

initializing a block

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

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.