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 n 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.