LogoLogo
  • Introduction
  • BSV Blockchain
    • Blocks
    • Transactions
    • Proof of Work
    • Capabilities
    • Economic Model of Governance
    • Digital Asset Recovery
  • Network Policies
    • High-Level Architecture
    • Mining
    • Standard and Local Policies
    • Consensus Rules
    • Local Policies
  • Node Operations
    • Node Software
    • Bitcoin Server Network (BSN)
    • ChainTracker
    • Transaction Validation
    • UTXO Storage
    • Mempool
    • Block Assembler
    • Block Validation
    • Mining Software
    • Pruning transactions
    • Responsibilities of a Node
  • Light Clients and SPV Processes
    • Simplified Payment Verification (SPV)
      • Proof of Publication in a block
      • Instant Payments
      • Proof of Integrity
    • Light Clients in Blockchain
  • Transaction Lifecycle
    • Transaction Inputs and Outputs
    • Script
    • Transaction Flow
    • Constructing a transaction
    • Sequence Number and Time Locking
    • Transaction Templates
    • Transaction Processing
    • Opcodes used in Script
  • Privacy
    • Keys and Identity
    • Private vs Anonymous
    • Digital Signatures
    • Privacy in Public Blockchain
Powered by GitBook
On this page
  1. Node Operations

Block Assembler

Transactions are "assembled" into a Merkle tree structure to provide the mining software a candidate block header.

PreviousMempoolNextBlock Validation

Last updated 1 year ago

The main purpose of the Block Assembler is to take the list of validated transactions stored by Mempool for its consumption and creates a fresh block template data structure to add transactions. It orchestrates block-template creation by talking to Chain tracker, Mempool and UTXO Store. It also performs basic checks on transactions before they are made part of the block template, including updating the transactions and UTXO status.

The ChainTracker provides the Block Assembler with the current Chain-tip. The Assembler then builds a new block on that tip by first fetching all the verified transactions present in the mempool. It then constructs the Merkle root value by ordering all the transactions in first-seen order and building a Merkle tree root value from the transaction ids. Once the value is calculated, it will construct the block header based on the current difficulty value.

In parallel, the mining pool software is constantly communicating with the Assembler to keep retrieving the latest mining candidate. It will keep responding to the mining pool calls and keep providing it with updated block candidate headers and mining candidate values (see mining topic for more details).