Fork type 5 is the last known unresolved fork cause in the Lisk network and important enough that it got its own logo. A fork of type 5 can occur when two different valid blocks of the same height with the same parent propagate across the network. This happens in two different ways: the first situation occurs when one delegate forges with more than one node. The second situation happens when two different delegates forge at the same height because the original delegate did not propagate the block to the next forger in time.

Propagation of the newly forged block from node e: not every node receives the block

Let’s review the concept of block propagation in a peer-to-peer network. We use a gossip protocol that broadcasts any new block to a fixed number of available nodes (peers). In this example every node broadcasts the new block R (red) randomly to up to 2 peers. This is very fast (after 5 broadcasting steps about 90 % of the network is covered) but not every node receives the block.

The fact that a block is not pushed to every node is not a problem because those nodes will recognize that their peers have additional blocks and download those blocks proactively. But for now we only look at the gossip push coverage.

Now we release a second competing block B (blue) into the network. R and B are both valid, of the same height and share the same parent. Furthermore, let’s assume B beats R.

Competing blocks R (red) and B (blue) are distributed in the network

All nodes agree by a hard coded relation that B beats R, so every node that sees both blocks is on the same page. But since propagation of B covers other nodes than propagation of R due to the random factor, there are nodes that know about R but not about B (see node n and p in the example above).

If node p was the next forging delegate, it would build the next block based on R, while the rest of the network agreed that R is not part of the blockchain. A fork would be created.

Node d does not know about any of the new blocks, which is not a problem. It will recognize it is behind and can catch up easily.

This is state of the art as described by Isabella in September 2017.

Gossip correction

Assume Alice tells a story to Bob, Charles and Dave and Charles blindly believes it and tells that story to Eduard, Frank and Gina. Now it turns out the story was a lie and Charles wants to resolve the situation. First of all, he tells Alice, because he got the false story from her and believes she told it to others as well. Next, Charles reaches out to everyone who he told the wrong story and corrects it by telling the right version. Following this pattern, very quickly everyone who ever got the wrong story will also know the correct one while people who don’t know any version of the story are left out.

This is what I refer to as gossip correction and what helps us to efficiently override falsehoods in a peer-to-peer network.

The unique gossip graph

While the peer-to-peer network itself is a graph including loops, the propagation of a block across that network has more structure: it is a directed rooted tree. I call this the unique gossip graph.

Gossip spread in the network (left) and unique gossip graph (right)

In the unique gossip graph, every node that heard about the news (a new block) is added only for the event when it first received the news. Thus a node is contained once or not at all in the unique gossip graph (e.g. nodes d and k are not included).

Since the unique gossip graph is a tree, every node except the root has a parent and an arbitrary amount of children. A single node does not have the full picture of the unique gossip graph.

Traversing the unique gossip graph

As soon as an arbitrary node x in the unique gossip graph receives a second block B that beats the existing block R for the first time, the new block must be propagated within the unique gossip graph to ensure that every node that knows about R also knows about B. The correction algorithm works as follows:

x sends the new block to its parent, if any. x sends the new block to all its children.

Now for every node that receives a new block, perform the correction recursively.

Block B (blue) overrides block R (red) by traversing the unique gossip graph

The order of those steps matters when the gossip correction should be done as fast as possible. Since the impact of the correction is higher the nearer you are to the root, propagating up is done before propagating down.

Since only the knowledge of the parent and direct children is required, the algorithm can be performed by the individual nodes without having a complete picture of the gossip graph.

Given a unique gossip graph has n levels, maximal number of steps to traverse the whole graph is 2n: n steps to go up to the root and n steps to reach all bottom nodes.

Missing nodes

For now the gossip correction algorithms assumed that every node that took part in the original gossip is available for the correction. But a node may either become unavailable, run an old node software that does not support correction or is malicious and thus does not perform correction.

Node o is missing for gossip correction and splits the gossip graph into 3 parts. Only 2 of the 3 parts receive the correction

Every missing node cuts the gossip graph into multiple parts. For every part the gossip correction algorithm is performed separately as soon as the stronger block is seen by any node in that part. This leads to the following cases:

A gossip graph part receives the stronger block A gossip graph part does not receive the stronger block and contains no active delegate A gossip graph part does not receive the stronger block and contains an active delegate

Case 1 leads to the proper correction and everything is fine. Case 2 leads to some nodes having a false top block, which will be replaced sooner or later. Case 3 allows the next forging delegate to built on top of the wrong block, which can cause a fork again.

The bigger the gossip graph part gets, the lower the likelihood of a fork.

K: likelihood of the event that one given node receives the weaker block only

p(K, n) = K^n: likelihood that in a gossip graph part of n nodes, every node receives the weaker block only

For example (trying to use realistic values but still they come out of thin air): assume for any node the probability to receive a new block within 2 seconds is 90 % and further assume there are two competing blocks. Then K = 0.9 * (1-0.9) = 0.09. Now further assume the node’s gossip graph part contains 5 nodes. This gives you a probability of p(0.09, 5) = 0.09⁵ = 5.9/1000000, i.e. 6 in a million blocks or 1 in 3 weeks. As soon as there are 8 nodes in the gossip graph part we are down to 4 in a billion or 1 in 80 years.

| nodes n | fork probability p |

|---------|--------------------|

| 1 | 0.09000 |

| 2 | 0.00810 |

| 3 | 0.00073 |

| 4 | 6.6e-05 |

| 5 | 5.9e-06 |

| 6 | 5.3e-07 |

| 7 | 4.8e-08 |

| 8 | 4.3e-09 |

| 9 | 3.9e-10 |

| 10 | 3.5e-11 |

| 11 | 3.1e-12 |

| 12 | 2.8e-13 |

| 13 | 2.5e-14 |

| 14 | 2.3e-15 |

| 15 | 2.1e-16 |

Conclusion

Performing gossip correction is a powerful way for a peer-to-peer network to efficiently decide between two competing blocks. The exponential nature of the rest risk function p makes fork prevention nearly perfect.

However, it is required that not too many nodes in the network are malicious, otherwise gossip graph parts become too small. The issue of missing nodes should be solved before this can be implemented.