Change to one vote per account

Abstract

The proposed LIP11 will have the opposite effect of what it is intending to solve. It will likely cause a decrease in decentralization, replace coalitions with whales (or coalitions of whales), and competition will decrease as standby delegates are disenfranchised even further.

###Motivation

First, it is not believed that new coalitions can easily manifest themselves in the top ranks. They exist now, but their ability to be replicated and successfully voted in has not occurred despite attempts. One often overlooked flaw is that ICOs don’t guarantee widespread distribution. Few early market participants, and delayed releases of a functional SDK, allowed coalitions to become entrenched. These issues are not from an inherent flaw in the voting system.

Additionally, providing security of the system is arguably the most important aspect of the delegates position. It can be seen as an advantage that a potential bad actor requires much more than 1% support to gain access to a forging position.

Secondly, there is a cost of voting for a standby delegate in the form of forgone rewards. Reducing votes increases the cost of voting for standby delegates to a point where in the proposed system 1 vote will cause a 100% loss of rewards for voting for a standby delegate.

The high barrier of entry, or the “cliff” as it is known, is a a large gap of votes between the active and standby delegates that will widen with a decrease in the number of votes provided.

The third problem, of only requiring 41% of the market tokens to replace the active delegates, would be even easier with a one vote per account system. Honest players can amplify their votes by exactly 101 times against an outside, malicious, actor who only has votes due to their own holdings. Limiting a vote to a 1 - 1 ratio removes the ability to do this form of defense.

In summary, coalitions will be replaced by “Whales” or groups with large holdings who could masquerade as an individual delegates. In fact, current coalitions would probably form whales with enough pooled tokens to stay in forging positions. This would simply concentrate them, but not remove them.

As explained later on, voting for a standby delegate actually costs potential value to the voter. One vote per account will destroy most chances of a standby delegate of getting into forging position.

This LIP proposes to limit the number of votes to one vote per account. The most dangerous and alarming terminology is: …fraction of 1/101 of the total stake is guaranteed to be an active delegate (in other words, any malicious group gathering support of approximately x % of the total stake will be able to obtain x delegate slots).

In practice, the threshold to become an active delegate will be even lower for whales. Also, the claim that “some votes will also be cast for standby delegates” will be the exact opposite as we will see that standby delegates that are not voting with their own tokens will drastically lose voting % as voters are economically disincentivized to vote for non-active delegates.

Having only one vote per account will: First, change out Coalitions for Whales, and many of the current Coalitions are Whales, and so they will stay in position. Secondly, the threshold to become an active delegate is significantly lower which means that the security of the network also becomes lower. These two things are almost always connected.

Rationale

It is important to acknowledge that we agree that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, we believe the proposed change is not an improvement and will be a form of technocratic tyranny forced upon the users of the system.

To start, a common misconception about rewards needs to be explained, as it is a primary basis for the underlying security of the entire system.

Reward Sharing; the misconception of greed and rational self interest:

The Bitcoin Blockchain is obviously known for its incorporation of computer science and cryptography. Lesser known, but just as important, was Satoshi’s execution of economics and game theory. In particular, the reward mechanism incentivized users and produced value which created a positive feedback loop successfully taking bitcoin from 0 to 1. (and now from 0 to over $3,000 USD.

Adam Smith, the Father of Modern Economics, in his book “The Wealth of Nations,” explains that “It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.”

Altruism should not be expected of anyone. Instead, rational players are expected to act in their own self interest. Acting in one’s self interest is not greedy, it is simply rational.

In the case of DPoS, the system is created so that voters can assign vote to those who they think provides them with the most value. The form of this value can be anything: maintaining the network, providing security, issuing tokens for sidechains, creating apps, and most commonly sharing rewards.

In relation to Lisk, we should assume that rational players (during a normal time and not a time of war) will be likely to vote to maximize their value received from the system. This typically means voting for the top 101 active delegates, or as close to this number as possible.

On this assumption, by only having 101 votes and 101 forging delegates, voters are given incentive to vote for the top 101 to maximize value and most notably, voting rewards. Voting for a standby delegate literally costs them potential value so they are not given incentive to do so.

Vote sharing is simply a way for delegates to provide value to their voters, due to a lack of many methods of doing so.

The current system dynamics have evolved fairly organically for lisk. The main issue in regards to large coalitions is that they formed from Lisk’s fairly shallow ICO, cheap early price evaluation, and few market actors early in its inception.

Desired Properties

In regards to the expressed desired properties of the voting system:

  • Decentralization: The idea that delegates should be independent entities but not allowed to form a coalition is an oxymoron. They are not independent entities if they are not allowed to act independently, which includes allowing them to form coalitions. Lisk is a democracy founded on crypto-anarcho capitalism. Therefore, we may need to settle for a middle ground of independence and coalitions. The scaling trilemma comes to mind.

  • Simplicity: The best way to increase accessibility of voting is with Dynamic Fees. This will greatly encourage all users to participate in voting regardless of the size of their personal holdings. This is again, a problem that can be greatly improved without changing the voting system.

-Fairness: can be an achievable property. Simple solutions such as dynamic fees and increased vote count makes it easier for an account with small holding to participate.

Most importantly, changes to the voting system should come second to functionality, reliability, and security. The number one desired property of the voting system should be to allow for users to participate in the security of the network. Drastic changes to the voting system cause potential concerns to all of these properties.

Dependence on Stake

Stake is one of the underlying security mechanisms of the system. Similar to Satoshi’s Bitcoin incentive mechanisms, Stake ensures that bad actors are highly disincentivized due to the potential risk of losing value in their holdings and their own resources.

Additionally, tokens can’t be faked so it proves that value is pledged in the form of votes.

In general, less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

Large accounts can always obfuscate their size and so they will only vote just enough to allow their own delegate get into position and then split their vote weight to assist another account to get into position.

Dependence on Delegate Productivity

In regards to penalties related to productivity:There is no need to add complexity when the system’s voting acts as a self correcting mechanism for poor performance. In a case such as former Delegate Luukas, he stopped processing blocks and was unvoted just days later.

Additionally, this motivates malicious attacks on delegate productivity in order to have them removed automatically from the system rather then allowing rational voters to decide.

Changing the Maximum Number of Allowed Votes

Although it is not a complete solution, it is a fantastic idea to increase the number of votes, while keeping the number of forging/validating delegates at 101.

This would allow voters to signal their support for standby delegates without giving up potential value or rewards from voting for the active 101. (low cost other than the transaction fee from voting, which dynamic fees should make very affordable.)

This helps create an even landscape by reducing the cliff and encourages standby delegate participation. In other DPoS systems with lower votes, the cliff is incredibly vast.

This is a great example of a fairly simple change that has little effect on the protocol or consensus layer but vastly increases the potential positions (based on vote weight) for standby delegates. Vast changes that can create unknown effects and change the game theory and inherent dynamics of the system should be avoided and at the least highly scrutinized.

Dependence on the Number of Votes Cast

This is more of a oddity: Having a single vote will actually incentivize users to play into strange game theory to maximize their value.

Voters won’t want to vote for a delegate who have too many votes, because the % share amount will be less if the account has more vote weight to divide the shared reward between.

This will actually incentivize voting for accounts with less vote weight, instead of who is the better delegate. It’s unclear how this will play out but it’s strange nonetheless.

Vote Expiration or Vote Decay

The ability to vote almost anywhere and any time, without anyone’s permission, is one of the greatest achievements of the DPoS system. Along with other cryptographic security, such as immutability and the inability to forge votes, this system is one of the best evolutions of democracy the world has seen successfully implemented.

Also, concepts such as vote decay or election dates would remove the immutability provided by the blockchain.

As an interesting but perhaps controversial idea: It is very common for video games to completely wipe a beta server at the official launch of the game.

While it goes against the idea of immutability, a one time re-vote / election could be seen as a way to make the landscape more fair for new delegates who will never have a chance of getting votes from some of the large “lost accounts”

Ranked Voting

Score Voting

Both of these are interesting concepts; but again, the added complexity and unknown game theory make them a risk to stability and security.

Impact on Security

The greatest issue is that the security model would be greatly hurt with the proposed system.

Less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

This model replaces coalitions with whales. Even worse, potential undead whales.

If the requirement to become an active delegate is lowered to only require 560,000 LSK , then it will be easy for a whale entity to buy their way into the network.

In a more extreme case, a large account such as Oliver’s, could easily vote in six or more delegate positions for themselves. A malicious exchange could vote in many more.

Then imagine that this whale dies. Due to the majority of their vote weight coming from their own personal account, the system doesn’t have a way to easily remove them from the system.

In a more dynamic system, with many votes, you can choose to unvote this delegate and pick a replacement. More votes means a more healthy system. If three nodes are bad actors, then you have the ability to unvote all three of them, and instead vote in replacements without harming yourself very much.

With only one vote, the voter can only watch and hope that the under performing delegate is removed from the system and replaced with another.

Furthermore, voters lose all incentive to vote for standby delegates, and instead must speculate on their getting into position in the future. The cost forgone for voting for a single standby delegate means that you get nothing as an honest user.

Vote Transaction Object

Specification

New Vote Transaction

Computation of Active Delegates

Backwards Compatibility

Reference Implementation

In summary, the proposal of reducing votes to 1 will cause:

Less Freedom – Reducing the votes of users reduces civil and economic freedom. Less choices means less freedom because users are allowed less options to change the overall landscape of the ecosystem.

Standby Delegate Chances Destroyed – Voting for a standby delegate currently has a cost to the voter of potential value and rewards because they are not voting for active delegates. Less votes means that the cost of voting for a standby delegate increases. 1 vote will means that voting for a standby delegate maximizes the cost of rewards to 0.

Reduces Security – Currently, a delegate would require millions of LSK in approval whereas the proposed system only requires 560,000 LSK.While the intent is to allow easier access to honest delegates, it also makes it much easier for malicious actors to enter the system.

The main issue is not the voting system:

The current system dynamics have evolved fairly organically for Lisk. It is highly likely that the main flaws are early economics such as a shallow ICO, few early market participants, and delayed releases of a functional SDK.

It is likely that as Lisk becomes more valuable holders will dilute their positions and the tokens will become more widely distributed. Block reward reductions will also diminish the power of coalitions. Additionally. delegates will have more value to provide the system will a fully functional SDK and base transaction layer.

Instead of extreme changes that bring a lot of unknown factors and uncertainty to the system, we should seek to implement simple solutions that give users more freedom, fairness, and opportunity.

Thank you for your time, and I hope this feedback is found useful,

Written by Ultrafresh @ LiskUSA
In cooperation with Stellardynamic

Dear community

@Ultrafresh and Stellardynamic: thanks for your input.

I believe I already addressed most of your points in the discussion summary that I send this morning to the mailing list. I try to address some more specific points of you email below.

I would also be happy to see an alternative LIP by you that we could compare/discuss with the current proposal.

Cheers,
Jan

## Abstract

The proposed LIP11 will have the opposite effect of what it is intending to solve. It will likely cause a decrease in decentralization, replace coalitions with whales (or coalitions of whales), and competition will decrease as standby delegates are disenfranchised even further.

###Motivation

First, it is not believed that new coalitions can easily manifest themselves in the top ranks. They exist now, but their ability to be replicated and successfully voted in has not occurred despite attempts. One often overlooked flaw is that ICOs don’t guarantee widespread distribution. Few early market participants, and delayed releases of a functional SDK, allowed coalitions to become entrenched. These issues are not from an inherent flaw in the voting system.

See summary point 6.

Additionally, providing security of the system is arguably the most important aspect of the delegates position. It can be seen as an advantage that a potential bad actor requires much more than 1% support to gain access to a forging position.

See summary point 3.

Secondly, there is a cost of voting for a standby delegate in the form of forgone rewards. Reducing votes increases the cost of voting for standby delegates to a point where in the proposed system 1 vote will cause a 100% loss of rewards for voting for a standby delegate

Voters could still split accounts and vote for multiple delegates. If this seems too inconvenient, we could further discuss the suggestion by cc001 (see point 8 of the summary) and maybe somebody is willing to create an alternative LIP based on that suggestion.

The high barrier of entry, or the “cliff” as it is known, is a a large gap of votes between the active and standby delegates that will widen with a decrease in the number of votes provided.

The cliff will decrease dramatically as only voters in total owning around 500,000 LSK have to change their votes instead of 28 million LSK (vote weight of delegate 101 now).

The third problem, of only requiring 41% of the market tokens to replace the active delegates, would be even easier with a one vote per account system. Honest players can amplify their votes by exactly 101 times against an outside, malicious, actor who only has votes due to their own holdings. Limiting a vote to a 1 - 1 ratio removes the ability to do this form of defense.

This point is already discussed in the LIP itself and basically in both voting systems are huge amount of stake is necessary to obtain 51 delegates slots.

In summary, coalitions will be replaced by “Whales” or groups with large holdings who could masquerade as an individual delegates. In fact, current coalitions would probably form whales with enough pooled tokens to stay in forging positions. This would simply concentrate them, but not remove them.

See point 7 of the summary.

As explained later on, voting for a standby delegate actually costs potential value to the voter. One vote per account will destroy most chances of a standby delegate of getting into forging position.

This LIP proposes to limit the number of votes to one vote per account. The most dangerous and alarming terminology is: ...fraction of 1/101 of the total stakeis guaranteed to be an active delegate(in other words, any malicious groupgathering support of approximately x % of the total stake will be able to obtain x delegate slots).

In practice, the threshold to become an active delegate will be even lower for whales. Also, the claim that “some votes will also be cast for standby delegates” will be the exact opposite as we will see that standby delegates that are not voting with their own tokens will drastically lose voting % as voters are economically disincentivized to vote for non-active delegates.

Having only one vote per account will: First, change out Coalitions for Whales, and many of the current Coalitions are Whales, and so they will stay in position. Secondly, the threshold to become an active delegate is significantly lower which means that the security of the network also becomes lower. These two things are almost always connected.

## Rationale

It is important to acknowledge that we agree that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, we believe the proposed change is not an improvement and will be a form of technocratic tyranny forced upon the users of the system.

To start, a common misconception about rewards needs to be explained, as it is a primary basis for the underlying security of the entire system.

Reward Sharing; the misconception of greed and rational self interest:

The Bitcoin Blockchain is obviously known for its incorporation of computer science and cryptography. Lesser known, but just as important, was Satoshi’s execution of economics and game theory. In particular, the reward mechanism incentivized users and produced value which created a positive feedback loop successfully taking bitcoin from 0 to 1. (and now from 0 to over $3,000 USD.

Adam Smith, the Father of Modern Economics, in his book “The Wealth of Nations,” explains that “It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.”

Altruism should not be expected of anyone. Instead, rational players are expected to act in their own self interest. Acting in one’s self interest is not greedy, it is simply rational.

In the case of DPoS, the system is created so that voters can assign vote to those who they think provides them with the most value. The form of this value can be anything: maintaining the network, providing security, issuing tokens for sidechains, creating apps, and most commonly sharing rewards.

I agree with your reasoning here. A blockchain needs to be designed crypto-economically sound. That is why we propose several other LIPs that improve the overall system of incentives in Lisk, see summary point 3. Note that proof-of-work actually gives quite weak security guarantees for cryptocurrencies with a small market cap (see https://www.crypto51.app/ or the recent 51 % attack on Ethereum Classic)

In relation to Lisk, we should assume that rational players (during a normal time and not a time of war) will be likely to vote to maximize their value received from the system. This typically means voting for the top 101 active delegates, or as close to this number as possible.

On this assumption, by only having 101 votes and 101 forging delegates, voters are given incentive to vote for the top 101 to maximize value and most notably, voting rewards. Voting for a standby delegate literally costs them potential value so they are not given incentive to do so.

Vote sharing is simply a way for delegates to provide value to their voters, due to a lack of many methods of doing so.

The current system dynamics have evolved fairly organically for lisk. The main issue in regards to large coalitions is that they formed from Lisk’s fairly shallow ICO, cheap early price evaluation, and few market actors early in its inception.

### Desired Properties

In regards to the expressed desired properties of the voting system:

- **Decentralization**: The idea that delegates should be independent entities but not allowed to form a coalition is an oxymoron. They are not independent entities if they are not allowed to act independently, which includes allowing them to form coalitions. Lisk is a democracy founded on crypto-anarcho capitalism. Therefore, we may need to settle for a middle ground of independence and coalitions. The scaling trilemma comes to mind.

The point is that the proposed voting system does not give incentives to form pools in contrast to the current voting system. I agree that decentralization cannot be enforced, but only incentivized.

- **Simplicity**: The best way to increase accessibility of voting is with Dynamic Fees. This will greatly encourage all users to participate in voting regardless of the size of their personal holdings. This is again, a problem that can be greatly improved without changing the voting system.

I agree dynamic fees are one way to encourage voting. But the voting system should be also easy to understand for the average Joe in my opinion. I think this is both true for the current voting system as well as the proposed voting system.

-**Fairness**: can be an achievable property. Simple solutions such as dynamic fees and increased vote count makes it easier for an account with small holding to participate.

Most importantly, changes to the voting system should come second to functionality, reliability, and security. The number one desired property of the voting system should be to allow for users to participate in the security of the network. Drastic changes to the voting system cause potential concerns to all of these properties.

### Dependence on Stake

Stake is one of the underlying security mechanisms of the system. Similar to Satoshi’s Bitcoin incentive mechanisms, Stake ensures that bad actors are highly disincentivized due to the potential risk of losing value in their holdings and their own resources.

Additionally, tokens can’t be faked so it proves that value is pledged in the form of votes.

In general, less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

Large accounts can always obfuscate their size and so they will only vote just enough to allow their own delegate get into position and then split their vote weight to assist another account to get into position.

### Dependence on Delegate Productivity

In regards to penalties related to productivity:There is no need to add complexity when the system’s voting acts as a self correcting mechanism for poor performance. In a case such as former Delegate Luukas, he stopped processing blocks and was unvoted just days later.

Additionally, this motivates malicious attacks on delegate productivity in order to have them removed automatically from the system rather then allowing rational voters to decide.

### Changing the Maximum Number of Allowed Votes

Although it is not a complete solution, it is a fantastic idea to increase the number of votes, while keeping the number of forging/validating delegates at 101.

It would be great so see a LIP with concrete specifications that proposes this idea.

This would allow voters to signal their support for standby delegates without giving up potential value or rewards from voting for the active 101. (low cost other than the transaction fee from voting, which dynamic fees should make very affordable.)

This helps create an even landscape by reducing the cliff and encourages standby delegate participation. In other DPoS systems with lower votes, the cliff is incredibly vast.

This is a great example of a fairly simple change that has little effect on the protocol or consensus layer but vastly increases the potential positions (based on vote weight) for standby delegates. Vast changes that can create unknown effects and change the game theory and inherent dynamics of the system should be avoided and at the least highly scrutinized.

### Dependence on the Number of Votes Cast

This is more of a oddity: Having a single vote will actually incentivize users to play into strange game theory to maximize their value.

Voters won't want to vote for a delegate who have too many votes, because the % share amount will be less if the account has more vote weight to divide the shared reward between.

This will actually incentivize voting for accounts with less vote weight, instead of who is the better delegate. It’s unclear how this will play out but it’s strange nonetheless.

Assuming rational players that want to maximize their profits, the system will move to a Nash equilibrium where nobody benefits by changing their vote. Let us look at a simple example: Two delegates A and B
- A shares 50 % rewards
- B shares 60 % rewards
Further, assume a total of 1,100,000 LSK vote. Assume initially 550,000 LSK vote for A and 550,000 LSK for B. As you correctly observe, the voters for B receive more rewards so people voting for A would shift their votes to B. But they only do this until an equilibrium is reached where nobody benefits from changing their vote. The equilibrium is:
- 500,000 LSK vote for A
- 600,000 LSK vote for B
(B shares actually 20 % more rewards so also receives 20 % more votes in the equilibrium state).

### Vote Expiration or Vote Decay

The ability to vote almost anywhere and any time, without anyone's permission, is one of the greatest achievements of the DPoS system. Along with other cryptographic security, such as immutability and the inability to forge votes, this system is one of the best evolutions of democracy the world has seen successfully implemented.

Also, concepts such as vote decay or election dates would remove the immutability provided by the blockchain.

As an interesting but perhaps controversial idea: It is very common for video games to completely wipe a beta server at the official launch of the game.

While it goes against the idea of immutability, a one time re-vote / election could be seen as a way to make the landscape more fair for new delegates who will never have a chance of getting votes from some of the large “lost accounts”

### Ranked Voting
### Score Voting
Both of these are interesting concepts; but again, the added complexity and unknown game theory make them a risk to stability and security.

### Impact on Security

The greatest issue is that the security model would be greatly hurt with the proposed system.

Less choices means less freedom. Having the ability to vote for more delegates gives the voter more freedom because they have more choices that could change the final outcome.

This model replaces coalitions with whales. Even worse, potential undead whales.

If the requirement to become an active delegate is lowered to only require 560,000 LSK , then it will be easy for a whale entity to buy their way into the network.

In a more extreme case, a large account such as Oliver’s, could easily vote in six or more delegate positions for themselves. A malicious exchange could vote in many more.

Then imagine that this whale dies. Due to the majority of their vote weight coming from their own personal account, the system doesn’t have a way to easily remove them from the system.

In a separate proposal, we propose that such a delegate would be eventually removed, see point 4 of the summary.

We thank everyone for the discussion going on around LIP 11 and improving the DPoS system. However, we believe that these following issues have not been addressed.

By having the same number of votes as active delegates, the DPoS system creates an inherent monetary cost for voting for a standby delegate.

In the case of 1 vote, if a voting account wishes to give their full support to a standby delegate, they will lose all of their potential rewards. That is a 100% loss in vote sharing rewards for supporting a standby delegate.

We use our basic economic principles already submitted and; additionally, submit Ark as a primary example of a chain that has one vote per account. You will notice that standby delegates are almost non existent.

Having the ability to automatically eject an active delegate for being down, after a reasonable amount of time, seems like a good solution to our UndeadWhale Problem.

However, a major attack method seems to be completely missed by Lightcurve. While the idea of lowering the barrier to entry is great in theory, it fails to realize that lowering the barrier to entry allows for malicious actors to attack the system. It is very unlikely that the majority of delegates will be bought up by a single entity with the idea of severely disrupting the network.

Instead, the Parasite Attack is arguably a more dangerous attack. The Parasite delegate simply buys their positions like normal. An entity such as Oliver could easily acquire 6-7 positions themselves. An exchange could get hacked, and if the Lisk are stolen, even more positions could be acquired. However, instead of not forging, they use the forged rewards to hinder the network or siphon off the resources to develop their own competing project. No amount of slashing conditions will save you from these actors.

It is likely that many were not around during the early days of Lisk when members of Ark were performing this attack. Voters were able to eventually unvote them by voting in standby delegates. Currently, the 1 vote per account suggestion has no solution for this attack.

We believe it’s a matter of poor token distribution due to the ICO, few early market participants, and a short period of low price evaluation not giving outsiders adequate time to accumulate.

Additionally, we agree with this statement by Jan: “In my opinion, the main reason is that the voting pools have by far the largest influence on the decision of who becomes delegates.” Thus, if this opinion is so strong, then we suggest focusing on solutions that affect the problem without doing damage to the average user.

The 1 vote solution seems to completely disregard the loss of value and freedom the current voters have. Instead of changing the voting dynamics, perhaps we should look at token distribution. Although, Lisk has a fairly high deflationary rate (the next reward reduction will be 33%) we could influence the distribution of tokens even more by implementing reward sharing at the protocol level. Something like 35% to even 50% would directly affect the accumulation power of the active delegates while giving more value to the average user, instead of taking power away from the user.

Let us clearly identify the problems and fix them. If large pools are the issue, let’s do something about them without penalty to the average user.

Written by Ultrafresh @ LiskUSA
In collaboration with StellarDynamic

It’s very simple…
1 vote per account = THE LARGEST ACCOUNTS WIN, period.
This is NOT decentralization.

1 Like

Hi @janhack

I’ve read in your post about introducing BFT. Does this mean we will have a hybrid or BFT-based DPoS? I was reading these days about the BFT-based PoS Tendermint consensus used for cosmos. I think is definitely worth the read.

I also have my thoughts if this one vote per account will have the desired effect. I also think most users will just vote the delegates rewarding most. From user experience perspective is nice and cool and it has to be much, much easier than today to vote. Personally I agree with @hirish and @cc001 that most of the voters will just vote the highest rewarding delegate. The balance of voters won’t be the one we are all hoping for. Somehow you can see this today were most just vote for max rewards. So relying on people would be a terrible mistake for a consensus mechanism. It has to be self sustaining and sufficient.
I’m personally thinking about having a larger pool of nodes and only use 101 active. Increasing the number of active nodes too much may decrease the TPS but maybe here some other solutions can be found like supernodes . Anyway randomly selecting forging nodes would be a great idea, maybe also weighted based on different criteria like stacking, availability, rewards sharing, etc. Somehow

Hi,

With all due respect to HQ and research team, seeing proposal to change number of votes to 1 from 101 and keeping 101 top delegates. Makes me wonder whether LiskHQ creator/creators of the idea, even read the topic from github. It’s the weakest idea from entire github thread, but the easiest one to implement, one change in constants and force drop old nodes.

It will lead to chaos, some delegates from groups will rage quit, and possibly liquidate all their holdings pushing price to bottom. 1 vote per account increases risk of rich addresses voting their own nodes very easily, much lower entry point. It will also force some end users to just split funds to few different accounts if they decide they want to support more than 1 delegates, if not it will just make people vote for delegates sharing 90-100% rewards, which is also pointless, in that case it’s better to follow Ethereum way and move to POS, but this isn’t great route either.

Much better idea, with similar positive effect but less/no negative consequences is to simply split vote weight between voted delegates, as a voter there is problem to keep up with all the delegates and keep up with work and news they do (if any :slight_smile:) Splitting vote weight proportionally among voted delegates, allows voter to actually choose the number of delegates, they are comfortable to keep close look at, otherwise, most people vote full 101 and do nothing with verification whether they do some work or not and if shared percentage is accurate - in result, most delegates do nothing and defend themselves by saying that running node is enough effort.

Lisk DPOS can and could actually work fairly well in scenario when there is SDK out, however, no one would have thought that here in 2019 there is still no sdk. This pathological situation created sharing, which is really bad, and essentially pointless, these days it translates well to how politicians bribe citizens with all the “financial benefits / free money from government in any form” which are actually eventually paid by working people to the leeches, just to keep ruling party in power. 1 vote per account will just increase speed of this degradation.

How Lisk DPOS can be actually and significantly improved?
SDK, SDK and once again SDK. Most people are stupid and cannot think of anything else than SHORT TERM GAIN. Regular voter, who can vote for one delegate only, will just browse delegates find someones who shares something close to 95-100% and they are good to go, they won’t care any more than this. Thing is to place incentives in the right place, this is how proof of work works so well economically, it puts incentives in right place.

Who is/should be ideal delegate?
Group of people / team / company / foundation / talented developer working on some blockchain project based on Lisk. Most people won’t vote for such delegate unless they can make money, directly, short sightly, substantially. Such delegate, should share % of tokens in their project, proportionally to received vote weight on Lisk network. This gives huge incentive for voters to seek good delegates/projects to vote for, instead of voting for the ones sharing the most. This is actually very close to proof of work, but not the mathematical proof of work, but proof of development work. LiskHQ should at least verbally approve only this model and disapprove sharing and admit that this is consequence missing part of Lisk called SDK. Without SDK, We will never see how it would work correctly.

As delegate, whoever says that running Lisk node is such hard work and that it’s enough, they don’t need to do anything, it’s so hard, they need to keep network secured and that’s enough, should feel ashamed.

However, there are some things to improve in Lisk DPOS

  1. Proportionally split vote weight between votes you make, no vote cap. there will be rational vote cap based on individual abilities to track voted delegates.
  2. Slightly increase rewards for higher positions in Lisk network with the extension of top forging positions, 50-100 more forging slots would be much better, it has some drawback, but with SDK out this could be really beneficial for development of Lisk ecosystem. Perhaps creating rewards group, just for indicative reasons:
    Group 1 - (delegates rank 1-33) - 40% of reward
    Group 2 - (delegates rank 34-66) - 25% of reward
    Group 3 - (delegates rank 66-100) - 20% of reward
    Group 4 - (delegates rank 101-130) - 10% of reward
    Group 5 - (delegates rank 131-150) - 5% of reward (perhaps, not by value of block, but by chance of forging block/getting the forging slot)
    (Total inflation remains the same, % above indicative)
  3. Creating delegate punish mechanism, along with solution number 2, there might be some risk of downtime from delegates from lowest rank / group which does not have good enough incentive to maintain best productivity, even though they should have enough incentive to get to higher rank, it would be good to have mechanism to ban them permanently from network, lower rank - easier to get banned as delegate. Possibility to unban as transaction with very high fee, depending on rank.
    4.(rather optional) Project funding, similar to the one from Dash Masternode network, reducing reward to delegates by for example, 10%, reserving to the the proposals coming to the network. People and/or delegates could vote for best proposals, some sort of event/one time job for lisk ecosystem thing.

This can, increase a bit processing times in Lisk network, but economically and in matter of decentralisation in can be very beneficial. It will solve many problems, as well problem with NO COMPETITION between top delegates whatsoever. Some delegates who fought for top101 did a lot of work, but after getting there, do nothing, reward groups in top forging nodes will solve that as well.

Really, idea with one vote per account is disappointing, really bare minimum of thought. As delegate and member of Lisk community I don’t even have words to say how disappointing it is.

If someone feels like assembling this into fancy looking academic document, publishing it and submitting this as official LIP, feel free to use these ideas, MIT license on these :slight_smile: I don’t need to be included there, I don’t care, if anyone wants to discuss it on lisk.chat feel free as well. I might assemble it into LIP later, currently I don’t have enough time to write it in academic style, nor I like to do it, but really, it isn’t necessary, essentially it’s all here.

Either Lisk goes the right path or the easy path.

1 Like

I believe that I have logically, and mathematically, proven that the 1 vote per account system will destroy any competition or chances among standby delegates.

By having the number of votes equal to the number of active delegates, the DPoS system creates an inherent opportunity cost for voting for a standby delegate. (Currently the opportunity cost can be directly measured in the form of reward sharing)

To easily understand this concept, let us assume a voter only has 100 votes and that the reward sharing from each delegate is the average delegate sharing amount. This is because the opportunity cost is even greater for unvoting a high sharing delegate or pool vs a low sharing one and we want to keep the math simple.

If a voter has each of these 100 votes for active forging delegates then they receive 100% of their value from the system. If the voter wishes to signal for a non-active delegate, then they will lose a % of their reward proportional to the number of standby delegates voted for. This is the opportunity cost.

That means that voting for 1 standby delegate will have an opportunity cost of 1%. Voting for 50 standby delegates would then cause an opportunity cost of 50% to the voter.

In the case of a 1 vote per account system, if a voting account wishes to give their full support to a standby delegate, they will have a 100% opportunity cost for supporting a standby delegate.

Ark will be a primary example of a chain that has one vote per account. With 51 forging positions we will take a look at the cliff between the active delegate position 51 and the standby positions below it:

51 has 1.12% approval at 1,424,327 votes
52 has 0.43% approval at 554,126
53 has 0.27% approval at 339,799
54 has 0.21 approval at 266,893
55 has 0.14% approval at 176,409
56 has 0.10% approval at 133,229

As we can see, the cliff in a one vote per account system is a difference of around 61.6%. It merely takes 5 positions in into the standby delegates to have an approval rating an order of magnitude lower than the lowest active position. Only 10 positions later, the approval rating drops another order of magnitude and into non-existence.

LIP11 claims to increase competition among the delegates by reducing the votes per account to 1. Based on the logic above, the cost of voting for 1 standby delegate will increase from 1% currently to 100% in the proposed system. This is an increase in the cost by 2 orders of magnitude with a maximized opportunity cost of 100%. The evidence suggests that this will cause competition and fairness among standby delegates to be nonexistent.

I think this issue needs to be addressed.

1 Like

Well, I urge every mainnet forging delegate and standby delegates from rank 102 to 303 to signal attitude to this idea on the blockchain, here is the interface and instructions.
https://thepool.io/api/info/lips_approval/

Data on blockchain, interface open source.

2 Likes

I am an active delegate, and one of the few who voted in favor of the proposal.

In short, BFT would not be in compliance with the 101 votes per account. There is a lot of theoretical groundwork underlying this, where for instance implementations can be found at Cosmos and Polkadot. Voting is not the same as staking. With staking the issues brought forward by some here are counteracted by a bonding period, a high inflation rate that forces token holders to stake, and slashing which forces token holders to select trustworthy delegates/validators or get punished. Voting that is used for EOS and originates from Bitshares (inventor of dPoS) has marginally low block rewards so that validators cannot amass block rewards over time. In that sense, Lisk was flawed from the very beginning and not really dPoS. Furthermore, with a view to long time acceptance and competitiveness of the Lisk platform the costs for users need to be low. As much it is likely that platforms need to have much more than the current 101 validators for being recognized as decentralized. Cosmos e.g. will have up to 300 and Polkadot 1000+ validators. Some platforms like Dfinity and Ethereum 2.0 will have even more. All in all, with BFT being implemented for Lisk the 101 delegates with 101 votes per each account is without merits, and fundamental changes are necessary.

I’m not sure I’m following why one is incompatible with the other. But I do agree that DFINITY and ETH 2.0 seem to have the right approach. DPoS with 1 vote !== POS. I would like to see a full POS implementation with nearly infinite network participants like DFINITY.

The multiple votes and the fixed rewards per spot is what brings in the cartels and group effects. BFT is a method for reaching consensus based on the condition that a certain majority of components/delegates does not fail. It is questionable that with the cartels and group pressure on delegates (which is actually enormous in Lisk) there is currently unaffected consensus coming from a majority of “non-failing” delegates, and one that represents real delegation from stakes/voters. With a view to producing correct state transitions for blocks it might not be critical, but for governance it appears bad, as the cartels act primarily as preservers of their own benefits. Thereby, a system that has inherent group building/collusion tendency is not really a basis for BFT.

What if you just:

Eliminate the ability for delegate accounts to vote.

Make the voting process anonymous - kind of like an election, only major difference being the delegates can be un-elected at any time by the masses.

That is not realistically possible as delegates can have various anonymous LSK addresses they control. Cosmos intends to not give block rewards to delegates in the staking token but in a utility token (transaction fees etc.), however this would require sufficient network adaption in order that the utility token has value.

Anonymous voting is also not easily possible, and undermines transparency of blockchains. The advantage/effect it would have won’t be worth it.

1 Like

Maybe a hybrid consensus would be an interesting solution for Lisk. There are some PoW/PoS systems that have additional PoW in case PoS fails or becomes too weak. Lisk could do a dPoS/PoS, where every holding above a certain threshold of LSK can run its own masternode for getting stake rewards on own address, and the dPoS nodes are basically for reliability of the system with a view to PoS weaknesses.

Dear @Matthew_Alexander,

thanks for your detailed analysis with regards to the opportunity cost of voting for standby delegates. I will try to respond to the points you mentioned in your two last comments.

I agree with your general analysis: If you only consider the “Change to one vote per account” LIP, then the opportunity cost for voting for a standby delegate are all shared rewards (as long as the standby delegate is not yet active). That is also why we have the “Incentivise standby delegates” objective on the roadmap. Iker is currently drafting a LIP for this objective and the basic idea is that standby delegates would also be able to forge in certain slots and therefore share rewards. In particular, this means that standby delegates can already share rewards and only voting for a standby delegate does not mean that you do not receive any rewards.

Moreover, you claim in your analysis that voting for 1 standby delegate only has an opportunity cost of around 1 % percent. But in practice this is not true. For instance, if you do not vote for one member of the Elite Group, you already lose all rewards from 54 delegates, so the opportunity cost is much higher.

Another aspect to consider is how long you likely forfeit the block rewards. In the proposed voting system only accounts with a total balance of around 560,000 LSK need to change their votes for a standby delegate to become active. This can happen much quicker than accounts with a total balance of 29,000,000 LSK changing their voting preference in the current system.

An entity controlling 6-7 delegate slots has basically the following options:

  • Normally forge blocks in their time slot and receive rewards.
  • Not forge (lose rewards, be eventually banned according to “Punish protocol violations by delegates” roadmap objective)
  • Maliciously double forge/send invalid blocks (lose deposit due to punishment as defined according to “Punish protocol violations by delegates” roadmap objective)
  • Send invalid transactions or do DoS on nodes/delegates (anybody - not only delegates - can do this, but the nodes would be banned soon as defined in LIP 0004 )

In any case, the effects on the network are limited and the maliciously entity either contributes or loses a substantial amount of money. Even if accounts or exchanges get hacked, the attacker wants to make money so would either sell immediately or use the tokens in a profitable way.

The general question here is: Do we think it is desirable or necessary (for security) that the majority of accounts in terms of stake approves (via the current approval voting) that somebody is allowed to forge blocks? I think for security this is not necessary as shown by many proof-of-work and proof-of-stake blockchains in pratical use. I further think it is not desirable that the majority needs to approve that a 5 % minority in terms of stake (this can be many different individuals) runs 5 delegate nodes, for instance.

I believe the evolution of the token distribution is mostly influenced by the block rewards and transaction fees. I don’t think reward sharing should be enforced by the protocol (enforcing a higher percentage of reward sharing that you suggest is equivalent to a lower inflation if everybody votes).

Cheers,
Jan

Hi @Ionut,

thanks for your comment. See my response below:

I think what is confusing is that the term “consensus” is used rather inconsistently in the blockchain space. I would distinguish the following two parts:

  1. Who can propose/forge blocks or participate in the consensus?
    The block proposers are typically selected using either proof-of-work (hash computations) or proof-of stake (randomized selection proportional to stake) or DPoS (voting).

  2. How do the consensus participants agree on one blockchain?
    This is what I would call a consensus algorithm. This can be the longest-chain rule (Bitcoin), Casper, Tendermint or the proposed BFT consensus LIP.

So the “Change to one vote per account” LIP only proposes to change part 1, i.e., how block proposers are selected. This can be combined with different solutions for part 2, i.e., Casper, Tendermint or the proposed Lisk-BFT consensus algorithm. I hope this answers your question.

I agree that most people in the current voting system as well as in the proposed voting system will vote to maximize their personal profit (although there are some idealistic people taking other factors into account). Economically, this is the rational behaviour and this should therefore be assumed when analysing a voting system. Assuming only this behaviour in the current voting system would mean that everybody only votes for active delegates and a change of delegates almost never occurs due to a huge number of voter representing 29,000,000 LSK that would need to change their preferences (the deviations in practice are largely due to the rules of the voting pools). For the proposed voting system, also everybody would vote for active delegates, but already a rather small group (560,000 LSK) can organize themselves to get one delegate into place.

Cheers,
Jan

Dear @thepool,

thanks for suggesting an alternative proposal. It would be great if it is concretely specified as a LIP (it is not necessary to have such a long motivation and rationale section as in the “Change to one vote per account” LIP, but the specifications need to be precisely stated). I guess it would be best to then open a separate topic to further discuss it there.

You can further find my response below.

This was already suggested by @cc001 and is also discussed in point 8) of the summary of my post above. Note that this change is equivalent to changing to one vote per account if you ignore the usability aspect for users to manage multiple accounts. In particular, almost the whole analysis for the “Change to one vote per account” LIP also hold for your proposal. For instance, we also would have proportional representation (a group owning x % of stake can basically decide about x % of the delegate slots) and, in particular, 560,000 LSK would be enough for a group/whale to vote itself into a delegate position.

Comparing to the “Change to one vote per account” LIP, the advantage of your proposal is the usability if users want to vote for multiple delegates. The disadvantage, on the other hand, is that in your proposal the voting system and code is more complex, in particular, processing vote transactions and determining the active delegate set is more complex and less efficient. Otherwise, the main properties of both proposals are the same.

I think the suggested difference in rewards would be unfair (all active delegates have the same amount of work in running a computer and forging blocks) and lead to several cliffs within the delegate ranks. For instance, a delegate on rank 33 would receive almost twice the amount of rewards as a delegate on rank 34. This would likely mean that the delegate on rank 33 receives a lot more votes (as it can share more rewards), than the delegate on rank 34 and can also accumulate a lot more tokens over time, which manifests this difference even further.

This is a good idea. But as it is a separate objective on the roadmap, it would be best to address this topic in a separate LIP/discussion.

As already mentioned above, I would personally be happy to see a proposal for a democratic, transparent and fair way to support community initiatives (Santerr proposed the creation of a DAO). I would also separate this topic from the voting system and address it in a different LIP/discussion.

Cheers,
Jan

Dear @carolina_delegate,

thanks for your thoughts and comments, see my response below:

This is a very good point. If the BFT consensus algorithm tolerates up to 33 Byzantine (malicious) delegates, then we would like the property that these represent approximately 33 % of the voters and not only one voting pool due to collusion. Therefore, it is important that a voting system that does not incentivize collusion.

Actually, as part of the roadmap objective “Incentivise standby delegates” we are exploring to go into this direction. This is still work in progress, but the basic idea is that standby delegates can forge proportional to vote weight (not stake) in a few slots.

Cheers,
Jan

Hi,

Thanks for reply.

Well, that changes a lot. I see no point in shaking entire network to first make change “one vote per account” and then patch it with different changes. Such big consensus change which will shake all forging delegates, it should be made as one LIP with all changes affecting forging positions. If not, incentive for standby delegates should come first.

Agreed, it might be bit more complex, but most people will support it unlike one vote per account. As I mentioned, it’s reasonable that voter should have ability and convenience to support and verify/track as many delegates is capable to with account weight being split proportionally.

I don’t agree. Running delegate account is not just running a computer and forging blocks. Good delegate is working on ecosystem, creating tools and doing other social/promotion work, maybe little sharing now too. In future - developing apps and sharing tokens in new apps to the Lisk voters.
Only running computer and forging blocks - is just being bad delegate, not to say, shitty delegate.

Right now, once you get in top 101, there is literally no incentive to do anything and I have seen that many times for people who made it into top 101. Their efforts stopped as soon they got in. However system is also flawed, as there is not much to do without SDK. Literally everything has been made, there is no more tools to develop. So hard to blame them too.

Cheers

Hi all,

The general feeling in the community is that Lightcurve and LiskHQ will push the update forcefully.

As expressed in other channels, the general feeling and perception is that Lightcurve will forcefully impose their “Change to one vote per account” “proposal”. Besides the already expressed potential dramatic consequences (exchanges owning most of the forging spots, +90% shares, discouragement of support of the ecosystem, yada yada…). This would put in serious discussion the LIP process per se and the whole centralization of the project. LIP stands for Lisk Improvement Proposal, please reflect on the word proposal. Proposal means something you discuss and then you agree. If Lightcurve GmbH decides to force such update, this would be yet another huge blow that Lisk takes in terms of centralization.

I’d recommend to take further inspiration on the BIP process, where the LIP process take inspiration, works:

Given that the majority of the network does not agree with the change (thanks @thepool for organizing the survey here: https://thepool.io/api/info/lips_approval/ ) and looking through this thread, only 2 voice supports the idea. Can we consider this proposal rejected and move ahead with a newer iteration, perhaps getting away from the mentality of making an easy change just for the marketing purpose?

We all agree that Lisk consensus algorithm can be improved. What I do not agree is that a quick change gets implemented in order to create some marketing.

I would like to share the following thinking in order to analyze the situation by taking some steps back. What is the role of a delegate?

Let’s take a step back and see what is the role of a forging delegate. The main task of a delegate is to make sure that the Lisk network runs smoothly and safely by keeping their infrastructure secure and an uptime as close as possible to an 100% in order to not slow down the block approval process. For this reason, the delegate that does this operation gets rewarded with LSK. It would be nice (even if not written anywhere) that this amount of LSK gets reinvested in resources for the Lisk Ecosystem in order to increase the adoption/value of it. Now let’s look at the current situation. Is the network running smoothly? Yes. As I guess most of us remember, Lisk went through some issues with the network stability multiple times in the past, one in particular was due to a malformed transaction (referring in particular about the 2nd of June bug, recap here https://www.reddit.com/r/Lisk/comments/8o033l/lisk_blockchain_temporarily_halts_due_to_an/) that halted the blockchain for some hours. Panic hours, but everybody ready to solve the situation. The network started to validate blocks immediately after the hotfix has been deployed and the whole network recovered in matters of hours. Therefore the base task of a delegate I would say is covered.

Getting back on the reinvesting into the ecosystem point. Funds are being reinvested in the ecosystem. We could take as example the two Lisk startup incubators from Elite group in China and Japan; or perhaps the Lisk Center in Utrecht from GDT; or the operating Lisk based exchange EliteX, with plans to become a DEX down the road; Or perhaps the countless sponsored and organized meetups. Furthermore is worth keeping in consideration the opportunities that the forging rewards created under the form of bounties in order to incentivize community members to stay in the Lisk community.

The follow up question on this point could be, are this fund reinvested in an adequate way? Maybe yes, maybe not, but for sure this actually created an ecosystem of contributions back to the community that were not designed by the protocol itself. But perhaps this a topic for another day.

According to the previous points I believe the delegates are doing a good job. Is it the consensus algorithm perfect? No and perhaps never will be and for sure the status quo can be improved, but the fact that the network runs smoothly, this gives us the possibility to work together in order to create better a consensus algorithm, instead of rushing the change because Lisk didn’t manage to handle bad press from competitor projects (spoiler alert, there are much worst projects with DPoS algos doing fine). Perhaps switching priorities on the roadmap allows the project to find and work on more elaborated and adequate improvements to the consensus algorithm (perhaps even considering on creating voting anonymity).

Please do not push such changes to create some marketing. Don’t apply a patch that can create more harm than good with the risk of destroying the ecosystem built. The reason why there is so much focus on the DPoS and seems to be priority #1 for the rest of the world is because people have nothing else to focus on Lisk besides the 101 forging positions, this created a lot of bad taste in the mouth of people that did not succeed, allowing competitors and trolls to exploit the situation in order to create bad press.

Nevertheless, forcefully pushing the “One vote per account” rule, brings up some conspiracy theories that have not been expressed in this post yet. One of the conspiracy leads to think that Lightcurve will forcefully impose this change for their own personal interest, given that the team holds 15,3m, which would be enough to self sustain ~30 forging positions assuming the 500k initial entry gap, but even one single account in forging position from Lisk Foundation/ Lightcurve GmbH would destroy completely the credibility of the project.

I hope nobody gets offended by my thoughts.

2 Likes