Educational

LiskUSA response to LIP11

Google+ Pinterest LinkedIn Tumblr

## 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 evolution 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 malicious delegate would require millions of LSK in approval whereas the proposed system only requires 560,000 LSK.

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