Discussion: Locking period for votes

Increase locking period

Currently, in the Lisk protocol, whenever a user unvotes a delegate, the unvoted amount remains locked for 2000 blocks (roughly 5.5 hours); we call this time locking period. Afterwards, the voter is able to perform an unlock transaction and the unvoted amount returns to their balance and can be used again for any purpose.

It was brought to the research team that some members of the community think that the current duration of the locking period is too short and that it should be increased significantly. The main reason behind this proposal is that the locking period in DPoS is crucial for the security of the blockchain, in particular, with respect to interoperability. The value of tokens locked is what backs up the security guarantees of a blockchain, in particular, the finality guarantee. Reducing the locking period for voters reduces these guarantees to some extent.

We remind that the current locking period of 5.5 hours was chosen to be as short as possible to make the user experience as easy and enjoyable as possible. Nevertheless, taking the aforementioned concerns into account, the research team is considering increasing the locking time significantly. The precise value of the new unlock time is open to discussion, but our initial proposal is to be at least 3 days. We note that much longer locking periods are used in other projects (e.g., Polkadot has a locking period of 28 days). As a consequence the unlock times for other cases (e.g., self-votes or unvoting a punished delegate with current unlock time 30 days) should be adjusted accordingly.

A downside of such a change, will be that if an honest voter wants to unvote delegate A and use the staked amount for voting another delegate B, they have to wait longer until they can vote again. Nevertheless, it is our intention to treat such cases differently in upcoming changes in the DPoS module. In particular, if a voter wants to revote a staked amount, this change could be effective much faster and the staked amount would be immediately moved from one vote to the other, with no need to wait for any locking period. Therefore, the unlock time would only impact using the tokens for purposes other than voting (e.g., sending to another sidechain etc.).

Let us know what you think or if you have further ideas on the topic. We look forward to exchanging ideas with you.

Not much that I can add. The idea of having a longer lock period for voting is only good if voters are able to switch votes while tokens are in the locked state, which you’re aware of. The lock duration part is more tricky, 28 days seems to be excessive (I feel like that would discourage people from voting, which is not good from a security perspective), personally I wouldn’t go longer than 7 days. 3 days seems to be reasonable.

Also, I’m not hating on the current implementation.

How important is the period of blocking funds for security? Is it about voting ? Because the vote is removed immediately. If someone want sell token he do this after 5h or 3 days.

Thank you for the replies and sorry for taking long to reply in this thread.

@anonimowy891: First of all, notice that increasing the locking time increases the chance of detecting malicious behavior and submitting a proof of misbehavior transaction. Then, all staked amounts for delegates that misbehaved will be locked for a much longer period (currently around 30 days for votes and 90 days for self-votes).

To explain why this becomes more crucial with respect to interoperability, let me first remind the role of certificates: A cross-chain update (CCU) contains a set of cross-chain messages and a certificate which is signed by a large portion of validators from the sending chain (and therefore authenticates a finalized state of that chain). Also note that some sidechains might have quite lower staking threshold for becoming an active delegate, therefore they would be “easier” to attack.

Consider the following scenario: An entity with a lot of capital votes in 2/3 of new delegates in a sidechain and unvotes again shortly afterwards (say 6 hours) and sells all tokens (this is possible due to short unbonding for voters). This means they temporarily have a majority to generate any certificates to include in cross-chain updates sent to any chain of finalized blocks. Afterwards, they have few tokens at stake (only the 10 % self-votes which currently require 30 days to unlock) but still the possibility to start several types of attacks (long range attacks, generate arbitrary certificates in case the chain has not submitted a certificate to the partner chain about the malicious entity being voted out). This makes the whole ecosystem vulnerable to an attack on the “easiest” (for the attackers) sidechain.

Therefore, increasing the locking time by e.g., a factor of 10 (from 2000 blocks to 20.000 blocks ~ 3days) significantly increases the chance that this kind of misbehavior is detected. In fact, the example above suggests that it might be worth considering the idea of having a larger locking time for sidechains compared to the mainchain.

As for the duration, we are still into discussion about it, however I would like to mention that many other projects have locking periods > 20 days. Therefore any value on the range we are discussing here (between 3 and 7 days) is much more flexible and user-friendly compared to the majority of the other projects.

Hi.

First one, If someone have 2/3 delegates can he reject POM transaction ? And take control of whole network and never be punished ?
Second, if we talk about sidechain what if sidechain creator want smaller period time of blocking ? This sidechain will be reject or accept with low security note ?

First one, If someone have 2/3 delegates can he reject POM transaction ? And take control of whole network and never be punished ?

This is correct. Already with more than half of the delegates it is possible to censor transactions and never allow a PoM. However, here the question is rather if someone unvotes how long can they still do something that harms the network although they are not active delegates any more. We then want to choose the unlocking period long enough so delegates and their voters still have accountability as long as they can significantly harm the network.

Second, if we talk about sidechain what if sidechain creator want smaller period time of blocking ? This sidechain will be reject or accept with low security note ?

The sidechain is free to modify their DPoS protocol as they want to. This is independent of the interoperability protocol and cannot be checked by the Lisk Mainchain. However, a bad choice of parameters (e.g., no locking period) may result in investors and users having little trust in the sidechain and the sidechain therefore obtaining a bad reputation.

1 Like

Hi @janhack

Longer Time of block token is Ok for security reason. If 5h is too low, 3 days is good option.

Next option for more security can be POM plugin, default enable on lisk node. Now is not and not too much node operator have it ON.

An update on this: Taking your feedback into account, we decided to increase the locking period for regular votes from 5.5 hours (2000 blocks) to ~3days ( 26,000 blocks).

This change is incorporated in the updated version of the DPoS module which we published yesterday.

1 Like

@gkoumout Will voters be able to switch votes during the lock state as you mentioned it here?

@przemer It is indeed our intention to include this feature but we discarded it for now. The reason is that switching votes immediately would allow voters to avoid the effects of a PoM by switching their vote shortly before. To avoid this, we would have to keep track of past votes and introduce a lot of protocol complexity which we don’t want to do at this stage in order to not delay the Sapphire release.

We will look into the topic again as part of the Diamond phase as we are also planning to improve the BFT consensus protocol in order to reduce the time to finality.