Skip to content
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

Closed
karek314 opened this issue Dec 11, 2016 · 95 comments
Closed

Solutions to improve Lisk DPoS #353

karek314 opened this issue Dec 11, 2016 · 95 comments

Comments

@karek314
Copy link

@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
Copy link
Contributor

@mrv777 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
Copy link
Author

@karek314 karek314 commented Dec 11, 2016

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

@densmirnov
Copy link

@densmirnov 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
Copy link
Author

@karek314 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
Copy link
Author

@karek314 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
Copy link

@simonmorgenthaler 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
Copy link
Contributor

@mrv777 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
Copy link

@2mdoty 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
Copy link
Contributor

@Isabello 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
Copy link
Contributor

@mrv777 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
Copy link

@Phoenix1969 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
Copy link
Contributor

@dakk 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
Copy link

@simonmorgenthaler 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
Copy link

@2mdoty 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
Copy link

@2mdoty 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
Copy link
Contributor

@mrv777 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
Copy link

@2mdoty 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
Copy link

@stenea 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
Copy link
Contributor

@Doweig 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
Copy link
Contributor

@mrv777 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
Copy link
Member

@karmacoma 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
Copy link
Contributor

@mrv777 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
Copy link

@stenea 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
Copy link

@corsaro1 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
Copy link
Contributor

@Isabello 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
Copy link

@Odsejen 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
Copy link
Contributor

@mrv777 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
Copy link

@corsaro1 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
Copy link

@wariner84 wariner84 commented Feb 13, 2017

@Corsaro interesting ...+1

@ducktank1990
Copy link

@ducktank1990 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
Copy link

@lichuan 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
Copy link
Author

@karek314 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
Copy link

@lichuan 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
Copy link

@ducktank1990 ducktank1990 commented Sep 17, 2018

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

@Korben3
Copy link

@Korben3 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
Copy link
Author

@karek314 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
Copy link

@Korben3 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
Copy link
Author

@karek314 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
Copy link

@smmujahid smmujahid commented Oct 3, 2018

@uvoz
Copy link

@uvoz 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.

@reaper699
Copy link

@reaper699 reaper699 commented Feb 6, 2019

"The Lightcurve Science team has just opened the discussion for our 11th LIP – Change to one vote per account in our DPoS.
" so the science team has been working very hard and lisk HQ has been spending alot of time and money on them only to come up with this ? very disappointing to say the least . Lets not forget who the ones are that are pushing to change the DPOS system, its the ones who are not forging, what will these "delegates" do when they are not included in the new system? push again and complain again when they are not forging ? Every person had the right to invest in lisk based on the DPOS system that was laid out to us investors in the early stage, to change this system now is to do no better than the rest of the failed DPOS coins that changed their voting process after raising funds. HQ dont forget where you got all your money from ! all your money came from most of the forging delegates who bought into your platform based on the DPOS system you designed as we all saw an opportunity for a good investment ! to change that and take that away is not very honest in terms of business. my personal opinion is that it is a terrible idea , things like ( Lisk incubators ) would not be able to happen if all delegates are sharing 90% plus! you will turn your platform into a Oxy or rise or LWF joke ! where is the incentive for the delegates to create, publish, market if they are all competing against higher sharing! this takes the value down the drain! I think the science team can at least come up with something better then supposedly spending months researching Arks platform ! its a joke
A more promising platform would be rotation of delegates that go down! ie, someone misses a block, second time they get swopped out for someone above 101 for a period of 24 hours, get cycled back and if still missing then get cycled out for another 24 hours
but to change the whole system for a select few that are not happy they do not forge is ridiculous to say the least!
I have been observing the other systems for months ! and I can tell you now that the current systems allows the entire list of delegates to work together against bad players! example: some other DPOS systems that use this 1 vote method , I wont name which one, but when a delegate is sharing 95% , his incentive to keep his node up is not very big, therefor some nodes (and this is fact) are red on mainnet for months! and there is nothing the community can do because all the votes are coming from outside and people who vote externally are not checking or caring about the health of the network at all
so If lisk wishes to "stale mate" the network by choosing this method then go ahead @mat because the reality is that firstly nodes will get voted in because of their sharing and nothing else (greed ) then who is to say 1 person doesnt create 10 nodes and market them all individually to share 95% , of course they will get votes , then one day when they decide to not care about the nodes and they have millions voted against them, the network will be a failure of red or down nodes because it will be impossible to unvote them as they will have too many votes! at least in the current system the delegates can work together politically to help the network! take this away and you dont have DPOS , but instead you are basically writting the future of the network and then cementing the delegates in place for ever
How often do ark Delegates change ? how is 1 vote in any way contributing to "decentralization" when it puts the networks health at risk ?
is this change for the good of the network or is this just to please some delegates who never invested early enough and worked hard to become delegates . il let the community decide

@Nazgolze
Copy link
Member

@Nazgolze Nazgolze commented Feb 6, 2019

@desjob
Copy link

@desjob desjob commented Feb 6, 2019

@reaper699 so you say it's about who invested the earliest? That list will of people will never change, so there also isn't an increased incentive to do a good job and keep their node up either. Funny that you mention greed. Delegates "create, publish and market" mostly themselves. If you look at the contributions on GitHub, most of it are tools around the delegate system itself. 99% of the people are driven by greed, both delegates and voters.
Honestly, why do you care so much who is forging? Are you really so concerned with the safety of the network? Or do you have something at stake?

@reaper699
Copy link

@reaper699 reaper699 commented Feb 6, 2019

Of course I have something at stake, my investment! no one wants to see their investment go down the drain! and changing the consensus that way would make lisk literally worthless! all big holders will sell , people will share competitively up to 99% making incentive to keep your node uptime worth nothing.

have you even seen the other systems that are doing what is propsed ? OXY ? RISE ? ARK ? LWF ?

take a look at their positions, Lisk needs to focus on SDK and deliver their product that all!

CODERS NUMBER 1 rule, if it works, dont change it, and right now the network works! what we need is a product ! its been how many years and HQ still havent delievered even a beta working product ?

Science team been working for years only to release a statement saying Ark has a good solution ?

@errouthier
Copy link

@errouthier errouthier commented Feb 6, 2019

The thing is, the current system does not work. The network may be stable and nodes may be of higher quality due to staking incentive, but the network is not secure when delegates can form groups having more than 51% control of the network. As long as the system falls victim to that, it does not work.

@reaper699
Copy link

@reaper699 reaper699 commented Feb 6, 2019

How is forming a group to base your voting stratergy in anyway making a 51% attack, the answer is it does not ,

@desjob
Copy link

@desjob desjob commented Feb 6, 2019

@reaper699

"and changing the consensus that way would make lisk literally worthless"

Please provide some arguments if you are going to throw big claims around. The only point I get from your story is that some other coins have changed their consensus in the past and lost value. I'm not convinced the loss of value ik their case is solely because of the change, nor does it mean that would also be guaranteed to happen with lisk.

@2mdoty
Copy link

@2mdoty 2mdoty commented Feb 6, 2019

Ark has had far more dynamic change in delegates than Lisk and Ark does not have voting cartels. Also, there is a mix of delegates offering varying amounts profit sharing, development work, code auditing, marketing outreach, and community engagement. Ark actually is functional proof which invalidates every point Reaper has made to try to justify the continued existence of the cartels with the current multiple voting system. The lack of interest in maintaining delegates in LWF has nothing to do with the profit sharing, but is due to the loss of value in the coin and abandonment of the project by its founders. Oxy discontinued DPoS and had also lost a lot of value, and hence, interest prior, though the delegates continued to maintain the network up to the switch to ERC20.

@2mdoty
Copy link

@2mdoty 2mdoty commented Feb 6, 2019

@reaper699 - "and changing the consensus that way would make lisk literally worthless"

This basically amounts to a threat against Lisk team and token holders that the Elite Cartel will dump their holdings and drive the Lisk value much lower if the voting is changed against their favor.

@hoklitrail
Copy link

@hoklitrail hoklitrail commented Feb 7, 2019

@2mdoty
Copy link

@2mdoty 2mdoty commented Feb 7, 2019

Forging rewards started on Ark just 4 months after Lisk, a relatively small difference compared to the 2+ years of operation. This is plenty of time for the different systems to demonstrate their fundamentally different results through both good and bad market conditions.

You use the term "greedy". What expected ROI do you define as "greedy", in order to give it an objective definition - .1%, 1%, 10%, 100%, 1000% or some other number? If you can provide such a definition is there consensus for it? Without an objective definition the term is meaningless in rational discussion and just becomes a tool of manipulation by appealing to emotion and casting unfounded guilt.

Also, based on current Lisk valuation of a little over $1 USD, have we seen 25 million dollars worth of development for the over $25,000,000 worth of Lisk kept by delegates?

@shuse2 shuse2 removed the rounds label Apr 15, 2019
@shuse2
Copy link
Contributor

@shuse2 shuse2 commented Jul 29, 2019

This requires Protocol changes.
Please move the discussion to https://research.lisk.io/

@shuse2 shuse2 closed this Jul 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet