All news

Consensus mechanism in CREDITS distributed system

The consensus mechanism used by the CREDITS platform is based on a combination of two mechanisms — the Delegated Proof-of-Stake (DPoS) algorithm and the Byzantine Fault Tolerance (BFT) algorithm. DPoS, which is a modification of the more common Proof-of-Stake algorithm, provides differentiation of voters and validators. The Byzantine Fault Tolerance, shortly BFT, implies voting protected against malicious activities. The consensus reaching process in the CREDITS network is split into several phases, with key phases encompassing the selection of head node and trusted nodes, the voting of selected nodes on transactions, ledger recording protected against malicious hackers.

Selection of head node and trusted nodes

Phase One entails the procedure for selecting the head node and trusted nodes to participate in the consensus algorithm.

“Consensus” means the consent of all parties involved in discussing a possible solution to this issue.

The head node and trusted nodes are expected to meet simple requirements, namely: have an updated database in place and comply with the recommended system requirements.

This is achieved through the following actions. Each node of the network sends the last block hash available at this node to the previous round node by which the last block is recorded on a blockchain (see the chart below). A certain amount of time is spared for this process, and all nodes from which no hash is received in this time interval drop out of the competition for eligibility to participate in the consensus procedure. The node receiving these hashes compares them with the hash of the block recorded by the receiving node during the previous round. This is followed by cutting off all nodes sending an unmatched hash. Accordingly, any node with an outdated ledger is unable to become the head node or a trusted node for the next round.


Phase Two. There can be m number of nodes participating in the transaction voting procedure in every round (trusted nodes and the head node). The node writing the last block generates the length list of nodes with an updated database (outcome of Phase 1). The nodes 3m are randomly selected from the nodes n. Then m number of nodes is randomly selected from these nodes 3m, with the first one being appointed as head node for the next round, and the remaining as trusted nodes for the next round.

Transaction voting procedure

During Phase Three, all transactions generated in the system while the head node and trusted nodes are being selected (during Phases 1 and 2) are sent from all nodes to the head node. The head node generates a pool of transactions eligible to be added to the ledger. This pool is sent by the head node to all trusted nodes.


Phase Four. Once this pool is received, each trusted node verifies every transaction within this pool throughout its database and generates the list of transactions that already been checked out. After that each trusted node forwards this list to all remaining trusted nodes.

During Phase Five, the first round of exchange between trusted nodes is followed by generating (at each trusted node) a set of lists received from each trusted node during Phase Four. After that each trusted node forwards this container to all remaining trusted nodes, which constitutes the second round of exchange.

Phase Six. The second round of exchange is followed by the generation of the final decision tree at each trusted node. Each trusted node goes through this tree and determines the majority of decisions (success/failed) in respect of each transaction.


During Phase Seven, we have a list of approved transactions in place, which is a finished pool to be recorded in a chain with verified transactions. This list coincides at each trusted node.

Protection against ledger recording by a malicious node

Phase Eight. A new block will be recorded onto a ledger by one of the trusted nodes which makes a decision on the pool that is identical with most of other nodes (reliably honest node). The procedure for intercepting betrayers from among trusted nodes is performed by verifying the outcome of decision-making during Phase 6. All nodes whose decisions are mismatched with the majority decision are removed from the list of trusted nodes which can potentially record a new pool in a chain. The remaining list will be identical at all honest nodes. Any node is randomly selected from the remaining nodes.

During Phase Nine, the node selected during the previous phase generates a hash of the new pool, records the new pool onto a storage, and sends it to all nodes system-wide. Then a new round begins and the whole procedure restarts with Phase One.


It is noteworthy that the CREDITS platform entails multiple stages of thorough selection and verification of both trusted and head nodes, round-based voting system, sophisticated verification of transactions, a fail-safe system of data recording onto a ledger. These solutions enable the algorithm to offer a proper level of network reliability, accurate decision-making, prevention of errors and abusive practices. In-house consensus mechanism based on a combination of DPoS and BFT is more effective than reliance upon any given ready-made solution or any of the above methods used individually.

Free consultation from Credits team