blockDAG To GHOSTDAG To Virtual State

First Contact#

blockDAG is the structure. GHOSTDAG is the consensus mechanism studied over that structure. Virtual state is where selected-parent-chain changes become accepted consequences.

Working Model#

This bridge keeps three questions apart: what is the graph, how does consensus reason about ordering, and what state consequences become visible afterward. The first-contact model is enough to navigate the guide. The implementation page is needed for exact algorithm and storage behavior.

Expanded Consensus Bridge#

This bridge carries the reader from structure to consequences. blockDAG gives the guide a way to talk about multiple blocks and their relationships. GHOSTDAG gives the guide the consensus topic for reasoning over that graph. Virtual state gives the guide a place to talk about accepted consequences and state updates.

The three layers should not be collapsed. If the claim is about graph shape, the blockDAG vocabulary is relevant. If the claim is about ordering, selected parent, mergesets, or blue work, the GHOSTDAG and consensus source paths matter. If the claim is about accepted transactions or UTXO diffs, virtual processing and acceptance data matter.

The reader should leave this page knowing which layer owns the next question. That prevents a visual blockDAG explanation from being stretched into a source-level implementation claim, and it prevents virtual-state consequences from being treated as simple wallet or explorer events.

Use the bridge as a diagnostic checklist. If a paragraph says "blockDAG", ask whether it means graph structure or ordering. If it says "GHOSTDAG", ask whether it is using paper-level research language or implementation source behavior. If it says "virtual state", ask what accepted consequence is being described and which source path supports it. The page is successful when it narrows the next source question instead of making the topic feel complete too early.