Kaspa consensus · real blocks and a teaching model, in your browser

DAGKnightthe consensus that measures the network instead of guessing it.

connecting to Kaspa mainnet…

The blocks below are real: Kaspa mainnet, arriving as the network makes them. Scroll, and they explain the DAGKnight paper one idea at a time: what a block cannot see, what the famous k is, why a fixed k fails both ways, and how DAGKnight finds k on its own. Where the story needs a slower network or an attacker, it switches to a simulation and says so.

start the story skip to the lab the paper ↗

scroll

01 · a blockDAG

In Kaspa, no block is thrown away.

In Bitcoin, two blocks found at the same moment race, and one is orphaned. Kaspa keeps both: every new block points back to all the blocks its miner has heard of that nothing points to yet. Parallel blocks merge instead of dying, and the chain of blocks becomes a blockDAG.

Each curve is one of those references. The bright line is the chain the protocol follows. It ends in the virtual block, the paper's name for the next block every honest miner is building.

… · … blocks a second

02 · past, future, anticone

What a block could not see.

Follow the white block. The cone behind it is its past: every block it points back to, directly or not. It saw those. The cone ahead is its future: every block that points back to it.

The amber blocks between the cones are its anticone. They were mined in the same moments, elsewhere on the network: it never saw them, they never saw it, and nothing in the DAG says which came first.

anticone of the white block: … blocks · …

03 · delay

The slower the network, the bigger the blind spot.

Blocks take time to cross the internet. The longer the delay D, and the more blocks a second (λ), the more of them are mined blind to each other: an honest block's anticone holds about 2Dλ blocks.

From here the stage is a simulation, at 3 blocks a second: it slows the network down and brings in attackers, which nobody can do to mainnet. The delay now breathes between 0.2 and 2.8 seconds. Watch the amber grow and shrink with it.

network delay … · anticone … blocks

04 · k

k is how much blindness is forgiven.

The number over each block counts the blue blocks in its anticone. The paper's first definition: a set of blocks is a k-cluster when no block in it misses more than k of the others.

Honest miners publish at once, so their blocks miss only a few. A block mined in hiding misses everything published meanwhile. So the largest k-cluster is the honest network: GHOSTDAG, which runs Kaspa today, colours it blue (inside the glass tube), leaves the rest red outside, and follows it. Here k = 5, enough for this network: almost every honest block is blue.

05 · GHOSTDAG

GHOSTDAG picks k once, before launch.

k must be chosen for the worst network the chain will ever see. Kaspa uses k = 124 at ten blocks a second, sized for delays of up to five seconds. This model uses k = 3.

Watch the delay rise. When the network gets slower than k allows for, honest blocks miss more than k others and fall out of the blue set. The fewer honest blocks count as blue, the slower the honest chain gains weight, and the smaller the attacker that can overtake it.

delay … · blue: … of recent blocks

06 · too small a k

The hidden chain wins.

A 40% attacker forks off the chain and mines in secret for 14 seconds, below the DAG. Its private chain is perfectly tidy: every block saw the one before.

At 2.5 seconds of delay the honest blocks are not tidy, and with k fixed at 3 too few of them count. When the attacker publishes, GHOSTDAG can follow its chain: less than half the hashrate rewrote the order.

…

07 · too big a k

The freeloader slips in.

Now the network is fast, but k was set for a slow one: 12. A 35% attacker builds on the DAG as it stood a second ago and holds each block back a moment.

Each of its blocks misses several honest ones: far too many for a network this fast, but fewer than 12. So GHOSTDAG counts them as honest and orders them among blocks they never saw. This is the attack of the paper's figure 5.

…

08 · DAGKnight

Let the DAG choose k.

DAGKnight asks, for k = 0, 1, 2 and up: how large is the largest k-cluster? It keeps the first k whose cluster covers at least half the DAG (section 2.3 of the paper).

Honest miners hold the majority, so their blocks can always form such a cluster (the paper's figure 1). Stopping at the smallest k that reaches half tolerates just the latency the network has: a small k when it is fast, a larger one when it is slow. Nobody tells it the delay; it reads it from the blocks. The bars top right are the search.

delay … · DAGKnight's k = …

09 · side by side

Same blocks, two rules.

Left: GHOSTDAG with k fixed at 3. Right: the very same DAG, block for block, coloured by DAGKnight's search. The hidden-chain attacker comes back round after round, at 2.5 seconds of delay.

…

10 · and the other way round

No fixed k gets both right.

A fast network, the freeloader, and k fixed at 12 on the left: its violet blocks sit inside the blue tube. On the right the search found a small k, and they stay outside it.

k = 3 loses the slow network; k = 12 lets the freeloader in. The search handles both, because it never assumed a network in the first place.

…

11 · why they usually look the same

On a healthy network, they agree.

Back to real blocks. On a network like this one the two rules colour almost every block the same way: the paper notes that when the delay is steady, KNIGHT coincides with PHANTOM, the rule GHOSTDAG approximates. What differs is the k each one works with.

Right now each mainnet block is blind to about … others, at most …. GHOSTDAG works with k = 124, set for a five-second worst case, and the paper points out that a protocol with a fixed parameter confirms at the pace of that worst case even when the network is fast. The search, run by this page on these same blocks, stops at k = ….

…

12 · why it matters

Confirmations follow the network, not its worst day.

A fixed k makes every confirmation wait as if the network were always at its worst. DAGKnight's waits follow the delay an attacker could cause now: in the paper's figure 3, at 3.75 blocks a second, a 2-second network means k = 4 and 12 seconds to confirm, 0.1 seconds means k = 0 and 1.2 seconds.

And when the network is worse than anyone planned for, it keeps working, only slower.

drive it yourself the full protocol

Chapter 01 · your turn

Drive the network.

Set the delay, set GHOSTDAG's k, launch either attacker, and watch both rules decide. Drag the stage to take the camera; the director takes it back after a few seconds, or pick free.

the chain
blue, in the cluster
red, outside it
the attacker's
virtual block

blocks

colouring rule

network delay1.0 s

GHOSTDAG's fixed k 3

speed

camera

attackers

The simulation is a teaching model, not the protocol. GHOSTDAG's greedy colouring stands in for the largest k-cluster, and "DAGKnight" here is the paper's optimisation idea (section 2.3): the smallest k whose cluster covers at least half of the recent DAG (the last 20 seconds of blocks, or everything after the attacker's fork point once its chain is public). The real protocol decides conflict by conflict with ranks, tie-breaking and a cascade vote (Algorithms 2 to 6, below), and is being built on the dagknight branch. Live blocks come from kascov's own Kaspa node, coloured by that node's GHOSTDAG; on them the delay, k and attacker controls do nothing, since nobody can steer a real network.

Chapter 02 · the full protocol, in plain words

From the idea to the algorithm.

The search above is the paper's Algorithm 1, and the paper says plainly it is not enough: it is safe only when latency is constant and the attacker naive, and finding the largest k-cluster exactly is NP-hard. The full protocol keeps the idea and applies it where it matters, one disagreement at a time.

Algorithm 2 · orderingConflict by conflict
The ordering walks the chain splits from oldest to newest. At each split, the latest common chain ancestor g of the competing tips, it decides between the groups of tips that agree on what comes after g, and repeats until one tip remains: the selected tip.
Algorithm 3 · rankThe smallest k that wins a majority
A group's rank is the smallest k at which one of its representative blocks has a k-cluster that uniformly covers a majority of the DAG outside its own future. The lowest rank wins the split: min k, max cluster, applied to one conflict.
Algorithm 5 · k-colouringClusters built like GHOSTDAG's
The cluster for a given k is built recursively, the way GHOSTDAG colours blocks. A block may take its cluster from a parent that disagrees with it only under conditions the paper spells out, for instance when that parent's rank is lower than its own.
Algorithm 6 · UMC votingA majority, everywhere
"Covers a majority" must hold uniformly: for every block in the set, at least as many of the blocks in its future lie inside the set as outside it, with a slack of g(k) = ⌊√k⌋. One pass from the tips back to g checks it, each block voting between −1 and 1. The paper credits SPECTRE's cascade voting for the idea; our soak recomputes every one of these votes.
Algorithm 4 · tie-breakingWhen ranks are equal
If groups share the lowest rank, each candidate chain is compared against a small reference cluster for k′ from ⌊k/2⌋ up to k, counting the blocks that sit too far from it. The group with the smallest worst case wins; a hash settles exact ties.
Sections 1.4 and 1.5 · the fine printFast, but not magic
No protocol that tolerates a 50% attacker can confirm at the speed the network merely looks like it has (Pass and Shi). DAGKnight follows the worst delay an attacker could cause right now, and each client sets that bound for itself when it confirms. The ordering assumes no delay bound at all; like any proof of work, it still assumes an attacker below half the hashrate.

And 100 blocks a second?

DAGKnight does not choose the block rate: Kaspa went from one block a second to ten with Crescendo. What it changes is the price of a high rate. GHOSTDAG sizes k for a five-second worst case, so k grows with the block rate, and confirmations wait as if the network were always that slow:

181 block/s, Kaspa at launch
12410 blocks/s, Kaspa today
36232 blocks/s
1,074100 blocks/s

DAGKnight reads k from the DAG itself, so its confirmations follow a delay bound each client sets for the network as it is now, instead of a worst case written into the protocol. The paper's figure 3, simulated at 3.75 blocks a second:

k = 42 s delay · 12 s to confirm
k = 11 s delay · 6 s to confirm
k = 00.1 s delay · 1.2 s to confirm

GHOSTDAG's k for each rate, from rusty-kaspa's own calculate_ghostdag_k: a 5-second delay bound and a 1% tail. The 100 blocks/s value is computed in log space, because the function's e⁻¹⁰⁰⁰ underflows a 64-bit float. At high rates the limits that remain are bandwidth and hardware.

Chapter 03 · one question, four answers

What happens when blocks come faster than the network can agree?

2013
GHOST
Yonatan Sompolinsky and Aviv Zohar: follow the heaviest subtree instead of the longest chain, so fast blocks stop wasting security. Ethereum's uncle blocks grew out of this idea. the paper ↗
2016
SPECTRE
Yonatan Sompolinsky, Yoad Lewenberg and Aviv Zohar: blocks vote on the order of the blocks around them. Enough for payments, not a full order of every transaction, but its cascade of votes comes back years later, inside DAGKnight. the paper ↗
2018
PHANTOM and GHOSTDAG
Blocks stop racing each other. Parallel blocks all land in a DAG and get ordered instead of orphaned; GHOSTDAG is the greedy, practical form. the paper ↗
2021
Kaspa
Kaspa launches on GHOSTDAG in November, with no premine, at one block per second.
2022
DAGKnight, on paper
GHOSTDAG fixes a number, k, from an assumed worst-case network delay. Assume too little and security suffers; assume too much and confirmation slows. DAGKnight reads the delay from the DAG itself and adapts: parameterless, in the paper's own title. Its February 2023 update added figures and an overview, and it is the version the branch implements, algorithm by algorithm. the paper, PDF ↗
2025
Crescendo
Kaspa goes from one block per second to ten.
now
DAGKnight, in code
The implementation is being written in the open on the dagknight branch. The rest of this page follows it.

Chapter 04 · from kascov's own index

GHOSTDAG, measured.

A reorg is the chain tip moving to a competing branch: kascov rolls back what it applied and follows the new one. These are the last 500 reorgs kascov applied on each network, and what its chain guard saw. GHOSTDAG follows the most blue work, so a reorg almost never lands on a tip with a lower blue score. DAGKnight picks the chain by rank, the smallest k at which a cluster passes its vote, and can, so kascov counts those separately.

mainnet

loading /data/mainnet/reorgs.json…

testnet-10

loading /data/testnet-10/reorgs.json…

DAGKnight

When DAGKnight runs on a public network, kascov follows it and its reorg profile appears here, measured the same way, beside GHOSTDAG's.

Chapter 05 · simulations we ran

The new code, under load.

simpa, Kaspa's network simulator, built from the dagknight branch with its baseline-debugging feature: every vote DAGKnight takes is also computed by a direct implementation of the paper's Algorithm 6, the UMC cascade vote, and any difference stops the run. We added one more check: after each run a fresh node validates the whole DAG again, in a different order, and both must end on the same chain tip.

loading /dagknight-soak.json…

Chapter 06 · the public branch

Where the code is moving.

The dagknight branch of kaspanet/rusty-kaspa, against master. Areas come from the tags on each commit, in plain words. A snapshot, read by kascov and served from here, so your browser never calls GitHub.

loading /dagknight-branch.json…