As this wise man explained nicely, one of the biggest threats to leader based blockchains are denial of service attacks (DoS). Lisk’s implementation of delegated proof of stake surely falls in that category.

Starting such an attack is pretty straight forward: create or buy a botnet, pull the list with the order of delegates from the network and ensure that the delegate of the current forging slot is attacked.

As a delegate, it might be fairly easy to protect yourself against very dumb attacks using off-the-shelf firewalls or DoS protection software. But if an attacker puts more work into designing an attack, it may become very hard to distinguish a friendly peer communication from an attacker’s request. If more advances DoS protection is required it becomes tempting to use a big cloud provider that offers great bandwidth, network analysis and support. But when all the delegates do that, we get a lot of centralization towards the few big providers.

Usually a delegate has multiple nodes ready for forging. Since forging with multiple nodes at the same time is not allowed, only the primary node is active and rest is on standby and can be activated when needed. But coordinating multiple nodes is challenging. One common method is to have a management server that monitors the primary node and switches to a standby node when the primary node becomes unavailable. But in order to attack this setup, you only need to attack the management server and the active node at the same time. Since the active node cannot publish a block and no standby node can be activated, the delegate will miss the forging slot. Having a central management server can be avoided if the nodes talk to each other directly and standby nodes activate themselves when the active node does not forge. But how does a standby node decide when the active node is down? When it does not respond for some time it may either be dead or it may have a high load or network latency. Even if the standby node decides to take over, it usually cannot guarantee that the active node will not publish a block. While there are ways and means to mitigate the risk of missing a block and at the same time mitigating the risk of double forging, those methods are hard to implement and not perfect.

At the moment it is not allowed to activate multiple nodes for forging at the same time because the network can create forks when different nodes from one delegate create different blocks in one slot. This type of fork is known as fork type 5 and avoiding those kind of forks is an open issue in Lisk. There are two main directions in how to avoid those forks: one idea is to add some clever node coordination mechanism that ensure that never two nodes forge at the same time and the other idea is that the network can sort out on its own which one of the forged blocks should stand.

Wouldn’t it be nice if all the nodes of a delegate wouldn’t need to be managed — if each node could forge in the delegate’s forging slot and publish its result to the network without the need to coordinate with other nodes? In the event of an attack, a delegate could spawn additional nodes very quickly leaving those behind that are not reachable temporarily.

I believe that double forging or even multi forging can be possible. Since this would vastly improve the network resistance of Lisk, this issue needs more attention.