Introducing PoB — How to design a more decentralized consensus

*Updated on December 2020

Every blockchain system is in itself a micro-society, an adaptive organization comprised of network nodes. The operation of this organization is regulated by a consensus mechanism. The consensus mechanism is a programmable benefit transfer rule that engages people, forms a secure network, and operates in an deterministic manner.

In the IOST PoB consensus mechanism, the block production committee has 17 seats, which are changed every 10 minutes. The 17 nodes with the highest Servi are selected for the committee in each round, and then take turns to produce blocks and claim rewards. Each time a node is selected to participate in block production, all committee members consume Servi. Therefore the unselected nodes will have more Servi and will have a greater chance of being selected for the committee in the next round. Under this mechanism, there may be hundreds of different nodes selected for the committee each day.

In the PoB mechanism, the entry barrier to becoming a candidate is lower than other DPoS networks, therefore more community members are able to participate. At the same time, the committee members will have increased variation and change with higher frequency. The committee’s mobility is very dynamic, and the degree of decentralization is much higher than EOS based on a small number of super nodes and candidate nodes, thereby achieving better community autonomy while also guaranteeing higher security.

Kevin Tan , Co-founder & Chief Development Officer, IOST

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.01% of available votes on the network, namely 2100000 IOST tokens. 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:

1. All candidate will get Servi proportional to their votes.
2. Ranked by Servi, the top 17 nodes will form a committee who are in charge of the block production for the next round.
3. 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 a predefined number of blocks ( 6 is used for mainnet ), 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. If a committee member does not produce any blocks in a round 3 times in 24 hours, it will lose Servis and be punished no longer to produce any blocks for the next 24 hours.

5. Tokens used to vote are redeemed after 3 days, and the same applies to a node that loses candidacy. Therefore, nodes that lose candidacy due to the 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 still stress testing this system and working on improvements and design tweets. If you have any feedback, suggestions or comments, please feel free to talk directly to our tech team by visiting https://t.me/iostdev

Q&A

Q: Anyone (even with 1 IOST) can vote?

A: Yes, our network is open for all and there is no barrier for participation. In fact, it is possible to become a candidate, join the committee, validate and produce blocks and earn IOST without requiring any investment other than having a standard home PC, as long as you get enough people to trust and vote for you.

Q: How many nodes are in the committee?

A:There are 17 nodes that form the committee to produce and validate blocks, but there may be hundreds of different nodes selected to participate in the committee every day due to the decentralized and rotating election process.

Q: How often will these nodes change?

A: In the current version, the time period for the election is 10 minutes. This means the committee will change every 10 minutes on the IOST network after Servi (awarded by votes) have been cleared. This creates a far more decentralized election than other DPoS systems. For example, EOS block producers will not change even if the voting is changed because the voting changes are so small. IOST’s PoB algorithm guarantees the effectiveness of the change.

Q: How does IOST compare to something like EOS in terms of decentralized voting and election process?

A: IOST has a more decentralized mechanism for voting, participation and electing the final committee to produce and validate blocks. On EOS there is no mechanism to rotate committee members if votes are not re-cast (which have a 3 day waiting period after un-staking). This means it is highly likely that the initial 21 BP’s will stay in the committee and produce all blocks. In IOST, our election process ensures BP’s are constantly rotated.

In EOS, only 1 block producer was chosen to run their initial election in total privacy, this is the most centralized process possible with no transparency.

Casting votes on the EOS network is very technical and not user friendly, creating a high barrier for participation, furthermore, private keys need to be shared with 3rd party organisations which creates massive security issues. Additional, with EOS, 1 vote is for each of 30 nodes, which dilutes small token holders voting power.

On the IOST network it is not possible to permanently stay in the committee forever, and therefore creates a much strong decentralized process for creating the committee.

Q: What stops collusion between nodes and voting for each other?

A: Because the candidates with the most votes have the highest chance of producing blocks, it would not make sense to share out votes and reduce the chance of being selected. This is especially true due to the election process and Servi clearing mechanism — it is far more beneficial to have a larger margin of votes over other candidates. With other DPoS systems, you only need to have just enough votes to beat your competitor, which incentives collusion and distribution of votes.

Q:What stops one entity hosting multiple nodes?

A: There is no way to identify if multiple nodes are owned by the same entity. This is a open and decentralized network, and there are no pre-conditions to hosting a node. However, as explained above, it is not effective to share out votes and risk not being selected as a candidate or being elected into the committee.

Q: What happens if there are not enough nodes above the 0.01% threshold?

A: Our protocol will be optimized so this does not happen, and the entry barrier will be adjusted accordingly. However, our consensus mechanism is very flexible and error resistant. In the very rare situation that there are less than the maximum committee members — or for example a committee member goes offline — it can still function with less than the maximum committee members and self adjusts accordingly.

Q: Do tokens need to be staked on the network?

A: Yes, IOST tokens can be staked for various purposes including voting and using network resources. This ensures fairness in committee elections, equality of resource availability and removes the “nothing at stake” problem to avoid attacks and spam on the network.

Q: To be qualified as a candidate, the candidate must receive 0.01% of all votes available on the network, where 1 IOST = 1 vote. Is this correct?

A: Yes, this is correct, although based on our test-network testing we will adjust this number as necessary before Mainnet to ensure the barrier for entry is not too high without compromising network safety and security.

Q: How does the voting system work in practice? How will a holder of IOST cast and be able to change their vote?

A: Technically, this will work via sending transactions and smart contracts. From a user perspective, there will be an intuitive user interface that makes it simple and easy for anyone to participate.

Q: How is the committee selected?

A:

1. Become a candidate: In the current version, if you get 0.01% of the IOST vote over the entire network, you can send a specific transaction to the blockchain network and become a candidate for the committee.
2. Receive Servi and be elected: Through publicity and promotion, seeking community trust and IOST voting, a candidate will receive a certain amount of Servi. At the time of the election, the top 17 nodes by Servi amount are accepted as members of the committee by the system and then take turns to generate blocks and receive rewards.
3. Servi update and committee change: All selected nodes deduct the amount of Servi received by the last node elected (the committee member with the lowest amount of Servi) This amount of Servi is cleared from all committee member nodes and a new committee is then elected and formed. In the current version, the committee will change every 10 minutes.

Q: Is the election related to both Servi and IOST Tokens? What is their proportion?

Votes corresponds to IOST tokens in the IOST network and can be used for voting. If you have more tokens, you have more voting power. The candidate node will obtain a certain amount of Servi based on number of votes cast, and at the same time, after each election is successful, a certain amount of Servi will be deducted, and finally the committee members will be selected from the candidate nodes according to Servi.

Q: Why would anyone want to become a block producer?

A: Block producers receive IOST for producing blocks and validating transactions. This article is about the decentralized candidate and committee selection, with fee model and structure explained in an upcoming article.

Q: What happens if a node produces an invalid block?

A: every block is validated by every committee member and requires ⅔ consensus. In the situation where there is a invalid block produced, the rest of the committee will not validate this block and the node that produced the invalid block will be removed from the committee.

Q: Can users delegate (“proxy”) their voting power to another user who can vote on their behalf?

Yes, this is possible and already integrated into the protocol and basic functionality of voting.