Let's talk about recipient curation mechanisms

general
#6

I also just came across this. I haven’t read it yet but it could be relevant for a future version if privacy turns out to be important in a curation context.

Abstract

Token-curated registries (TCRs) are a mechanism by which a set of users are able to jointly curate a reputable list about real-world information. Entries in the registry may have any form, so this primitive has been proposed for use— and deployed— in a variety of decentralized applications, ranging from the simple joint creation of lists to helping to prevent the spread of misinformation online. Despite this interest, the security of this primitive is not well understood, and indeed existing constructions do not achieve strong or provable notions of security or privacy. In this paper, we provide a formal cryptographic treatment of TCRs as well as a construction that provably hides the votes cast by individual curators. Along the way, we provide a model and proof of security for an underlying voting scheme, which may be of independent interest.

1 Like
#7

The prediction market plaform Omen now uses Kleros Curate to manage the list of valid markets: https://curate.kleros.io/tcr/0xb72103eE8819F2480c25d306eEAb7c3382fBA612. This is very similar to our use case.

#8

Yeah, I’ve been following this pretty closely. I almost spun up a list back in june, but the gas prices were too high. Regretting it now because they are even higher. lol.
But this looks like the best current option to me.

1 Like
#9

Started an acceptance criteria doc here: https://docs.google.com/document/d/1BKyCVY2gkCiDOESu0HjQG14l2-1uELvz-ksByqZ_tNI/edit?usp=sharing

1 Like
#10

Let’s try to tighten this up. Gas is cheap(er than it has been since DeFi went nuts), so we should capitalize on it and spin up the Kleros curate list ASAP.

1 Like
#11

Here is our Kleros Curate TCR

1 Like
#12

We’ve got a new entry in our registry: https://curate.kleros.io/tcr/0x2E3B10aBf091cdc53cC892A50daBDb432e220398/0x9fcfe7ef7ba3cae1163c0036a8ac15a3b98d3e82098c96f33335d3fea9b7ac15

But their logo image is not a square, so this entry can be challenged in court :laughing:

1 Like
#13

This is actually the second time that this has happened. The commons stack did the same thing and was challenged. I’m actually interested to see if anyone challenges this one.

#14

An better scaling solution for clrfund has not yet arrived, so we’ll continue to run funding rounds on xDai for some time.
Unfortunately Kleros TCR is not available on xDai chain. So we have two options (other than just waiting):

  • Read data from mainnet TCR. This would require some kind of oracle, but it seems that there is no such thing on xDai at the moment. Celeste subjective oracle is probably closer to launch than other solutions.
  • Create our own TCR, either by forking Kleros TCR (which seems like a lot of work) or by implementing a simplified version of it.

A simplified version of TCR could have API similar to Kleros Generalized TCR but actually be a simple registry managed by a trusted party. For that simplified version of TCR we can create an adapter which we can later reuse with real TCR on mainnet.

#15

The xDai and Kleros team are both interested in creating a solution to allow contracts on xDai to query contracts on mainnet. We kicked off a discussion about it yesterday. But I have no idea if or when this will actually materialize into a solution that we can use.

I’m not sure I see a huge benefit to this. Other than the fact that it would have the same interface as Kleros so that we can swap them out later, it is no practical benefit over the current solution where our Safe is the gatekeeper.

I beleive 1Hive might deploy an instance of Aragon court, so perhaps that could be an alternate option to Kleros on xDai.

#16

The benefit is that we can start working on it immediately, because for mainnet clrfund instance we’ll need this Kleros TCR adapter anyway. I don’t know if it is worth spending our resources on xDai-specific solutions if our goal is mainnet.

#17

That’s fair. I’m on board with going for this route then.

I imagine that we could probably plug this into whatever solution xDai and Kleros come up with also, since they’ll probably want to keep the interface the same as well.

#18

More analysis and discussion in this GitHub issue: https://github.com/clrfund/monorepo/issues/36

tl;dr:

  • If we use Kleros TCR as is, clrfund will be susceptible to DoS attack. Currently the vote option limit is 125, so if required submission deposit is 0.05 ETH it would cost less than 6.25 ETH to fill a recipient list. Of couse, the limit can also be reached naturally if there’s enough interest from the community.
  • If we want to protect clrfund against this, the ranking mechanism is needed. We can implement our own or use something like Conviction Voting. Unfortunately it will make it a bit harder to become a valid recipient.
#19

Another important question is how to identify recipients. Currently we use recipient’s eth address: http://clrfund.eth.link/#/project/0x4E2f7c052376727ff6F6DE2715850419ecacC302. But there are projects in TCR that share the same recipient address, so we need to either add a requirement for addresses to be unique to our recipient acceptance criteria or use something else as an identifier. Kleros TCR uses keccak256 hash of entry data as an identifier, we can use it as well (instead of eth address). For example, here’s the URL of clrfund entry: https://curate.kleros.io/tcr/0x2E3B10aBf091cdc53cC892A50daBDb432e220398/0xc9cc75acbd333a72719da5446fc1752406ae0922a3c8818f769d6156af04adeb, it contains the ID 0xc9cc75acbd333a72719da5446fc1752406ae0922a3c8818f769d6156af04adeb.

Where is my other project?
Recipient data storage
#20

I’ve actually been wondering if we should use ENS names to identify recipients.

My rational being that:

  1. it’s perfectly reasonable to expect each recipient to have a different ENS name.
  2. because metadata can be linked to on the ENS name, it would mean that list items in Kleros could be much simpler (they would probably only require one field).
  3. because the metadata lives on the ENS name, it could be easily updated by whoever controls the ENS name.
  4. recipients could specify receiving addresses for different networks on their ENS name, so we don’t have to add/remove list items if/when we deploy to a new network.
Recipient data storage
#21

This won’t work well unless metadata format is enforced by ENS dapp. There will be too many mistakes as with image size requirement. Also ENS names are not free, so this would create another hurdle for recipients.

But we can add optional ENS name field to Kleros registry. That would be much better that twitter handle.

#22

I think the most important metric for ranking public goods is amount of funding received via QF. Ideally this data should come from clrfund itself, so we need to implement our own ranking mechanism (which will work independently from curation mechanism such as Kleros TCR).

The very basic version of ranking mechanism was implemented in SimpleRecipientRegistry contract and is currently used in production. It divides projects into two categories: valid and invalid (removed). When the total number of projects in the registry reaches the limit and the owner adds a new project, the smart contract replaces one of invalid projects by reassigning its index to a new valid project.

We can use this logic to create a ranking mechanism that uses the amount of funds received during the last N rounds as an input.

  1. New project replaces old project that didn’t collect any funds during the last N rounds. It’s easier to implement but at some point all non-receivers will be removed and it will be impossible to add new project.
  2. New project replaces old project that received the smallest amount of funds during the last N rounds according to on-chain data. Such mechanism can work indefinitely, but it requires on-chain sorting which is hard to do and gas-intensive. I think it requires some advanced data structure like binary search tree. Example of solidity library: https://github.com/saurfang/solidity-treemap.
  3. New project replaces old project that received the smallest amount of funds during the last N rounds according to the oracle. In this case the sorting is done offchain and to replace the least popular project someone needs to submit a replacement request (usually it is someone who wants to add a new project). The replacement request can be disputed in decentralized court and if jurors rule in favor of the requester, the project gets replaced.

I think option 3 is the best but it’s probably not necessary today. If we increase the vote option tree depth in MACI by 1 it will allow 625 recipients which should be enough for the foreseeable future. For now we can use a simpler ranking mechanism that relies only on validity (similar to SimpleRecipientRegistry, but integrated with Kleros TCR).

1 Like
#23

It’s really only an issue currently because of the friction of changing it. If we use text records on ENS domains, then it’s trivial for users to change those records if they make a mistake or something renders poorly. At some point, we can even build this into our UI.

This is valid, but given that there are a number of places where you can get free ENS domains I don’t think it’s really that much additional friction.

Perhaps we add an ENS field and make the address field optional as well, but require that at least one of them be filled. I’d prefer for an ENS name to be the default.

#24

We can use TCR as a fallback data source. If there’s an ENS name, we’ll try to fetch project description from it, otherwise we’ll read it from TCR. This would allow projects to easily update their descriptions without removing and re-submitting their entry to TCR, while they will not be forced to buy and configure ENS.

Yes, that makes sense.

1 Like
Client-side filtering, sorting, and curation
#25

The adapter will be a simple registry integrated with Kleros TCR. To add recipient someone will need to call addRecipient() with TCR entry ID (this method can be called by anyone). The registry contract reads recipient data from TCR and decodes recipient address, then it assigns a vote option index to recipient. If the number of recipients reaches the limit, a simple ranking algorithm is used to find a place for a new recipient:

This adapter is designed to work with Kleros TCR on mainnet but on xDai we can deploy a dummy contract that pretends to be a Kleros TCR and use the same adapter with it.