Part 6: Technical introduction - How is blockDAG getting PoW beyond its limits?

We need to ameliorate and continuously extend the dynamics of such a native protocol like the basic application of the longest chain rule, where is thinking that every system miner uses the network from their local point of view, where every miner typically sees one tip of the chain (or, in the case of a fork, sees multiple blockchain tips).

In the Bitcoin paradigm, the miner selects the winning tip and continues their mining on top of it while ignoring the rest. This leaves some space for improvement. For instance, you can't change this dynamic by simply telling the miners:

"No, no, please, do refer to all the tips that you see so that nobody's work is wasted, and let the protocol decide which one is the correct one that wins."

Then, you would not hide any information from the protocol, but you can still use the longest chain rule if you must stick to that concept.

Instead, The blockDAG paradigm is all about: "Hey, tell us about all the blocks that are mined in the PoW system, and let's start with all the tips that you see." Once we do that, we have already arrived at the directed acyclic graphs (DAG) paradigm.

If we have this idea in mind, let's add a visualization of this network's morphology on top of it.

Regarding blockchain growth, consider this analogy: Think back to the classic Snake game, where the blocky "snake" expanded horizontally after devouring its tetragonal prey. Blockchains expand over time in a very similar way, gradually increasing in length over time. Then, each new block refers back to the previous block.

Now, when it comes to DAGs, we introduce an additional dimension to this.
Imagine that it's not just about the length, as in the case of blockchains, but also the width, which represents all the branching paths, not unlike blockchain forks, complete with their interconnections.

Visualize this as the birds-eye view of a railway system, with multiple tracks forking and converging before arriving at the same station.

Do you have it? Good! Now, visit  Kaspa Graph Inspector and watch it for a while.

Now, the needed background to start observing blockDAG is this:

On the left side is the Genesis block, a starting point representing the simple block from which your network's history originated. Arrows in the diagram depict the graph's edges, pointing from new blocks back to their predecessors.

On the right side is the latest block, referencing all previously mined blocks. In the middle, you find all other blocks shaping the past and present of your network. Similar to the linear ordering of a blockchain, these blocks are arranged based on their creation times, with older blocks placed farther to the left.

When the blockchain/DAG visualization respects the chronological order from left to right, block referencing operates in the opposite direction. For instance, block 1 references the block it originated from, reaching out to the left, in this case, to block 0.

See how the new block in a DAG references all the preceding blocks.

In a DAG, the new block references do not look for the longest chain to select what tip they should point to. Instead, it references all possible tips of the DAG and all possible candidates visible in its reach. This goes alongside the core blockDAG idea, where the honest network blocks should be connected somehow. Since all honest miners communicate with each other and are not withholding blocks, their honest work should form a well-connected blockDAG.

In a blockDAG ledger, freshly minted blocks reference all unlinked tips within the graph, which are the blocks that have not yet been incorporated into the ledger according to what their miners perceive locally. Similar to a conventional blockchain, these blocks are promptly disseminated upon creation. Basically, you are connected to all the blocks in the DAG apart from k blocks, where k is proportional to the latency in the system, and it is an expected number of blocks that are mined in parallel.

A parameter 'k' controls the tolerance for simultaneously created blocks, allowing adjustments for higher throughput. When k=0, it means no forks, similar to Bitcoin's single chain and the longest chain structure.

From the morphology of the DAG, and I mean DAG of blocks, blocks in the DAG that result in a blockDAG, you can see that there are a lot of forks. These forks create the width of the DAG that is proportional to the system's latency. Also, the higher the block creation rate in the system, the more forks will be created, and the DAG will grow wider, where miners mine on top of other miners' blocks.

This element distinguishes the classical linear ordering of a blockchain with its longest chain rule, indicative of the hash rate majority, from blockDAGs' asynchronous and parallelizable PoW realm. It's crucial to note that both approaches ultimately have a linear aspect. However, blockDAGs require an additional ordering protocol to untangle and unveil the linear order, serving as the foundational element for every ledger.