Introduction

IOST’s consensus algorithm — PoB — includes a more decentralized committee election process than current DPoS systems while still maintaining the scalability benefits and censorship resistance.

In the first of a series of articles introducing our consensus algorithm, we describe the mechanism of PoB with regards to block producer election and committee formation that ensures decentralized governance of block production, transaction validation and network integrity.

Our design ensures a voting and committee formation process where most nodes are qualified for block production (instead of only the top few nodes) and where nodes with more votes are assigned a higher probability to produce a block.

To achieve this, we do not use the voting result as the only factor for selection. Instead, we introduce a point system (Servi) to decide and rotate members of the committee.

Becoming a Candidate

To ensure network safety, PoB has an entry barrier for block producer candidates. In the current version, this barrier has been set to 0.1% of available votes on the network. When a node has received more votes than the threshold, it can then send a specific transaction to become a candidate and participate in the committee formation and block production process.

Acquiring Servi and Voting

Although the results of voting does not directly determine the committee members, they do have proportional impact on Servi acquisition rate. In the current version, 17 committee members are selected for block production each round.

Each round consists of three steps:

All candidate will get Servi proportional to their votes. Ranked by Servi, the top 17 nodes will form a committee who are in charge of the block production for the next round. All selected committee members will have their Servi balance reduced by the balance of the 17th node. In other words, the 17th node will have its Servi reset to zero, and the other 16 nodes will lose the same amount.

In the current version, the voting period is 10 minutes. This results in the committee rotating once every 10 minutes in the IOST network.

Example

For simplicity, let’s assume we have a simplified version where 3 nodes are selected for each committee and the current candidate pool is 5.

The nodes are awarded with 10, 8, 5, 4 and 1 Servi respectively. Let’s name them A, B, C, D and E. Also let’s assume the votes are unchanged throughout the voting period.

In the first round, their points are 10, 8, 5, 4, 1. A, B and C will become the committee member since they have the highest amounts of Servi.

Their Servi balances are then subtracted by 5, the same amount that C had. The Servi balance of D and E remain unchanged. We now have the Servi balances of nodes to be 5, 3, 0, 4 and 1.

In the second round, Servi is awarded to each node again. Their balances are now 15, 11, 5, 8 and 2.

A, B and D now become members of the committee, and they all lose 8 Servi (the Servi balance of node D). Their Servi balances are now 7, 3, 5, 0 and 2.

In the third round, they have balances of 17, 11, 10, 4, 3. This round A, B and C are voted committee once again.

Fast forward to Round 9. Their Servi balances are now 26, 8, 5, 12 and 9. Node E will become a committee member despite only receiving 1 Servi each round.

Other Features and Mechanisms

1. When voting and committee member selection has completed, a “round robin” DPoS-like rotating block generation begins. in other words, for each committee that is formed, each member takes turns to produce one block, while all other committee members validate all blocks.

2. In most cases the candidate with the most Servi will become a member of the committee. To limit this, we set a rule that prevents Servi balances to be more than ten times the total amount of votes cast.

3. If there’s a tie for the 17th spot, the node that acquired candidacy first will win. In practice this will be extremely rare.

4. Candidate nodes need to submit a validation transaction once every 6 periods (1 hour) to prove availability. Otherwise, this candidate will lose candidacy and all votes.

5. If a committee member does not produce a block in a round, it will lose votes and candidacy.

6. Tokens used to vote are redeemed after 7 days, and the same applies to a node that loses candidacy. Therefore, nodes that lose candidacy due to reasons above will have a “cooling off” period and not be eligible for selection.

Conclusion

IOST’s PoB consensus mechanism provides a more decentralized voting and committee formation process by introducing a Servi point system, where the number of blocks produced will be closely proportional to the votes they receive.

While this design ensures decentralization of the block production process and fairness throughout the network, it does not compromise the benefits of a DPoS system that enables high scalability and throughput speeds.

We are still stress testing this system and working on improvements and design tweets. If you have any feedback, suggestions or comments, please feel free to get in touch at kevin@iost.io. You may also talk directly to our tech team by visiting invite.iost.io.