Reducing the power of the pivotal voter

Purpose of document: Outline and communicate a design idea to harden the voting of a future Kiwi writers contest
Date: 2024-09-30
Author: timdaub

Feedback is welcome! Please share your thoughts with me on Telegram, in the comments or on HackMD!

Context and Problem Description

During our last writers contest the point difference between prize receiver #3 and #4 was only a two upvotes difference. I didn't witness this, but there could have easily been a situation where, in the last minute, someone quickly casted one or two upvotes to change who qualifies for a prize. For context, the four highest upvoting submissions qualified for prizes.

For the purpose of this document, we call the person who takes advantage of determining the outcome of the contest with their strategic voting behavior a "pivotal voter." In our last contest, although we didn't see this happening, two voters had the power to change the outcome.

We think pivotal voting is bad.

It is our goal to make all votes weight equally. A person should not have further power through finessed strategic voting.

Pragmatic Solution for the Next Contest

Below is an algorithm that will errode the power of pivotal voters. If we stick to it, we can perhaps fend of pivotal voter behavior.

In secret Mac and Tim will pick a random time when the contest will end, for example: October 1 3:31pm. They don't share this time or date with anyone.
Combined with a random salt Nt7LSR7T0+DEbdfu and a formatting of their liking, they will produce a keccak256 hash of the string that represents the end date, for example: keccak256("Nt7LSR7T0+DEbdfu contest ends on october 1 3:31pm") == 36ad02c4cd0db47b3c9b1f39bc06304e1b2c3fc3303ea23fa879adef701a3902.
They will share the hash publicly, either in a blog post, or they will write it onto the blockchain.
In external communication about the contest they will roughly announce the end of the contest. If it actually ends on Oct 1, they'll externally communicate that the context ends between Sept 30 and Oct 2, as to not give any useful indication when the true datetime of the contest's end is.
At the secret, agreed-upon time Tim and Mac will screenshot the outcome of the contest (as done in the screenshot above). And they'll also reveal the input (Nt7LSR7T0+DEbdfu contest ends on october 1 3:31pm) to the priorly publicly commited end date hash.
Contest participants will be able to validate that Tim and Mac have priorly committed to a date and that they've sticked to this date.
Pivotal voters power is erroded as their strategic advantage to control the contests outcome is nullified. A pivotal voter will have to cast their vote some time on Sept 30 or Oct 2.

Drawbacks to this Solution

In a recent blog post, Vitalik proposed the following as criteria for a project to be considered decentralized and secure:

Decentralization and security - avoiding points of trust, minimizing censorship vulnerabilities, and minimizing centralized infrastructure dependency. The natural metrics are (i) the walkaway test: if your team and servers disappear tomorrow, will your application still be usable, and (ii) the insider attack test: if your team itself tries to attack the system, how much will break, and how much harm could you do? An important formalization is the L2beat rollup stages.

For (i), the walkaway test, I anyways think it won't be solvable for writers contests, at least for now. We are doing the essential BD work with brand partners for all writers and this is fine and probably won't change for some time.

But with the just proposed pragmatic solution, to prevent pivotal voting, we are definitely failing (ii), the insider attack test, as we (Mac and Tim) could now pivotally control the outcome of the contest. We could either vote with our mains or sock puppets right before the secret end time.

So clearly, I admit, this is solution is more pragmatic than it is perfect right now. Ideally, for course, Mac and I also don't know the exact end time of the contest as to errode our pivotal voting advantage too.

Future improvements

An improvement to the drawbacks is something we strive to add in yet another iteration, but not for the upcoming writers contest.

A solution could be that we commit to an end date that's connected to a publicly announced condition which no one of us, neither writers or organizors, can control.

For example, we could say that the contest ends on Oct 1, the very moment when a first Ethereum L1 block is produced that ends with 00 in its hash.

This is an elegant solution but also need much more technical work to before we can use it in production.