With all due respect to HQ and research team, seeing proposal to change number of votes to 1 from 101 and keeping 101 top delegates. Makes me wonder whether LiskHQ creator/creators of the idea, even read the topic from github. It’s the weakest idea from entire github thread, but the easiest one to implement, one change in constants and force drop old nodes.
It will lead to chaos, some delegates from groups will rage quit, and possibly liquidate all their holdings pushing price to bottom. 1 vote per account increases risk of rich addresses voting their own nodes very easily, much lower entry point. It will also force some end users to just split funds to few different accounts if they decide they want to support more than 1 delegates, if not it will just make people vote for delegates sharing 90-100% rewards, which is also pointless, in that case it’s better to follow Ethereum way and move to POS, but this isn’t great route either.
Much better idea, with similar positive effect but less/no negative consequences is to simply split vote weight between voted delegates, as a voter there is problem to keep up with all the delegates and keep up with work and news they do (if any ) Splitting vote weight proportionally among voted delegates, allows voter to actually choose the number of delegates, they are comfortable to keep close look at, otherwise, most people vote full 101 and do nothing with verification whether they do some work or not and if shared percentage is accurate - in result, most delegates do nothing and defend themselves by saying that running node is enough effort.
Lisk DPOS can and could actually work fairly well in scenario when there is SDK out, however, no one would have thought that here in 2019 there is still no sdk. This pathological situation created sharing, which is really bad, and essentially pointless, these days it translates well to how politicians bribe citizens with all the “financial benefits / free money from government in any form” which are actually eventually paid by working people to the leeches, just to keep ruling party in power. 1 vote per account will just increase speed of this degradation.
How Lisk DPOS can be actually and significantly improved?
SDK, SDK and once again SDK. Most people are stupid and cannot think of anything else than SHORT TERM GAIN. Regular voter, who can vote for one delegate only, will just browse delegates find someones who shares something close to 95-100% and they are good to go, they won’t care any more than this. Thing is to place incentives in the right place, this is how proof of work works so well economically, it puts incentives in right place.
Who is/should be ideal delegate?
Group of people / team / company / foundation / talented developer working on some blockchain project based on Lisk. Most people won’t vote for such delegate unless they can make money, directly, short sightly, substantially. Such delegate, should share % of tokens in their project, proportionally to received vote weight on Lisk network. This gives huge incentive for voters to seek good delegates/projects to vote for, instead of voting for the ones sharing the most. This is actually very close to proof of work, but not the mathematical proof of work, but proof of development work. LiskHQ should at least verbally approve only this model and disapprove sharing and admit that this is consequence missing part of Lisk called SDK. Without SDK, We will never see how it would work correctly.
As delegate, whoever says that running Lisk node is such hard work and that it’s enough, they don’t need to do anything, it’s so hard, they need to keep network secured and that’s enough, should feel ashamed.
However, there are some things to improve in Lisk DPOS
- Proportionally split vote weight between votes you make, no vote cap. there will be rational vote cap based on individual abilities to track voted delegates.
- Slightly increase rewards for higher positions in Lisk network with the extension of top forging positions, 50-100 more forging slots would be much better, it has some drawback, but with SDK out this could be really beneficial for development of Lisk ecosystem. Perhaps creating rewards group, just for indicative reasons:
Group 1 - (delegates rank 1-33) - 40% of reward
Group 2 - (delegates rank 34-66) - 25% of reward
Group 3 - (delegates rank 66-100) - 20% of reward
Group 4 - (delegates rank 101-130) - 10% of reward
Group 5 - (delegates rank 131-150) - 5% of reward (perhaps, not by value of block, but by chance of forging block/getting the forging slot)
(Total inflation remains the same, % above indicative)
- Creating delegate punish mechanism, along with solution number 2, there might be some risk of downtime from delegates from lowest rank / group which does not have good enough incentive to maintain best productivity, even though they should have enough incentive to get to higher rank, it would be good to have mechanism to ban them permanently from network, lower rank - easier to get banned as delegate. Possibility to unban as transaction with very high fee, depending on rank.
4.(rather optional) Project funding, similar to the one from Dash Masternode network, reducing reward to delegates by for example, 10%, reserving to the the proposals coming to the network. People and/or delegates could vote for best proposals, some sort of event/one time job for lisk ecosystem thing.
This can, increase a bit processing times in Lisk network, but economically and in matter of decentralisation in can be very beneficial. It will solve many problems, as well problem with NO COMPETITION between top delegates whatsoever. Some delegates who fought for top101 did a lot of work, but after getting there, do nothing, reward groups in top forging nodes will solve that as well.
Really, idea with one vote per account is disappointing, really bare minimum of thought. As delegate and member of Lisk community I don’t even have words to say how disappointing it is.
If someone feels like assembling this into fancy looking academic document, publishing it and submitting this as official LIP, feel free to use these ideas, MIT license on these I don’t need to be included there, I don’t care, if anyone wants to discuss it on lisk.chat feel free as well. I might assemble it into LIP later, currently I don’t have enough time to write it in academic style, nor I like to do it, but really, it isn’t necessary, essentially it’s all here.
Either Lisk goes the right path or the easy path.