Change the physics.
Watch what breaks.
Everything below runs in your browser from the same two parameters that constrain every real proof-of-work network: how fast blocks are produced, and how long they take to reach other miners. Turn the block rate up on a single-chain protocol and it starts bleeding orphans. Turn it up on a blockDAG and the structure just gets wider.
Mainnet is 10. Above roughly 25 the tip set gets wide enough that miner tip-selection strategy starts to matter.
How long before a published block is visible to other miners. A block cannot reference a tip it has not received.
The anticone width GHOSTDAG tolerates before colouring a block red. Only affects the DAG mode.
Post-Crescendo mainnet: 100 millisecond blocks. Several blocks are in flight simultaneously at all times.
Nothing is being discarded. Widening the DAG is how the protocol absorbs concurrency: blocks whose anticone exceeds k =18 are coloured red, which costs them security weight but not validity or inclusion. Try dropping k to single digits and watch honest, well-behaved blocks start turning red — that is why raising the block rate requires retuning k rather than just changing a timer.
Try to break it on purpose
The simulation is more useful when you are trying to make something go wrong. Each of these produces a result that explains a real design decision.
Raise the block rate on a single chain
Set the protocol to Single chain and drag the block rate to 40. The orphan share climbs past a third. Now consider that those orphans are not a bug being fixed — in a single-parent protocol there is nowhere to put them.
Starve k
Switch to GHOSTDAG, leave the rate at 10, and drag k down to 3. Perfectly honest blocks turn red because the concurrent set is wider than the protocol was told to tolerate. Red still settles — but weight is lost, and that is a security cost.
Wreck the network
Push propagation to 1200 ms at 10 blocks per second. Twelve blocks are now in flight before anyone sees the first. Both protocols degrade; only one of them keeps the work.
What this simulation is not
It is an illustration of the shape GHOSTDAG produces, not a reimplementation of it. Real GHOSTDAG computes anticone sizes across the entire DAG and orders blocks by a recursive blue-score rule; this canvas approximates colouring from the concurrent tip set so the visual reads correctly at interactive frame rates.
Three specific simplifications worth knowing. There is no difficulty adjustment, so the block rate is exactly what you set rather than an emergent average. Propagation is uniform — every node learns about a block after the same fixed delay, whereas real networks have a distribution with a long tail. And there is no adversary: nothing here withholds blocks or attempts a selfish mining strategy, which is precisely the case k is chosen to defend against.
If you want the real thing, the ordering rule lives in consensus/src/processes/ghostdag in the rusty-kaspa repository, and it is more readable than you would expect.
Change the physics.
Watch what breaks.
Everything below runs in your browser from the same two parameters that constrain every real proof-of-work network: how fast blocks are produced, and how long they take to reach other miners. Turn the block rate up on a single-chain protocol and it starts bleeding orphans. Turn it up on a blockDAG and the structure just gets wider.
Mainnet is 10. Above roughly 25 the tip set gets wide enough that miner tip-selection strategy starts to matter.
How long before a published block is visible to other miners. A block cannot reference a tip it has not received.
The anticone width GHOSTDAG tolerates before colouring a block red. Only affects the DAG mode.
Post-Crescendo mainnet: 100 millisecond blocks. Several blocks are in flight simultaneously at all times.
Nothing is being discarded. Widening the DAG is how the protocol absorbs concurrency: blocks whose anticone exceeds k =18 are coloured red, which costs them security weight but not validity or inclusion. Try dropping k to single digits and watch honest, well-behaved blocks start turning red — that is why raising the block rate requires retuning k rather than just changing a timer.
Try to break it on purpose
The simulation is more useful when you are trying to make something go wrong. Each of these produces a result that explains a real design decision.
Raise the block rate on a single chain
Set the protocol to Single chain and drag the block rate to 40. The orphan share climbs past a third. Now consider that those orphans are not a bug being fixed — in a single-parent protocol there is nowhere to put them.
Starve k
Switch to GHOSTDAG, leave the rate at 10, and drag k down to 3. Perfectly honest blocks turn red because the concurrent set is wider than the protocol was told to tolerate. Red still settles — but weight is lost, and that is a security cost.
Wreck the network
Push propagation to 1200 ms at 10 blocks per second. Twelve blocks are now in flight before anyone sees the first. Both protocols degrade; only one of them keeps the work.
What this simulation is not
It is an illustration of the shape GHOSTDAG produces, not a reimplementation of it. Real GHOSTDAG computes anticone sizes across the entire DAG and orders blocks by a recursive blue-score rule; this canvas approximates colouring from the concurrent tip set so the visual reads correctly at interactive frame rates.
Three specific simplifications worth knowing. There is no difficulty adjustment, so the block rate is exactly what you set rather than an emergent average. Propagation is uniform — every node learns about a block after the same fixed delay, whereas real networks have a distribution with a long tail. And there is no adversary: nothing here withholds blocks or attempts a selfish mining strategy, which is precisely the case k is chosen to defend against.
If you want the real thing, the ordering rule lives in consensus/src/processes/ghostdag in the rusty-kaspa repository, and it is more readable than you would expect.