Change to 131 (or 151) votes instead of reducing it to one vote

Consensus
1

TLDR:
I propose the following change: Increase the allowed votes per account from now 101 to 131 or 151 (exact number to be defined). This will remove the high cliff at 101 and therefore will allow standby delegates enter the top 101 much easier and quicker. This will increase the competition between delegates and motivate new delegates to fight for a spot in the top 101 which will lead to more decentralization. Additionally it gives the voters more choice and freedom, which will further increase the decentralization.
In my opinion this is much better than reducing it to only 1 vote.
See my reasons for that proposal in the following:

The reason why the top101 is so static, and why it's extremely difficult to enter that list, is because there is a huge "approval-cliff" at position 101. This cliff exists mainly because people have only 101 votes to vote for the active delegates. Because delegates on rank 1-101 share rewards, and standby delegates on rank 102 - XXX do not, a voter has the most personal benefit/income if he votes the top 101 ranks. The reason why almost everybody does not vote delegates on rank 102 - XXX is because to do so, they would have to remove a vote from top 101, which means that they will lose the rewards from this removed vote. This means basically that every vote they want to give a delegate on rank >101 will cost them money, what most are not willing to do. Additionally, because that cliff is so high, it takes a lot of time until someone on rank >101 can forge, which means that voters voting for standby delegates lose money during a long time. Voters have an incentive to wait until a delegate on rank 102 has almost the same weight as the one on rank 101, before changing their vote to lose the least possible amount of rewards. Problem is that every voter thinks the same (basically "the others should vote first, I'll follow then"), and nobody changes their votes.
What a change to 131 possible votes will do is the following:
People will still vote rank 1-101 to get maximum rewards. But now, they have additional 30 votes, which they can use for free. They can't earn more with them in the short term, but they can profit from it in the mid- to long-term. This means, those 30 votes can be used for any delegate they want from rank 102 - XXX. Some votes will be used for standby delegates who promise to share more than the current active delegates. Some votes will be used for standby delegates doing great work, like developing tools, organizing meetups, and so on.
If we assume that most voters will use those additional 30 votes, the approval weight on the ranks 102 - XXX will increase drastically, which basically removes the huge cliff at rank 101. If this cliff is removed, and let's say rank 102 - 110 have almost the same approval like rank 101, it will allow a lot more changes around rank 101 and standby delegates have a realistic chance to enter 101.

In the same time I'd like to suggest that we should allow more than only 33 votes per transactions. It should be increased to the maximum allowed votes, let's say 131, it will improve the usability for voters significantly.

Of course other improvements like "incite standby delegates", "floating point forging probability", etc... should be implemented, but they are not part of this proposal.

Benefits:
* top 101 will change more often, because there will be no 101 cliff anymore. The 1-vote-system would actually increase this 101 cliff even more.
* A higher chance for standby delegates to join top 101 will increase the competition between delegates and will motivate additional delegates to join the race for top 101. This increases the decentralization of the whole network.
* People have a lot more choice/freedom who to vote which increases the decentralization
* Pretty easy change (code wise).
* No drastic and unproven change from 101 to 1 votes is needed. The current votes could be kept and simply allow additional 30 votes from a specific date on.
* It makes it more simple to implement additional LIPs like incentivising standby delegates, because there is no cliff anymore at rank 101 and standby delegates are already involved in forging and fighting for rank 101.

Critics:
* One can argue that it does not solve the issue with the groups. Well, the biggest issue with current system, the big 101-cliff, doesn't exist because of the groups. Even if current top 101 are all individuals with not a single group, even then all voters will only vote top 101, because this brings them the most possible rewards. It's independent from groups.
* One can argue that existing groups would add new members then. I think this will not be the case. Groups could add additional members already now, but they don't do it. The reasons for it are that they realize that the community would not tolerate it and it would be too much of a burden to ask all their voters to change the votes. Additionally the groups would hurt their existing group members by adding additional members.
* One can argue that groups will start demanding exclusive votes for them. I think this would not happen. They could do this already now but they don't do it. The voters would not accept it to give away their additional free votes. They have more incentive to use their additional votes to promote new highquality delegates into top 101.
* One can argue that it's more complicate to vote for 131 instead of for 101 or only 1 delegates. But this is not true if it is communicated well that 131 votes per account are possible, and if the process of voting is easy (like all 131 votes in one single transaction), Currently the way how to vote is the problem, because multiple transactions are needed to vote for 101 delegates.

Comparison between 131-votes vs 1-vote system:
* 131-votes will lower the 101-cliff, 1-vote will increase it
* 131-votes will increase the competition between delegates, 1-vote will reduce it
* 131-votes will increase decentralization by encouraging new delegates, 1-vote will decrease decentralization by spawning unknown sock accounts.
* 131-votes will keep the high quality and engagement of forging delegates, 1-vote will drastically reduce every community work on Lisk.
* 131-votes will increase the freedom of voters, 1-vote will reduce it
* 131-votes will give a more smooth transition from the current system, 1-vote will introduce a hard and unproven "cut".

Reasons why I am against the 1-vote-per-account proposal can be found here:

https://lists.lisk.io/pipermail/lips_lists.lisk.io/2019-February/000017.html
https://lists.lisk.io/pipermail/lips_lists.lisk.io/2019-February/000037.html

cc001

2

Dear cc001,

thanks for sharing this alternative proposal for a new voting system.

I think your proposal is definitely an improvement of the voting system that we currently have. It would be much closer to the idea of approval voting (Approval voting - Wikipedia) and there is no good reason why the number of votes per account and delegates should coincide.

I still have two major concerns with the proposal:
1) I believe the current voting pools will persist, there will be no big change in active delegates and no fair competition between delegates.

I think as soon as current delegate groups would fear losing power, they will change their reward scheme according. For instance, a pool could not share rewards if voters cast votes for standby delegates. Then we are exactly in the situation that you describe in a lot of detail below: Voters won't vote for standby delegates as they lose rewards.

You write that you think that would not happen, but it is already happening to some extend now:
"In order to get the new 5% bonus on top of your 25% reward, you just have to make sure that you are voting for all the Elite Members and not voting any Sherwood members." (https://liskelite.com/)

I don't want to judge this behavior here, but my point is that from a game theoretic point of view this is the rational strategy for a group of players (active delegates) in this case.

2) Current voting pools could further add new (unofficial) members

You claim that current voting groups don't add new members because the community would not tolerate it. But in a trustless, decentralized system nobody can now who is part of a voting pool and who not. So you cannot rely on this fact for the voting system to work.

Furthermore, in your other email you claim: "I fear there will be at least 90 unknown sockpuppet delegates, sharing 95-99%, and nobody has ever seen them in the chat. "
But also in the current DPoS system 50 delegates could be run by the same person (that just pays some people to hang out on Lisk chat and to go to Lisk meetups claiming they are distinct delegates). So you cannot make the security of a blockchain rely on some social activity supposedly attributed to different people.

I address some more detailed points of your proposal below. I would be happy to eventually see your proposal become a complete draft with a PR on GitHub so it can be evaluated as one of the alternatives for a new voting system.

Cheers,
Jan

TLDR:
I propose the following change: Increase the allowed votes per account from now 101 to 131 or 151 (exact number to be defined). This will remove the high cliff at 101 and therefore will allow standby delegates enter the top 101 much easier and quicker. This will increase the competition between delegates and motivate new delegates to fight for a spot in the top 101 which will lead to more decentralization. Additionally it gives the voters more choice and freedom, which will further increase the decentralization.
In my opinion this is much better than reducing it to only 1 vote.
See my reasons for that proposal in the following:

The reason why the top101 is so static, and why it's extremely difficult to enter that list, is because there is a huge "approval-cliff" at position 101. This cliff exists mainly because people have only 101 votes to vote for the active delegates. Because delegates on rank 1-101 share rewards, and standby delegates on rank 102 - XXX do not, a voter has the most personal benefit/income if he votes the top 101 ranks. The reason why almost everybody does not vote delegates on rank 102 - XXX is because to do so, they would have to remove a vote from top 101, which means that they will lose the rewards from this removed vote. This means basically that every vote they want to give a delegate on rank >101 will cost them money, what most are not willing to do. Additionally, because that cliff is so high, it takes a lot of time until someone on rank >101 can forge, which means that voters voting for standby delegates lose money during a long time. Voters have an incentive to wait until a delegate on rank 102 has almost the same weight as the one on rank 101, before changing their vote to lose the least possible amount of rewards. Problem is that every voter thinks the same (basically "the others should vote first, I'll follow then"), and nobody changes their votes.
What a change to 131 possible votes will do is the following:
People will still vote rank 1-101 to get maximum rewards. But now, they have additional 30 votes, which they can use for free. They can't earn more with them in the short term, but they can profit from it in the mid- to long-term. This means, those 30 votes can be used for any delegate they want from rank 102 - XXX. Some votes will be used for standby delegates who promise to share more than the current active delegates. Some votes will be used for standby delegates doing great work, like developing tools, organizing meetups, and so on.
If we assume that most voters will use those additional 30 votes, the approval weight on the ranks 102 - XXX will increase drastically, which basically removes the huge cliff at rank 101. If this cliff is removed, and let's say rank 102 - 110 have almost the same approval like rank 101, it will allow a lot more changes around rank 101 and standby delegates have a realistic chance to enter 101.

I completely agree with your analysis. Assuming rational players interested in maximal gain (shared rewards), the Nash equilibrium is that everybody just votes for active delegates (except the reward sharing scheme demand additional requirements as voting for certain standby delegates belonging to a pool or unvoting certain delegates).

In the same time I'd like to suggest that we should allow more than only 33 votes per transactions. It should be increased to the maximum allowed votes, let's say 131, it will improve the usability for voters significantly.

Of course other improvements like "incite standby delegates", "floating point forging probability", etc... should be implemented, but they are not part of this proposal.

Benefits:
* top 101 will change more often, because there will be no 101 cliff anymore. The 1-vote-system would actually increase this 101 cliff even more.

I agree that the cliff will decrease unless pools change their reward sharing scheme (see above).

* A higher chance for standby delegates to join top 101 will increase the competition between delegates and will motivate additional delegates to join the race for top 101. This increases the decentralization of the whole network.
* People have a lot more choice/freedom who to vote which increases the decentralization

Agreed.

* Pretty easy change (code wise).

I thinks so too. I could decrease performance slightly though as more votes need to be taken into account for every balance change.

* No drastic and unproven change from 101 to 1 votes is needed. The current votes could be kept and simply allow additional 30 votes from a specific date on.
* It makes it more simple to implement additional LIPs like incentivising standby delegates, because there is no cliff anymore at rank 101 and standby delegates are already involved in forging and fighting for rank 101.

Critics:
* One can argue that it does not solve the issue with the groups. Well, the biggest issue with current system, the big 101-cliff, doesn't exist because of the groups. Even if current top 101 are all individuals with not a single group, even then all voters will only vote top 101, because this brings them the most possible rewards. It's independent from groups.

I agree that if all 101 were independent individuals and there were no reward sharing schemes that demanded voting for more than 1 delegate for shared rewards, then this proposal would greatly decrease the cliff and have a very positive effect.

* One can argue that existing groups would add new members then. I think this will not be the case. Groups could add additional members already now, but they don't do it. The reasons for it are that they realize that the community would not tolerate it and it would be too much of a burden to ask all their voters to change the votes. Additionally the groups would hurt their existing group members by adding additional members.

See point 2) at the beginning.

* One can argue that groups will start demanding exclusive votes for them. I think this would not happen. They could do this already now but they don't do it. The voters would not accept it to give away their additional free votes. They have more incentive to use their additional votes to promote new highquality delegates into top 101.

I believe this will not be the case, see point 1) at the beginning.

* One can argue that it's more complicate to vote for 131 instead of for 101 or only 1 delegates. But this is not true if it is communicated well that 131 votes per account are possible, and if the process of voting is easy (like all 131 votes in one single transaction), Currently the way how to vote is the problem, because multiple transactions are needed to vote for 101 delegates.

Comparison between 131-votes vs 1-vote system:
* 131-votes will lower the 101-cliff, 1-vote will increase it

The cliff for 1 vote per account will be at most 500,000 LSK. The cliff for 131 votes will probably be not much lower.

* 131-votes will increase the competition between delegates, 1-vote will reduce it

I personally doubt it, see point 1 at the beginning.

* 131-votes will increase decentralization by encouraging new delegates, 1-vote will decrease decentralization by spawning unknown sock accounts.

See point 2 above.

* 131-votes will keep the high quality and engagement of forging delegates, 1-vote will drastically reduce every community work on LiskIn 2 years block rewards are 1 LSK. With the current price, would

delegates still have the same resources for engagement? Maybe we need to explore a community fund (Santerr proposed the creation of a DAO).

* 131-votes will increase the freedom of voters, 1-vote will reduce it

If the main point is the number of votes, then I think balance/#votes instead of 1 vote per account (as you also suggested) would be a better direction to go.

* 131-votes will give a more smooth transition from the current system, 1-vote will introduce a hard and unproven "cut".

I agree that the transition to 131 votes would be more smooth, but maybe that is the reason that current issues (lack of competition) would persist.

Reasons why I am against the 1-vote-per-account proposal can be found here:

https://lists.lisk.com/pipermail/lips_lists.lisk.com/2019-February/000017.html

https://lists.lisk.com/pipermail/lips_lists.lisk.com/2019-February/000037.html

cc001

3 
LIP: <LIP number>
Title: Change to 131 votes per account
Author: cc001 <cc001.bct@gmail.com>
Type: Standards Track
Module: DPoS
Created: 2019-02-24
Updated: 2019-02-24

Abstract

This LIP proposes a change of the voting system for the election of delegates in Lisk. I suggest to allow 131 votes per account with a vote weight given by the balance of that account for every vote. The goal is to increase the decentralization of the network by lowering the entry barrier into active forging slots and creating a healthy competition for active delegate slots. This could potentially break up existing coalitions which would be very welcomed by the community. Additionally, voters have more votes available and therefore more freedom to vote those delegates they like to see forging. This further increased the decentralization. Moreover, the proposed voting system is very simple and encourages a high participation of stakeholders.

Copyright

This LIP is licensed under the [GNU General Public License, version 3](http://www.gnu.org/licenses/gpl-3.0.html "GNU General Public License, version 3").

Motivation

In the current voting system in Lisk, every account holder can vote for up to 101 delegates and the vote weight of the account is the balance of the account, also referred to as the stake of the account holder. The current voting system is based on approval voting and the idea is that the delegates approved by the highest proportion of stake are the most suitable to secure the Lisk network. In practice, this system suffers from several shortcomings, which also have been addressed by members of the Lisk community. First of all there is a high incentive for voters to vote for the current top 101 delegates because of the received rewards. This creates a very high barrier for anybody to become an active delegate (called "the 101 cliff") which hinders a healthy competition for active delegate slots.

This LIP proposes to increase the number of votes to 131 votes per account. This would be closer to actual approval voting which allows approval of an arbitrary number of delegates. Because voters need only 101 votes for maximizing their profits, they basically have 30 additional votes which can be used to vote standby delegates. Because it doesn't matter which standby ranks are voted, people will vote for those delegates they would like to see forging, either because they share a higher percentage than the current forging delegates, or because they do great work for Lisk and its community. This will lower the 101 cliff tremendously and make it much easier for anybody to become an active delegate. The resulting competition between delegates will be very healthy for the security of the network, the decentralization and the efforts of the community. The upcoming change to dynamic fees will reduce the costs for voting tremendously which will encourage a much higher participation in voting and more often changes of votes.

Rationale

It is important to acknowledge that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, the proposed change of the voting system is a great improvement of the current state and an important step in evolving the Lisk Delegated Proof of Stake system. In this section, we give our reasoning for favoring the proposed voting system and also discuss some alternative solutions, some of which were put forward by the community on GitHub. In general, the vote weight or rank of a delegate could depend on a lot of different factors, which we also discuss in the following.

Desired Properties

At first, we want to list the main desired properties of a voting system for Lisk:

  • Decentralization: In order to have a truly decentralized network, the entry barrier for new delegates should be as low as possible to encourage new delegates to enter the competition for a forging spot. Voters should have a high degree of freedom who they vote to increase the decentralization of the system. A potential break up of exising coalitions would further increase the decentralization of the system.
  • Simplicity: Accessibility is one of the core values of Lisk, which should also be reflected in the Lisk voting system. This means that the voting system should be very easy to understand making the entry-barrier to participate low.
  • High participation: For a well-functioning Delegated Proof of Stake system a high participation of all stakeholders is crucial.

Another property that may be intuitively named is "fairness". However, this property is very subjective and is hard to precisely define. Thus, it is not mentioned above.

Dependence on Stake

One of the first fundamental questions is how the voting power of an account should relate to the amount of stake in that account. A proposal that is often mentioned in this context is to somehow limit the power of very large stakeholders who have a large influence on the network. In a trustless, decentralized system it is however impossible to map accounts to people. In particular, it is impossible to distinguish if many small accounts are controlled by many people or just one big stakeholder. Therefore, any voting system that gives many small accounts more cumulative voting power than one large account can be easily circumvented by a large stakeholder by creating multiple accounts. In our proposal, the voting power is therefore linearly dependent on the amount of stake.

Dependence on Delegate Productivity

Another important factor to take into account for ranking the delegates is their productivity, i.e., the percentage of blocks successfully created as active delegate in the assigned forging slots and included in the blockchain. Delegates that are offline for an extended period of time have a big negative effect on the productivity of the system. In a separate LIP, we therefore propose a very conservative approach of taking the delegate productivity into account and only punish active delegates after not forging for a long period of time. This way delegates cannot indefinitely harm the Lisk network in the case that they stop to maintain their server or lose their private key, for instance.
One may argue, it is dangerous to directly punish lower productivity as it can create an incentive for delegates to have a competing delegate miss their slot by starting a denial-of-service attack, for instance. But it is the job of a delegate to secure his systems in a way that others can't harm his productivity and it is not something which should be taken care of by the core protocol.

Changing the Maximum Number of Allowed Votes

A parameter that we propose to change in the current voting system is the maximum number of delegates an account can vote for. This parameter is currently 101. However, it does not necessarily need to coincide with the number of active delegates.

If we change the maximum number of votes to one, this would incentivise voters to vote only for the delegate who shares the highest percentage of his income. Voters would not vote for any standby delegate. Delegates would only be voted based on their sharing percentage and not based on their work they do to promote Lisk. Additionally, if forging delegates have to share most of their rewards, they have no incentive to pay for good hardware, donate to other community members or do any work for Lisk. Also the argument that no coalitions could be formed with only one vote is wrong. Groups could ask potential voters to vote for specific members if they want to receive a reward.
Reducing the number of votes to one would lower the decentralization of the network significantly because big account holders could take multiple active delegate spots and nobody could prevent it. An account with 4 million LSK could bring up to 8 of his own delegates into a forging position. With 101 or 131 votes, the LSK needed by an individual to enter an active forging position is currently around 30 million LSK, which is around 3.5 times higher than the current biggest LSK account.

Dependence on the Number of Votes Cast

Abstractly we could describe a voting system depending on the number of votes and linearly on the stake of an account as follows: The vote weight of an account is given by vote weight = f(# votes cast) * account balance in LSK for a function f. The delegate weight is then the sum of all vote weights of accounts voting for that delegate. The top 101 delegates by delegate weight are the active delegates securing the Lisk network. Currently, the vote weight of an account is independent of the number of votes cast, i.e., f(# votes cast)=1.
The problem with making the vote weight dependent on the number of votes cast is that it invalidates the advantages of having 131 votes. People will have the incentive to vote only for the highest sharing delegate with their full account weight. They would earn less, if they split their weight and vote also for other delegates. This would again result in nobody voting for standby delegates and an even higher 101 cliff. Therefore I strongly suggest to keep the full account weight for all 131 votes.

Vote Expiration or Vote Decay

In order to encourage a dynamic voting environment and stakeholders to regularly re-evaluate their votes, a mechanism of vote expiration or vote decay have been discussed. Vote expiration means that a vote is only valid for a certain period of time and has to be renewed to be still taken into account. In contrast to that, vote decay means that the weight of a vote gradually decreases over time instead of expiring. While a dynamic voting environment is desirable, both proposals have some shortcomings. First of all, it adds additional complexity to the voting system, in particular for users.
Secondly, regularly casting a vote transaction can be easily automated by a voting bot, which would circumvent both mechanisms. In particular, it would be possible to sign a large number of vote transactions at once, each with different timestamps, and have a bot broadcast them automatically at specific times. Thirdly, requiring stakeholders to vote regularly increases the total cost for participating in the voting system giving a disadvantage especially to small stakeholders. The two mechanism may, nevertheless, be re-evaluated for future improvements of Delegated Proof of Stake in Lisk along other possibilities such as proxy voting, which also encourage a more dynamic voting environment.

Ranked Voting

Ranked voting systems have nice theoretical properties and implementations such as single transferable vote are endorsed by NGOs such as FairVote. The complexity of ranked voting, however, has disadvantages in the context of the Lisk blockchain. Most importantly, as votes are changing dynamically all the time, it is essential that Lisk nodes can efficiently recompute a ranking of the delegates and decide which active delegates are securing the system. First of all, computing the outcome of a ranked voting is far more complex and takes substantially longer than for the system of simply having 131 votes per account. Moreover, even if only a small number of votes change, it is unclear if it is possible to recompute the results much faster than computing the outcome from scratch considering all votes. Another disadvantage in terms of usability is that the number of delegates is large and requiring a ranking of only a subset of delegates involves a much more complex decision by stakeholders than simply voting for one delegate.

Impact on Security

In this subsection, we want to discuss the security implications of the proposed voting system. Changing the amount of votes from 101 to 131 does not have any negative impact on the security. The amount of needed approval is the same as it is now. This means that also in the new voting system there does not exist a single account which has enough weight to bring a delegate into forging position on their own. The new voting system is even more secure because it is more decentralized than the current system. Because of the much lower 101 cliff, competition between delegates is higher and therefore the risk to be voted out of a forging position when acted maliciously is much higher.
Because the new proposed system allows a continuous transition from the old to the new voting system, possible negative impacts on security are much lower than if a radical new system will be activated at a specific block.

Vote Transaction Object

In the current vote transaction JSON object, public keys are used to reference specific delegates for voting and unvoting. We propose to use the same system but allowing 131 total votes instead of only 101.
To make voting as simple as possible, we propose to increase the maximum amount of votes per vote transaction from 33 to 131. This allows the user to vote for all delegates in one single step/transaction and improves the experience and simplicity significantly.

Backwards Compatibility

The changes will allow a continuous transition from the old to the new voting system. From block XYZ on, 131 instead of only 101 votes are allowed. From this block on people can vote for an additional 30 delegates. Unforeseeable risks are very limited and the change will be easily understandable for the users.

Reference Implementation

TBD

1 Like
4

@janhack Hit the nail on the head with her previous comments about adding more votes than there is Forging positions

"I still have two major concerns with the proposal:

I believe the current voting pools will persist, there will be no big change in active delegates and no fair competition between delegates.

I think as soon as current delegate groups would fear losing power, they will change their reward scheme according. For instance, a pool could not share rewards if voters cast votes for standby delegates. Then we are exactly in the situation that you describe in a lot of detail below: Voters won’t vote for standby delegates as they lose rewards.

You write that you think that would not happen, but it is already happening to some extend now:
“In order to get the new 5% bonus on top of your 25% reward, you just have to make sure that you are voting for all the Elite Members and not voting any Sherwood members.” (https://liskelite.com/)

I don’t want to judge this behavior here, but my point is that from a game theoretic point of view this is the rational strategy for a group of players (active delegates) in this case.

Current voting pools could further add new (unofficial) members

You claim that current voting groups don’t add new members because the community would not tolerate it. But in a trustless, decentralized system nobody can now who is part of a voting pool and who not. So you cannot rely on this fact for the voting system to work."

Also there is the vote swamp agreements that happen between large holders. Giving them more votes would only strengthen their positions as this allows them to make more vote swamp agreements. Large holders even across coalition lines making agreements to ensure forging positions.

5

@cc001 Thanks for creating a complete draft of the proposal of changing to 131 votes per account! As I outlined my concerns already above, I merged your post to the existing topic.

6

Just a reminder for any ideas and LIP drafts regarding the “Delegated Proof of Stake” roadmap phase suggested here. It would be great if you could finalize your LIP and open a PR on https://github.com/LiskHQ/lips until the end of September to ensure that it is fully considered by the Lisk foundation. The research team will also publish 3 more LIPs for the “Delegated Proof of Stake” roadmap phase before then. So stay tuned for some exciting new proposals to discuss here.