New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solutions to improve Lisk DPoS #353

Open
karek314 opened this Issue Dec 11, 2016 · 83 comments

Comments

@karek314

karek314 commented Dec 11, 2016

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

This comment has been minimized.

Contributor

mrv777 commented Dec 11, 2016

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 :)

@karek314

This comment has been minimized.

karek314 commented Dec 11, 2016

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

@densmirnov

This comment has been minimized.

densmirnov commented Dec 13, 2016

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.

@karek314

This comment has been minimized.

karek314 commented Dec 13, 2016

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.

@karek314

This comment has been minimized.

karek314 commented Jan 31, 2017

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

This comment has been minimized.

simonmorgenthaler commented Feb 7, 2017

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

This comment has been minimized.

Contributor

mrv777 commented Feb 8, 2017

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

This comment has been minimized.

2mdoty commented Feb 8, 2017

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

This comment has been minimized.

Contributor

Isabello commented Feb 8, 2017

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

This comment has been minimized.

Contributor

mrv777 commented Feb 8, 2017

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

This comment has been minimized.

Phoenix1969 commented Feb 8, 2017

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

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

@dakk

This comment has been minimized.

Contributor

dakk commented Feb 8, 2017

@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

This comment has been minimized.

simonmorgenthaler commented Feb 8, 2017

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

This comment has been minimized.

2mdoty commented Feb 8, 2017

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

This comment has been minimized.

2mdoty commented Feb 8, 2017

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

This comment has been minimized.

Contributor

mrv777 commented Feb 8, 2017

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

This comment has been minimized.

2mdoty commented Feb 8, 2017

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

This comment has been minimized.

stenea commented Feb 9, 2017

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

This comment has been minimized.

Contributor

Doweig commented Feb 10, 2017

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:
cosmos/cosmos#43

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

@mrv777

This comment has been minimized.

Contributor

mrv777 commented Feb 10, 2017

@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

This comment has been minimized.

Member

karmacoma commented Feb 10, 2017

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

This comment has been minimized.

Contributor

mrv777 commented Feb 10, 2017

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

This comment has been minimized.

stenea commented Feb 10, 2017

@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

This comment has been minimized.

corsaro1 commented Feb 10, 2017

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

This comment has been minimized.

Contributor

Isabello commented Feb 11, 2017

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

@Odsejen

This comment has been minimized.

Odsejen commented Feb 11, 2017

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

This comment has been minimized.

Contributor

mrv777 commented Feb 12, 2017

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

This comment has been minimized.

corsaro1 commented Feb 12, 2017

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

This comment has been minimized.

wariner84 commented Feb 13, 2017

@corsaro interesting ...+1

@karek314

This comment has been minimized.

karek314 commented Apr 26, 2018

If they change transaction fees generally it also affects voting fees, or should at least. Vote is just different type of transaction. 1.0.0 is also hard fork, it's not a problem whatsoever. Changing tx fees in general is also a hard fork. We had 1 or 2 already in Lisk. Hard forks are not an issue in any chain unless there is at significant support of change.

@tomploem

This comment has been minimized.

tomploem commented Apr 27, 2018

Exactly, Type 0 and Type 3 transactions can be refactored at a similar time.

The idea was a dynamic voting fee with voting decay. Isabella mentioned that voting decay would not be easy to implement. Voting decay will be hard to implement but dynamic voting fee isn't.

Dynamic voting fees creates less insentive for large balances to vote while smaller balances can have a chance to vote again because of the voting fee being a percentage and not 1 LSK ( ~ 11 USD )

A factor thats need to be taking into account is that the change would only work if all votes are dismissed. The large accounts would never vote for upcoming delegates because of the dynamic fee being to much. Votes for the current forgers will never be updated.

@Jaxkr

This comment has been minimized.

Jaxkr commented May 2, 2018

I don't think something as complex as voting decay is necessary.

Here's how I would implement voting:

  • Make the fee astronomically small. Perhaps consider removing the fee altogether and replacing it with some PoW like Nano uses for its transactions. Users should never be punished for participating in the delegate voting process.
  • Make a vote last a single calendar year. It's long enough that it's not too inconvenient, but keeps the delegate set fresh.

Additionally, having a number of votes equal to the number of delegate slots makes no sense, and has led to an incredibly steep cliff between position 101 and 102 (16.2 MILLION) while the average difference between the delegates in the top 101 is less than 500k.

The decision to have 101 delegates was made for a reason. It's an odd number , so there is no risk of a stalemate vote on a potential network fork.
So, it would make sense to give the user 50 votes. This lets them vote for a technical minority of the candidates and keeps the vote distribution less even between the top 101, which makes the forging delegate pool more dynamic.

In conclusion, I think the following would lead to a healthy Lisk DPoS ecosystem:

  • Cheap / free voting.
  • A lifespan for votes, preferably a year or less.
  • A number of available votes per wallet that is less than the number of delegate slots.
@Joo5t

This comment has been minimized.

Joo5t commented May 2, 2018

My experience in leading a software development company is that you and your team are able to make a far better decision at the time you are ready to cross the bridge when you get there. The whole team will have more knowledge how things will end up working and what is possible after releasing a stable core version 2.x and the SDK. It will be pure luck if you think of a solution now that will work in 6 to 12 months.

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented May 2, 2018

I second everything that @Jaxkr said. Especially limiting the vote to a number less than 101 forces users to think about individual votes. Maybe the number should be as low as we want the biggest party to get. If there are only 33 votes for example, no party can ask you to vote for more than 33 delegates in order to receive reward sharing.

@5an1ty

This comment has been minimized.

Member

5an1ty commented May 4, 2018

@webmaster128 I agree with what @Jaxkr said, I would just like to add that in case of a limited total vote size of 33. Any group could still form a group of 66 for example, they could use a website where you need to register as a voter and the website will assign you the people you need to vote for. That way they could in theory divide the votes across their 66 members pretty evenly.

Another option could be to increase the amount of votes to for example 201. That would close the cliff between the 101 forging delegates and the others causing a lot more competition. This might however cause too much jitter (delegate forging / not forging / forging ...) that it could cause stability issues for the network.

@Jaxkr

This comment has been minimized.

Jaxkr commented May 4, 2018

Hi. I've expanded on my ideas a bit more and have written a proposal on changes I think would help improve the Lisk DPoS ecosystem.
It's a bit lengthy for a GitHub comment, so you can read the draft here: https://medium.com/@jacksonroberts/8896310e202c

I would appreciate your feedback.

@lichuan

This comment has been minimized.

lichuan commented May 31, 2018

DPOS has many drawbacks, for example, if a witness node was controlled by a attacker, then the attacker can broadcast many conflicting block with the same block height, in such condition, the 101 witness network would be split to many sub-network which are not compatible with each other, at this moment,
if the confirmations of these conflicting blocks is less than 2 / 3 of total num of witness, then the whole network would be suspended. you might say that if can not reach 2 / 3, the system has a timeout mechanism, but wait, if system allow one witness produce two height within a small interval, then different witness would generate different LIB (last irreversible block).

@lichuan

This comment has been minimized.

lichuan commented May 31, 2018

So, I recommand that lisk should use POW algorithm which is the only one suitable for public blockchain.

@lichuan

This comment has been minimized.

lichuan commented May 31, 2018

In fact, SHA256 with large amount of memory computations can resist ASIC, because ASIC is good at SHA256 computation, but not memory access.

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented May 31, 2018

@lichuan please stop spamming about proof of work. Nobody here wants to waste endless amounts of energy, produce tons of carbon dioxide and burn the whole planet just to have a blockchain. This is about how to improve DPoS, not how to go back to the stone age of blockchains.

@Isabello

This comment has been minimized.

Contributor

Isabello commented May 31, 2018

@lichuan

This comment has been minimized.

lichuan commented May 31, 2018

@webmaster128 It's not spamming, what I want to point out is that DPOS is not safe, not safe, not safe !!!

@diego-G diego-G added this to Icebox in Lisk Pipelines Aug 24, 2018

@ducktank1990

This comment has been minimized.

ducktank1990 commented Sep 14, 2018

Votes should get chanceled after xxxxx blocks

Expected behavior
If a delegate is doing bad work or stop forging for some days he should be outvoted fast

Actual behavior
If a delegate is doing bad work or stop forging the process of unvoting took too long

Reason
There are a lot frozen accounts and the motivation of voting is not big enough
Also vote fee is to expensive atm

Solution
Votings get chanceled after xxxx blocks

Pros
steady voting per account would increase the dynamic of the system
increasing frozen voter accounts dont make the 101 dynamic more sluggish

@lichuan

This comment has been minimized.

lichuan commented Sep 14, 2018

The only real safe consensus algorithm is POW, because it is measured by accumulated SHA256 power, others like DPOS or POS is not measured by accumulated stuff.

@karek314

This comment has been minimized.

karek314 commented Sep 14, 2018

@lichuan POW won't work well in system which requires blocks to be made with constant block interval time. It's meant to be running applications - imagine clicking "log in" in any modern application and waiting randomly from 10 to 50 seconds.

However, POW is great system to create currency with great properties of perfect money, though we don't need another Bitcoin. Bitcoin as medium of exchange is doing quite well and it's getting better.

@lichuan

This comment has been minimized.

lichuan commented Sep 15, 2018

@lichuan POW won't work well in system which requires blocks to be made with constant block interval time. It's meant to be running applications - imagine clicking "log in" in any modern application and waiting randomly from 10 to 50 seconds.

However, POW is great system to create currency with great properties of perfect money, though we don't need another Bitcoin. Bitcoin as medium of exchange is doing quite well and it's getting better.

In term of security, POW is far better than DPOS.

@ducktank1990

This comment has been minimized.

ducktank1990 commented Sep 17, 2018

Type xy Transaction: Give your Votepower to xxxxxL
Type yx Transaction: Get back your Votepower from xxxxxL

@Korben3

This comment has been minimized.

Korben3 commented Oct 1, 2018

Here are some more ideas, I also posted this on lisk chat.

"I would like to share a raw and wild idea I had about a small remake of the current lisk DPOS system.

The following rules might be implemented into the lisk system:

  • A registered forging delegate should automatically share at least 50% of it's daily rewards divided to its voters based on the amount of lisk they own.
  • Voters receive their lisk as a "type 8 transaction - Transfer lisk to voter" with a 0 lsk fee.
  • Delegate may choose to increase sharing percentage by making a "type 9 transaction - Set share percentage" (50-100%).
  • Each day at 24:00 is payout day and the voters and delegates receive their lisk.
  • Voting fee is changed to 0.1

Example: delegate korben3 shares 50%, earns 256 lsk a day, has 2 voters both own 100 lsk. Voter 1 receives 128 lsk - (100/200)x(256x0.5) or (voter 1/total lsk of all voters)x(total lsk of delegate in 24hr x share percentage).

Reason: This makes voting more attractive, less expensive to switch delegates, pools are less attractive - you're no longer 'forced' to vote for someone in fear of not receiving max payout, voters can now earn lisk from each delegate without having to wait 423+ days for a payout, a more fair system since delegates must share at least 50%, lisk sharing with the voters is now automatically, a delegate cannot suddenly decide not to share, or share less then 50%, an under performing delegate is easier to unvote, ..

Just some brainstorming, let me know what you think "

@karek314

This comment has been minimized.

karek314 commented Oct 2, 2018

A registered forging delegate should automatically share at least 50% of it's daily rewards divided to its voters based on the amount of lisk they own.

That is purely invalid and this is wrong direction at all. Sharing anything was not an intention of the system whatsoever. It is broken because network is live for more than 2 years without any product. Ideally delegate position should be ran by entities / associations of developers running delegate account and using it as funding for their own projects. What you propose is actually hardcoding negative consequence of non existent product to lisk core codebase.

I still believe system can get back on track as soon there is something to work with, then voters would get more active as well. Voters should not get any LSK as rewards, but instead getting rewards in sidechain projects token.

@Korben3

This comment has been minimized.

Korben3 commented Oct 2, 2018

Sharing might not be the intention of the system, but it grew organically and it can become part of the system, As long as there is a vote fee, the main incentive for owners of lisk to vote is a share of the forging reward. Why not make it a part of the system? Without sharing, you would have only a few users who care enough to vote.

@karek314

This comment has been minimized.

karek314 commented Oct 2, 2018

Then conclusion is simple - voters are incredibly stupid and vote based system is invalid in first place.

Main incentive of LISK holders should be to choose delegates in wise manner, which would positively impact entire Lisk ecosystem. Voting just to receive rewards is pointless, because if ecosystem does not grow, received token share may be worthless.

However, I presume this is hard to understand for most voters, similar way the democracy does not work properly, while most people tends to vote for very short-sighted gains like:
-social care
-free benefits
-free everything
While missing that eventually they will pay for everything in taxes, if not directly then indirectly in "inflation tax". Moreover such government provided services are mostly ran very inefficiently, therefore it costs much more for much worse service.

So system must be designed wisely. I believe that If Lisk would have sidechain development feature from early days, We wouldn't have this conversation, because delegate accounts securing network could share tokens in own projects, instead of sharing Lisk token, ultimately - this is much better incentive for most voters than receiving LSK. LSK might not have such great potential for further price growth while newly created project always have, either down to nothing or "to the moon". That would also incentives deeper research of delegates/teams.

@smmujahid

This comment has been minimized.

smmujahid commented Oct 3, 2018

@uvoz

This comment has been minimized.

uvoz commented Nov 11, 2018

Just some thoughts:
Reward the delegate a 1% "mining fee" and distribute the remaing 99% among its voters. That's actually fair. On top of that, compose the delegate top 101 daily based on the quality of their service and not quantity of coins. Such approach likely makes thousands of us switching on a delegate VM on Azure or Amazon resulting in a faster, stronger and better distributed blockchain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment