An Improvement to DPoS

I am here not suggesting any change to Bitshares-2, I wrote this just because I am queried on DPoS by some new blockchain projects from China, I feel but I am not sure that my suggestion provide a better DPoS implementation. hope experts can review this article and feedback, any comments will be appreciated.

DPoS is a blockchain consensus mechschanism developed by Bitshares team, here is a summary of its logic: https://bitshares.org/technology/delegated-proof-of-stake-consensus/

PoW and PoS use a lottery drawing way to decide which candidate node will be the next block generator, however, DPoS adopt a different way. Under Bitshares 2.0 version DPoS the slate of active witnesses is updated once every maintenance interval when the votes are tallied. The witnesses are then shuffled, and each witness is given a turn to produce a block at a fixed schedule of one block every 3 seconds. After all witnesses have had a turn, they are shuffled again. If a witness does not produce a block in their time slot, then that time slot is skipped, and the next witness produces the next block. Within this way Bitshares get a stable and low block generation interval.

Currently Bitshares2.0 runs well in the network layer, however, in my view, the current DPoS design still has some shortcoming and can be made better:

1.too few witnesses, while I am writing there are only 27 active witnesses working, in Bitshares2.0 the witness number comes from the voted witness number of each users, I don't think this is a good way, as users always do not have incentive to vote more witnesses, and common users always do not have enough knowledge to judge which witness work well enough.

2.risk brought by "stake is all" logic: now suppose one control 600M BTS, theoretically he can control the whole witness pool and do evil.

to overcome these shortcoming, I suggest:

1.introduce reward to witness and also the voters.
2.introduce "coinage" concept and set "destroyed coinage" as the measure for rewarding voters.
3.use another way to decide the witness numbers.

first define below parameters that can be adjusted by committee:
max_witness_number
min_witness_support_weight
active_witness_number
witness_reward
witness_voter_reward_rate
witness_voter_max_reward_limit

in each maintenance interval the witness pool will be updated, firstly all the witnesses with support weight higher than min_witness_support_weight will be selected to the pool, if the number is higher than max_witness_number, only the top max_witness_number will be kept.

and then by comparing the total coinage of voters, from the witness pool the top active_witness_number will be selected to active witness pool, and then begin to generate block just as the current active witnesses do, the difference is, both the witness and the voters will be rewarded while the witness generate a block, the witness will be rewarded a fix quantity, the voters will be rewarded proportional to the coinage of the account with the witness_voter_reward_rate, however, the whole reward to voters can not exceed witness_voter_max_reward_limit. this setting is to avoid that the voting from concentrating on some special witnesses, but encourage voters to pay attention to help more witness to work.

if it is turn for one witness to generate block, the coinage of the voter will be reset after the time and start growing from 0 with time collapse, either the witness generate block successfully or not, this setting will encourage the voters to find good working witness to vote.

when the active witness pool begin work, another pool, which can be named "ready pool" will also be selected out from the rest witnesses in the witness pool, also based on the total coinage of voters, while each witnesses in active pool has finished its turn, the ready pool will become active pool and start a new around of block generation, and another ready pool will be selected, the same process will keep going forward.

the coinage destroy process increase the cost to control witness group and bring more security to the network.