Second LiskHQ’s AMA About DPoS LIPs
On October 15th, Iker Alustiza, Research Scientist at Lightcurve, came in Discord to answer questions related to the latest 3 DPoS LIPs or current research.
“if you could compare complexity of implementing BFT to the new voting system with incentives and punishments, what’s harder?” asked przemer.
According to Iker “As you may assume, from the user perspective, the new voting system will have a great impact since it completely changes the dynamics of the system, whereas the BFT LIP is secondary, almost transparent to the end user. But for the implementation I would say that the situation is almost the opposite. If you have had the opportunity of reading over the BFT LIP, you may see it is a quite complex topic, impacting most of the core of Lisk’s consensus algorithm.
This is why it requires a significant effort, specially for testing, as my colleagues in development are doing at the moment: change chain mechanism, round system, new synchronisation mechanism etc.
On the other hand, the DPoS LIPs require a set of changes which are not so deep in the core of the system.I would say that the big challenge for the voting system implementation is not the actual implementation but to organize a smooth migration to the new system on mainnet.”
Ionut from Chainode Capital asked: “wouldn’t make sense to start a new network where every node downloads the DB snapshot and voting is reseted? This would also be a motivation for voters to wake up and get involved”
But according to Iker there are 2 main reasons: “It may be the simplest technically way to deploy it but:
a) I can feel it would be controversial and not easy to get the necessary consensus in the community, as someone may say that is a different fork/new blockchain
b) the instability of the first moments when there are not enough votes casted in the network would be too dangerous for such a mature project as Lisk, specially for exchanges and third party tools.“
Some questions from ultrafresh came up: “Would it be more accurate to say that a chance of forging is based equally between total vote weight and the minimum locked tokens? For example, if you have a 10,000 vote weight, but only 500 self votes, then you would actaully only forge at a rate of having a 5,000 vote weight?”
“I think it is correct to see it that way. Delegates should always have in mind the ratio between their self-votes and the votes from other accounts. With that, they will try to maximize the chances of forging by playing with this ratio and if every delegate behaves in this rational way, a equilibrium should be reached…but of course this is much more complex in real life, it is going to be very interesting to witness” answered Iker.
Ultrafresh also added: “As far as introducing the 2 standby forging slots, I’m sure stability has something to do with limiting the set, but why not increase this to 4 and double the number of standby delegates that participate in each round?”
And the last answer from Iker was: “Indeed I believe that to have 4 slots is not a meaningful impact in the security (and properties of the random process). But we came up with this 2 slots figure for other reasons, not only the security aspect: rounds would be longer than now (with 4 slots would be approx 4% longer) and we believed these are already long enough.”
———————————————-
Lisk Magazine is a project supported by Lisk Italian Group and EliteX.
Support our work, vote for Lisk Magazine.
