In brief
Kaspa keeps nearby valid blocks in a blockDAG and uses consensus rules to reason about ordering and accepted effects.
What this page explains#
PHANTOM and GHOSTDAG belong in the research-to-implementation bridge: the paper motivates the model, and Rusty Kaspa closes current behavior. 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 PAPER-GHOSTDAG, WIKI-BACKGROUND, RK-GHOSTDAG, RK-GHOSTDAG-ORDERING, RK-GHOSTDAG-MERGESET. 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 PHANTOM And GHOSTDAG, the model is built around these anchors: paper vocabulary helps describe why honest parallel blocks matter; Rusty Kaspa implementation paths support current GHOSTDAG ordering and mergeset behavior; paper examples are simplified compared with node processing; deployment claims need implementation or release evidence; research context remains labeled research when it is not current code. 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. paper vocabulary helps describe why honest parallel blocks matter. 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. Rusty Kaspa implementation paths support current GHOSTDAG ordering and mergeset behavior. 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. paper examples are simplified compared with node processing. A node is useful only after its network, peer, sync, and index assumptions are understood. Process uptime is not the same as useful state. P2P handshake, IBD progress, logs, ports, and optional indexes each answer a different operator question, so troubleshooting starts by locating the failed layer rather than retrying commands blindly.
4. deployment claims need implementation or release evidence. 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. research context remains labeled research when it is not current code. 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.
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#
| Step | Check | Evidence gate |
|---|---|---|
| 1 | Check paper vocabulary helps describe why honest parallel blocks matter. | Read PAPER-GHOSTDAG, WIKI-BACKGROUND, RK-GHOSTDAG; distinguish graph shape, ordering, selected-parent context, and accepted-state consequences. |
| 2 | Check Rusty Kaspa implementation paths support current GHOSTDAG ordering and mergeset behavior. | Read PAPER-GHOSTDAG, WIKI-BACKGROUND, RK-GHOSTDAG; distinguish graph shape, ordering, selected-parent context, and accepted-state consequences. |
| 3 | Check paper examples are simplified compared with node processing. | Read PAPER-GHOSTDAG, WIKI-BACKGROUND, RK-GHOSTDAG; distinguish graph shape, ordering, selected-parent context, and accepted-state consequences. |
| 4 | Check deployment claims need implementation or release evidence. | Read PAPER-GHOSTDAG, WIKI-BACKGROUND, RK-GHOSTDAG; distinguish graph shape, ordering, selected-parent context, and accepted-state consequences. |
| 5 | Check research context remains labeled research when it is not current code. | Read PAPER-GHOSTDAG, WIKI-BACKGROUND, RK-GHOSTDAG; distinguish graph shape, ordering, selected-parent context, and accepted-state consequences. |
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.
Related Pages#
- blockdag-model
- consensus-blockdag-ghostdag
- ghostdag-mechanics