DPoS - Second-Earth/setchain GitHub Wiki

setchain consensus introduction

Brief introduction

The setchain blockchain adopts the dpos consensus mechanism of entrusted equity proof, which relies on N candidates/validators, and randomly rotates out blocks in M ​​seconds to complete the consensus security.
The block producer list (valid candidates) is sorted according to the number of votes from high to low, and the highest N candidates and L candidates are selected as backups.

The initial N candidates/validators of the genesis block will randomly rotate out of the blocks as a list of block producers before dpos is started.
Every 7 days, accounting is carried out on a calendar week.

Registered candidates need to pledge a certain amount of coins, and these pledged coins will be part of the candidate's total weight; the other part comes from other people's votes. So
More collateral means easier election. However, these mortgages will also be deducted as a fine when the candidate’s account produces abnormal blocks or misses a large number of blocks.
Drop.

Our main purpose of doing this is to hope that the candidates have certain strength to provide better services for the entire network. The good operation of the entire network is largely
Rely on each elected candidate to be able to package transactions and distribute blocks stably. We recommend that while choosing a machine with good enough hardware performance as the block producer,
Set up some proxy nodes (sentinel architecture). By broadcasting the block to the network through the proxy node, instead of directly accessing it. We will refer to the performance of the elected
Sufficient economic incentives to encourage them to better contribute to the entire network. For this we need to set a suitable threshold.

On the other hand, if you don't want your currency to be mortgaged, you can also vote for candidates to get some voting rewards. The total number of votes a voter can cast
The number is calculated through snapshots of each cycle. We start the cycle at 0:00 every Sunday and continue to 0:00 on Sunday the next week. At 0:00 on Sunday,
The system will generate a snapshot to record the amount of non-collateralized currency held in each account. Divide the number of recorded currency holdings by the number of units required for each ticket, and the integer obtained is
It is the total number of votes that a coin holder can vote for in the current period.

Coin holders can arbitrarily allocate the number of votes and vote for multiple candidates. However, the votes cast in each cycle are irrevocable, and the votes can only be redistributed until the next cycle.
The votes cast in each period will be recorded in the current period record and used as the basis for the distribution of voting rewards in the current period. At the beginning of the next cycle, the previous
Voting in the cycle will not be postponed, and the number of votes will be recalculated. Voting also requires token holders to redistribute their votes in order to obtain voting rewards for this cycle.

Regarding the design of using snapshots as vote counting, our original intention is to hope that token holders with liquidity needs can also participate in the operation of the chain, so vote
There is no need for token holders to pledge any tokens. When the snapshot is generated at the beginning of the cycle, as long as you hold a certain amount of currency, even if the currency is transferred to it during the cycle
Other accounts can also vote according to the amount of votes calculated by the snapshot during the current period and get rewards, but at the same time, the holdings of coins obtained during the period cannot be counted as votes.
the amount.
When designing, we gave the greatest freedom to vote. Candidates participating in the registration can also vote for themselves or other candidates, of course only those other than mortgages
Tokens will be counted as votes. For accounts with a considerable number of tokens, this mechanism allows them to better manage their own assets without having to allocate the tokens to
Operate in multiple accounts.

When the total number of candidates and total votes reach the dpos start conditions set by the genesis block, the initial candidate/validator exits the block producer list.

Block production and voting rewards

In our current plan, the accounts in the block list, the accounts of the backup candidates, and all the accounts in the block list will receive the corresponding economic incentives.
To encourage them to continue to participate in the operation of the blockchain and make greater contributions.
The block producer (miner) will get a part of the transaction fee in the block, and the other part will be distributed to the asset owner and the contract writer.
In addition to the handling fee, the community also plans to use set sustainable mining as the source of funds, and rewards the block producer's account and voters in each cycle (7 days in a natural week)
Encourage. The distribution method of this part of the reward is planned to be comprehensively ranked based on the statistical data of block producers during the period. Among them, the substitute block producer will also press
It is evaluated based on the number of blocks that should be broadcast during the replacement period to participate in the ranking. Different rankings have different proportions of bookkeeping rewards, and the sum of all proportions is 100%

Voters are based on the distribution ratio announced by the given block candidates, multiplied by the proportion of their votes in the total votes of the candidates, and the rewards obtained by the block producers are distributed. This
This means that it is a good choice to vote for more stable candidates. Of course, you can re-vote to other candidates in the next cycle.

All the above rewards are collected by means of contracts, which are called by each account.

Consensus process

-System administrator single-node block generation
-Map user assets (erc20), create a mapped user
-Create user
-Transfer
-Registered candidates/validators
-Voting candidates/validators
-dpos officially launched
-Issue assets
-Additional issuance of assets
-Release contract
-Create user
-Transfer
-Registered candidates/validators
-Voting candidates/validators
-Autonomous restoration

Before dpos is officially launched, whether to restrict assets and contract transactions

Genesis block genesis.json

{
"config": {
"bootnodes": [],
"chainId": 1,
"chainName": "set",
"chainUrl": "https://scan.setcoin.net",
"accountParams": {
"level": 0,
"length": 16,
"subLength": 8
},
"assetParams": {
"level": 2,
"length": 16,
"subLength": 8
},
"chargeParams": {
"assetRatio": 80,
"contractRatio": 80
},
"upgradeParams": {
"blockCnt": 10000,
"upgradeRatio": 80
},
"dposParams": {
"maxURLLen": 512,
"unitStake": 1000,
"candidateMinQuantity": 10,
"voterMinQuantity": 1,
"activatedMinQuantity": 100,
"blockInterval": 3000,
"blockFrequency": 6,
"candidateScheduleSize": 3,
"backupScheduleSize": 0,
"epchoInterval": 10800000,
"freezeEpchoSize": 3,
"extraBlockReward": 1,
"blockReward": 5
},
"snapshotInterval": 3600000,
"systemName": "set.admin",
"accountName": "set.account",
"assetName": "set.asset",
"dposName": "set.dpos",
"feeName": "set.fee",
"systemToken": "settoken"
},
"timestamp": 1555776000000,
"gasLimit": 30000000,
"difficulty": 131072,
"allocAccounts": [{
"name": "set.admin",
"pubKey": "0x047db227d7094ce215c3a0f57e1bcc732551fe351f94249471934567e0f5dc1bf795962b8cccb87a2eb56b29fbe37d614e2f4c3c45b789ae4f1f51f4cb21972ffd"
}, {
"name": "set.account",
"pubKey": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}, {
"name": "set.asset",
"pubKey": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
},{
"name": "set.dpos",
"pubKey": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}, {
"name": "set.fee",
"pubKey": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}],
"allocCandidates": [],
"allocAssets": [{
"name": "settoken",
"symbol": "set",
"amount": 10000000000000000000000000000,
"decimals": 18,
"founder": "set.admin",
"owner": "set.admin",
"upperLimit": 10000000000000000000000000000
}]
}

Detailed explanation of dpos parameters

-cadidateScheduleSize

The maximum number of valid candidate/validator lists (list of block producers) in each round, and blocks are randomly released. The candidates are sorted according to the total number of votes cast by the candidates.

-blockFrequency The number of valid candidates/verification blocks produced in a row in each round. Can reduce network delay and provide tps -blockInterval

Block Producer Interval

-blockReward

Additional rewards are issued for each block, and block candidates/validators are rewarded. Stimulate ecological development

-extraBlockReward

The additional reward for each block is based on the number of blocks produced by the previous block candidate/validator, and the additional reward is given to the block candidate/validator (rewarded only in the first block). Avoid the candidate maliciously overturning the previous candidate's block.

  • delayEcho

    The current block producer list, delayed round acquisition. Due to the network delay, in order to ensure that all nodes can obtain the same current block producer list and reduce forks, the current block producer list can use the block producer list N rounds ago.

  • maxURLLen The maximum url length. Candidates can provide website url to introduce their team and other information to get more tickets.

  • unitStake

    Ticket unit, N rights/votes.

  • cadidateMinQuantity

    Lowest number of votes from candidate

  • voterMinQuantity

    Minimum number of votes for token holders/stakeholders

  • activatedMinQuantity

    One of the conditions for the official launch of dpos, the minimum number of votes on the network

  • accountName

    System dpos contract account name

dpos transaction

-Registered candidates/validators -Modify candidates/validators -Deletion of candidates/validators -Voting candidates/validators

Notes on dpos mechanism

-Votes cast by voters are irrevocable in this cycle. -Voters are counted in their votes and will be cleared automatically in the next cycle. -Voters can vote for the same candidate multiple times. -Voters can vote for multiple candidates. -Candidates can also vote for other candidates. -Once dpos is successfully started, it will not fall back to single-node block production.

dpos autonomy

When the consensus fails to work or automatically takes over after the consensus fails to work, the system administrator can enable the system administrator takeover function through rpc. After the takeover, the system administrator will generate the block, and the relevant autonomous transaction can be received during the block generation period, and the autonomy will be passed. After the consensus can be restored, it can withdraw from the takeover, and there will be a list of block producers to produce blocks.

Autonomous transaction (only valid during the autonomy period)

-Set candidates/validators to enter the blacklist -Exit takeover