Critical Consideration For TCR’s that use Partial Lock Commit Reveal Voting in Conjunction with Minority_Bloc_Slash

[Ethereum1227]

As we know, in Partial Lock Commit Reveal voting (PLCR), voters can vote with the same tokens across multiple polls. This surfaces a few issues when a TCR has MINORITY_BLOC_SLASH (MBS) implemented in order to deter vote splitting. Here’s why:

Problem:

If MINORITY_BLOC_SLASH is set to 100% and a voter votes across multiple polls with the same tokens within a PLCR environment, and once the voter ends up in a losing bloc (100% of their tokens are taken due to MINORITY_BLOC_SLASH being set at 100%), there won’t be any token left for that voter to cover the debt for any remaining polls still open.

Solution:

We can solve for this by setting the MINORITY_BLOC_SLASH lower than 100%. Let’s say that the Minority_Bloc_Slash is set to 10%.

Problem:

At a 10% Minority_Bloc_Slash, we still run into issues.
For example, if a voter uses 100 tokens to vote across 11 polls and the Min_Bloc_Slash is set to 10%. If the voter loses in every poll then 10% is taken out of 100 tokens 11 times, we can see the dilemma. In this scenario, the user will end up with a negative token balance: 100 - 110 = -10.

Solution:

We can solve for this however by implementing the MINORITY_BLOC_SLASH to deduct tokens in chronological order. For example, taking the above scenario of a voter using 100 tokens to vote across multiple polls with a MINORITY_BLOC_SLASH set to 10%. See below.

Conclusion:

For TCR’s using PLCR in conjunction with MINORITY_BLOC_SLASH (as a deterrent for vote splitting), the MINORITY_BLOC_SLASH shouldn’t be set to 100%.
If MINORITY_BLOC_SLASH is set to a percentage less than 100%, then in order to prevent a voter who is voting with the same tokens across multiple polls from ending with a negative balance, we should deduct the MINORITY_BLOC_SLASH percentage chronologically (or implement some other logic to address the potential for a voter to end with a negative balance).

[GNSPS]

I'm not really sure about the chronological slashing... Shouldn't the slashing still be equal to 10% of the stake or 10% of the balance, whichever's the smallest (a min function basically)?

I think it would be more sensible to implement a maximum of polls in which a token holder can vote simultaneously:

Max_simulPolls = 100 / MINORITY_BLOC_SLASH

It would solve both the edges cases presented above.

[Ethereum1227]

Ya, that would be easier to implement.

[eduardo-munoz]

Although it is true that there are a max number of polls equal to 100/MBS, token holders won't always be voting with their entire funds. Rationale behind voters not using the entirety of their token holdings to vote includes the uncertainty they have in winning the vote. If they are uncertain, they will be less willing to vote with the entirety of their token holdings as they will end up losing more tokens if they lose.

I propose that voters have the MBS percentage of their votes locked until the end of each vote. For example, if MBS is 10%, and a voter commits 100 tokens to vote, then 10 tokens are locked for the entirety of the voting period, with 90 unlocked to be used across other polls. An outlined example can be found here.

This solution allows for users to vote simultaneously across polls with the same tokens, while guaranteeing that they can forfeit tokens if they're on the losing side, regardless of the MBS percentage.

[GNSPS]

👏 Totally in favor! 😄

[skmgoldin]

Closing this because it isn't implemented in this repo.