In brief
Kaspa keeps nearby valid blocks in a blockDAG and uses consensus rules to reason about ordering and accepted effects.
First Contact#
A blockDAG is needed in this guide because proof of work networks can produce blocks close together. If education starts by pretending that only one clean chain exists at every instant, the reader has no place to put parallel blocks, selected parents, mergesets, or accepted transaction evidence.
Working Model#
Think of blockDAG as the structure that keeps block relationships visible. GHOSTDAG is the mechanism that helps the protocol reason over that structure. Virtual state is where selected-parent-chain changes are processed into consequences that tools can later observe.
The model stops being complete when it tries to decide exact ordering, blue work, mergeset details, or accepted transaction data without source review. Those belong in the consensus and core protocol pages.
Mechanics#
The guide's transition is:
blocks -> competing blocks -> linear-chain orphan pressure -> DAG structure -> ordering problem -> GHOSTDAG intuition -> selected parent and mergeset mechanics -> blue score/work -> Rusty Kaspa source walk
That sequence matters because it prevents two common mistakes. One mistake is calling the graph itself the ordering rule. Another is treating accepted transaction evidence as if it came directly from wallet submission rather than from consensus processing.
Expanded Problem Bridge#
The reason this guide introduces blockDAG early is that a linear-chain-only story cannot carry the rest of the Kaspa vocabulary. If the reader only has "one chain, one winner, discarded alternatives" as a model, then selected parent, mergesets, blue score/work, GHOSTDAG ordering, and virtual-state processing have nowhere natural to attach.
blockDAG should be understood first as structure: a graph of block relationships. That alone does not settle every ordering or acceptance question. GHOSTDAG belongs to the next layer because consensus has to reason over that structure. Virtual state belongs after that because accepted transaction evidence and UTXO changes are consequences of processing, not just visual features of a graph.
This bridge also protects against a common overclaim. Saying "blockDAG" does not by itself prove a transaction is accepted, prove an application state transition is safe, or prove an indexer representation is authoritative. Those claims must route into the transaction lifecycle, virtual state, accepted evidence, and source-path pages.
