Solutions to improve Lisk DPoS

[ghost]

I think current Lisk DPoS is way to centralised and vulnerable to many attacks. One person with big wallet can possibly up vote all his 101 delegates to top 101 forging with current implementation. There is also risk that delegates will stop forging and network will stuck so new ones will be impossible to pick, it seems it was problem in Crypti. When price is falling incentive to run node is getting smaller and smaller.

Possible solutions:

• Making Lisk DPoS more decentralised by lifting up forging delegates up to 202 (to avoid issues with accounts which did make 101 votes already, it will also require halving reward) and keep possible votes to make at 101, so each account will be possible to chose only 50% delegates, this way single person with big wallet won't be able to take over network. This will actually reduce vulnerability to this type fo attack and make network more decentralised, this will also prevent/reduce buddy-2-buddy / vote-4-vote scheme which discourage new people to become part of Lisk ecosystem.

• Implement mechanism which will pick closest standby delegate as forging one when any of Top forging ones failed X times to create block, along with function which will check if previous delegate recovered itself so forging power will be granted back. More or less, should be discussed.

Even after implementing those ideas, there still will be few things to improve, but this will be big step forward. Will post few more possible improvements in upcoming time.

[mrv777]

One if the reasons 101 is currently used I believe is because of the 10 second blocks. Speed is important as forging nodes need to try and keep consensus. If you double forging delegates, you double the nodes that need to stay in sync. While this is all possible, I believe more optimizations to the code may be necessary before something like that can happen. Disclaimer: This is just my understanding of it all :)

[ghost]

Of course round will be longer or/and reward halved, there are few possible solutions.

[densmirnov]

Why raising the number of forging delegated, when you can simply limit the number of possible votes to, lets say, 50? It's not the complete solution, but it will work better against 101 attack.

[ghost]

Because many accounts did make more than 50 votes already, i think it will be quite hard to make everyone to remove votes, other-way it requires more messy hard-fork.

[ghost]

There are other possible approaches to improve DPOS

• Split votepower among votes made, this has been already proposed by @4miners as far i know

• Another idea is to not only extend number of top delegates, but increase competition between top delegates by making block rewards higher for those with higher position and smaller for those with lower rank, this can possibly significantly increase competition in top delegates and create some more space for top delegates. Some people can even enjoy being active delegate with 0.1 LSK block reward with lower rank, this is at least something what can make development around Lisk ecosystem more active. As soon dapps sdk will be ready, then small reward delegates may fuel small dapps creation while bigger projects can get more revenue for development etc. Increasing number of delegates, in addition with less revenue per block has some drawbacks, although nothing what can't be solved. like more stable core client with built-it failover on different servers and setting different forging delegate if top one failed X times and more.

[simonmorgenthaler]

it would be very interesting to see how dpos works if the votes are anonymous, meaning you only see the total approval rate on a delegate, but you don't see who or how many voted for it.

[mrv777]

A few other ideas:

1. Voting weight of an account = The square root the balance of the account --This should help balance large accounts vs small accounts. However, I know big accounts can split their funds, but I'm not sure to what extent they would.
2. Voting weight of an account = Balance - (Balance (#delegates they voted for.005)) --I think this is better than just (balance/#votes), but still promotes being more selective with votes. (ex. An account votes for 100 delegates, those delegates only receive 50% of their weight, but if they vote for just 1 delegate, that delegate gets 99.5% of their weight)
3. Voting weight of an account = Balance, until 50 votes then lose 1% of weight for every additional vote. (ex. an account that votes 101 delegates will only vote at 49% balance to those delegates) --While I think its too difficult to set a lower voting limit on accounts at this point (ex. each account only gets 51 votes), this can achieve a similar result in rewarding more selective voting choices and make it more difficult for one big account to get all 101 spots.
4. Delegate weight = 0.8(votes) + 0.2(votes*productivity in last 30 days). --If 30 day productivity > 0 and 30 day missed blocks > 10. This would reward well run delegate nodes (Should add a double forging penalty too, ha)

I would personally be interested in seeing the results with 2, 4 and maybe 1 were all used.

Disclaimer: I'm not saying we should use all of these ideas. They are just my random 4am thoughts, where I didn't double check any of the math and being such, please point out any flaws.

[2mdoty]

from karek314 - "Split votepower among votes made, this has been already proposed by @4miners as far i know"

This is what I have proposed since when I first saw the current Lisk voting system in Crypti 2 years ago. We are currently implementing this in Ark, ark.io . We are keeping the ability for delegates to see who voted for them to encourage profit sharing with voters in the form of direct payments, equity shares in funded projects run by delegates, and non-profit community service type projects.

[Isabello]

Lisk DPOS - The current implementation and its problems

The current incarnation of Lisk continues on the tradition of Delegated Proof Of Stake. In the implementation we have inherited all of the problems and issues with the protocol that were present in Crypti and by extension, BitShares. While these problems are not terribly pressing, we should look to address them.

Current State:

In the existing implementation, every wallet address is given 101 votes to assign as they choose. These votes carry a set amount of weight based on the total amount of LSK found in that wallet. There for every user is actually granted (Stake * 101) in power to influence the network. Each account can only vote for another account once, this means is only allowed to apply its full stake to another account once.

Extending the concept of 101 votes, we have 101 delegates. These delegates are tasked with securing the network by signing transactions into blocks and broadcasting those blocks onto the network, pushing the blockchain forward and sealing data into its immutable structure.

In this current state we are subject to some faults. Here is a list:

1. One individual with a high amount of stake can overtake all others on their own. Currently, a user only requires 19.44% of all available lisk in order to secure all 101 delegate slots.
2. A group of individuals can effectively reproduce this attack by securing most or all positions within the 101 delegates. Once they have achieved control of the network, nothing stops them from implementing a forked copy of the software on all nodes/delegates involved. This essentially provides them unfettered access to do as they please, accept or reject transactions they choose and more.
3. With a majority stake in delegates, control is basically guarenteed. These users will continue to get richer and richer, creating a higher and higher barrier to entry for anyone looking to join the elite ranks of the 101.

These issues are present in most implementations of DPOS, but they are more pronounced in Lisk where all of the available Lisk was purchased during the ICO and only recently has more Lisk been added to the system in the form of forging rewards. These rewards carry the problem mentioned above.

Future State:

In order to resolve the deficiencies mentioned in the previous section, we must address some of the core assumptions. These core changes are listed below:

1. To address the 101 vote and stake attack, we must change the amount of votes every account is allowed. The most desirable number ends up being 33 votes per account. This is the most amount of votes that can be included in a single transaction. Now in order for an evil agent to overtake the entire network they will require 60%+ of all LSK to secure every available delegate position. Mathematically, this looks like (STAKE * 33) for the amount of power a single stake can apply.

2. Further limits should be placed on the value of a stake. The recommendation is to reduce the total amount of weight a stake carrys when spread across more individuals. Therefor, we should change from (Stake 33), to ((Stake 33) / VOTES). This further increases the required amount of funds to attack and control all 101 positions.

Additional Improvements to the Algorithm

Fostering external interest is also on the agenda. Currently, if you aren't in the 101, you probably won't be, unless you cut a deal with groups like GDT or other large holders. In an effort to reduce the amount of control large groups like this have, we must look at other options for incentivizing standby delegates.

One initiative is to move to a two tiered system. A hybrid of DPOS and ALGORAND by Silvio Micali. In ALGORAND, blocks are generated by a Round Leader and subsequently validated by a pool of signers. In Lisk, we already have a Round Leader for every block in the form of delegates. To extend the concepts of ALGORAND for our purposes, we will look to include Standby delegates as the block validators. A subset of standby delegates will be selected after every block is forged to participate as block validators. This second layer of consensus will work to ensure that the blocks coming from delegates are not only secure, but valid.

A reward to standby delegates who participate as block signers will be given. The current proposal is that they will receive part of the blocks fees, and part of the forged lisk from that block. Validators signatures will be weighted based on the STAKE voting for them, so that standby delegates who are closer to the 101 will be chosen more often. This prevents an attack from an EVIL user who could generate hundreds of accounts to gain an advantage over others. While this will still be possible, its effects are greatly diminished by the voting and stake application changes mentioned in the previous section.

Other important (Potential) changes.

Within the current system we are faced with an ever present issue with voting. Users vote once and thats the end of their engagement. Theres never a reason to change or remove a vote. Theres no incentive to do so.

Therefor, we look to implement a system of VOTING DECAY. This decay system will diminish the stake value of a vote until a new transaction is put onto the chain reapplying the vote(s). To extend this concept, we will look to limit the "Terms" a delegate can serve. The basic idea behind this is so that new delegates can enter into the 101 more frequently. Delegates who have been removed from the 101 by having votes decay will enter into a COOLDOWN phase where they cannot be voted back into the 101 for a set time period. They will be able to serve as a block validater during this time period, though.

Following up on the concept of voter decay, we need to reward people for voting more than once. To this end, we look to provide all voters of a block signer/validator a small slice of the block rewards generated by those delegates. While this value may not be huge, it should be enough that people will want to vote for users.

Closing Sentiments.

DPOS has some fundamental issues, and we aim to address them by adapting some concepts from ALGORAND and using our existing infrastructure in conjunction with those changes. Expanding on those changes we aim to create more engagement and increase the fluidity of the overall system, allowing more individuals to participate within the confines of the 101 system. I believe these changes will be very important to allow Lisk the room it requires to grow and evolve.

[mrv777]

First thoughts for me is a combination, but prioritized by complexity: Now VOTING STAKE = Balance-(Balance (#delegates they voted for.005)) I prefer a linear decrease over STAKE/VOTES as it decreases stake too fast and by too much in my opinion.

In between unless it's very easy to do 33 Vote max if change to voting stake wasn't enough of a change as these two do somewhat similar functions (encouraging accounts to be more picky with their votes and prevent a large bag holder from buying all 101 spots) (If this is added with the linear decrease, I would increase the reduction per vote mentioned above by about 3x to keep it similar)

Future after new SDK is working Voting Decay and ALGORAND. These are very interesting ideas. ALGORAND sounds like it would be complex to add, but if it adds to the security of the system it may be good to have.

[Phoenix1969]

What about complete randomization of forging delegates? (ducks under desk)

and progressive timeout bans for missing blocks or similar...

[dakk]

@Phoenix1969 if you randomize the forging delegates without considering votes, one person can create more delegates account to increase his probability to forge more blocks in a round

[simonmorgenthaler]

Reducing the possible votes to 33 is in general the same as dividing the Voting stake through 3 (because you can split your account into 3 accounts, and vote with every account 33 different delegates, which result in the same 100 votes, but with a third of the weight).

I agree with mrv that dividing the STAKE/VOTES is too harsh and leads to the situation where delegates only vote for themselves. I prefer a more sophisticated formula like the one mrv suggested, or the square root of the amount or something like that.

I like the idea of the VOTING DECAY

An I think also the idea of automatically remove a delegate from the active group if he doesn't forge for a specific amount of time might be a good addition.

Will follow up with other thoughts :)

[2mdoty]

Think this all sounds way too complicated and will lead to unintended consequences. It is much simpler to just divide an account's voting weight by the number of delegates voted for and apportion it equally among the votes. We are also looking at adding chainable proxy voting for Ark to enable Liquid Democracy applications, so an account can assign another account to vote for it, which in turn, can assign its cumulative voting weight from the proxies to yet another account.

The use of standby delegates as automatic backups to replace non-functioning delegates is a very useful improvement since there is currently no way to replace an non-functioning delegate which still has sufficient vote to remain in the top 101.

There may be some merit to lowering the maximum number of votes and applying some sort of algorithm to adjust voting weights based on number of votes cast, but between the Ark system of simply dividing the vote and the current Lisk system, we'll have real data from the two extremes to define a range of expected behavior.

[2mdoty]

Also keep in mind, that it is a challenge already to encourage people to vote, so any additional complexity added to voting will reduce participation even further.

[mrv777]

I like the idea of proxy voting. Have that tx be just 0.1LSK too. That way people that are too lazy or don't have time to keep up with votes can just give some else they trust permission to vote with their weight. Can also expire, like NXT's balance leasing maybe

[2mdoty]

Ranked voting, where the order of the votes applies a multiplier, so if 10 are voted for, 1st choice multiplies stake by 10, second by 9, and so on down to 1X for 10th choice.

[stenea]

I would rather have lisk team focusing on sidechain SDK instead of finding workarounds on current DPOS consensus mechanism. @karek314 one person taking over all the 101 delegates would kill lisk, it makes no economic sense to try to do such a "power-play" because nobody would trust lisk anymore. People invested(and still are) time or money in lisk for being the first blockchain sidechain framework developed in JS, not for improving DPOS. I would like to have lisk remembered as the first blockchain framework that allowed sidechain not as the blockchain that reinvented DPOS. That's not lisk mission. And having lisk team even thinking about this, while there are a lot of other important things to be done, I think it's just affecting lisk and not in the way we all want.

[Doweig]

My 2 cents on few things:

To address the 101 vote and stake attack, we must change the amount of votes every account is allowed. The most desirable number ends up being 33 votes per account. This is the most amount of votes that can be included in a single transaction. Now in order for an evil agent to overtake the entire network they will require 60%+ of all LSK to secure every available delegate position. Mathematically, this looks like (STAKE * 33) for the amount of power a single stake can apply.

I strongly agree with this one. I really believe that the Number of votes per account should be LESS than the number of forging delegates.

One individual with a high amount of stake can overtake all others on their own. Currently, a user only requires 19.44% of all available lisk in order to secure all 101 delegate slots.

This is also true on any PoW blockchain, if you spend enough $$$ you can take over the network. But in reality, no one will spend millions of $ to double spend a few LISK and get his millions in holding collapse. However PoW is largely seen as the most secure consensus algorithm.

Therefor, we look to implement a system of VOTING DECAY. This decay system will diminish the stake value of a vote until a new transaction is put onto the chain reapplying the vote(s). To extend this concept, we will look to limit the "Terms" a delegate can serve. The basic idea behind this is so that new delegates can enter into the 101 more frequently. Delegates who have been removed from the 101 by having votes decay will enter into a COOLDOWN phase where they cannot be voted back into the 101 for a set time period. They will be able to serve as a block validater during this time period, though.

It would be very hard for a voter to keep track of all 101 votes and refresh/change them when needed. Most people even do very little due diligence before voting at the moment. I think the effect will be to just lower the approval % needed to get into the 101 because people just forget to revote. Therefore making the network easier to attack

One initiative is to move to a two tiered system. A hybrid of DPOS and ALGORAND by Silvio Micali. In ALGORAND, blocks are generated by a Round Leader and subsequently validated by a pool of signers. In Lisk, we already have a Round Leader for every block in the form of delegates. To extend the concepts of ALGORAND for our purposes, we will look to include Standby delegates as the block validators. A subset of standby delegates will be selected after every block is forged to participate as block validators. This second layer of consensus will work to ensure that the blocks coming from delegates are not only secure, but valid.

An easier and just as effective way to make regular holders to get a share of the newly created tokens would be to have more pools forging. On the security aspect, if we judge the 101 forging layer to not be secure enough, the problem should be addressed on that layer, not adding an extra layer of validation. Like for example having a block to be signed by multiple delegates before being considered valid (a la STEEM)

Further reading on DPoS concerns and possible improvements: https://github.com/cosmos/cosmos/issues/43

My own proposal on Number of Votes per Account (Draft): https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-2.md https://github.com/ArkEcosystem/AIPs/issues/1

[mrv777]

@Doweig Good input, thank you

My thoughts on the vote weight splitting: You don't really need this and to limit # of votes. People will most likely severely limit their votes with the halving. Most likely I think it will result in this out come: Regular Holders - most likely just placing 1 or 2 votes and most likely with pools. A few unselfish holders may vote outside pools and themselves, but with halving it could have little effect depending on how many votes they make Greedy Whales - most likely place <10 votes spread across pools and themselves Unselfish Whales & Core team - Only groups I could see placing more than just a handful of votes and voting for delegates other than just themselves and pools.

Overall, I think applying any penalty to voting weight will limit the number of votes an account will want to make so may have little additional effect when combining the two.

I think halving is too aggressive though and will result in the 101 being mostly a combination of pools & greedy whales, if Unselfish Whales & Core team can't even it out (which in the long run they won't be able to maintain since they will most likely not be forging). I would prefer more of a linear decrease in voting weight (0.25-0.9% decrease of account balance with each vote).

[karmacoma]

I would rather have lisk team focusing on sidechain SDK instead of finding workarounds on current DPOS consensus mechanism.

The blockchain application platform is getting absolute focus. Structured brainstorming sessions are being conducted everyday, and great progress is being made here towards SDK implementation.

Despite what some might think or say, we are very glad to see open and frank discussion on how we can possibly make the current DPoS implementation fairer. The set of proposals brought forward by @Isabello was as a result of a brainstorming session we held, and is by no means the authoritative solution.

[mrv777]

Thought of another idea, but this one may be unnecessary and just add too much complexity. Wanted to write it down though, just to note:

What if with each vote, you had to assign a percentage of your balance to go with it. In increments of 1% and they combined for no more than 100%: Example: I place 3 votes.
Vote A I want to get 50% of my weight Vote B gets 20% Vote C gets 15%

And I'm left with 15% of my weight to vote with if I want or I don't have to. Trying to place Vote D for 16% would result in an error.

[stenea]

@karmacoma I get it. And I know you are brainstorming about sidechain SDK. It's just that it seems too early to think about this while there are still so many things to do. I would prefer having you focusing and talking 100% about sidechain SDK instead of improving DPOS.And that's available for us too. Maybe we can help you on SDK instead of brain-squashing on how to change the current DPOS.

[corsaro1]

Most part of the listed proposal are excellent and it will be great to see them applicated. Anyway I think dpos can be perfected as soon as we'll have a working Lisks's App SDK to create sidechains and dapps.

[Isabello]

The SDK and DPOS can be thought about at the same time. We have the resources to do both.

[Odsejen]

There are great ideas to improve the current system, but i remember one of the last milestones was "mainnet stabilization" (just saying). A new forging model may be necessary and for security reasons the ALGORAND approach looks like the most interesting and sounds like necessary on the long run.

A reward to standby delegates who participate as block signers will be given. The current proposal is that they will receive part of the blocks fees, and part of the forged lisk from that block. Validators signatures will be weighted based on the STAKE voting for them, so that standby delegates who are closer to the 101 will be chosen more often. This prevents an attack from an EVIL user who could generate hundreds of accounts to gain an advantage over others. While this will still be possible, its effects are greatly diminished by the voting and stake application changes mentioned in the previous section. <<

It can be combined with whatever, a.e "voting decay", "more/less delegate spots", "more voting activity ->(leads) to a higher probability to get a validator spot" .. seems endless. My favorite is increasing the spots to 200 & halving the rewards with a forging reward ranking (the higher the more) and some additional changes to voting power or votes per se, but for now i would stay with a running system and further improve & adapt the core, sidechain integration and sdk, with this in sight also new possibilities for governance models and therefore DPoS systems can occur which could give even more and wider prospects (a.e. a flexible core in which forging-parameters can be elected in a given frame, the integration of sidechains etc.) . I think the majority is now more likely interested and focused on stability, value(preservation), usability and especially use-cases. And what about a second Testnet in which we're just trying discussed changes to dpos, think could be a good idea.

Views are different but in my opinion we have currently a very nice group of different persons, GDT or NON-GDT, as there is a big difference, whose a lot of them followed Lisk since start and a lot new great delegates, i think the big majority here are interested to make Lisk a fresh, nice experience & investment. Exactly these group of all our current delegates cooperating with the LiskTeam and each other, are i.m.o able to prevent many many sorts of attacks and will hopefully find a good consensus about this topic.

just my 2 Lisk.

[mrv777]

Also, vote limiting can be added with my linear decrease of voting weight. Currently, if you decreased voting weight by 1% after the first vote, vote 101 would remove all your weight. Example: 1 vote = that delegate gets 100% your weight 2 votes = both delegates get 99% your weight 100 votes = each delegate gets 1% of your weight 101 votes = each delegate gets 0% of your weight

if you increased the decrease to 2%, no one can really vote for more than 50 delegates as it would set your voting weight to 0 for all voted delegates

I still prefer something in the 0.5-1% range though

(Just writing down ideas again :) )

[corsaro1]

I think it could be fine too choosing at each forging round the 101 forging delegates, among the first 150-200 delegates, with an higher probability to be choosen based on:

• more closer to 1st rank
• less missed blocks

So doing even delegates outside the first 101 position could be randomly called to forge a block, making the community more participant in the process of forging. At same time, even if a delegate is in the first 101 slots, and he has too much missed blocks, he could not be included in all rounds, due to the fact the algoritm could prefer on some rounds at its place a delegate in rank > 101 with better performance.

The result would be a less rigid border between standby and active forgers.

Just my 2 cent

[wariner84]

@corsaro interesting ...+1

[mrv777]

I have another idea that may not be too difficult to implement that would help the system. What about an expiration on a voting transaction? Maybe 1, 2, or 3 months?

[Isabello]

weve discussed vote weight decreasing over time require reapplication but technologically it introduces some unneccessary complexity

On Wed, May 3, 2017 at 2:01 PM, mrv777 notifications@github.com wrote:

I have another idea that may not be too difficult to implement that would help the system. What about an expiration on a voting transaction? Maybe 1, 2, or 3 months?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/LiskHQ/lisk/issues/353#issuecomment-298891248, or mute the thread https://github.com/notifications/unsubscribe-auth/APzFsEJN0mkfIaFDv95XPjDw01n7j1r2ks5r2Gx9gaJpZM4LKAVd .

[mrv777]

I'm not just talking about decreasing or decaying though, but actually expiring the vote. If a vote is X days old, it's no longer valid

[Isabello]

And how do we handle this during synchronization? It needs to be X blocks old, not time.

The problem with expiring the vote is it creates alot of uncertainty, those transactions still exist but we ignore them after a certain round? It touches memory tables more than I am comfortable since those transactions are valid until the end of time. So we create a hard fork situation where new transactions can expire? If we implement this today, right now, most votes would expire immediately, yes? This is not the way.

[Isabello]

Additionally, if votes expired, someone would just create a script that automatically removes and revotes delegates just before the time is up. It does not solve the problem.

[mrv777]

Sorry, I meant X blocks.

It should take the same effect as if they did a remove vote tx. It's just done automatically instead of by the user. Yes, someone could create a script. However, it should fight against people that just leave since they would need to still have that script running somewhere and the version they are running would still need to work.

Again, just an idea.

[Isabello]

Its an idea weve discussed a few times here internally but the end result is that its just not feasible. The user has made a decision on their vote and we should not mess with that. Their vote is immutable and should remain until they withdraw it.

[simonmorgenthaler]

On the other side, for example the president needs to be reelected every four years. In other words, the vote expires after 4 years and needs a reapplication then. I think it wouldn't be a problem for the users if it is very clear from the beginning that a vote is valid until withdrawal but at max for X blocks. I think it indeed could make the 101 list more vivid.

[Isabello]

Nobody agreed to these terms when they first voted. This is what makes such a change a hardfork.

[ghost]

Expiring votes is just not convenient at all for end user. Not even considering other aspects. Firstly there should be implemented as soon as possible, something more or less like limiting one account to be allowed pick 50% of current delegates forging instead 100%. There was also many other decent ideas out here in recent posts to consider, there is no single silver bullet solution so it will be nice to pick best ones and implement along with other. Generally speaking those changes should be made sooner than later, because as lisk price grows it will become harder to depose current delegates if new system will threaten their position. It will be similar story as with Bitcoin, never ending war.

Dpos seems to be quite good, but needs changes mentioned here, currently one entity can easily upvote all delegates to top101 this doesn't sounds like decentralised yet.

Apart of that, Hard fork is not scary or bad at all, sort of we already had fork in past. The hard one, specifically soft-hard-fork. When network cut off nodes below 0.5.0 (or 0.6.0 i'm not sure which version).

[hoklitrail]

I would suggest a system where delegates have to keep a fixed percentage of their forging rewards as "proof of stake" meaning they can't sell it as long as they are a delegate. If they sell, they automatically lose their position. May not be as easy to implement as it sounds. Just an idea...

On top of that they get punished if they run a node that has a lower uptime than the average across all nodes. So if the average uptime is 99.5% then you get punished for each tenth of a % that your node is below that number which will mean you drop in your ranking. So ranking is no longer based on votes as you can only be voted for to become an active delegate but your rank depends on the service you provide. The better it is, the higher you go.

If we reach a point where all the active delegates are running close to 100% uptime then that would be the best outcome we can imagine and there's no reason to kick any of them out, bar any wrong doing. I'm not saying this is going to work. It's basically a point of discussion that may add something constructive to the debate.

Personally, I believe the end of pools is coming quickly anyway as they will lose most of their appeal the more voters we see coming on board. Their payouts will drop (and already have) significantly and it will become more attractive for people to vote for individuals again.

In the end, we have to realise that the Delegate Proof of Stake System is utterly problematic to begin with. It solves the issue of "big miners" Bitcoin is suffering from but it just shifts the problem to another area.

As long as people get paid for their votes, the system can't survive. The idea of paying somebody to vote for you is the most corrupt system imaginable. As others have pointed out, it would be illegal in any decent democracy and surely can't be a sustainable way going forward. This is the biggest grief I have with LISK right now.

I'm looking forward to a list of delegates that offer an actual service instead of just a percentage of their earnings to keep their voters happy.

[georeith]

I would suggest a system where delegates have to keep a fixed percentage of their forging rewards as "proof of stake" meaning they can't sell it as long as they are a delegate. If they sell, they automatically lose their position. May not be as easy to implement as it sounds. Just an idea...

Many delegates have promised a large chunk of their reward to voters. We don't want to disincentivise voting.

[chauey]

We need to be able to vote to ban people from being delegates who are not acting in the best interest of Lisk, like actively campaigning against Lisk and selling all their LSK? Need help to make more visible/apparent who is doing what and be able to respond more quickly and inexpensively ;)

[mrv777]

who decides who gets banned? if it's other accounts, isn't that the same as unvoting them? and what's stopping them from making another delegate?

[kctdfh]

I think it'd be beneficial to have 2 kinds of votes: vote of confidence and vote of no confidence.

If you think about it, since you can withdraw your vote from a delegate, by voting you're essentially saying "I support you until I don't". This is not how ballot democracy works because when you vote for a president, your vote is good for a full term. So to call the DPoS system 'voting' is not correct I think.

The better characterization here is a vote of support. Currently there's two positions - no vote and vote of support/confidence. But the problem (as extensively discussed) is that a small number of whales can elect their preferable delegates because of their huge vote weights. This is because the masses, with small wallets, can't in any way devalue the whales' vote. If there is a way to say "I support you until I don't", there should also be a way to say "I don't support you until I do".

If we had 3 possible positions (vote of confidence and vote of no confidence and no vote) then the masses could recognize collusion as it arises (since votes are public) and could roll back big votes. In the case of no confidence, your vote weight would SUBTRACT from the total votes of a delegate.

And technically I don't think this needs a fork because votes in the past still count the same as they did before the addition of the second vote type.

I think it's more fair this way because if whales can plan to overtake the delegate list, the smaller wallets should have the power to similarly plan and overthrow them. The higher the value of the coin, the worst our current situation will get.

[desjob]

We need to be able to vote to ban people from being delegates

How? it's decentralized. You could do it by voting, but then the vote will be worth the amount of LSK held by the vote caster, thus leading to the exact same problem. There is by definition no censorship on who can run as delegate, and people can register as many account seeds or delegates as they want. Only factor in play is maybe the delegate registration fee, but at this level that is negligible.

[smmujahid]

If the problem of delegates control is not resolved. we would perhaps encounter more forks than BTC, thus destroying the whole system

[coolrunnings16]

I'm afraid that things are starting to blow out of proportion judging from the Lisk Reddit community. Things are getting heated between investors and delegates. Censorship in the Lisk subreddit has only fueled the anger and frustration of voters. The situation needs to addressed as soon as possible, this simply cannot continue. It's only going to tarnish and undermine the work put in by LiskHQ. I suggest that the idea of pools should be scrapped and delegates not allowed to vote for each other. 55 members controlling the network and setting their own rules is simply not a consensual democracy. It's a completely centralized concentration of power and it's only going to worsen as project becomes more entrenched in society and LSK tokens gain value. As an investor I urge you to address this issue as soon as the rebrand is implemented and Alpha SDK is released.

Thanks, Michael Riordan Ireland

[DiederickJacobs]

@coolrunnings16 i agree!

[fastfalcon94]

I think the whole voting system needs to be reworked. Problems I see with it:

1. 1 LSK for 33 votes is stupid when there are 101 delegates. To get all the votes in you are wasting 1 LSK (Currently $10) just for 2 votes

2. Also every delegate is different. Some are single, some are groups, some require you to do extra stuff (register elsewhere, vote for all members, different LSK payout). This is beyond confusing to keep track of.

3. The threshold and current LISK fee is awful if you do not own thousands of LSK. If you own 400 LSK it would cost you $40 to vote right now. It could take months (assuming the people you voted for are even in the top 101) for you to reach a threshold where you'll get pay. Maybe 0.2 LSK from someone will come to you but you'll lose half in fees. This is the only semi-good thing about pools is that a pool of 30 people could combine your rewards and you only eat the transaction fee once.

4. Eventually it's going to create a monopoly of delegates. Say all the delegates in the top 100 pay out 80%. A new person comes along. They offer something better, 90%. People are going to be hesitant to vote for this new person because they realize the hurdle that needs to be crossed for him to make it to the top 101. They are going to stick with the 80% person as they know there vote will stay in the top 101. Eventually you are going to get 101 delegates that earn so much that no one will be able to overtake them.

How would I do it?

• Change the voting system to a membership fee instead. Make it so 2 LSK gives you 101 votes per month for a year. Eventually as price rises you can lower the membership fee. This will make it simpler and not waste 1 LSK for 2 votes.

• Get rid of the vote rolling over. Ever month you have to re-vote. This will encourage fresh blood in the delegate pools. It will also encourage community involvement.

• Make it so that if you are a delegate and send money there is a smaller fee (or no fee). This will help people will smaller LSK balances earn more and encourage monthly payouts. It also will get rid of stuck LSK if you have a 0.1 balance for a delegate that is no longer in the top 101.

Also I would make a 2nd subsection for delegate advertising. It's annoying to see the same people posts "vote for me" ads in the reddit pages and forums. Keep that clutter separate.

[ghost]

One idea came to me mind, it can be implement along with other solutions. This system would make DPoS more competitive and cartel-proof.

I will explain this by an example, it should be pretty straightforward to implement. Total number of delegates extended to 201, or number of delegates managed dynamically. top 101(or any other number) - receiving constant block reward. For example 2LSK. All other position from 102 to 201, proportionally less according to rank. Example, delegate 133 - reward 1.1 LSK, delegate 150 - 0.8 LSK, etc. (all of course matching assumed inflation scheme)

It would make DPOS more competitive and active. Lower rank delegates in future could easily fund smaller projects, tools while full top delegates bigger ones. This can be also used with feature to punish delegates which double forge/miss blocks from forging for X blocks and replace with other chosen delegate from 102-201 or even 201-300 range (incentivising non-paid standby delegates to keep their nodes up and running), this has con, might cause some instability with block creation. Worth considering anyway.