Introduction of Incognito’s DPoS & Incentive Model
Appendix
In this section, we explain more clearly the concepts mentioned below:
-
Credit: Represents the collateral of stakers in the Incognito’s RDPoS model. Based on how the stakers receive the credit, we can categorize it into 2 types: Delegation Credit and Staking credit.
-
Delegation Credit: The credit that each shard’s staker receives when joining the shards’ committee for the first time. It will be revoked if the owner gets slashed out of the committee, or unstakes and gets removed from Incognito. Each shard’s staker can only get 1 credit.
-
Staking Credit: The amount of credit converted from the staking amount of the beacon’s staker. The conversion rate is 1750 PRV equal to 1 credit.
-
Delegating Credit: The act of giving delegation credit to a certain beacon staker of the shard’s staker. The shard’s stakers take part in the beacon committee selection process by delegating their own credits, and they can also delegate other beacon stakers after each epoch.
-
Delegates: These are beacon stakers that can receive credits. They may either be on the waiting list, have joined the beacon committee, or are on the pending list.
-
Delegator: A “delegator” is someone who wants to contribute their credit to a delegate for increasing the probability that the delegate will be selected for the beacon committee.
-
Performance Score: This is the measure of the stability of a beacon validator. This parameter is changed block-by-block according to the below formula. It is designed to incentivize validators to maintain the stability of their node so that they can participate in the consensus process continuously. Performance Score also directly affects the rewards of beacon validators and their delegators, so this is important reference for shard’s stakers to choose the right validator to delegate their credits.
-
Reputation Score: This is the measure of the credibility of a beacon validator. We use it to choose and slash the beacon committee members. This parameter is based on the total amount of Delegation Credit, Staking Credit, and Performance Score of a beacon validator, as the formula mentioned below.
New Solutions
We are introducing a Delegated Proof-of-Stake model specific to the Incognito chain, along with some new metrics that help enhance the security of the network.
These metrics are the credit point and reputation score, which directly affect the selection of beacon committees and the distribution of rewards. Shard’s staker, after receiving credit points, will delegate to the beacon’s staker they trust. In order to be added to the beacon’s list of substitutes, the beacon’s staker needs to stake a minimum amount of PRV and get a minimum amount of delegators. In addition, the total reward of an epoch is divided up equally among the total credits of the beacon committee. For every individual beacon committee validator, however, the actual reward that they and their corresponding delegators receive will change in accordance with their performance score.
Impact on Incognito’s performance
This design creates 3 main advantages:
-
Increase staker’s commitment: With this design, Shard’s stakers need to ensure that their node operates stably in order to avoid being slashed and monitor the beacon validators’ operability through reputation in order to choose reliable beacon validators to delegate to. The beacon validator must ensure their node’s operability, and at the same time, regularly check for updates because contributing to the consensus process will directly affect their reputation score.
-
Increase the security of the network: This design requires the attacker to gain control of at least ⅔ of the total credits of all beacon committee members and their delegators (shard’s stakers) to manipulate the beacon committee. The decentralization of the network is also significantly improved.
-
Rewards are divided more equitably: With the credit-based reward division mechanism, theoretically, there is no difference in the APY on top of every 1,750 PRV staked between the beacon stakers and shard stakers. This design enables equality in reward division between the foundation’s nodes and the community’s nodes.
Protocol details
RDPoS
Overview
Explanation
- The states of a staker:
- For beacon stakers, we expect them to have taken part in the Incognito network and be stable during that time. Therefore, we restrict the ability of shard’s stakers to create transaction stakes for beacons rather than letting any user stake to become a beacon validator. The requirement is: Participated in the shard’s committee for 50 epochs, and at those epochs, their voting percentage is greater than 90%. Transaction stakes for beacons must have a minimum staking amount of 87500, equivalent to 50 credits, staked amount can also be added via a special transaction type. The amount of PRV added per transaction must be a multiple of 1750. After staking successfully, the staker will be added to the waiting pool. Here, the staker’s nodes need to synchronize the network’s data and call the shard staker delegates for it. Once the required minimum number of delegators has been obtained and the synchronization is fully complete, the beacon stakers in the waiting pool will be moved to the pending pool.
- Once added to the pending pool, each staker will have a performance score of 0.5. This list is sorted in descending order based on the reputation score of each validator. The first 32 positions will be selected for the committee. We will calculate the reputation score S of a validator as follows:
-
where SA is the Staking amount, D is the total delegator, and P is the performance score of that validator.
-
- Once added to the pending pool, each staker will have a performance score of 0.5. This list is sorted in descending order based on the reputation score of each validator. The first 32 positions will be selected for the committee. We will calculate the reputation score S of a validator as follows:
- While in the pending pool, and not in the committee, a validator can unstake by creating an unstake transaction, this unstake command will be processed in the next epoch.
- While in the committee, the performance score of each validator will change continuously from block to block, with value ranges from 0 to 1, calculated based on the validators’ voting behavior:
-
if validator_i’s vote is correct in block t. -
if validator_i’s vote is invalid in block t.
-
- In case the performance score of a validator at the end of the epoch is lower than 0.3, we will slash this validator.
- After validators successfully execute unstake orders, or are slashed from the committee, we will lock their staked amount in t epochs:
. t is the number of locked epochs, P is the validator’s performance score.
- For beacon stakers, we expect them to have taken part in the Incognito network and be stable during that time. Therefore, we restrict the ability of shard’s stakers to create transaction stakes for beacons rather than letting any user stake to become a beacon validator. The requirement is: Participated in the shard’s committee for 50 epochs, and at those epochs, their voting percentage is greater than 90%. Transaction stakes for beacons must have a minimum staking amount of 87500, equivalent to 50 credits, staked amount can also be added via a special transaction type. The amount of PRV added per transaction must be a multiple of 1750. After staking successfully, the staker will be added to the waiting pool. Here, the staker’s nodes need to synchronize the network’s data and call the shard staker delegates for it. Once the required minimum number of delegators has been obtained and the synchronization is fully complete, the beacon stakers in the waiting pool will be moved to the pending pool.
New incentive mechanism
Overview
Explanation
- The new reward distribution mechanism has absolutely no effect on the previously introduced tokenomics. The total supply and the amount of PRV released each year will not change, we only change the way we distribute the rewards to the validators.
- In the diagram above, we specify where the rewards come from and reiterate the sharing of the total reward at each epoch for the DAO address. Regarding the reward distribution for validators, we summarize the steps:
- After the beacon committee calculates the total reward of an epoch and shares a portion with the DAO address, the rest is divided equally among the total credits associated with the beacon committee. This total credit includes credits converted from the staked amount of the beacon stakers on the current committee and the total credit delegated to them.
- Once the amount of reward per credit has been obtained, each beacon validator will know the total reward that they and their delegators can receive. However, the amount of reward they actually receive will be modified in accordance with the performance score of each beacon validator. For example:
- Let base_reward be the reward for each credit at an epoch
-
be the beacon validator i
-
be the total staking amount of
-
be the performance score of
-
be the delegator j of
-
be the reward that a validator X received 
- Thus, theoretically, shard’s stakers and beacon’s stakers would both have the same APY. But in reality, each beacon validator’s performance score is different, resulting in a change in the number of rewards that stakers can receive. Accordingly, shard’s stakers will have the incentive to find high-performance beacon stakers to delegate, and low-performance beacon validators will gradually lose credibility from shard’s stakers.
- To make it easier to understand, we will simulate the APY of each credit in the following conditions:
- Total shard’s stakers: 3204
- Number of the beacon committee members: 24 (7 foundation’s node and 17 community’s node)
- The staked amount of each beacon’s validator from the foundation: 350000 PRV (200 credits)
- The staked amount of each beacon’s validator from the community: 87500 PRV (50 credits)
- Assume that all delegates of shard’s stakers are beacon committee members, so the total number of credits that belong to beacon committee is
. - With the current Mainnet parameters:
- Block-time: 20s.
- Epoch-time: 350 blocks.
- The number of epochs per year: 4508.
- Base reward for a block (block-time 20s): 0,693333 PRV
- Reward amount of an epoch: 1941,3324 PRV
- Reward for DAO (10% of total reward, reduced by years): 194,13324 PRV
- Reward amount for beacon committee and their delegators (TotalReward): 1747,19916 PRV
- Assume performance of all beacon validators is 100%:
- Reward that a beacon’s validator from the community receives per epoch:
- Reward that a delegator receives per epoch:
- Thus, after each epoch, each credit is received
and the reward it gets in a year is:
- So, with this setup, the expected APY per credit is 82,52%.
- Reward that a beacon’s validator from the community
Summary
- Compare the new model with the old design, in the case of full 32 validators in the beacon committee.
- Note that the problems with beacon committees in the old design only occurred in theory, in practice, Incognito-chain does not yet allow staking beacons.
| Old beacon staking design | New model | |
|---|---|---|
| Control ⅓ committee | 115500 PRV | 1/3 of the entire network’s credits, including shard staker’s credit and credits converted from beacon staked amount. |
| Incentive mechanism | Inequality between beacon committees and shard committees | APY is the same for each 1,750 PRV staked. |
| Create block | ⅔+1 foundation nodes | ⅔+1 credits from committee & ⅔+1 foundation nodes |
