Following the last fork of the Lisk network, several delegates were unproductive for about three weeks. Though this is not a security concern, we could improve this feature to prevent a situation with even more unproductive delegates. Two main options come to mind:
shortening the banning tolerance to 2 weeks,
introducing a modified delegate weight computation to include the delegate performance.
Keep in mind that the proposed change must be fully deterministic and only rely on past information, e.g.: it is not possible to know in advance if a delegate will propose a block for the given block slot.
Also, it is important with the current consensus algorithm that delegate banning does not happen too quickly when a delegate is inactive. Roughly speaking, this time window is equivalent to the frequency at which nodes should connect to the network to reliably choose the correct chain. So if delegates are banned after 2 hours of inactivity, then a node not connected for 2 hours could be susceptible to a long range attack.
General Productivity Incentivization
To make delegate productivity more impactful we could (additionally, and separately) introduce a new protocol feature that makes missing blocks more costly. Currently the cost of missing a block is missing the block reward = 1 LSK. Options could include:
Missing a block ==> burning some self locked tokens,
Missing a block ==> future blocks have a reduced block reward.
Note: the economic incentive to forge (= gaining 1 LSK per block) should be in balance with the cost of missing blocks. As such, a rule like: 1 missed block = 1000 LSK burned would probably not be desirable in our case.
So far, the opinion of the research team was that such an additional rule is not really necessary, and that the block reward is incentive enough for delegates to run proper setups. Testament to this being the very low number of missed blocks in general.
Let us know what you think of those options or if you have further ideas on the topic. We look forward to exchanging ideas with you.
I think shortening the banning to 2 weeks is a good idea.
Missing 1 block I don’t think is a big enough issue to warrant the changes.
I also like the idea of a delegate missing blocks gets “jailed” and their weight goes to 0 until they fix the issue and do the “unjail” transaction to forge again. If they don’t do that within 30 days, then they are banned. In this situation I think the “jail” should happen faster then 2 weeks. Maybe in the 3-7day range.
Missing a block ==> burning some self locked tokens,
I think no one want burn their token.
This option in my opinion can be use only when delegate can fast pause and resume forging without remove selfvote. For example you know you have server problem and you miss blocks, you dont want burn selfvote then you run backup server. Risk is when you run backup server you main server will start respond and you will doubleforge and get POM. If you will can pasue forging without remove selfvote and waiting 30 days you have time to repair server and resume forging. If you will miss X blocks and do nothing you can lose selfvote by burning. Optionwith burning is for sure most drastic
And this delegate will be still red on network unless 100 miss = -1000 lsk selfvote then will be fast kick out
Missing a block ==> future blocks have a reduced block reward.
In this option delegate can create new delegate account and transfer funds if is “whale”. It all depends on how much it will be reduce reward.
I think good option is like MrV write above X missed blocks and delegate “jailed”, voteweight is 0 and he is out of 101. 3-7 days for this is also good. He have 30 days for repair and back then he must send special tx to unlock voteweight. In this time he can unvote selfvote and voters can unvote him. After 30 days is banned.
I also think about limit delegate on one node.
Last time this “10 delegates whale” not update node at time and 10 was red. Of course if he will have 10 not updated servers also will be all red. But what if he will be have issue with server ? Then also 10 delegates will be red and slow network. If will be have 10 delegates on 10 servers chance is less for 10 red.
Banning a delegate after missing blocks for 2 weeks sounds like a good idea, especially after seeing 10 red nodes for several weeks.
I don’t think additional consequences are needed since missing a block is already a punishment because the delegate is missing rewards.
now delegate get 3 months fine for self vote, and 1 for voters, need to do it equal, because so many delegates spend only 1/10 of total votes to self-vote, and can start new delegate after 1 month.
I think the best way if you miss block, you get -1 lsk(fine) every block. Every missed block you waste not potential, you lost real balance. It’s mean that every missed block you get -2 lsk potentially.
Ban after 10 days missed blocks.
When you banned you slashed by 25% of minimal self-vote in top 101. Because every one has different self-votes, and fine make fair, made the fine by minimal self-vote from top 101.
I don’t think punishing delegates more, for missing blocks is needed. We could see, that very often some delegates just don’t care, or are not even aware that they are missing blocks. The last big example was losing potential of 25k in tokens by bunch of delegates, it also makes a long range attack more appealing. What’s needed is a way of a quick removal of those unproductive delegates from active forging with network security in mind. So I agree that we could shorten the blocks to ban number, it’s clean and easy to implement.
The idea of reducing voteweight to 0 after certain number of consecutively missed blocks, and then regaining the voteweight after sending a special transaction is also very interesting. Having that implemented would give the ability to shorten the blocks to 0 voteweight time, to week or less, and it shouldn’t be susceptible to a long range attack more than the current implementation, since the 0 voteweight status can be removed by a delegate at any time with the special tx.
Hi everyone,
Thanks for your input on this question. I understand that we all have slightly different preferences on specific details of how much delegate productivity should be accounted for. Though it seems that the generally preferred option is:
Yes to shortening the banning tolerance. For example 2 weeks (or 10 days).
No additional consequences for missing a small number of blocks.
Unfortunately, in terms of protocol, reducing the delegate weight to 0 after only a few blocks (with the option to send a special transaction to return to the normal weight) does open us to long range attacks. To explain why in just a few words, the attacker would create a fork on which other delegates miss a few blocks and hence get their weight = 0. This attacker could therefore quickly control all active delegates on this fork. The special transaction to get your weight back does not help you in this context, because the attacker would not include it in the blockchain.
I will share your opinion with the rest of the team and I’ll make sure to come back to this thread to post any updates we do on the DPoS module.
Thanks again to everyone who shared some opinion on this
Hi @maxime.gagnebin Would reducing the vote weight to 0 after X finalized blocks help the long range attack scenario you brought up? This would ensure that the chain has to be healthy before the punishment.
Yes, I think this would help and that could be a nice improvement. The downside would be that the protocol becomes a bit more complex. Because whenever a block is missed, you have to store it somewhere and only count it when enough final blocks are built on top of it.
Maybe there is still a nice way to make this happen, I’ll think about it some more .
Hi @przemer Sorry for taking so long to reply to this thread. We discussed your proposition with the rest of the team. It is a nice idea and definitely something that we would look into further. The team is however a bit too busy right now to include such a change in the next release of Lisk core (several of the modules are also already implemented and we would rather not modify them too much at this stage). We would reduce the banning threshold to 2 weeks, as this is a rather limited change.
Overall, the risks to the network of a delegate missing their blocks for a while are small, and we would rather move forward with interoperability for now and update this at a later stage. I hope this sounds ok.
