Security of DPoS

The goal of this article is to assess the algorithm of Delegated-Proof-of-Stake consensus from various point of views.

Consensus in real-world interactions are quite common. It could be stated that humans are good at consensus. In machine world, an algorithms driven by conditions, computations and codes, are not on par. For them, it is fundamentally the deterministic state providing by some particular process with variables. Basically, these variables are threads formed by community of humans. Thus, a consensus is a process of agreeing on deterministic order of transactions. Part of the decision making is filtering invalid transactions and providing correctness plus irreversibility. As a result, all blocks must be valid according to such a deterministic machine logic and the supported logic must be open source in nature.

DPoS Backgrounds

The DPoS algorithm comprises two parts:

  • Stake in form of Penalty
  • Delegation in form of Election

Behind these two parts, lies the machine logic that represents selection of a group of block miners and a continuous block assembly according to the schedule. On one side, the voting asymptotically converge to the selection of the stakeholders that are ultimately in control, on the other side, the delegation makes a low impact on the achievement of consensus between delegates, on a block by block basis. Because their are the most penalized thus they lose the most when the network does not operate in the ordnance.

This article will further review the mechanisms of consensus between this selection of miners.

In order to illustrate the process, let's assume the following miners A, B, and C. By extending Byzantine Fault-Tolerant consensus, DPoS requires 2⁄3 + 1 of votes to resolve an argument. This simplified model implicates that producer C is deemed to be the tie breaker. Like in Proof-of-Work consensus, the general rule of thumb is that longest chain always wins. A honest miner builds on top of to the strictly longest chain and he will filter out shorter forks. Let's study similar scenarios in more detail.

Normal operation

Under normal circumstances, miners are scheduled to produce a new block every 5 seconds. Given an assumption that no one misses their turn, this will produce the longest possible chain. By network of miners, It is seen invalid to produce a new block at any other dedicated time slot.

Double Spend Attack

When circumstances change, a double spend can occur in case of denying of the previous transaction that has been already included in blockchain. By other words, the miners had a communication breakdown caused by internet malfunction. In DPoS, the probability of such a circumstance, is low and it is mitigated by design. The core network protocol heartbeats with scheduled miner and it immediately detects an loss of communication. In such a case, the scheduled miner has missed his opportunity, hence multiple substituting miners has to confirm this transaction what imposes some delay.