The Basics of TRON’s DPoS Consensus Algorithm

Published in

TRON

9 min readSep 7, 2020

The consensus is at the core of the distributed system. A good consensus algorithm greatly benefits the distributed system. In the blockchain sphere, you may have heard about many consensus algorithms, such as PoW, PoS, DPoS, BFT, and other improved algorithms based on them.TRON, like many other public blockchains, has done tremendous research and practice to improve its consensus mechanism. In keeping with its own positioning, TRON network first implemented the DPoS consensus mechanism and then combined it with PBFT consensus mechanism, and the two gradually evolved into the new TPoS consensus mechanism.

This series of three articles will unveil the mysterious mask over TRON’s public blockchain consensus algorithm.

Article 1: The Basics of TRON’s DPoS Consensus Algorithm

Article 2: An Introduction to PBFT Consensus Algorithm

Article 3: TPoS Consensus Mechanism in TRON 4.0 Great Voyage

Overview

In the blockchain system, the bookkeepers are usually elected in a way where different nodes perform the same consensus. PoW (Proof of Work) consensus algorithm identifies bookkeepers by solving difficult PoW questions. Typical blockchain systems like Bitcoin and Ethereum, both adopt PoW consensus. Ideally, PoW consensus is a highly decentralized algorithm, ensuring the security of distributed ledgers. However, as resolving questions is extremely difficult, most nodes, in reality, choose to partner up with mining pools to mine together. This leads to the concentration and monopoly of bookkeeping rights within a handful of large mining pools. Therefore, the decentralization advocated by PoW is compromised. Meanwhile, conducting meaningless computation at the cost of huge amounts of electricity is another problem of PoW heavily criticized by many people. On the other hand, the inefficiency of the PoW consensus algorithm also compromises the system’s throughput.

PoS (Proof of Stake) blazes a new trail and issues stakes (tokens) in the blockchain system, empowering nodes that hold more stakes to partake in bookkeeping. Such a new consensus helps address the issue of wasting computing power to solve difficult questions. Furthermore, only miners that hold stakes are allowed to participate in mining, which ensures the interests of miners and stakeholders are aligned, protecting the security of blockchain systems. Of course, PoS also has its own problems, which include complex communication, and negative impacts on the system when people bribe voters or cast multiple votes.

In DPoS, a consensus evolved from PoS consensus, a handful of representatives are selected among all stake-holding nodes, and are given the rights of bookkeeping. In this case, the issue of complex communication is thus resolved. Also, the rights of bookkeeping are granted before blocks are produced. Votes are cast for bookkeepers instead of blocks, which helps prevent people from casting multiple votes. In contrast with PoS, DPoS consensus substantially reduces the number of nodes participating in validating and bookkeeping, delivering an efficient model of consensus-making. Bookkeepers validate and pack transactions into blocks, and broadcast new blocks to other nodes in the system. Then the other nodes recognize the new blocks.

A typical implementation of DPoS consensus algorithm is as follows:

When a blockchain system is first deployed, the system issues a certain amount of tokens and distributes them to nodes in the system. With a certain amount of tokens, nodes can apply to become candidates of a bookkeeper in the blockchain system. All nodes holding tokens may vote for these candidates and bookkeepers (block producers) are chosen based on the number of votes each node receives. After some time (T), the system will recount the votes each candidate receives and decide on the bookkeepers for the next cycle. And this process repeats itself. Bookkeepers produce blocks in the time period of T and receive corresponding rewards stipulated in the incentive mechanism of the system.

The practice of DPoS consensus

TRON public blockchain adopts DPoS consensus algorithm. In practice, the system sets the role of super representative candidates, and the top-voted 27 candidates are elected as SR (Super Representatives). Candidates ranked between 28 and 127 are called SRP (Super Representative Partners). The system recounts the votes each candidate receives and decides on the next batch of SRs. SR is entitled to produce blocks and receive corresponding block-generation rewards. Also, SR and SRP will receive voting rewards for each new block produced.

Round and Slot of block generation

TRON network defines every six hours as one Round and every three seconds as one Slot. Each Round, therefore, contains 7200 Slots. The relationship between Round and Slot is illustrated in Figure 1. The last two slots in every round are a maintenance period, during which no blocks will be produced and new SRs are decided on, as well as their order of producing blocks.

Figure 1: The relationship between round and Slot

Block generation and consensus

SRs take turns, as is decided in the maintenance period, to produce new blocks and only in their corresponding Slots. Figure 2 illustrates how an SR produces blocks.

Figure 3 shows a situation where a fork occurs in the system during one of the Slots. S3, S4, and S5 all kept block B1 and B2 produced by S1 and S2 in their ledgers. However, due to a temporary network partition, S4 and S5 did not receive block B3 produced by S3. When it’s the Slot for S4 to produce a block, S4 deems that S3 might have failed and therefore produces block B3' on top of B2. S5 then produces block B4 on the basis of block B3' because it didn’t receive B3. Now, there are two different blocks, B3 and B3', at the same block height (=3) in the entire blockchain system. Such a situation is called a temporary fork.

Figure 3 Fork caused by network partition

As network partition is inevitable in a decentralized system, coupled with occasional temporary forks, TRON allows temporary forks to occur in order to improve its throughput. TRON does not overemphasize the real-time consistency of the system and instead ensures that the ultimate consistency is achieved. This is a compromise made while observing the CAP principle. The following two approaches are adopted to ensure the consistent state of the system:

1. Adopting the longest chain to minimize fork as quickly as possible

Whenever a temporary forking happens, nodes always prioritize the longest chain, where SRs store every single fork and produce blocks on top of the longest chain when their slot to produce blocks comes. As is shown in Figure 4, S6 receives both block B3 produced by S3 and B3' produced by S4, and also B4 which S5 generated based on block B3'. There are two chains in S6’s local ledger, namely B1-B2-B3 and B1-B2-B3'-B4. According to the principle of the longest chain, S6 would then continue to produce block B5 on the basis of B1-B2-B3'-B4. The following SRs would in the same principle generate blocks. There might be multiple forking chains in the blockchain system when there’s a bad network partition. Yet, as long as SRs adopt the longest chain, SRs will synchronize their known blocks and switch to the longest chain upon resumption of network communication, fixing the temporary forking issue.

Figure 4 SRs produce blocks on the basis of the longest chain

2. Block consensus with solidification mechanism

The consensus is designed to ensure that a finalized block won’t rollback. A fair mechanism is required for block consensus as blocks on the original chain are likely to be rolled back when nodes are prone to switch chains upon temporary forking.

In the above example, node S6 produces blocks according to the state of its local ledger without knowing the state of the ledger for other nodes. The block that S6 produced has been finalized. Only when a majority of SRs recognize this block can a consensus be reached for it. SRs recognize the block when they produce subsequent blocks (i.e. block hash of this block will be used as the parent block hash for the subsequent block) on top of it. TRON network, while adopting the longest chain, sets the threshold for block consensus at 19. That means apart from the SR producing the block, another 18 different SRs should produce their subsequent blocks on top of this block in order to reach consensus for the block. When this block is recognized by a majority of SRs and is made impossible to roll back, such a block reaches consensus and therefore is called a solidity block.

Figure 5 illustrates the process of block solidification: after S6 produced B5, B3' got confirmed by three SRs, including S4 who himself produced B3', and S5 and S6 who produced B4 and B5 respectively on the basis of B3'.If subsequent SRs continue to produce blocks on chain B1-B2-B3'-B4-B5, then B1 will become a solidity block at the time when B19 is produced, and the same for B2 and B3' when B20 and B21 are produced. It should be noted that the real significance of “different SRs” lies in that it ensures the height growth of any other fork will not surpass that of the current chain, which means solidity blocks have been confirmed by the majority of SRs.

Figure 5 Confirm blocks as solidity blocks

SR rotation and incentive

SR rotation is an important feature of DPoS consensus. Consider this scenario: one single SR dropped offline, and the throughput of the entire blockchain system would be compromised. With an SR rotation mechanism in place, there will be other available Super Representatives Partners filling that role. The old SR who fails to produce blocks and distribute block rewards to his voters will be replaced by other Super Representatives Partners. The SRs to produce blocks for the next round will be determined during the maintenance period. In this way, SRs will take turns to perform their tasks.

In a decentralized system like blockchain where an admin role is absent, a sound incentive model and feedback mechanism are indispensable to the effective governance of the system. Similar to PoW consensus which rewards block-producing nodes with tokens, DPoS consensus also offers rewards to block producers so as to incentivize them to validate transactions and produce blocks while distributing rewards to voters, which helps maintain the healthy operation of the blockchain network and encourage more voters to partake in network governance. Previous articles have explained this incentive model in detail, please check the link: TRON network incentive mechanism

Advantages and limitations

The DPoS consensus mechanism employed by TRON can guarantee system availability in the event of network partition. Upon recovery of network connection after the chain split, nodes will follow the longest-chain principle to swiftly shift to the longest chain and finalize the blocks that have been confirmed by most SRs.So the TRON network guarantees top-level availability of the blockchain system and is highly friendly to applications with lower needs for consistency. On the other hand, TRON’s solidification mechanism provides highly consistent status for solidifying blocks, which to a certain extent ensures high network consistency.

In our current implementation of DPoS consensus, it takes as long as 18 slots (54 seconds) of confirmation to finalize a block. Although we could modify the confirmation threshold to 14 (a block will be solidified after 13 slots, namely 39 seconds) based on the majority rule, this will compromise safety. As a result, the efficiency of block consensus under the current DPoS algorithm is yet to be improved. In the following articles, we will dive into this matter further and discuss possible solutions.

Summary

As the first issue of the series, this article first briefly introduces some common consensus algorithms in the blockchain system, then explains the fundamentals of the DPoS consensus algorithm currently adopted by TRON MainNet, and lastly discussed its advantages and limitations. This article lays the foundation for our future discussions on the technical philosophy and implementation of TPoS consensus mechanism.