DPoS: Consensus on the Aergo Mainnet

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

Sung-Jae Woo
May 27 · 6 min read


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

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).


Figure 3. Fork lead by network split; B and (A, C, D) disconnected from each other

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

Technically speaking, a LIB is determined via two phases:

  1. When a majority (⅔+) of BPs appends blocks to a chain, the first among them becomes a proposed LIB.
  2. 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.

Figure 4. Last Irreversible Block Determination in a 4 BPs case

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

Figure 5. BPs Election Scheme


  • 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.

Join us on our Discord server for any technical inquiries. Visit our website to learn more about Aergo. View our source code on GitHub.

Stay up to date on our Twitter, Telegram, YouTube; and be sure to join our WeChat and Kakao communities.

Aergo blog

Enterprise-ready, open-source hybrid blockchain and easy-to-use serverless cloud platform for building practical decentralized apps and business solutions.

Sung-Jae Woo

Written by

A Developer at Blocko and AERGO

Aergo blog

Enterprise-ready, open-source hybrid blockchain and easy-to-use serverless cloud platform for building practical decentralized apps and business solutions.