DPoS: Consensus on the Aergo Mainnet

A detailed description of the Delegated Proof of Stake consensus implemented for the Aergo blockchain kernel.

Introduction

Every blockchain protocol uses a consensus algorithm to maintain one and only one list of cryptographically linked blocks — a blockchain. The most famous in the blockchain scene is the Nakamoto consensus from Bitcoin, which is based on Proof of Work (PoW). It achieves a large degree of decentralization by allowing finality only in a probabilistic manner, where several branches may compete with each other and gradually evolve into one over time. The other extreme in the spectrum are those originated from the traditional Byzantine Agreement (BA). They guarantee an instant block finality by limiting the degree of decentralization.

The Delegated Proof of Stake (DPoS)¹ consensus used by the Aergo main network is on a middle ground between the aforementioned two. It delegates the exceptional right of generating blocks to a set of elected block producers (BPs) — while allowing a reorganization within a finite range. By (a) following a Proof of Stake model (PoS) and (b) maintaining only a limited number of BPs, it addresses both the performance issue as well as the excessive energy consumption problem found in PoW-based consensus.

This article gives a detailed description of the DPoS as implemented in the Aergo blockchain kernel. In the remaining part of the article, “DPoS” means the DPoS implemented in the Aergo blockchain kernel, unless specified otherwise.

Delegated Proof of Stake on Aergo

Block Production

In DPoS, only a limited number² of nodes, called active block producers (BPs), are permitted to generate blocks. They are chosen through a voting process among stakeholders. Time is evenly partitioned into slots, and for each slot, at most one block should be generated. Active BPs are scheduled over those slots by voting score and take turns producing blocks.

For simplicity, let’s consider an example of four active BPs, which are respectively A, B, C, and D in decreasing order of voting score. The block interval is 1 second. If all things are OK, the blockchain proceeds as shown in Figure 1.

Figure 1. Block production under a normal operation; The letter in each box is the block producer.

Here, each BP generates a block every four seconds. However, when the former block is not received in time, the next BP should generate it. For example, assume that A produced the block “1” and then B crashed before producing the block “2.” In this case, C should generate the block “2” instead of B. Figure 2 shows what the blockchain look like in such a failure case.

Figure 2. Block production when B crashes

There are no blocks corresponding to the slots “1” and “5” since B crashes so that blocks are non-uniformly distributed over time; the time interval between the blocks “1” and “2” is about two times longer (2s) than the normal (1s).

Fork

On the other hand, DPoS allows fork and reorganization like Bitcoin. Let’s assume B is disconnected from the other BPs due to some network failure. Even in that case B and the others (A, C, D) do not stop block production. They respectively manage their own blockchains as shown in Figure 3.