Consensus Building Using the Community PoS Algorithm in the Distributed Ledger Token Accounting System of the Bitbon System

Blockchain[i] is one of the types of a distributed ledger[i]. 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 Bitbon System Social Network[i]. The implementation of such a solution leads to the need for creating not only tools, which will allow the community to manage the distributed ledger token accounting system[i], 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 distributed ledger token accounting systems 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 allowed for a significant increase in the performance of the distributed ledger token accounting system (the number of transactions per second). But this protocol has a number of distinctive technological 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 developed its own solution, a Community PoS (Proof-of-Stake) consensus building algorithm.

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 Registrators[i] (designated in the form of Assetbox[i] powers) among the nodes of the 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 network nodes;
• Development of the system of peer-to-peer (P2P) protocols and communications;
• Decentralized verification of a block by all nodes of the 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 network;
• Organization of the remuneration distribution system for participating in Community PoS consensus building taking into account the motivation for the development of the Bitbon System Social Network.

1.1. The Main Idea of Community PoS

The main idea of Community PoS lies in organization of Providers[i] with the status of a Registrator by uniting their Assetboxes into Registrator pools by allocating Bitbon[i] digital asset units[i] in such Assetboxes for automatic distribution of powers of these Assetboxes among the nodes of the distributed ledger token accounting system in order to carry out the voting procedure to form the sequence of block producers, which will sign and announce blocks.

Each Provider with the role of a Registrator aims to attract new Registrators in order to increase the power of his/her pool. Registrator pools with higher power have a higher chance of participating in block formation because they are supported by a higher number of participants with a bigger amount of bitbons. Each new Registrator automatically receives an opportunity to participate in the validation of blocks generated by other Registrators, as well as in formation of new blocks, which significantly complicates the organization of hacker attacks on the network. Each new Registrator 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 number 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. Therefore, the increase in the number of Registrators leads to a further increase in the ability to withstand attacks on the distributed ledger token accounting system of the Bitbon System[i] making any type of attack impossible.

Simcord plans to implement the consensus building algorithm in two stages. This article describes the algorithm implemented at the first stage (Figure 1), which is a preparation for the transfer to a fully decentralized model of the Bitbon System in accordance with the Decentralization Roadmap. When moving onto the second stage, the algorithm will be expanded and provide the binding of Assetboxes to nodes[i] of Users[i] (Figure 1*). This will allow Providers to launch their own distributed ledger token accounting system nodes and guarantee their reliable operation, which, in turn, will increase the diversity, reliability and security of the Bitbon 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 distributed ledger token accounting system of the Bitbon System will allow it to successfully pass the tests for the attacks listed below:

• 51% attack;.
• Sybil;
• Timejacking;
• Pool cannibalizing;
• Block withholding;
• Deorganizing attack;
• Eclipse attack;
• P + epsilon attack;
• Blacklisting;
• Transaction malleability;
• Selfish mining;
• Cancellation of all transactions;
• Double spending;
• Random hard forks;

Organization of the infrastructure[i] of the distributed ledger token accounting system of the Bitbon System based on the Community PoS consensus gives an opportunity to build a decentralized execution environment of the Bitbon System, the social, legal, architectural and technical solutions of which will allow for a quick reaction to challenges of the modern world and changes of conditions without decreasing the quality of services of this system for its Users.

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 block formation sequence;
• Introducing a strict synchronized sequence diagram of network node operation to ensure the exact determination of the state of the 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 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[i] (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 ensuring time synchronization of nodes that is essentially a background process based on the poll of a 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 Registrator stake (Assetbox powers) 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 powers of Registrators 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 powers 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 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 network can have the following roles:

• Synchronization node. In this role, the 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, verifying them and storing in the local 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 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 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 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 network, the number of nodes has to be higher than the size of the quorum determined by the Bitbon System Operators[i] (no less than 2/3 of the number of 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 processing rules, 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 Providing[i] mode turned on. In this case, such a node will be included in the procedure of distributing powers (stakes) of Assetboxes of the Registrator pool.
• Block producer. This role is taken on by the 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) (Figure 2).

2.3. Supporting the sortition system

To eliminate the threats of the Bitbon System centralization and to automate the voting procedure of Registrators within the limits of participating in building consensus in the distributed ledger token accounting system of the Bitbon System, there is a procedure of automatic redistribution of stakes (Assetbox powers) among block producer candidates.

All that is required in order for an Assetbox to participate in voting is to carry out a one-time transfer of the Registrator’s Assetbox power to the pool by transferring 0.0001 bitbons with a comment “/pool” to any Assetbox of the Registrator pool.

Assetbox powers that participate in automatic distribution randomly associate among all network nodes 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 Assetbox powers distributed 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 (Figure 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 Bitbon System Operators.

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 Assetbox powers distributed among block producer candidates, must randomly form a list of possible positions (sequence) from 1 to n for each block producer candidate node with power 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 the same 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 the 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;
• The block producer cannot under any circumstances 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 nodes 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 a 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 network from the quorum.