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.
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.
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.
Note the slots “1” and “5” of the main chain (the upper) is empty because the blocks produced by B is not received by (A, C, D) due to the network split.
The lower chain managed by B is a side chain since it is shorter than the other; While the height of the main chain becomes as high as 7, that of the side chain is still only 3. Thus according to the longest chain rule, once the network issue is resolved and the blocks of the main chain are sent to B, B becomes knowing that its chain is shorter than the other. Finally, it will follow the main chain (reorganization).
Finality: Last Irreversible Block
If a block is connected to a blockchain, it can be regarded as casting the block itself and the parent blocks. Based on this idea, a concept called last irreversible block (LIB) was introduced to DPoS. Once a block becomes a LIB, any reorganization beyond it is prohibited. Accordingly, the finality of the LIB and the blocks before that are guaranteed. Under a normal condition, a LIB is continuously updated to a higher number except for the initial bootstrapping period.
Technically speaking, a LIB is determined via two phases:
- When a majority (⅔+) of BPs appends blocks to a chain, the first among them becomes a proposed LIB.
- The proposed LIB finally becomes a LIB when appended by the blocks from another majority of BPs.
Originally, the range of voting [or confirmation] of a block had no limit. Put another way, a block connected to the chain was considered as voting for the block itself and all the parent blocks. However, later it is changed to avoid conflicting LIBs³. Under the modified version, a block generated by a BP X confirms only the range of ancestors after the block lastly produced by BP X.
A simple example is illustrated in Figure 4. This is a 4-BPs DPoS network case; Its majority count is 3. In such a case, the votes by 3 BPs are required for consensus respectively in each of the phases of LIB determination. Therefore, as shown in Figure 3, the block “1” becomes a proposed LIB when the block “3” is connected to the chain (1st phase). After that, the block “1” is finally promoted to a LIB when the block “5” is appended (2nd phase). Under a normal condition, once a block has been finalized as a LIB, the height of LIB proceeds by 1 whenever a new block is connected; One new block accompanies a new LIB.
Staking, Voting & Election
Active BPs are elected by Aergo users, who stake their tokens (Aergo)⁴. The stakeholder can freely vote multiple candidates (max 30 candidates) although casting is restricted as 1 vote per day. The voting result is gathered every 100 blocks. The ranking affects the regime change after 100 blocks. This election scheme is illustrated in Figure 5. Here the BPs at block “700” are chosen according to the ranking gathered at block “600” (not “700”). It is designed to lower the possibility of unnecessarily frequent regime changes resulting from reorganization since the past blocks are less likely to reorganize than the recent blocks.
Summary
Thus far, by using an example of a simple system consisting of 4 BPs, we have explained how DPoS works. Its main ingredients are:
- block generation by a limited number of elected BPs, and;
- possible reorganization only within a restricted range of blocks.
The former ensures fast and stable block production, while the latter guarantee absolute block finality as long as a majority of active BPs are under normal operation. By virtue of them, DPoS can achieve high performance with a moderate degree of transaction finality. Such a balance between performance and finality is one of the most important factors why we chose DPoS for the Aergo mainnet’s consensus.
¹ DPoS was first introduced as a consensus algorithm for BitShares. The current Aergo implementation is similar to that of EOS.
² The Aergo mainnet is currently being operated with 13 active BPs through its incubation phase.
³ Read: “Fix DPOS Loss of Consensus due to conflicting Last Irreversible Block”.
⁴ Staking and voting are conducted by submitting transactions.
