From transaction to block - part 2
Blocks are central components of a blockchain. They are composed of all information required to execute the transaction and prove that a transaction is a valid source of state transition. Blocks are also central to blockchain consensus.
This is part 2 of from transaction to block guide. This guide will explore
how blocks get initialized and propagated within the blockchain network. We
will also understand how state proofs are generated from blocks and explore
some of the implementation details of these concepts.
Help us measure our progress and improve Substrate in Bits content by filling out our living feedback form. It will only take 2 minutes of your time. Thank you!
Recap
The lifecycle of an extrinsic as described in the previous guide includes the following:
- Extrinsic Submission; where a node receives valid transactions through an open RPC endpoint.
- Extrinsic Validation and Queuing; where transactions are validated and queued in the node's transaction pool.
- Extrinsic Ordering; where transactions are ordered based on substrate priority system and packaged into a block.
- Extrinsic Execution; where the FRAME execution pallet along with the external client, orchestrates the execution of pallets with state changes stored in the local memory.
- Block Authoring; where a block is proposed by a block-producing node.
- Block Propagation; where blocks are imported and shared among nodes in the network.
Part-1 of from transaction to block
provided a detailed description of how transactions can be submitted using
libraries like subxt. We walked through some of the steps of a transaction
lifecycle and exposed some of the implementation details of these steps. We saw
how Substrate implements a client's transaction pool and dived deep into the
very nature of what constitutes an extrinsic within the framework of Substrate.
This guide builds on the knowledge acquired from part-1 and focuses on the last two steps of the transaction lifecycle. It dives into the nature of blocks, expands on how blocks are handled within the framework of Substrate, and highlights other related concepts.
Block authoring
After extrinsic within a block generated by a node has been executed
successfully, a block-producing node can propose a block to be added to the
block-chain. It is important to note that only consensus nodes can propose
blocks.
Depending on the block authoring mechanism being used in the network, a
proposed block may be voted on by other consensus nodes and selected as the
next block in the block-chain.
We will focus our attention on how Substrate implements the block proposal and authoring step in this guide.
A consensus node is a node that participates in the network's consensus. Substrate consensus mechanism is discussed in a future guide. However, you can find a primer on Substrate consensus mechanism here
Pending our guide into Substrate consensus and block authoring mechanism, you can find more details about Aura and BABE block authoring mechanism here and here
Block propagation
After blocks are authored and added to the local chain of the block author, they are distributed among all nodes in the network. This helps to facilitate a consensus on what the latest state of the blockchain is. The authored block is by default published to the network and can be imported by other nodes within the network.
Each node has an RPC endpoint dedicated to block import. This RPC endpoint is linked to a block import queue which listens for incoming blocks and adds these incoming blocks to the block pool. In the pool, each block header is verified against the extrinsic in the block, and invalid blocks are discarded. Verified blocks are subsequently added to the node's database of blocks.
Block propagation has complex implementation involving specific network modules for block gossiping and block verification. To customize how blocks are propagated in Substrate, you can modify consensus-specific network implementation. This means that customization of block propagation through the network is specific to a consensus mechanism. However, you can check out Substrate network configuration related to keeping peers in sync here.
Block importation, verification, and other node-specific block actions are
defined in the sc_consensus module
Summary
This brings us to the final part of from transaction to block. In this guide,
we develop a high-level understanding of how blocks are authored and gain
insight into how blocks are propagated and synced among nodes. We also
highlighted some of the components that can be customized to handle custom
block syncing operations.
To learn more about how transactions and blocks are handled in Substrate, check out these resources:
Help us measure our progress and improve Substrate in Bits content by filling out our living feedback form. Thank you!
