A Deep Insight of CPChain Reputation System
by CPChain at Aug. 20, 2019
 Reputation (RPT) is a critical value under the Reputation Value Assessment Procedure of RNodes. The RPT has a positive correlation with the chance of being selected into the proposer committee.
Thanks to the launch of various blockchain projects based on the PoS consensus, the staking economy is embracing a rising trend. The logic of “staking is mining” has been popular among the PoS projects. However, PoS takes sorely the balance into account upon the assessment procedure. Unlike PoS, the DPoR consensus takes not only balance layer into account, but also layers such as transaction, data contribution, maintenance, proxy history into account. PoS faces the risk of centralization. DPoR intends distributed the chances for proposers to more widely ranged participants.
Why we need RPT?
To address the common problem of node consistency in distributed systems, CPChain proposes LBFT2.0, a threephase consensus protocol based on bipartite committees. The core of this protocol is to design a dynamic voting mechanism to select a trusted committee who will collect and package the data into blocks. The process of building the mechanism is the process of creating a set of assessment model and algorithm.
The DPoR consensus generates the RPT Assessment Model (the “Model”) with the data from the blockchain. The model is constructed by the following five factors:
 Account Balance (AB):
The AB score is granted to an RNode according to its account balance rank among all RNode addresses (excluding CPChain Foundation and Exchange addresses). The AB score weights 50% of weight in the final RPT calculation.
## Please be noted the AB score is generated by the rank by not by the amount. ##
 Transaction(TX):
Transactions here include all transactions sent by a given user. The definition of transactions can be expanded as the CPChain ecosystem develops. TX score is evaluated by all transactions statistics. The distribution of transactions can follow a long tail distribution or power laws. The TX score weights 15% in the final RPT calculation.
 Proxy Reputation (PR)
An RNode can serve as a proxy helping other nodes complete transactions. Its RPT is augmented after assuming the responsibility as a proxy. It weights 10% in the final RPT calculation.
 Data Contribution (DC)
Uploading data will augment RPT value. There are two parts in data contribution, as basic DC and bonus DC.
Data contribution score is calculated according to the following rules:

For each file an RNode uploads, the node is rewarded 3 points in DC score.

The full score of basic DC is 30 points.

Each time other node purchases a file that RNode uploads, the RNode is rewarded 5 bonus points.

The full score of bonus DC is 70 points.
DC weights 15% in the final RPT calculation.
 Blockchain Maintenance (BM)
BM score is calculated given a node’s contribution in proposing a certain block. It weights 10% in the final RPT calculation.
The final RPT score is calculated in the following formula:
RPT=50∗AB+15∗TX+10∗PR+15∗DC+10∗BM
## Please be noted that the factor of PR and DC are currently not calculated in that at an early age after mainnet launch, the score for these two factors will close to zero. ##
Although it is clear in DPoR description that EVERY RNode will have the chance to be selected into the proposer committee, the success rate of being selected differs among RNodes. The election mechanism is based on the concept of “dynamic balance”, which means the committee members in every single term are not fixed. The algorithm will dynamically adjust the RPT of every single RNode based on their realtime performance in terms of AB, TX, DC, PR and BM. Such dynamic mechanism will somehow create a scatter distribution of the proposers. We believe with DPoR consensus, oligopoly is less likely to appear.
RPT& Proposer
The higher RPT one RNode has the better chance of being selected as a proposer. We need to clarify that the statement is only a description of probability correlation. In real selecting circumstances, it is not guaranteed that the RNode with high RPT will be selected every time because of the randomness characteristic of the algorithm.
Every term of the committee consists of 36 blocks which will last for 360s (6 mins). It means, the RPT, in general, will face some slight change every 6 mins.
In order to avoid Matthew effect within RNodes, we created two zones in the proposer committee. As mentioned before, every term of proposer committee is linked by 12 proposers, with 4 of which are in the CPChain team node zone (in case of united faulty ), and 8 of which are in the community RNode zone. The RNode zone is further divided into two parts. The first 6 spots in the committee will be covered by the RNodes in the top 50% of RPT value than the rest 2 spots will be covered by the RNodes in the rest 50% of RPT value.
We cannot deny that RPT still has some shortcomings in the design and needs to be improved. For example, regarding the two factors of PR and DC, although it is listed as the factors to calculate RPT, we have not provided any means to improve the score for these two factors. In addition, the RPT algorithm has not yet included the behavior of “single RNode causing impeach block” into the RPT assessment. The mission for our R&D team in the next stage is to solve such problems.
How to Maximize the Proposer Benefits for the CPC in Your Pocket?
This is perhaps one of the most frequently asked questions in the community. In this regard, we have only one suggestion: take the initiative to participate, the sooner the better.
If you have more 200,000 CPC in reserve, you can choose to participate in the RNode program for the proposer reward. The current single block reward is 12.65 CPC. If you want to get more than 10% yearly ROI, you need to at least propose: 200,000 CPC*10%/ 12.65 CPC =1581 blocks in a year. We need to know that the ideal total blocks a year is around 3 million.
In the future, with the gradual completion of the token swap and the gradual growth of the entire CPChain ecosystem, more SaaS providers and investors will participate in the RNode pool to compete for the proposing right in the entire network. By then, the propser benefit of a single RNode will gradually decline.
By the end of 8/19, there are 57 RNodes in the pool and more than 10 RNodes have already proposed at least 1000 blocks.