Last February, we published a proposal to change the voting system on Lisk’s Research Forum following the Lisk Improvement Proposals (LIPs) process. This thread has received a lot of attention and discussions. Voting and elections are a hotly debated subject in general — Lisk is no exception. Not every LIP requires a blogpost, but we feel it’s important to expand on this topic to the wider community. We’d like to thank every member of the community who has dropped by the forum to share their thoughts on the future of Lisk’s consensus algorithm.
We are happy to announce that we have published three new LIPs to achieve the “Network Consensus” roadmap milestone, at the same time incorporating community feedback.
This blog post is broken down into three main sections. In the first, we describe the properties we feel are most important for a voting system. Then, we point out areas of improvements and why the current system needs an update in the first place. In the second section, we give an overview of the proposal made last February and some proposed solutions by community members. We also explain why we have edited our roadmap to prioritize the improvement of our DPoS. In the third, we present the content of the three new LIPs and explain why we believe them to be the best solution for Lisk. Each one of the new LIPs has a dedicated thread on the research forum where it is published and discussed.
- A delegate: any account which has expressed interest in being a block forging account. This is done by issuing a “register delegate” transaction via Lisk Hub or Lisk Commander. Any account can register as a delegate. At this time, there are 1804 registered delegates.
- Active delegate (for a given round): a delegate selected to forge a block and receive block rewards in this round.
- Vote weight: the amount of support given by a vote. Currently, any vote you cast has weight equal to your account balance. With the new proposal, you can choose the vote weight of each vote you cast.
- Delegate weight: the weight of the delegate in the selection mechanism. A delegate with high weight is more likely to forge a block than a delegate with low weight. Currently, the delegate weight is calculated as the sum of all the votes they have received.
- Standby delegate: a delegate not active in a given round. Currently, those delegates do not receive the right to forge blocks. In the new DPoS system, they would be selected to forge proportionally to their delegate weight.
Before getting into any specifics, we’d like to define the factors relevant to the choice of our DPoS system. In other words, how do we define the process and set of rules to select the forging delegates in Lisk? As mentioned in the “Change to one vote per account” proposal, there is no such thing as the perfect voting system, but depending on the specific blockchain’s use cases and specifications, different properties can be prioritized. For Lisk, after all the feedback expressed by the community (gathered in the mentioned proposal and through other channels) and an internal research considering this feedback, we came out with five properties for the voting system:
- Decentralization: The voting system should not incentivize voting groups or coalitions. They may be created by community engagement or social reasons, but the voting system should not itself encourage them.
- Open & Fair: Our DPoS blockchain should encourage motivated individuals to run a forging node. Fairness is difficult to define, but in general for PoS systems, it can be approached when forging delegates receive block rewards proportionally to their staked tokens.
- Security: We should incentivize stakeholders to elect delegates who maintain a secure and effective network. Our DPoS system should also enforce some sort of accountability for delegates. This is, if a delegate is not behaving by the rules, this behaviour can be spotted and the delegate punished.
- Efficiency: The voting system should allow to efficiently compute the set of forging delegates. Also, voting transactions should be kept as small and efficient as possible. This way the network will be able to process blocks faster and it will scale easily with the increasing number of voters.
- Flexibility: Voters should have the flexibility to give different vote weights to their preferred delegates if they choose so.
Currently in Lisk, every account holder can vote for up to 101 delegates and the weight of each vote is the balance of its account. This voting system faces three key challenges:
Incentive to form coalitions: Your current vote weight is independent of your number of votes. This creates a high incentive for delegates to form coalitions by voting for each other. The Lisk blockchain aims to be a trustless system, relying on decentralization for its security. To put it simply, the voting system should give no economic incentive for delegates to form groups and instead foster decentralization wherever possible.
High entry barrier: There is currently a very high barrier for anybody wanting to become an active delegate. For example, a delegate with the support of roughly 5% of the total amount of LSK might not be able to become an active delegate. This opposes the core principle of PoS claiming that your probability of forging should be roughly proportional to your account balance.
Complex delegate weight updates: In the current system, all transactions mean a change of the account balance which in turns means a change of the affected delegate weights. This adds a lot of strain on the network and affects its efficiency. This is especially the case when a block contains a balance transaction where the sender and the recipient of the transaction are accounts voting 101 delegates. It can be the case that this transaction requires to update more than 200 values (consider that these accounts are voting different delegates) in the nodes database.
To dive into potential solutions to the challenges listed above, let’s detail three of the propositions made in the research forum.
One Vote per Account
As the starting point of the discussion around the `Change voting system` roadmap objective, the Research Team proposed the “Change to one vote per account” LIP. With this proposal, every account would have at most one vote with a weight given by its balance. This proposal addressed the three main challenges of the current system mentioned above: Allowing accounts to only cast one vote would remove any mathematical advantage of forming coalitions. At the same time, it would lower the barrier of entry, so that gathering support of 1% of the total LSK would be sufficient to become an active delegate. Additionally, this system makes the computation of delegate ranks very efficient.
However, since each account can only cast a unique vote, it does not give enough flexibility for the users to vote according to their preferences. This LIP has gathered a lot of attention and we recommend you to read the full debate.
Proportional Reelection Each Round
An option suggested on the research forum by cc001 would be to re-select the forging delegates randomly each round, proportionally to their total vote weight. This system doesn’t have a fixed set of active delegates and forging delegates are re-selected every round. Choosing the delegates this way is interesting. In fact, we are taking a similar direction in order to select the two forging standby delegates (see the New Selection Mechanism section below).
Selecting delegates this way does address the three challenges mentioned above. However, it also introduces most of the difficulties found in proof of stake systems, such as a very unsteady set of forging delegates or having access to a good source of randomness. The research forum link mentioned above includes the debate on this topic.
Change the Maximum Number of Votes
Another key proposal suggests keeping the current voting system, but modifying the maximum number of votes. Forum member “Consensus” suggested lowering this number to 20. This would limit the ability to share votes in a coalition and would improve decentralization of the network. On the other hand, “cc001” would prefer to increase it to 131. This would give accounts the possibility to vote for all 101 active delegates to receive rewards and still have 30 votes left to support standby delegates.
Overall, changing the number of delegates could be a step in the right direction for Lisk, but it doesn’t directly solve the challenges stated above. Modifying the number of votes can change the extent to which delegates exchange votes, or can mitigate the high entry barrier problem. But it doesn’t reduce the complexity nor does it increase the accountability of the current system. We feel that we need a more convincing change.
After much discussions on the research forum and additional research from our team. We felt that the above solutions do not fully address the current challenges, or, in some cases, create new ones. The discussions on the research forum have been very helpful and the new DPoS presented below owes a lot to them. We would like to thank cc001, thepool, st3v3n_delegate, carbonara, carolina_delegate, 5an1ty, Matthew_Alexander, Santerr, hirish, korben3, Simon Warta, JesusTheHun, lisk.central.america for their contributions in the forum discussions.
Considering the mentioned limitations of the current voting system and the extensive feedback from the community on it, we have decided to update the timeline of the Protocol Roadmap presented at the end of 2018. The “Network Consensus” milestone will now be implemented before “Network Longevity”. This implies that the changes in the voting system and related aspects in the consensus algorithm will be implemented and released next after the “Network Economy” milestone.
The main motivation for this decision is to bring these improvements to the DPoS system and network consensus sooner rather than later. We acknowledge that these improvements are more important than, for example, implementing a new ID system. Additionally, the “Network Longevity” phase includes the “Introduce decentralized re-genesis” objective. The nature of this objective makes it more effective once the protocol changes from the DPoS milestone are implemented. You can read the full rationale here.
The three new LIPs define a whole new mechanism for choosing the forging delegates in Lisk. If chosen for implementation, they will introduce a new vote transaction, a locking mechanism for voted tokens, a new way to compute the delegate weight and a new method to select forging delegate from those weights. We believe these changes address the current challenges in our consensus algorithm. The three LIPs would allow users to support their favorite delegates with their votes having significant weight, as well as allow motivated individuals to run a forging node and receive rewards for their efforts.
We also introduce consequences for delegates violating the consensus rules and for their voters. This makes voting an important decision and we recommend that you research available information on the delegates you wish to vote for.
New Voting Mechanism
The LIP Introduce vote locking periods and new vote weight definition proposes a change of the voting system. We suggest to move closer to a proof of stake system by having voters lock their tokens when casting a vote. This means that voting is now more consequential (your tokens are locked) but also more flexible (you can choose how much you lock for each vote).
Accounts will be able to vote for up to ten delegates, but a given LSK token can only be used in a single vote. This system brings new benefits by, for example, taking away the incentive for delegates to “trade” votes. In other words, delegates will have no incentive to form alliances since they are encouraged to campaign independently for each vote.
This also means that any delegate gathering support by a fraction of 1/101 of the total stake is guaranteed to be an active delegate. We feel that this is an important feature of proof of stake systems and we would like to see it appear in Lisk.
Even though they are “locked”, the tokens used for voting are still your own. The delegate does not gain any access to them. In no case should you send tokens to a delegate while voting.
Unvoting will be done with the same transaction, but with a negative amount. After unvoting, you will have to wait for a given amount of time before to be able to use the tokens for something else. The waiting period for voters will be 2000 blocks, roughly five hours and forty minutes. This allows regular users of the network to vote for their favorite delegate but to regain access to their tokens in a short time. Delegates play a crucial role in Lisk since they secure the network and process every transaction. As such, their commitment is expected to be even more meaningful. For this reason, the waiting time for delegates voting for themselves (self-votes) is 30 days.
The computation of the delegate weights is also modified to account for the amount of self-votes cast by delegates. The new delegate weight is computed as the minimum between ten times the delegate’s self-votes and all the votes received by the delegate (self-votes plus votes from other accounts). This means that the delegate weight must contain at least 10% of self-votes.
This new way of computing the delegate weight makes it necessary for delegates to have at least a portion of their tokens locked. This makes delegates more accountable for the blocks they forge and will be an additional incentive to run a safe and secure setup.
New Selection Mechanism
The LIP Use Randao-based scheme to include standby delegates and reorder delegate list introduces two new forging slots in each round. The round length will be now 103 blocks. Those two new slots will be assigned to two standby delegates randomly and proportionally to their delegate weight.
The second DPoS LIP defines how to choose those two standby delegates and analyzes the expected number of forging slots one can expect. If the sum all the standby delegate weight is 1,000,000 and you have weight 10,000, you would be selected every 50 rounds on average. This corresponds to fifty blocks per month. Of course this is only an estimation — the actual number of blocks you get to forge as a delegate will be random and will depend on the number and the total weight of standby delegates. But, in general, this improvement makes it possible for most of the registered delegates to forge blocks, which will encourage them to run a node and participate in the network security.
Punishment for Protocol Violations
The third LIP Punish BFT violations introduces a way for users to report delegates creating contradicting blocks to the network. The roadmap milestone “Security and Reliability” introduced the BFT set of protocol changes. The BFT LIP specifies which rules the delegates should follow to avoid proof of stake problems like the nothing at stake problem. However, encouraging honesty among delegates and punishing misbehavior is currently not part of the protocol. This new LIP introduces a transaction type called “Proof of Misbehavior”. This transaction allows users to reveal to the network any BFT protocol violation by a delegate. This proposal also specifies the consequences of a breach of protocol.
In short, a punished delegate will be stopped from forging for 90 days. Its self-votes will be locked for 90 days and all of its voters votes will be locked for 30 days.
This is a strong incentive to respect the BFT rules. Trying any kind of violation will have a very little chance of being profitable and this mechanism will help the network to remove all delegates running faulty or non-reliable software.
There is a common critic towards such punishments: it trades some liveliness for security. Indeed it is now less harmful to miss a block than to double forge. This is a wanted feature in our network. Missed blocks are only a mild issue which is mitigated by running a stable server on a stable internet connection. On the other hand, consensus violations can be used to mount an attack on the entire chain and should be totally avoided.
Now that we have a general overview of the proposed DPoS improvements, let’s have a look at how the three new LIPs will achieve the five properties we outlined at the beginning:
- Decentralization: This proposal states that one LSK can only be locked to one delegate. Delegates are incentivized to campaign independently and to break any coalition to attain the maximum possible rewards. This is complemented by the inclusion of standby delegates slots. Users will now have a greater incentive to register a delegate to get some block rewards, hence increasing the decentralization of the network.
- Open & Fair: In line with the previous point, the new DPoS system means a voting system based on proportional representation. Having two standby delegates spots every round allows delegates with smaller delegate weight to get a definite chances of forging new blocks. Assuming one million LSK voting for standby delegates, a delegate with a delegate weight of around 10,000 LSK can expect to forge fifty blocks per month. This is a vast improvement compared to the current situation where delegates need more than 25,000,000 LSK to start forging their first block.
- Security: One of the key features of the proposed voting system is that it introduces delegates and voters accountability. Delegates who want to be selected as forging delegates have to lock a considerable part of their stake as self-votes. This automatically creates a commitment of the delegates with the network, if they do not comply with the protocol rules they may lose access to some of their tokens and their right to forge for a good amount of time. In the same way, voters are incentivized to vote for good and productive delegates. This concept is enforced by the LIP Punish BFT violations, as it creates incentives for users to monitor the network searching for misbehaving delegates.
- Efficiency: The introduction of locking votes would mean a great improvement in the block processing efficiency. The complexity pitfall explained in the “Reasons to improve our DPoS mechanism” section above disappears in the proposed voting system, since the votes submitted by an account are locked and cannot change with any other transaction type. This basically means that the delegate weights are updated much more efficiently, which in general implies faster block processing.
- Flexibility: With the new proposal, users of Lisk can decide how much support their account gives to each of their preferred delegates. This way, users can define a voting strategy depending on the amount of tokens they have and their confidence in the different delegates.
We invite all community members to go to the forum, read the LIPs and give feedback. This blog post is a general overview and more information is available in the different threads. We are always happy to hear your feedback and will be present on the Research Forum for further scientific discussions on those LIPs.
Lisk Research Team
Lisk is on a mission to enable you to create decentralized, efficient, and transparent blockchain applications. Join us: