We often talk about Proof of Stake, Proof of Work, Delegated-Proof of Stake and many other consensus mechanisms. These include the little-known Proof of Believability, which is the consensus algorithm used by IOST.
Though not well known, this is a very interesting consensus algorithm, considering the technological challenges it aims to solve.
So here’s how it works and what are the characteristics of Proof of Believability.
Proof of Believability: the SERVI concept
One of the main challenges facing the traditional Proof of Stake consensus mechanism is the trend towards centralisation. In order to mitigate this risk, IOST has introduced the concept of SERVI to measure users’ contributions to community maintenance and to encourage and stimulate the continued development of IOSChain.
SERVI has the following characteristics:
- It is not tradable: SERVI is not conceived as a means of exchange, therefore it cannot be traded in any way;
- Self-destructive: after validating a block, the system will automatically erase the SERVI balance belonging to the validator. In this way, nodes with high credibility scores can validate blocks in an alternate way, so as to ensure a fair process of generating blocks and avoid the emergence of validators over the others;
- Self-issuance: SERVI are automatically generated and deposited on users’ accounts based on the contributions made to the community. These contributions consist in the provision of services to the community, or in the control and evaluation of services provided by other entities.
SERVI contribute to the credibility score that will be illustrated shortly. They also allow maintaining a certain level of entropy in the choice of validators in charge of processing a transaction.
How does the IOST Proof of Believability consensus algorithm work?
Classic blockchain-based systems have a certain compromise between security and throughput. It depends on the requirements and size of the Shards, and also of the blocks.
A system with a large number of Shards offers better performance but is much more vulnerable to attacks. To overcome this compromise, in order to maintain a certain level of security and performance, IOST has developed a new consensus algorithm.
The Proof of Believability (PoB) – used on the IOSChain – ensures that the nodes have a negligible probability of error, thus significantly increasing the volume of transactions that can be executed thanks to the variation in the size of the Shards.
The PoB-based protocol uses an intra-shard Believable-First-based approach. This means that the protocol divides all validators into two groups: on the one side, the credible validators and on the other, the normal ones.
As a result, credible validators process transactions very quickly in the first phase. Then, the normal validators sample and verify the transactions in the second phase, so as to finalise the operation and guarantee the legitimacy of the transactions.
The probability that a node is elected as credible by other credible validators is determined by the node’s credibility score. This is calculated using multiple parameters, including token balance, community contributions, etc. The higher the score, the more likely it is that the node will be elected.
This means that there are credible validators who manage the necessary procedures to decide the set of transactions to be processed and the order in which they are processed. These validators can aggregate, forming their own validation groups. However, these groups can also be very small, so much so that they are made up of only one validator per group.
This will result in a random distribution of the transactions to be processed among the various credible validators. Consequently, smaller blocks with extremely low latency are produced.
However, there may be some security issues, since the verification is done by only one node. Hence, some malicious transactions may be performed by credible malicious validators. To solve this problem, a certain sampling interval is defined that will determine how often normal validators will have to verify transactions in the second phase, thus detecting any inconsistencies. If a validator is detected as malicious, it will lose all its tokens and reputation within the system.
For all the details about the PoB, it is possible to consult the official documentation: PoB.