Reputation creation

[chancehudson]

Right now we give people 30 rep every epoch. Instead we could use a system where users get a 30 rep subsidy each epoch. The first 30 rep spent is covered by the system. After that it's taken out of the users rep balance. If the user doesn't spend or receive any rep in an epoch their balance is unchanged.

• rep is only created by interactions in the system
• people can't hoard rep by getting airdrops and never spending
• if people create posts/comments just for exchanging rep others can vote and take rep away (vote negatively on the posts/comment for free)

This would also make the case of missing an epoch more clean. Right now if a user doesn't do a UST for an epoch they miss 30 rep for each epoch they skip.

[chancehudson]

If a user has negative reputation they will receive an airdrop of 30 rep. e.g. if I'm at -100 rep I will be bumped to -70 rep.

Unclear what will happen if a user is at -15 rep. Maybe they forfeit the remaining 15 rep?

[kittybest]

agree, but what if I post a lot but gain no positive points? or I keep on voting others instead of making posts, my reputation will become <= 0 very soon

[chancehudson]

The first 30 reputation that you spend each epoch is free. So if I have 0 reputation I can still spend reputation without becoming negative.

If I have 5 reputation I can spend the first 30 reputation for free in an epoch, then after that I will be spending my 5 reputation. Or I can wait until next epoch and keep my 5 reputation and get 30 more free rep.

[chancehudson]

One way we could implement this is by storing a 2 dimensional mapping of subsidies for users like this:

// a mapping of epoch number to aggregate epoch key to subsidy spent
mapping (uint => mapping (uint => uint)) subsidySpent;

// so access like this subsidySpent[epoch][aggregateEpochKey]

We want to allow any of the users epoch keys to spend from the subsidy. To do this we can define an aggregate epoch key that is a hashchain of the user epoch keys for a single epoch. e.g. H(H(H(epk0), epk1), epk2). We can then define a zk circuit to prove that an epk belongs to an aggregate epk which accepting the following inputs:

• identity (private)
• epk
• epoch

and outputting:

• aggregate epoch key

--

When creating a post using the subsidy we require the user to submit two proofs:

• a proof spending 0 reputation but proving that their reputation is >= 0
• a proof calculating the aggregate epk from the epk in the spend proof ^

Once we have these two proofs we can check that subsidySpent[epoch][aggregateEpochKey] + 5 < 30 and then perform the operation.

• If we're creating a post we simple emit a PostCreated event
• If we're voting on a post then the attester attests to an upvote value with fromProofIndex = 0

--

In the case where a user has negative reputation we accept the same two zk proofs as above, but instead of proving 0 reputation they prove that negRep > 0. Then the attester attests to positive reputation equal to the proven negative rep, or 30 rep, whichever is smaller.

This action should only be allowed once, even if the user claims less than 30 rep.

[chancehudson]

So all of the pieces are built and ready for this system.

In #22 the unirep social contract has been updated to accept reputation proofs that spend less than the required amount. For example, if a user tries to create a post with a rep proof spending only 3 rep, the system will try to use 2 rep from the subsidy. This means the frontend will continue to work the same until we decide to implement the subsidy logic (by submitting proofs spending less rep). The existing airdrop system still works the same. If a user spends from the subsidy the zk proof is verified on chain and the attester only attests to the gst root (meaning the synchronizer doesn't have to verify the zk proof) (see next paragraph).

In Unirep/Unirep#84 I added a function in the Unirep contract for an attester to attest to a specific GST root without giving a proof to unirep. This way the attester can verify zk proofs on their own and then give rep if a certain GST is valid. This is important because attesters might want to implement their own zk proofs that unirep does not know about.

In Unirep/Unirep#85 there is a zk proof that does the following:

• Prove that a user has less than a certain amount of rep
• Output all epoch keys for the user
• Output the gst

This proof is used to receive a subsidy airdrop when the user has negative reputation. The user receives either the amount of negative rep they have, or the max subsidy, whichever is smaller (so they don't go over a balance of 0 rep). All of the users epoch keys are output so they can claim subsidy rep for each. In this case revealing the epoch keys should not matter because the user cannot perform any operations in the system until the next epoch (when they get the subsidy airdrop).

All we need to do now is review and merge the pull requests and then update the user interface.

[ChialiT]

move this to scrum board.