# Hybrid Consensus Algorithm Based on Modified Proof-of-Probability and DPoS
## 3 System Model and Algorithm
### Design  
Through the analysis of various mainstream consensus algorithms, it is not difficult to realize that there is a trade-off among three desirable properties, namely decentralization, efficiency and resources saving, and security. For example, although PoW is highly decentralized and safe, it is inefficient and consumes a lot of resources. Although DPoS is efficient, it sacrifices security and decentralization in part. Therefore, using a single consensus algorithm to control the whole block generation process is difficult to achieve satisfactory results. Therefore, this paper comprehensively considers the advantages and disadvantages of PoP and DPoS, and uses them in the process of mining and block verification, in order to improve efficiency as much as possible under the premise of ensuring security. In the original PoP algorithm, the true hash is not determined in advance, but depends on a random number, \(n\), that is, if the nonce value of a hash is represented by a binary number and the \(n\)th bit is 1, then, the current target hash is determined as the true hash. However, this way of determining the true hash is not rigorous, the result may not be unique, and there is a greater risk of fork. Therefore, in view of this defect, the following improvements are proposed for the PoP:  
Before each round of mining, the supernode of DPoS needs to choose an expected value between 0 and 9. Every time the PoP node decrypts a hash, it modules the nonce value to 10. The reason for choosing 10 is that we want to make the shortest time for successful verification of a block equal to that of an existing mainstream blockchain system (e.g., bitcoin system) to ensure its practicability. If the selected value is too small, it cannot effectively restrain multiple nodes with high computing power, and if the value is too large, the system's efficiency will be affected too much. If the result is the same as the expected value selected by the DPoS supernode, it is considered to have decrypted the true hash. The initial verification of the block is successful. According to the number of tokens that DPoS nodes hold, they vote to select supernodes to make decisions instead of themselves. In our proposed algorithm, the token acquisition method is basically the same as that of the PoS-based blockchain system, that is, nodes need to purchase to obtain tokens. By introducing a sublinear function \(Y=\sqrt[6]{X}\) (\(Y\) is the corresponding number of votes and \(X\) is the number of tokens held by the node), this limits the voting weight of nodes with many tokens. All the voted nodes in each round form a candidate pool, from which 72 nodes with the most votes are selected as supernodes. The reason why 72 nodes are selected as supernodes is that in the BitShares project, which adopts the DPoS consensus mechanism, the number of supernodes is set to 101. However, according to the observations of community members, there are not so many ideal nodes that can be voted for, so we choose a relatively small number of 72 nodes. If the total number of nodes is less than 72, all nodes will automatically become supernodes. After scrambling the sequence, a block is successfully verified in turn. Blocks that are not generated in sequence are considered invalid. If there is a supernode that does not act or does evil, it will be replaced by a new supernode selected from the candidate pool according to the number of votes. If the number of supernodes is less than 72, no new supernode will be added after the malicious supernode is removed until new nodes join the system. The bits value is dynamically adjusted by the bit adjustment algorithm [12] to ensure that a hash is decrypted every minute. In fact, the time to decrypt the hash can be dynamically controlled according to specific needs. The supernode can specify an expected value for the first time. If it is not correct, the PoP node which decrypted the hash will enter the waiting time. The supernode can specify an additional expected value the next time a hash is decrypted, and so on.