-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathghostdag-explained.html
More file actions
195 lines (187 loc) · 14 KB
/
Copy pathghostdag-explained.html
File metadata and controls
195 lines (187 loc) · 14 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>GHOSTDAG Explained | Kaspa Explained</title>
<meta name="description" content="How GHOSTDAG orders parallel proof-of-work blocks in Kaspa's blockDAG, why losing blocks still count toward security, and what it doesn't buy you: instant finality.">
<meta name="robots" content="index,follow,max-snippet:-1,max-image-preview:large">
<link rel="canonical" href="https://kaspaexplained.com/ghostdag-explained">
<link rel="icon" href="kaspa-favicon.svg?v=20260512-real-k" type="image/svg+xml">
<link rel="icon" href="favicon.svg?v=20260512-k4" type="image/svg+xml">
<link rel="icon" href="favicon.ico" sizes="any">
<link rel="icon" href="favicon.png" type="image/png">
<link rel="apple-touch-icon" href="apple-touch-icon.png">
<link rel="manifest" href="site.webmanifest">
<meta name="application-name" content="Kaspa Explained">
<meta name="apple-mobile-web-app-title" content="Kaspa Explained">
<meta name="theme-color" content="#000000">
<meta property="og:title" content="GHOSTDAG Explained | Kaspa Explained">
<meta property="og:description" content="How GHOSTDAG orders parallel proof-of-work blocks in Kaspa's blockDAG, why losing blocks still count toward security, and what it doesn't buy you: instant finality.">
<meta property="og:type" content="article">
<meta property="og:url" content="https://kaspaexplained.com/ghostdag-explained">
<meta property="og:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Kaspa Explained - proof-of-work blockDAG guide">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="GHOSTDAG Explained | Kaspa Explained">
<meta name="twitter:description" content="How GHOSTDAG orders parallel proof-of-work blocks in Kaspa's blockDAG, why losing blocks still count toward security, and what it doesn't buy you: instant finality.">
<meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta name="dateModified" content="2026-07-25">
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is GHOSTDAG?",
"acceptedAnswer": {"@type": "Answer", "text": "GHOSTDAG is Kaspa's live ordering rule for its blockDAG. Instead of discarding blocks that lose the mining race, it classifies them into a blue set and gives every node the same procedure for ordering the whole graph."}
},
{
"@type": "Question",
"name": "Is GHOSTDAG the same as DAGKnight?",
"acceptedAnswer": {"@type": "Answer", "text": "No. GHOSTDAG runs on mainnet today. DAGKnight is a separate, later consensus design. It is research-stage: KIP-2 still reads Status: Proposed, and the implementation branch has not been touched since March 2026."}
},
{
"@type": "Question",
"name": "Does GHOSTDAG give instant finality?",
"acceptedAnswer": {"@type": "Answer", "text": "No. GHOSTDAG orders parallel blocks fast, but confirmation confidence still builds probabilistically as more blocks stack on top."}
}
]
}
</script>
<link rel="stylesheet" href="styles.css?v=20260725-rows-j">
<script defer src="nav.js?v=20260708-dark-default"></script>
</head>
<body>
<a class="skip-link" href="#top">Skip to content</a>
<header class="site-header">
<nav class="nav" aria-label="Primary">
<a class="brand" href="/" aria-label="Kaspa Explained home"><span class="brand-mark" aria-hidden="true"></span>Kaspa Explained</a>
<button class="nav-menu-button" type="button" aria-expanded="false" aria-controls="primary-links">Menu</button>
<div id="primary-links" class="nav-links">
<a href="/what-is-kaspa">What is Kaspa</a>
<a href="/status">Live now</a>
<a href="/kaspa-claims-checker">Check claims</a>
<a href="/skeptical-case">Risks</a>
<a href="/build-on-kaspa">Build</a>
<a href="/sources">Sources</a>
</div>
<button class="theme-toggle" type="button" aria-label="Switch theme">Light</button>
<a class="nav-cta" href="/toccata-status">Toccata status</a>
</nav>
</header>
<main id="top" tabindex="-1" class="knowledge-page">
<section class="sources-hero section">
<p class="eyebrow">Protocol explainer</p>
<h1>GHOSTDAG explained</h1>
<p class="lead">Kaspa's losing blocks still count toward security. GHOSTDAG is the rule that keeps them in the graph and turns a tangle of parallel proof-of-work blocks into one ordered history.</p>
</section>
<section class="section">
<p class="eyebrow">The setup</p>
<h2>Why Kaspa needs it</h2>
<div class="summary-grid grid-cards">
<article><span>Problem</span><p>Fast block times mean honest miners regularly find blocks within moments of each other.</p></article>
<article><span>Old shape</span><p>A single chain has to pick one branch. The losing branch's work gets thrown away as orphaned or stale.</p></article>
<article><span>Kaspa shape</span><p>A blockDAG keeps both blocks. Neither gets discarded.</p></article>
<article><span>Ordering rule</span><p>GHOSTDAG splits the graph into a blue set and a red set, then applies the same ranking procedure at every node.</p></article>
</div>
</section>
<section class="section prose-section">
<p class="eyebrow">Step one</p>
<h2>How a block gets colored</h2>
<p>A Kaspa block names its parents: every tip the miner could see when it started hashing. Those references are the whole data structure. Follow them backwards and you get a block's past, follow them forwards and you get its future, and everything left over is its <a href="/glossary#anticone">anticone</a>, the blocks that neither came before it nor after it. A single chain has no way to rank an anticone, which is why it discards one side of it.</p>
<p>GHOSTDAG ranks the anticone using one behavioral difference between honest miners and attackers. An honest miner publishes a block the second it is found, so within a propagation delay everyone else sees it and starts referencing it. Its anticone stays small by construction. A miner building a hidden history does the opposite: nobody can reference blocks they were never shown, so withheld blocks surface later carrying wide anticones. Secrecy has a shape, and the graph records it.</p>
<p>The coloring rule reads that shape. Kaspa has a security parameter, k, which caps how many blue blocks are allowed to sit in any blue block's anticone. A node starts from the heaviest tip and works through the graph, adding each candidate block to the <a href="/glossary#blue-red">blue set</a> only when adding it keeps every blue block under that cap. Blocks that break it get marked red. The parameter is derived from block rate and expected network delay, so a faster network needs a larger k for the same safety margin.</p>
<p>Red is not deletion. A red block keeps its place in the graph, keeps its parents, and keeps its transactions. What it loses is a vote in the weight comparison below.</p>
</section>
<section class="section prose-section">
<p class="eyebrow">Step two</p>
<h2>From a colored graph to one order</h2>
<p>Coloring alone gives no sequence, and payments need a sequence: if two transactions spend the same coin, one has to be first. GHOSTDAG builds that sequence from a spine. Each block picks the parent carrying the most accumulated <a href="/glossary#blue-work">blue work</a> as its <a href="/glossary#selected-parent">selected parent</a>, and chaining those choices together produces the selected parent chain, the closest thing Kaspa has to Bitcoin's longest chain.</p>
<p>The spine then absorbs everything hanging off it. Each block on the chain has a <a href="/glossary#mergeset">mergeset</a>: the blocks its parents saw that its selected parent's history did not already include. Those get ordered by the same procedure, blue blocks ahead of red ones, and appended in the spine's order. Walk the chain from the genesis block to the current tip and you have laid every block in the DAG, red ones included, into a single line.</p>
<p>Transactions are read off that line in order. The first spend of a coin wins and any conflicting spend later in the sequence is rejected, which is how a graph with no unique newest block still produces exactly one payment history. Every node runs the identical procedure over the identical DAG, so they all derive the identical order without voting, messaging, or a committee.</p>
<p>Blue work is also the tiebreak between competing histories. Bitcoin compares chains by accumulated work; Kaspa compares them by accumulated work in the blue set. An attacker whose blocks are colored red is spending real electricity that buys no weight in that comparison.</p>
</section>
<section class="section prose-section">
<p class="eyebrow">What you get</p>
<h2>What this buys, and what it doesn't</h2>
<p>Your transaction lands in a block fast, and confidence that the block stays blue builds as more blocks reference it. That is the payoff: parallel blocks stop being waste, so block rate can rise without the orphan rate eating the security budget.</p>
<p>Fast inclusion is not irreversibility. GHOSTDAG settles which blocks are blue and what order they sit in; it does not make a fresh transaction permanent, and confirmation confidence still climbs probabilistically as work accumulates. <a href="/kaspa-confirmations-finality">Confirmations and finality</a> covers how deep to wait and why.</p>
</section>
<section class="section">
<p class="eyebrow">Common mix-ups</p>
<h2>What GHOSTDAG is not</h2>
<div class="table-wrap">
<table class="reality-table">
<thead><tr><th>Question</th><th>Answer</th><th>Best wording</th></tr></thead>
<tbody>
<tr><td>Is GHOSTDAG live?</td><td><span class="status-pill live">Live</span></td><td>GHOSTDAG is Kaspa's live blockDAG ordering rule.</td></tr>
<tr><td>Is it DAGKnight?</td><td><span class="status-pill not-live">No</span></td><td>DAGKnight is a separate, later consensus design.</td></tr>
<tr><td>Does it remove finality risk?</td><td><span class="status-pill not-live">No</span></td><td>Inclusion is fast. Confirmation confidence is still probabilistic.</td></tr>
<tr><td>Does it mean unlimited TPS?</td><td><span class="status-pill not-live">No</span></td><td>Throughput is bounded by block capacity, mempool policy, fees, and demand.</td></tr>
</tbody>
</table>
</div>
</section>
<section class="next-step section">
<p class="eyebrow">Sources</p>
<h2>Check it yourself</h2>
<p>Kaspa Research has the protocol lineage and Rusty Kaspa is the code that runs it, including the current value of k and the rest of the consensus parameters. The <a href="/sources#learn-kaspa">source list</a> collects the term-by-term references for anticone, mergeset, k-clusters, blue score, and blue work.</p>
<div class="actions">
<a class="button primary" href="https://research.kas.pa/">Kaspa Research</a>
<a class="button" href="https://github.com/kaspanet/rusty-kaspa">Rusty Kaspa</a>
<a class="button" href="/kaspa-confirmations-finality">Confirmations and finality</a>
</div>
</section>
<!-- related-links:start -->
<section class="section site-related" aria-labelledby="related-links-title">
<p class="eyebrow">Keep reading</p>
<h2 id="related-links-title">Next pages</h2>
<div class="site-related-grid">
<a href="/kaspa-confirmations-finality"><span>Previous</span><strong>Fast is not final.</strong><p>A transaction can land in a block in under a second on Kaspa. It still isn't final the moment it lands. How GHOSTDAG ordering, 10 BPS, and...</p></a>
<a href="/faq"><span>Next</span><strong>Kaspa questions, answered</strong><p>Direct answers to common Kaspa questions: Toccata, DAGKnight, smart contracts, TPS, 10 BPS, GHOSTDAG, blockDAG, vProgs, and RTD.</p></a>
<a href="/status"><span>Status</span><strong>Kaspa current status</strong><p>What is live, targeted, roadmap, and research on Kaspa right now, checked against mainnet, releases, and KIPs.</p></a>
</div>
</section>
<!-- related-links:end -->
</main>
<footer class="footer">
<div class="footer-grid">
<p><strong>Independent Kaspa explainer.</strong> Claims are labeled live, targeted, roadmap, research, unsupported, or wrong. Not investment advice.</p>
<nav class="footer-nav-groups" aria-label="Footer">
<div class="footer-link-group" aria-label="Learn">
<span>Learn</span>
<a href="/start-here">Start here</a>
<a href="/what-is-kaspa">Kaspa 101</a>
<a href="/overview">90-second overview</a>
<a href="/glossary">Glossary</a>
</div>
<div class="footer-link-group" aria-label="Verify">
<span>Verify</span>
<a href="/status">Status</a>
<a href="/kaspa-claims-checker">Claims checker</a>
<a href="/toccata-status">Toccata status</a>
<a href="/skeptical-case">Skeptical case</a>
<a href="/sources">Sources</a>
</div>
<div class="footer-link-group" aria-label="Build">
<span>Build</span>
<a href="/build-on-kaspa">Build on Kaspa</a>
<a href="/builder-guide">Builder guide</a>
<a href="/kaspa-app-ideas">App ideas</a>
</div>
<div class="footer-link-group" aria-label="Site">
<span>Site</span>
<a href="/search">Search</a>
<a href="/about">About</a>
<a href="/about#corrections">Corrections</a>
</div>
</nav>
</div>
</footer>
</body>
</html>