[LIPS] Change to one vote per account

hirish hirish at protonmail.com
Thu Feb 7 07:51:53 EST 2019


Delegate hirish here. I would like jump in with my considerations about this proposal.

First of all we need to set the goals Lisk wants to reach. I assume the goals are:
- Get rid of groups
- Increase competition between delegates
- Still maintain secure the network
- Makes community happy with rewards (?)

I'm currently a forging delegate. I'm a developer investing his time on Lisk. I'm an entrepreneur who has an idea to be implemented on Lisk (www.sapiensproject.io). The majority of community members could read my words as biased, but I will try to analyze this proposal from all point of views: delegates, developers and promoters, community members interested in shares. This because I was and I am all of them.

Before starting to analyze the future scenario, I would like to spend some words about greediness and high incentives. In simple words, greediness and high incentives is what is making bitcoin, and the crypto-world in general, secure. I understand it is very unpopular, but that's how it works. High rewards push people to do great things.

As a delegate point of view, we already know what will happen thanks to other DPOS projects that have already implemented this solution. It will end up with delegates with an average share percentage of 90+%. This means very low incentives. Low financial incentives means also low carefulness to the secure aspect of the network. It's a natural reaction of human kind.

As a developer and promoter, since there are low incentives, there will be also low level of participation in the project. I honestly think I would never have coded all the Ledger Integration and all the other project I did with low incentives. And the reasons is simple: I can make more money by doing something else (see? greediness push people to do *also* great things!). The same conclusion could be made for a promoter point of view. We had tons of Lisk Meetups around the world. I believe this will disappear. Projects like Lisk Utrecht Center and Elite Center would not have been possible without a proper amount of funds.

As a community member interested in shares, this proposal seems like heaven. But I'm not sure they're going to get more shares. Since you have only 1 vote, the 90% share acts like an upper-bound-hard-cap on how much you can get from vote sharing. Currently you get in average 25% from *every* delegate. It is also true that with "1 vote per account" you will share the vote with a lot less people. But I'm not sure this will be enough to get more. Automatic Bot that does switch of votes in favor of low-ranked high-shares delegates will popup making delegate ranks very unstable. This will create network instabilities if delegates are not ready. I'm quite sure (but it needs more calculations) that voters will get less rewards in average compared to the current solution if they do not act on weekly basis on their vote.

I will try to summarize pros and cons of this solution.

- New delegates will join the game
- Large groups will lose power, but probably won't disappear
- More competition for active delegate slots, but (CONS) based mostly on share percentage and not on great contributions.

- Voters will get less rewards if they do no switch vote on regular basis
- It could cause network instabilities
- Low incentives to keep secure the network
- Low incentives to contribute to Lisk
- It is not a definitive solution
- Projects like sidechains and Lisk centers and meetups won’t be funded anymore since financial incentives are low.
- Low financial incentives it means also becoming less attractive to developers.

In my honest opinion as an investor in this project, this solution cannot be interpreted as a definitive one because it simply shift the current problems to some different (and more delicate/critical) ones and doesn’t fit all the goals behind this change.

I would like to see Lisk as a vanguard in the DPOS field by finding a proper and original solution, and not a “temporary patch” that solve some problems, but creates new and more monsters.
And these monsters are already out there.



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Il mercoledì 6 febbraio 2019 14:45, Jan Hackfeld <jan.hackfeld at lightcurve.io> ha scritto:

> Hi cc001,
> thank you very much for your input.
> Before addressing your concerns, let me emphasize that the whole LIP
> process is designed to make the whole evolution of Lisk transparent and
> include the expertise and knowledge of the community. So it would be
> great to have several sound, well-reasoned proposals for a new voting
> system in order to carefully weigh the arguments and choose the best
> solution (maybe combining different proposals).
> Regarding your reasoning below:
> 1.  I agree that if people ONLY vote based on maximal gain (shared
>     rewards), then the delegates with the highest percentage of shared
>     rewards will get into the top 101 slots. However, if people also value
>     other factors (expertise in running a node, community involvement,...),
>     then these factors matter and a person with a good community
>     involvement, for instance, has a realistic chance of becoming a delegate
>     (after convincing account holders with a balance of around 500,000 LSK,
>     see LIP for details). Currently, this is not really possible. Overall,
>     it will probably be a mix of both (people voting selfish and people
>     considering involvement/other factors) and the community will determine
>     in which direction the system moves.
> 2.  The LIP already discusses the security implications of the proposed
>     change of the voting system in detail and makes it clear that only a
>     large number of malicious delegates would pose a serious threat.
>     Furthermore, we have several other proposals on the roadmap that will
>     substantially increase the security guarantees:
> -   The objective 'Improve blocks verification' proposes to add Byzantine
>     fault tolerance to the protocol. This means that the protocol will
>     tolerate malicious/Byzantine delegate up to a certain threshold.
> -   The objective 'Punish protocol violations by delegates' will add a
>     mechanism to the protocol that punishes a delegate if it can be proven
>     on the blockchain undoubtfully that the delegate acted maliciously. We
>     haven't finalized the research and specifications, but think of a 10,000
>     LSK security deposit (value is to be decided) that a delegate loses if
>     they do something malicious.
> 3.  I also don't clearly see that sharing a high percentage of rewards is
>     a problem. Most delegates have and most likely will have a considerable
>     amount of Lisk (it could be discussed if this should be enforced by the
>     protocol). Take for example a delegate that shares 100 % of the rewards
>     (extreme case, likely it will be less), but also owns 50,000 LSK (and
>     votes for themself). According to the estimates in the LIP, votes by
>     additional 450,000 LSK would be approximately sufficient to secure an
>     active delegate slot. In this case, 10 % of the rewards go to the
>     delegate (10 % of the vote weight is from the delegate itself), 90 % to
>     all other votes. Everybody would be interested to keep productivity high
>     as otherwise they lose money. Moreover, delegates can be voted out of
>     the 101 much easier if the productivity is low (much less people have to
>     change their votes).
>     I am happy to discuss more!
>     Cheers,
>     Jan
>     On 2/6/19 1:02 PM, Vit Stanislav wrote:
> > Hi cc001,
> > I very much enjoyed reading your explanation of what "one vote per
> > account" will lead to. I'm not strongly convinced it will happen, but
> > I'm interested in understanding the scenario better. One thing I miss
> > mentioned there explicitly is why the scenario you describe applies to
> > the proposed "one vote per account"  and not to the current "101 votes
> > per account". I can think of some reasons, but I'm no expert in
> > economics or game theory, so I would like to read your explanation.
> > Can you please elaborate on that for me and others that might wonder
> > about the same question?
> > Thank you,
> > Vít
> > On Tue, Feb 5, 2019 at 10:40 PM cc001 <cc001.bct at gmail.com
> > mailto:cc001.bct at gmail.com> wrote:
> >
> >     In my opinion the only purpose (or at least the most important one) of
> >     the voting system is to guarantee a secure and an efficient
> >     network/blockchain. If the voting system can not guarantee the security
> >     and efficiency of the blockchain, it is not suitable for Lisk, no
> >     matter
> >     if it has all desired properties listed in the proposed LIP.
> >
> >     I will explain in the following why in my opinion the "one vote per
> >     account" system will lead to an inefficient and maybe even an insecure
> >     blockchain/network and why it is therefore not suitable for Lisk. This
> >     is not because of technical aspects, but because of economical and
> >     game-theory aspects.
> >
> >     TLDR: The "one vote per account" system will lead to 101 delegates not
> >     caring about the integrity, efficiency and security of the network
> >     because they will have not enough financial incentive to do so. They
> >     will use the cheapest possible nodes, they won't update their nodes
> >     in a
> >     timely manner when critical security fixes should be applied, they
> >     won't
> >     care about missed blocks, they won't use their time to promote and
> >     support Lisk in any way and they will be bribeable for very low cost.
> >
> >     Let me explain why:
> >     The following will happen in the long run: Well, I think it could
> >     happen
> >     pretty quickly, because the voters and delegates already know the drill
> >     from other DPOS systems like ARK, Oxy, etc...
> >     But let's assume we play the game from the beginning, in little steps:
> >
> >     1. delegates will offer very little rewards, let's say 0-5%.
> >     2. people will vote for those who offer 5%, and 101 delegates offering
> >     5% will be forging.
> >     3. clever standby delegate on rank 102 will offer 10% to give voters
> >     more incentive to vote him instead of one of the top 101, to join the
> >     forging position.
> >     4. voters will vote for the 10%-delegate on rank 102 (because they will
> >     get more rewards by doing this), who will finally replace the
> >     5%-delegate on rank 101.
> >     5. delegates on rank 102 - 150 will offer the same, 10%, maybe also
> >     delegates on rank 1 - 101 will increase their rewards.
> >     6. this will lead to a situation where all forging delegates on rank
> >     1 -
> >     101 will offer 10%, until rank 102 begins to offer 20% and step 4 - 6
> >     will repeat with 20%.
> >     7. This cycle will continue with increasing sharing rewards.
> >     ...
> >     ...
> >     Delegates will continue to share more and more, until everybody shares
> >     around 95-99%. Actually, an equilibrium will happen, at the point when
> >     delegates share so much, that their income (maybe 1-5%) barely covers
> >     their costs. To reduce their costs, they will use the cheapest possible
> >     $3/month VPS nodes, they will spend as little time as possible for
> >     Lisk,
> >     and they won't care about their nodes, because they earn almost nothing
> >     anyways, it doesn't matter for them if they miss blocks or if they
> >     become unvoted. If people think this is no problem because they can
> >     unvote those sloppy delegates and simply vote for better delegates,
> >     they
> >     are wrong. There won't be better delegates, because every delegate will
> >     HAVE TO give 95-99%+ rewards to have a chance to join 101 and for an
> >     income of like $100 per month, there won't be many offering a good
> >     delegate job.
> >
> >     The end result will be, that those 101 forging delegates have extremely
> >     little financial incentive to run their nodes in a secure and reliable
> >     manner. They won't care about the network or the ecosystem. Even worse,
> >     they could earn more by accepting bribe money. The LIP explains the
> >     situation about bribing, it is not too easy to bribe 51 delegates to do
> >     real harm to the network. But still, it would be very cheap for a
> >     competitor blockchain to bribe a fair amount of delegates (which don't
> >     even have to be coordinated) to disturb the Lisk blockchain severely.
> >
> >     For voters those 95% sharing rewards might sound like heaven. BUT: the
> >     high LSK rewards will be worth nothing when the blockchain is insecure,
> >     is inefficient, is not upgraded in a timely manner when crucial
> >     security
> >     fixes should be applied, because this will lead to falling LSK
> >     prices on
> >     the market. You could even lose your LSK if the blockchain is not
> >     secured properly by financially incentivised, serious delegates.
> >
> >     Another reason why I don't like the "one vote per account" system is
> >     that I want to vote for multiple delegates, because there are many
> >     great
> >     people in our community! I can't and don't want to reduce my vote to
> >     only one single delegate. I know at least 50 delegates who definitely
> >     would earn my vote. I would definitely prefer a system where I can vote
> >     multiple people and everyone gets (account balance)/(# of votes) voting
> >     weight from me. Of course I could split into 30 accounts, but it's too
> >     much of a hurdle to do that and it would need quite some LSK for paying
> >     the fees.
> >
> >     Because in my opinion the "one vote account" would lead to an
> >     inefficient, abandoned and insecure blockchain I refuse this proposal
> >     severely.
> >
> >
> >     --
> >     LIPS mailing list
> >     LIPS at lists.lisk.io <mailto:LIPS at lists.lisk.io>
> >     http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io
> >
> --
> Jan Hackfeld
> Cryptographer, Lightcurve
> ---------------------------------------
> LIPS mailing list
> LIPS at lists.lisk.io
> http://lists.lisk.io/mailman/listinfo/lips_lists.lisk.io

More information about the LIPS mailing list