Recipient curation about monorepo HOT 15 CLOSED

Are two different issues now being discussed here?

1. Preventing spam project attacks -- solved if we can guarantee >0 non-spam projects exist in every round. We might do this by hardcoding the next clr.fund matching pool as index 0 in MACI, or something similar.
2. Curating real projects given that MACI may always have some voting option limit -- in a situation where we get more real projects than MACI has slots, neither asking projects to pay a fee nor having past projects curate newer ones (as in Everest) seems like the right answer. Similarly, a decentralized court might be good at binary decisions (is X a Y or not a Y?) but not at picking the best N of M options. This is a for-the-future issue, but right now I favor something like Burn Signal for curation, I think.

from monorepo.

Some version of this will be needed for the MVP, right? Should I create a separate issue for that, or want to use this one @slgraham ?

from monorepo.

@EzraWeller Technically, yes, we'll need a way for users of the MVP to see which recipients they can contribute to. But since there is a max of 16 recipients and early users are likely to be fairly motivated (relative later adopters), I wouldn't characterize discovery as a potential blocker for success of the MVP.

Therefore, my recommendation is for discovery for the MVP to be extremely minimal, e.g. just a straight alphabetized list of recipients. Potentially that could be covered under #29, but a separate issue would be fine too. Thoughts?

from monorepo.

Agreed, I don't think we need discovery for the MVP, but we should probably have a statement about how the 16 were chosen.

But I guess that assumes the MVP is run as anything more than a test. If the MVP is really just a test and has very little matching funds, I guess it's not important?

from monorepo.

For MVP, manual recipient registration was implemented in #40.

For further iterations, other options were suggested:

• Use Everest or its fork.
• Require recipients to pay a fee.
• Create a recipient registry where entries can be challenged in a decentralized court.

from monorepo.

I like the philosophy that voters (funders) should be given as much decision-making power as possible (as opposed to founders or other projects).

To this end my favorite suggestion so far is that we guarantee there will be a sizeable number of non-spam projects by taking the n projects that received the most matching funding from the previous rounds.

How about we take the number of total available slots (not used slots), divide it by 2, and say that many projects automatically carry over to the next round? n = totalAvailableSlots / 2

from monorepo.

Another thing we need to consider is how to curate the metadata associated with each recipient.
Where should that data be stored and who should have the right to modify it?

from monorepo.

In my view, the ideal solution would be a registry of valid projects where anyone can add entries and anyone can challenge new entries in a subjective dispute resolution system.

• To add an entry, user must stake coins.
• During some challenge period, anyone can try to remove the entry by starting a dispute.
• The dispute resolution is done by humans. In the beginning we can use a DAO to resolve disputes and switch to decentralized court when the tech becomes more mature.
• If the jury rules in favor of challenger, the submitter loses their stake and the entry is getting removed from the list.
• If entry remains unchallenged during the challenge period, it can not be removed anymore (or we can devise some scheme that involves voting by other registrants and again a decentralized court).

This registry can live separately from clr.fund contracts and there must be a way to switch to another registry using the registry proxy mechanism described here (in case of an attack on the registry or the emergence of a better curation mechanism).

On the side of clr.fund, we'll keep a separate list of recipients and probably ask recipients to re-register each round (it's also possible to build a mechanism that involves one-off registration, but I won't consider it here). When recipient registers for the round, the contract will do the following:

• Check that recipient is in the registry and gone through the challenge period, reject if it's not the case.
• Calculate the rank of the recipient according to some formula that takes into account the age of an entry in the registry and the total number of contributions in previous rounds.
• If the total number of registered recipients is less than MACI's maximum vote options, register recipient for the funding round and store their rank.
• If the total number of registered recipients reached the MACI's limit, find the recipient with the lowest rank and replace it with the new recipient if its rank is higher (we'll need a data structure that supports this kind of operations). Reject recipient if their rank is the lowest among all other registered recipients.
• When the round begins, freeze the recipient list and assign a number to each recipient which will serve as a vote option index in MACI).

That scheme would prevent the attacks described in our wiki:

Fill up the recipient list with spam to prevent others from signing up as recipients

This is solved by automatically removing lowest-ranked recipients from the round.

Fill up the recipient list for a given round so that you are the only one who can receive funds

This is solved by only allowing projects from the curated registry (that got through the challenge period).

Impersonate a project you don't own

This is also solved by curated registry. To become a valid entry the project may be required to make a post from an official social media account, so impersonators can be easily challenged in a subjective dispute resolution system.

from monorepo.

If we will use Kleros TCR as a recipient curation mechanism, the process of recipient registration could look like this:

• Add new entry to the Kleros registry.
• When the entry is accepted, navigate to the details page. The URL of this page contains item ID (example: https://curate.kleros.io/tcr/0x2E3B10aBf091cdc53cC892A50daBDb432e220398/0xc9cc75acbd333a72719da5446fc1752406ae0922a3c8818f769d6156af04adeb => 0xc9cc75acbd333a72719da5446fc1752406ae0922a3c8818f769d6156af04adeb)
• Get item data by querying TCR smart contract: GeneralizedTCR.getItemInfo(itemId).
• Decode item data using solidity-rlp like Generalized TCR View does.
• If item is valid, add recipient address to recipient registry along with its item ID from Kleros TCR.
• When RecipientRegistry.getRecipientIndex() is called, it should re-check status of the entry in GeneralizedTCR contract by doing an item ID lookup.

from monorepo.

We can also use Kleros registry without copying entries to our own registry. But indexes of entries in Kleros registry can only increase, so once the total number of entries (including disputed and removed) hits the MACI limit it will be no longer possible to add new recipients. Currently the vote option limit is 125, so if required submission deposit is 0.05 ETH it would cost < 6.25 ETH to perform a spam attack on clrfund. In our own registry we can reassign indexes previously occupied by removed recipients, and we can also use a queue-like data structure as described in this comment #36 (comment).

It's also not practical to look up recipient in Kleros registry by its address (it would require sequential scan), so we'll have to adjust our core contracts to keep track of item ID or to change claimFunds() method to accept arbitrary data instead of recipient address.

from monorepo.

we can also use a queue-like data structure as described in this comment #36 (comment)
We'll need to think more on this. The way it's described in your earlier post, I don't really see how new projects would be added once the cap is reached (unless old projects are removed from the list because they become invalid), because they would always have a higher score than the newly added items.

Perhaps we should explore a TCR mechanism that actually ranks recipients? Something like Ideamarkets, for example.

It's also not practical to look up recipient in Kleros registry by its address (it would require sequential scan)

Do the contracts have to do this lookup? Or can the client lookup the corresponding ID and then the contract just checks to make sure the ID and address do in fact correspond?

from monorepo.

We'll need to think more on this. The way it's described in your earlier post, I don't really see how new projects would be added once the cap is reached (unless old projects are removed from the list because they become invalid), because they would always have a higher score than the newly added items.

Yes, we just remove projects with a lowest score. We can rank recipients according to some formula which takes into account both historic contributions and the age of the entry. For example:

rank = a * (contributions + b) - c * age

Where a, b and c are some carefully selected coefficients. So when recipient collects more contributions, its score goes up, but as it ages its score goes down. A newly added entry will have score a * b which is positive so it can replace entries with a lower score (old recipients with few contributions).

Perhaps we should explore a TCR mechanism that actually ranks recipients? Something like Ideamarkets, for example.

Their landing page says that people should buy upvotes to increase item's rank. This is not appropriate for public goods, but I agree that a similar mechanism could work for us. I think the Conviction Voting which Luke recently suggested in the chat is an interesting candidate for such mechanism.

However, permissionless ranking mechanisms can't decide what is public good and what is not, for that we still need a subjective oracle like Kleros.

Do the contracts have to do this lookup? Or can the client lookup the corresponding ID and then the contract just checks to make sure the ID and address do in fact correspond?

Yes, the contracts have to do that in when someone calls claimFunds(). But it's not really a problem, we can identify recipients by arbitrary string instead of address. We should probably do that anyway.

The main problem here is a lack of ranking.

from monorepo.

Their landing page says that people should buy upvotes to increase item's rank. This is not appropriate for public goods, but I agree that a similar mechanism could work for us.

Ideamarkets creates a bonding curve for each item, which I think could be an interesting way of ranking. But I just had a chat with them and their rankings can't be queried on chain. 😢

I think the Conviction Voting which Luke recently suggested in the chat is an interesting candidate for such mechanism.

Agreed, I think this is another worthwhile option to look at.

However, permissionless ranking mechanisms can't decide what is public good and what is not, for that we still need a subjective oracle like Kleros.

Agreed, we'll probably need to layer these solutions on top of one and other.

from monorepo.

Kleros GTCR adapter was implemented in #208.
It does not always reflect TCR state: recipients have to be added and removed from it manually (but anyone can do it because addRecipient and removeRecipient methods are permissionless).
It is possible to reflect removals automatically by checking TCR item status in getRecipientAddress() but I don't think it's necessary. (Also, removal timestamp is not available but one can retrieve the submission time of removal request using getRequestInfo())

from monorepo.

UI development tasks: #209 #210 #211

from monorepo.