Consensus Building Using the Community PoS Algorithm in the Blockchain Network of the Bitbon System

Blockchain is one of the types of a distributed ledger. The key feature of the distributed ledger is its decentralization, which means the absence of an integral center for storing and registering data. At the same time, the information in all the nodes of the distributed ledger must be valid and relevant, which is possible only through achieving consensus among all the nodes of such a ledger. The first consensus building algorithm that was applied to the Blockchain network was a general instance of solving the Byzantine fault tolerance, where the number of network nodes is unlimited and can dynamically change.

To solve this problem, an approach to organizing communities that use Blockchain can be applied, where ways of joint activity should be proposed instead of sudden sequences, where participants of communities would create decentralized community organizations representing their interests and participating in the development of the Smart Community. The implementation of such a solution leads to the need for creating not only tools, which will allow the community to manage the Blockchain network, but also a social and legal model of relationships between users and state authorities.

Such an approach opens the possibility to increase the performance of Blockchain networks by using synchronized protocols while maintaining the security and decentralization of Blockchain. A good example of that is the proposed in 2014 by D. Larimer Delegated Proof-of-Stake (DPoS) protocol, its implementation into Blockchain allowed for a significant increase in the performance of the network (the number of transactions per second). But this protocol has a number of distinctive system features that substantially limit the possibilities of its application.

Taking into account the relevant matters concerning the development of the distributed ledger technology (DLT), as well as the distinctive features and downsides that were found in modern consensus protocols, Simcord Company developed its own solution, a Community PoS (Proof-of-Stake) consensus building algorithm.

In order to describe the operation of the Community PoS consensus building algorithm in the Blockchain of the Bitbon System, we need to introduce the terms that are used in the Bit bon System and in this article:

Bitbon means a token of the Blockchain network of the Bitbon System, which is a unit for measuring the exchange value of all Digital Assets in the Bitbon System, as well as an indicator of Assetbox capacities of the Bit bon System Miners within the context of Consensus building mining.

Assetbox means a record (equivalent of a wallet) with a unique alphanumeric identifier created by the Bitbon System User in the Blockchain for storing, transferring and receiving Digital Assets. Assetboxes can also be used to participate in Consensus building mining of the Bit bon System.

Mining pool means a cluster of Assetboxes of Miners, which is formed as a result of the registration of new Assetboxes in the mining pool through an Assetbox that is already participating in mining. Such a connection is called a graph edge of social connections of a specific Miner. The graph node has no limitations for the number of graph edges for the lower nodes.

Assetbox capacity means a value that depends on the Bit bon balance in the Assetbox, as well as on the contribution of a Miner to the development and maintenance of the Miner Community. The Miner’s Assetbox capacity is calculated as a total of the base and social capacities of the Miner’s Assetbox. Base Assetbox capacity is determined by the Miner’s Assetbox’s own capacity and the capacity of their first line of social connections in the Miner Community. Social Assetbox capacity is formed by Miner’s social connections starting from their second line and lower. Assetbox capacity directly influences the Miner’s remuneration.

Community PoS consensus building algorithm is an improved DPoS protocol due to the following solutions:

• Introduction of the system of automatic distribution of stakes of Miners (designated in the form of Assetbox capacities) among the nodes of the Blockchain network, which leads to the elimination of the voting centralization problem of DPoS participants, which is caused by the Pareto principle (the 80/20 rule);
• Introduction of the node rating system to prevent incorrect behavior of the Blockchain network nodes;
• Development of the system of peer-to-peer (P2P) protocols and communications;
• Decentralized verification of a block by all nodes of the Blockchain network and formation of node ratings based on verification results;
• Introduction of a network state “service denied” to register the value of the uncertainty period when business offer cannot qualify the state of the operation carried out by the nodes of the Blockchain network;
• Organization of the remuneration distribution system for participating in Community PoS consensus building taking into account the motivation for the development of the Smart Community.

1.1. The main idea of Community PoS

The main idea of Community PoS lies in organization of a community of Users in the status of a Miner by uniting their Assetboxes into mining pools. Miners provide their Bitbons in such Assetboxes for automatic distribution of the capacity of these Assetboxes among the nodes of the Blockchain network of the Bit bon System in order to carry out the voting procedure to form the sequence of block producers, which will sign and share blocks.

Each community participant aims to attract new Users in order to develop the community. In turn, each new User provides their Bitbons in their Assetboxes to form a mining pool, therefore increasing the capacity of that pool. Mining pools with higher capacity have a higher chance of participating in block formation because they are supported by a higher number of participants and bigger amount of Bitbons. Each new Miner automatically receives an opportunity to participate in the validation of blocks generated by other community members, as well as in formation of new blocks, which significantly complicates the organization of hacker attacks on the network. Each new network participant lowers the chance of malicious nodes entering the group of block producers, while at the same time increasing the requirements for hardware resources and the amount of Bitbons that the hacker must have in order to carry out an attack on the network. According to the conducted calculations, the likelihood of a hacker being able to predict the moment when they can carry out an attack, i.e. having control over Assetboxes and nodes, which will allow such nodes to enter the list of block producers, is 10–40(which means that the chance is incredibly low, and just as a comparison, imagine if a cat wrote a scientific novel by randomly stepping on a keyboard). Therefore, the increase in the number of network participants leads to a further increase in the ability to withstand attacks on the Blockchain network of the Bit bon System making any type of attack impossible.

Picture 1. Flowchart of operation of the Community PoS algorithm

Simcord Company plans to implement the consensus building algorithm in two stages. This article describes the algorithm implemented at the first stage (Picture 1), which is a preparation for the transfer to a fully decentralized model of the Bitbon System. When moving onto the second stage, the algorithm will be expanded and provide the binding of Assetboxes to nodes of Users (Picture 1*). This will give Miners additional motivation to launch their own network nodes and guarantee their reliable operation, which, in turn, will increase the diversity, reliability and security of the Bit bon System as a whole.

Another important aspect is the matter of the Community PoS consensus building algorithm’s ability to withstand hacker attacks carried out by exploiting the weaknesses of the Blockchain technology. Analysis of the Community PoS concept allows us to confidently state that the use of this consensus building method in the Blockchain network of the Bit bon System will allow it to successfully pass the tests for the attacks listed below:

• 51% attack means a capture of Blockchain network resources, which will allow making decisions on the creation of blocks to discredit the system and/or obtain illegal profit through unsanctioned spending (double spending) and generation of a chain of blocks with data that is beneficial for the hacker.
• Sibill means a substitution of valid nodes, Blockchain network resources, code or sources of network data for resources controlled by the hacker in order to influence the creation of blocks and add transactions to them to receive illegal profit through unsanctioned spending (double spending).
• Timejacking means a transfer of incorrect time to the nodes of the Blockchain network that work with a time-sensitive consensus algorithm by passing the hacker’s infrastructure element as a valid exact time server for short-term control over block creation and/or substitution of transactions in order to receive illegal profit through unsanctioned spending (double spending).
• Pool cannibalizing means an increase of the hacker’s resource that influences the size of mining remuneration compared to other network and pool participants through phishing of actions of other participants, as well as exploiting weaknesses of the protocol by using a super resource in order to receive bigger remuneration for mining by pushing out other Miners, for example, by showing them the economic inefficiency of mining in this network segment.
• Block withholding means not issuing the block and delaying the completion of transactions in order to receive illegal profit through unsanctioned spending (double spending), as well as to get an opportunity to block the operation of the network.
• Deorganizing attack means a selective choice not to reveal a block and/or delay the addition of transactions to the block with their further substitution (selective) or breaking of their sequence in order to receive illegal profit through unsanctioned spending (double spending). Destructive activity of the hacker’s node is random and hard to predict.
• Eclipse attack means a restart of a Blockchain P2P network (used to find the nodes and control their state) by sending out spam messages via gossip-like protocols to disrupt the integrity of the network and to further use other attack methods in order to get temporary control over block formation and, therefore, discredit the network.
• P + epsilon attack means a manipulation of a consensus building procedure by a hacker through sending out both valid and invalid signals within the network systematically influencing the other network nodes in a way that the majority of participants would vote in favor of the hacker in order to receive illegal profit through unsanctioned spending (double spending).
• Blacklisting means the process of sending out protocol messages aiming to add valid nodes to the blacklist of the Blockchain network, which, at worst, will allow the hacker to carry out a 51% attack.
• Transaction malleability means the process of the hacker exploiting the weaknesses of the consensus protocol to substitute a valid transaction for their own with the same hash code (during a block withholding attack) or any other in order to receive illegal profit through unsanctioned spending (double spending).
• Selfish mining means a variation of pool cannibalizing where a big group of Miners creates a separate, hidden from other Miners valid chain of blocks longer than the primary one revealing it afterwards and receiving remuneration that is out of proportion with the resources spent through manipulations aimed at making this chain primary.
• Cancellation of all transactions can occur in case of a 51% attack where a hacker can obtain the majority of blocks and, as a result, get an opportunity to cancel all the following transactions, which can lead to the destruction of the network.
• Double spending means the exploitation of the weaknesses of the network (protocol, infrastructure, client) by the hacker in order to receive illegal profit through unsanctioned spending.
• Random hard forks mean a divergence of a chain of blocks that later becomes primary because of a global system failure or a random exploitation of the weaknesses of the network.

Organization of the Bitbon System Blockchain infrastructure based on the Community PoS consensus gives an opportunity to build a decentralized autonomous community, social, legal, architectural and technical solutions of which will allow for a reasonable and quick reaction to challenges of the modern world and changes of conditions without decreasing the quality of services of such a system for end users. 2. Concept of the Community PoS Consensus 2.1. The goal of Community PoS and ways of achieving it

The main goal of the Community PoS consensus is to provide true decentralization of the processes of announcing, verifying and storing data of the distributed ledger with a high level of performance of storage network and guaranteed short wait time of transaction confirmation.

The achievement of this goal is ensured by:

• Using ways of preliminary block production sequence approval by block producers to prevent forks and block collision;
• Centralizing the network at the moment of block formation by the network node in accordance with the node formation sequence;
• Introducing a strict synchronized sequence diagram of network node operation to ensure the exact determination of the state of the Blockchain network;
• Introducing the network state “service denied” to register the value of the uncertainty period when business offer cannot qualify the state of the operation carried out by the nodes of the Blockchain network;
• Mutual synchronization of network nodes to ensure adherence to the voting and block formation sequence diagram;
• Using a fixed maximum amount of time for processing the transaction (with its cancellation in case of failure to complete it within the given timespan);
• Introducing three types of network node operation protocols:
• Protocol for quorum control and insuring time synchronization of nodes that is essentially a background process based on the poll of a Blockchain P2P network and keeps the information on the availability of the nodes, which can participate in the voting and block formation procedures, up to date;
• Sortition protocol, within which the network node sequence is formed, according to which network nodes will act as block producers;
• Block formation protocol, which includes the creation of the block by the block producer, its verification by other network nodes and a node rating system, which provides the accuracy of carrying out the block producer functions by the network nodes;
• Using the algorithm of the random Miner stake (Assetbox capacities) distribution among the network nodes prior to sortition of the nodes the rating of which allows them to be candidates for block producers. Such a decision allows increasing the difficulty of predicting the block producer sequence. The algorithm is based on the value of the “nonce” parameter (the last block or genesis block), which, in turn, is based on a random number from a hardware random number generator and a time stamp by generating a hash code from this information using the Keccak-256 based on elliptic curves. The resulting numeric sequence is used as a key to distribute the Assetbox capacities of Miners in favor of network nodes (block producer candidates);
• The mechanism of decentralized sortition when determining the sequence of taking on the role of block producers by the nodes, which is conducted by sorting the list of nodes according to the capacities allocated in favor of these nodes, defining the sequence limits and observing the nodes’ compliance with the rules of participating in the formed sequence of block producers;
• A decentralized verification of the block by all the nodes of the Blockchain network and sending out the message on the increase or decrease of the rating of the block producer that generated the block depending on the verification results.

2.2. The roles of nodes in the Community PoS consensus

Each node of the Blockchain network of the Bit bon System can have the following roles:

• Synchronization node. In this role, the Blockchain network node, when connecting to the network, synchronizes with the other nodes by receiving blocks, transactions and objects related to them from the other network nodes, their verifications and storing in the local Blockchain storage. Synchronization of the node time is conducted in accordance with the timestamp of the last valid block and the latency metric to the block producer that formed this block, as well as the timestamps from the other network nodes. After synchronization, the node conducts the verification and storage of transactions and blocks it receives. If the metric of distributing the block for this node is less than 1 second, then this Blockchain network node must accept transactions from client applications for processing and after verifying them, rebroadcast them to all the other network nodes. Otherwise, or if the quorum of the Blockchain network nodes has not been reached, the node does not accept transactions for processing, displaying the “service denied” error.
• Node participating in the quorum. This role can be taken on by any synchronization node, whose value of latency for nodes that are part of the quorum does not exceed 400ms. To implement the protocol of operation of the Community PoS consensus in the Blockchain network, the number of nodes has to be higher than the size of the quorum determined by the Bitbon System Operators (no less than 2/3 of the number of Blockchain network nodes). The node participating in the quorum takes part in the rating formation procedure in accordance with the node rating system. If while processing transactions and blocks the quorum participant notices a violation of the rules of processing, they send all the network nodes the relevant message on the decrease of the rating of sources of invalid data. If the data is valid, then the message contains the information on the increase of the rating of the relevant block producers.
• Block producer candidate. This role can be taken on by any node participating in the quorum with the rating above 10 if it has the mining mode turned on. In this case, such a node will be included in the procedure of distributing capacities (stakes) of the pool of Assetboxes of the Miner Community.
• Block producer. This role is taken on by the Blockchain network node that is a block producer candidate, which was included in the block producer sequence as a result of conducting the sortition to sign and announce only one block in the specified time period (timeslot) (Picture 2).

2.3. Providing sortition system

To eliminate the threats of the Bitbon System centralization and to automate the voting procedure of Miners within the limits of participating in Consensus building mining of the Bit bon System, there is a procedure of automatic redistribution of stakes (Assetbox capacities) among the block producer candidates.

In order for an Assetbox to participate in voting, it is enough to carry out a one-time transfer of the Miner’s Assetbox capacity to the pool by completing a transfer of 0.00001 Bit bon with a comment “/pool” to any Assetbox of the mining pool.

Assetbox capacities that participate in automatic distribution randomly associate among all the nodes of the Blockchain network of the Bit bon System with the corresponding rating, which meet the relevant requirements for the performance and quality of the connection channel (node in the role of a block producer candidate) at the time of voting.

2.4. Sortition procedure

The goal of the sortition procedure is to form the sequence of block producers based on the distributed Assetbox capacities among the block producer candidates, according to which said block producers will sign and announce blocks in the next round.

The sortition procedure is conducted in accordance with the voting and block formation sequence diagram (Picture 2) and contains the rounds, the duration of which is equal to the number of block producers multiplied by the 1 second time interval. The number of block producers is determined by the Bit bon System Operators.

Picture 2. Sequence diagram of the Community PoS consensus

The sortition procedure starts after the end of each round and is conducted over the entire duration of the round. The final block of the round or the message of the timestamp instead of it, if this timeslot had no transactions, can serve as an indicator of the end of the round. Voting is carried out in the following order:

• Within the first 2 seconds, every node, based on the distributed among block producer candidates Assetbox capacities, must randomly form a list of possible positions (sequence) from 1 to n for each block producer candidate node with capacity higher than the lower limit and a corresponding rating, and then send the hash of this list (sequence) to all the nodes participating in the quorum;
• Out of the nodes that can be included in the sequence, the block producer, which is the last to form a block in this round, is excluded;
• Sequence elements with identical positions are not allowed;
• It is forbidden to include 2 elements with one identifier in the sequence;
• On the 5th second, each node participating in the quorum, based on the number of votes for each unique sequence hash, must determine whether or not the sequence it formed collected the maximum amount of votes. If not, the node goes into the standby mode awaiting the block producer sequence. Otherwise, the node checks if the number of votes exceeds or equals 2/3 of the quorum. If the number of votes exceeds or equals 2/3 of the quorum, the node announces the sequence. If not, the node announces the message about the sequence forming error and goes into the standby mode until the start of the next round;
• Each node receives either the block production sequence or the error from the other nodes by the 9th second.

Each node, regardless of its role, verifies the received blocks in accordance with the calculated/received sequence of block producers. The block producer candidate specified in the resultant sequence takes on the role of a block producer during its timeslot.

2.5. Block formation

Blocks are formed by block producers in the rounds with the duration of n blocks (for example, the round duration of 21 blocks). The block producer forms the block out of transactions that are in its transaction pool with the timestamp of the latest transaction in the last valid formed block and the moment of block formation in the next timeslot, which it serves according to these rules:

• If no transactions were received in the processed timeslot, the block will not be formed, but all the nodes will be sent the timestamp of the ending of the timeslot;
• The node in the role of a block producer forms a block based on the hash code of the previous valid block out of transactions in its transaction pool;
• During the round, the block producer can form a block only once;
• Under no circumstances can the block producer form 2 blocks in a row;
• All the nodes (including block producers in this round) take on the role of the synchronization node receiving transactions, carrying them out and checking the received blocks:
• If the block is valid, then both it and the transactions it includes are registered in the storage;
• If the block is invalid, the node ignores it and awaits a valid block with the same number;
• If a block producer was unable to verify the previous block at the time of serving its timeslot, it forms a new one with the same number, which includes all transactions in the transaction pool, with the ones that arrived in the previous timeslots, filtered by the time of creation (excluding the ones that ran out of processing time). Same as with the synchronization nodes, the block producer sends out a message on the decrease of the rating of the previous block producer.

Such measures allow us to avoid creating forks of the chain of blocks, as well as attacks related to the processing delay or ignoring transactions, while at the same time they ensure a guaranteed time of processing a transaction.

2.6. Node rating

The rating of each node is formed through messages that are sent out via a P2P network by all the Blockchain nodes of the Bit bon System as a result of verifying another block formation. The changes in the rating are accepted by all the network nodes in favor of all the network nodes, in particular in favor of the block producer, and are applied after a time period equal to the duration of three timeslots after block formation, on condition that the number of messages exceeds or equals the quorum (at the same time, the number of messages from each node is being monitored). Only one message from a node for each block is included. Below are the main factors that influence the rating of the nodes:

• Rating is increased:
• For the correctly formed block;
• For fulfilling the terms of participating in the quorum (issued by the Bitbon System Operator);
• If a block producer formed at least one block during the day and did not receive the rating decrease;
• Rating is decreased:
• If a block producer included more than 10 transactions related to the previous timeslot;
• If a block producer formed a block in a timeslot that is not its own;
• If a block producer did not form and send the package with a timestamp in its timeslot;
• If the node sent more than 2 messages on the increase/decrease of the rating for one block (pause);
• If the node broadcasted an invalid transaction or the same transaction once again (for each repetition);
• Rating reduction to zero if a block producer formed an invalid block (included an invalid transaction).

The described feedback system allows us to effectively prevent attacks and incorrect behavior of potential hackers, as well as exclude unstable nodes of the Blockchain network from the quorum.

Originally published at https://www.bitbon.space.