[Withdrawn] Change to one vote per account

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.

1 Like

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.

1 Like

@janhack Any comment on my last message, or any update on the LIP11?

Hi carbonara,

thanks for sharing your thoughts on the LIPs process and governance. I agree that it would be nice
to have a governance system that is part of the protocol where not only delegates, but every account holder can vote on protocol changes or other topics related to Lisk. Something like this could also be proposed as part of the LIP process.

The purpose of this thread is to discuss the advantages and disadvantages of the “Change to one vote per account” LIP, not the decision making process around LIPs. The community review and input is valuable for us and we take it seriously. This is one of the main reasons for establishing the LIP process and this forum. We will soon publish more LIPs which tackle the different roadmap objectives in the “Delegated Proof of Stake” roadmap phase. These will give a more complete picture of the things that we are trying to achieve in that roadmap phase. So stay tuned for some exciting new proposals to discuss.

Furthermore, we would also be happy if the community finalizes some of the proposals that they brought forward and they open a pull request on the lips GitHub repository.

Cheers,
Jan

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

I created a PR for this LIP with status Withdrawn as we published a proposal for a different voting system today.
https://github.com/LiskHQ/lips/pull/27

1 Like

@janhack :+1: thanks for following up on this.

I will close this topic as the proposed LIP is withdrawn. Please provide any feedback regarding the new proposed DPoS system in the topic for the respective LIP: