Reputation System - aeftimia/paratii-contracts GitHub Wiki

Reputation System

We want to be able to reach a decentralized consensus on the association of tags with content, and determine quality

For the puropses of Paratii video, reputation can be thought of as how representative a user's decisions are of other users of a given system. This can naturally justify why one user's vote should be weighed more than anothers. If one user can be thought of as twice as representative of other users, their vote should carry twice as much weight.

Reputation can be acquired through a history of aligning one's decisions with other users and reputations.

Background

All content posted in Paratii has the following fields:

  • Tags: A series of UTF fields associated with each video entry. Users can choose existing ones or create their own.
  • Up/Down vote: An up vote denotes positive feedback from the viewer, while a downvote denotes negative feedback from the viewer.

A naiive system would allow users to vote arbitrarily and weigh them all equally. This system remains vulnerable to a sybil attack in which a user creates a swarm of fake identities to vote together.

Reputation provides a means of assessing the odds a given vote is representative of the general community, and can be integrated into a reward system. Reputation can be acquired by consistently acting in way that best represents the rest of the community.

A vote should require some risk on the part of the voter and potential for reward. If they vote in a manner aligned wtih the consensus, they will be rewarded with reputation. If they don't, they are penalized.

The mathematical nature in which users are rewarded or penalized should be deterimed with some care and ideally be representative of some overarching philosophy.

Constraints Given Attack Vectors

The reputation change of the current and previous voters should be completely determined by the current and previous voter reputations at the time of voting. Optionally, one could incorporate their current reputations as well.

Attacks

In this section we will outline a series of increasingly complex attacks on a decentralized reputtaion system and explain how to mitigate each of them with correspondingly sophisticated reputation schemes.

The adversary's objective is to reap the benefits of producing highly valued content without actually producing highly valued content. The most vulnerable and commonly exploited aspect of decentralized networks is the sybil attack, in which the adversary creates and directs a swarm of fake identities to behave like an approving crowd.

To illustrate the most trivial attack on Paratii's video sharing service, let's briefly discuss the notion of someone voting for their own video. In this instance, someone uploads a video, upvotes their own video, and proceeds to profit off of their increase in reputation. This is obviously disallowed and has little real world effect, but this is the effect we are attempting to twart in its simplest form. Identities come and go on a decentralized network, and this makes it difficult to know monitor interactions, create a consistent notion of reputation, and create incentives that reward people of altruism.

First Order Sybil Attack

In the most basic sybil attack, an adversary would create an identity that uploads a video and a swarm of identies that upvotes that same video. The content producing identity is rewarded for producing good content while the voting identites gain reputation for voting together.

The first order sybil attack can be immediately generalized into a network of identies that upload content and upvote each others content.

Proposed Solution: Sacrifice Reputation to Vote

As proposed in the backfeed protocol, sacrificing a nonzero reputation R_0 to vote would suffice to prevent an attacker from directing a swarm of fake identities voting together since the fake identities would have to acquire reputation in a nontrivial way. This then raises the question of how users acquire reputation.

We outline two approaches to this.

Nonzero Initial Reputation and Reputation from Uploading

Users could, for example, be initially given "the benifet of the doubt" and awarded enough reputation for a small number of votes. In this case, we must be careful that they earn less reputation voting together than they lose casting their initial votes.

If a voter loses C_n reputation per vote in perfect accordance with all other votes, and gains U_n reputation for their nth upvote in perfect accordance with all other votes, gains Q_n profit per upvote per upload,

The user can bootstrap their reputation by uploading valued content. The first voters are then going to be early adopters who set forth a precedent for what makes for good content by voting it up, and thereby awarding the uploaders reputation that allows them to vote for other videos.

Proposed Solution: Voters Cannot Surpass Uploader Reputation

This technique can be used in conjunction with any other approaches. In essense, it prevents malicious users from boostrapping reputation by creating fake identities that only interact with each other by requiring the uploader have more reputation than the voter for the voter to earn reputation by voting on the video. Users may still lose reputation by voting on a video.

ALtnernatively, one can take any reward function and rescale it to cap at the reputation of the uploader. One could, for example, send the initial caluclation of reputation earned through a sigmoid function and multiply by the reputation of the uploader.

Possible Cost and Reward Functions

In this section we outline possible cost and reward functions for voting. The backfeed protocol is an obvious choice. Comments from @Jelle are much appreciated. The cost function is the change in reputation incurred from the voter and all previous voters by the act of voting.

Backfeed

In the backfeed protocol, we use a cost function, given by the following formulas.

For the most recent voter of k votes, the new voter loses some reputation, dR_k proportional to their current reputation:

dR_k=-s R_k (1 - (V/R)^alpha)

Where R_k is the reputation of the most recent voter, 0<=s<=1 is an arbitrary rescaling, V_k is the sum of the reputation of all users who voted on this tag, W_k is the sum of all the reputation of all the users who voted in the same way as the most recent vote, and R is the sum of all reputation of all voters in the system, and alpha is the skewness of the payout distribution for each value of reputation. We can always choose a distribution so alpha is 1 or 0, which makes for easier analysis.

To ensure conditions are satisfied such that

For previous voters:

dR_i = 0 if they voted differently from the most recent voter, and otherwise dR_i = R_i/W_k, where R_i is the ith users reputation, and W_k is the reputation staked in the most recent voter's vote (including their vote).

This can be summarized as "the new voter loses a proportion of their reputation, possibly less so if they vote like other people, and all previous voters who voted teh same way gain reputation propotional to the contribution of their reputation to the total reputation staked on that vote.

Uploader Reputation Ceiling

To prevent a swarm of fake identities from bootstrapping their reputation from scratch, we can either not grant them any increase in reputation if their reputation is already greater than that of the uploader, or continuously rescale their increase in reputation such that it infinitesimally approaches that of the uploader. In either case, we would map the cost and reward functions through a nonlinear function.

In the case of a hard cutoff, we can leave the cost function unaltered when it will not boost the voter's reputation higher than the uploaders, and otherwise set the voter's reputation equal to the uploader's reputation.

⚠️ **GitHub.com Fallback** ⚠️