Solutions to improve Lisk DPoS #353
Comments
|
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. |
|
Of course round will be longer or/and reward halved, there are few possible solutions. |
|
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. |
|
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. |
|
There are other possible approaches to improve DPOS
|
|
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. |
|
A few other ideas:
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. |
|
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. |
|
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:
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:
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. |
|
First thoughts for me is a combination, but prioritized by complexity: In between unless it's very easy to do Future after new SDK is working |
|
What about complete randomization of forging delegates? (ducks under desk) and progressive timeout bans for missing blocks or similar... |
|
@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 |
|
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 :) |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
My 2 cents on few things:
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.
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.
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
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: My own proposal on Number of Votes per Account (Draft): |
|
@Doweig Good input, thank you My thoughts on the vote weight splitting: 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 |
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. |
|
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%: 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. |
|
@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. |
|
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. |
|
The SDK and DPOS can be thought about at the same time. We have the resources to do both. |
|
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.
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. 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. |
|
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: 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 :) ) |
|
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:
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 |
|
@Corsaro interesting ...+1 |
|
@webmaster128 It's not spamming, what I want to point out is that DPOS is not safe, not safe, not safe !!! |
|
Votes should get chanceled after xxxxx blocks Expected behavior Actual behavior Reason Solution Pros |
|
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. |
|
@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. |
|
Type xy Transaction: Give your Votepower to xxxxxL |
|
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:
Example: delegate korben3 shares 50%, earns 256 lsk a day, has 2 voters both own 100 lsk. Voter 1 receives 128 lsk - 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 " |
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. |
|
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. |
|
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: 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. |
|
Very well put up arguments
…On Wed, 3 Oct 2018 at 1:02 AM, Unhandled Exception ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#353 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AfeMFfkAusSn2p4m7Dr9k7JiNlCfOSKaks5ug8Y-gaJpZM4LKAVd>
.
|
|
Just some thoughts: |
|
"The Lightcurve Science team has just opened the discussion for our 11th LIP – Change to one vote per account in our DPoS. |
|
Forwarding to the lips mailing list so we have this there as well
…On Wed, Feb 6, 2019 at 7:58 AM reaper699 ***@***.***> wrote:
"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 <https://github.com/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
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#353 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAB2X08tFj2dWbI2dgjzc4Od-HUouloOks5vKn0VgaJpZM4LKAVd>
.
|
|
@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. |
|
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 ? |
|
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. |
|
How is forming a group to base your voting stratergy in anyway making a 51% attack, the answer is it does not , |
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. |
|
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. |
|
@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. |
|
Hello from Down Under. BlockcoinAU here.
I subscribed to this Github way back using an old email address so I just want make it clear who’s behind it.
I already mentioned my view in the Lisk chat but I’m posting it here with additional comments, having read previous posts by various people.
Hold your horses there, 2mdoty. :)
There are clearly a lot of fortunes at stake here and changing the voting system will affect existing pools. Understandably there is resistance from pool members and their concerns may seem to solely protect their own agenda.
However, in this case I believe there is merit to voice concern about this proposal. It goes way beyond self interest and self preservation. Reaper has a valid point regardless of whether he’s the representative of Elite or an individual. It is pointless to push for a change at all cost when the bad result of it is already visible across various other blockchain projects. That is basically as destructive to the project as big pools and vote buying are to the DPOS system.
All the potential scenarios that have already been outlined by @cc001, @5an1ty and @Reaper69 did already come to fruition in other projects that tried them. It is of course just my personal view that this proposal is not worth much if the only thing HQ has so far, is to copy what others have done. Especially given that the outcome is so easily verifiable.
Claiming that this is not the case for ARK is just as short sighted as claiming that there’s no issue at all with a 51% attack on the LISK blockchain. ARK may simply not have progressed down the path enough for all these issues to become more prominent. All projects are on track to exhibit these exact symptoms and people are already creating delegates following the recipe that has been outlined by @Reaper69 and @cc001.
This should not be about who came first and who has a right to be a delegate. The idea of DPOS is that a voting mechanism protects the network and that an active, caring community can vote delegates in and out based on how they perform and how much of a stake they have in the LISK ecosystem. The current system fails in that regard. It has already been shown that un-voting an unresponsive delegate is very difficult to achieve. However, the network is stable and so far we have no evidence that any of the pools are out to cause harm. Quite the opposite actually. Every time we had a major upgrade, it went smoothly and all delegates promptly responded. To suggest/debate a new voting policy that already has a clearly predictable outcome which isn't in our favour seems rather puzzling to me.
There is frustration amongst new delegates because it is impossible to enter the 101 field without the support of one of the big pools. That may well be an issue but this current proposal doesn't solve it in an improved way so it's not worth implementing because it comes with a whole lot of other/new issues/risks that we're already well aware of.
Personally I go as far as claiming that DPOS can't be fixed. It is a failed, flawed system that introduces and encourages corruption and vote buying. It works on paper but it fails in real life because people are greedy. Always have been, always will be. This goes for both sides. Delegates and voters. All these solutions have problems but some problems seem to be particularly nasty and difficult to overcome.
Maybe this is a much bigger topic and moving away from DPOS should be considered as part of a bigger longer running proposal. Even POS will do just fine when compared with DPOS. Patching a broken system is bound to introduce more risk when the actual fundamental flaws continue to exist. So far our chain has moved along quite nicely and all delegates have worked together to solve issues. The suggested proposal puts greed even higher up the chain and does nothing to make the blockchain more secure or stable for that matter.
Talking about solutions is certainly appreciated and working on an improvement rather than replacing DPOS can be helpful too but it would have to address the fundamental issues. It would be just as big a big mistake to settle for the status quo. In my view, this will take considerable time and effort far beyond a few emails and online postings.
… On 7 Feb 2019, at 8:35 am, 2mdoty ***@***.***> wrote:
@reaper699 <https://github.com/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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#353 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWZl9LwQUgsNc1yKMFuq0F9KZmDp4xSpks5vK1i9gaJpZM4LKAVd>.
|
|
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? |
|
This requires Protocol changes. |
and others
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.
The text was updated successfully, but these errors were encountered: