Skip to content

Blocks

Introduction

In the Polkadot SDK, blocks are fundamental to the functioning of the blockchain, serving as containers for transactions and changes to the chain's state. Blocks consist of headers and an array of transactions, ensuring the integrity and validity of operations on the network. This guide explores the essential components of a block, the process of block production, and how blocks are validated and imported across the network. By understanding these concepts, developers can better grasp how blockchains maintain security, consistency, and performance within the Polkadot ecosystem.

What is a Block?

In the Polkadot SDK, a block is a fundamental unit that encapsulates both the header and an array of transactions. The block header includes critical metadata to ensure the integrity and sequence of the blockchain. Here's a breakdown of its components:

  • Block height - indicates the number of blocks created in the chain so far
  • Parent hash - the hash of the previous block, providing a link to maintain the blockchain's immutability
  • Transaction root - cryptographic digest summarizing all transactions in the block
  • State root - a cryptographic digest representing the post-execution state
  • Digest - additional information that can be attached to a block, such as consensus-related messages

Each transaction is part of a series that is executed according to the runtime's rules. The transaction root is a cryptographic digest of this series, which prevents alterations and enables succinct verification by light clients. This verification process allows light clients to confirm whether a transaction exists in a block with only the block header, avoiding downloading the entire block.

Block Production

When an authoring node is authorized to create a new block, it selects transactions from the transaction queue based on priority. This step, known as block production, relies heavily on the executive module to manage the initialization and finalization of blocks. The process is summarized as follows:

Initialize Block

The block initialization process begins with a series of function calls that prepare the block for transaction execution:

  1. Call on_initialize - the executive module calls the on_initialize hook from the system pallet and other runtime pallets to prepare for the block's transactions
  2. Coordinate runtime calls - coordinates function calls in the order defined by the transaction queue
  3. Verify information - once on_initialize functions are executed, the executive module checks the parent hash in the block header and the trie root to verify information is consistent

Finalize Block

Once transactions are processed, the block must be finalized before being broadcast to the network. The finalization steps are as follows:

  1. -Call on_finalize - the executive module calls the on_finalize hooks in each pallet to ensure any remaining state updates or checks are completed before the block is sealed and published
  2. -Verify information - the block's digest and storage root in the header are checked against the initialized block to ensure consistency
  3. -Call on_idle - the on_idle hook is triggered to process any remaining tasks using the leftover weight from the block

Block Authoring and Import

Once the block is finalized, it is gossiped to other nodes in the network. Nodes follow this procedure:

  1. Receive transactions - the authoring node collects transactions from the network
  2. Validate - transactions are checked for validity
  3. Queue - valid transactions are placed in the transaction pool for execution
  4. Execute - state changes are made as the transactions are executed
  5. Publish - the finalized block is broadcast to the network

Block Import Queue

After a block is published, other nodes on the network can import it into their chain state. The block import queue is part of the outer node in every Polkadot SDK-based node and ensures incoming blocks are valid before adding them to the node's state.

In most cases, you don't need to know details about how transactions are gossiped or how other nodes on the network import blocks. The following traits are relevant, however, if you plan to write any custom consensus logic or want a deeper dive into the block import queue:

  • ImportQueue - the trait that defines the block import queue
  • Link - the trait that defines the link between the block import queue and the network
  • BasicQueue - a basic implementation of the block import queue
  • Verifier - the trait that defines the block verifier
  • BlockImport - the trait that defines the block import process

These traits govern how blocks are validated and imported across the network, ensuring consistency and security.

Additional information

Refer to the Block reference to learn more about the block structure in the Polkadot SDK runtime.

Edit this page
Last update: November 22, 2024
| Created: October 16, 2024