Change to 131 votes per account

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

2 posts were merged into an existing topic: Change to 131 (or 151) votes instead of reducing it to one vote