Consensus, GHOSTDAG, And blockDAG

What this page explains#

Build the bridge from public Kaspa descriptions into GHOSTDAG, virtual state, and source-level consensus review. This page sits in Consensus, GHOSTDAG, And blockDAG. It gives the topic a plain-language handle first, then shows the working idea, the mechanism, the source trail, and any limits that still matter. This category explains how Kaspa reasons about many blocks without pretending the graph itself is enough. The flow moves from graph shape, to GHOSTDAG classification and ordering, to virtual state and accepted transaction evidence.

The writing follows a simple Kaspa documentation pattern: answer the practical question first, then link outward for details. The closest public sources for this page are WIKI-KASPA, WIKI-BLUE-SCORE, WIKI-MERGING-REWARDS, WIKI-THEORETICAL-TOPICS, RK-GHOSTDAG. Local notes can help choose what to explain, but public-facing references resolve to upstream websites, repositories, papers, release pages, or docs.

How to think about it#

The practical model starts by naming the layer that owns the topic: wallet use, node operation, consensus, transaction validation, Toccata script behavior, tooling, or research. From there, the page shows which public source can support the explanation and where the explanation becomes incomplete.

For Consensus, GHOSTDAG, And blockDAG, the model is built around these anchors: Kaspa blocks can reference multiple direct parents, forming a blockDAG; GHOSTDAG selected-parent, ordering, and mergeset behavior must be separated from the graph shape itself; Blue score, blue work, and header checks are current implementation claims when source-backed; PHANTOM, GHOSTDAG papers, and DAGKnight material remain research context unless implementation and release evidence support stronger wording; Virtual processing and accepted data are the bridge from ordered DAG consequences to transaction-state evidence. This model is useful, but it does not encode every constant, branch, error type, or edge case. Those details belong in the source path and the source notes.

How it works#

1. Kaspa blocks can reference multiple direct parents, forming a blockDAG. Consensus pages separate graph structure, ordering, work signals, and state consequences. A claim in this section is useful only when it says whether the source is describing the DAG shape, GHOSTDAG classification, selected-parent context, virtual-state processing, or research background.

2. GHOSTDAG selected-parent, ordering, and mergeset behavior must be separated from the graph shape itself. A mergeset is the part of the DAG brought into view by a block beyond the selected-parent path. It matters because Kaspa is not merely following a single chain tip; it is deciding how parallel work is incorporated. When explaining mergesets, keep the graph relationship, ordering consequence, and transaction consequence separate so app pages do not treat every visible block as immediate accepted state.

3. Blue score, blue work, and header checks are current implementation claims when source-backed. Blue/red vocabulary belongs to consensus classification, not user reputation or transaction success. Blue score and blue work are progress signals inside the consensus view. They are useful for understanding chain progress and ordering context, but wallet, indexer, and app pages still need accepted-transaction or UTXO evidence before claiming a spend has taken effect.

4. PHANTOM, GHOSTDAG papers, and DAGKnight material remain research context unless implementation and release evidence support stronger wording. Readiness pages are evidence gates. A testnet result is useful only with network name, date, release or branch, node/wallet/tool versions, and accepted evidence. Release notes and source paths support stronger claims; old testnet observations remain historical unless refreshed.

5. Virtual processing and accepted data are the bridge from ordered DAG consequences to transaction-state evidence. Virtual state is the bridge from ordered consensus consequences into the state surfaces that tools can inspect. Mempool visibility says a node is considering a transaction; accepted evidence says the transaction was incorporated through consensus processing. UTXO diffs, accepting data, and indexer replay are the review trail for applications that need durable state.

This mechanism section separates graph structure, GHOSTDAG classification, selected-parent context, ordering consequences, and virtual-state effects. A diagram or summary can orient the reader, but implementation paths and KIPs carry high-risk claims.

How to check it#

When using this page for consensus explanation, identify whether the claim is about graph shape, GHOSTDAG classification, selected-parent context, virtual-state processing, or transaction consequences. Diagrams are orientation aids; source paths and KIPs carry the high-risk behavior claims.

Expanded Category Guide#

This category carries the consensus learning ramp: proof of work, blockDAG structure, GHOSTDAG reasoning, selected parent, mergesets, blue score/work, virtual state, and research-edge boundaries.

Use this category as a curated path. Start with the category README to understand the boundary, then read the mechanism pages, then follow source-path or open-gap pages for claims that need stronger evidence. If a page contains needs checking rows, keep those claims visibly unresolved until a reader reads the cited public source directly.

The category should not be treated as final authority by folder name alone. The authority comes from page Source Notes, Source Lists, public URLs, and the status labels attached to each claim.

Related Pages#

• consensus-blockdag-ghostdag
• blockdag-model

Topic pages#

• blockDAG Model: A blockDAG starts from the simple fact that valid blocks can be found close together, but it does not remove the need for a consistent ordering rule.
• PHANTOM And GHOSTDAG: PHANTOM and GHOSTDAG belong in the research-to-implementation bridge: the paper motivates the model, and Rusty Kaspa closes current behavior.
• GHOSTDAG Mechanics: This page explains selected parent, mergesets, blue/red classification, blue score, and blue work as connected mechanics.
• Selected Parent And Mergesets: Selected parent and mergesets are the first place where DAG intuition becomes source-level mechanics.
• Blue Score And Blue Work: Blue score and blue work are progress indicators in the consensus view and need careful explanation before apps use them.
• Virtual State And Accepted Transactions: Virtual state is where ordered consensus consequences become transaction and UTXO evidence for tools and applications.
• DAGKnight Research Edge: DAGKnight belongs in research edge unless current implementation and release evidence supports stronger status.
• Consensus FAQ And Failure Modes: This question-led page corrects common misreadings: DAG does not mean no ordering, selected parent is not the whole state story, and mempool visibility is not accepted evidence.

Topic notes#

This category is accepted when the subpages explain the actual topics, not merely the source links. Each subpage carries public source IDs, claim labels, Open Questions, and a path from first contact into source review.