Oracle-based recipient curation

general
#1

The current gas costs associated with maintaining our recipient registry on Kleros are a significant barrier to entry for new projects and make recipient curation for rounds running on xdai (or anywhere that can’t synchronously query mainnet data) more trustful than they would be on mainnet.

I would like to explore the idea of replacing our Kleros TRC with an oracle-based registry built on Reality.eth.

For those not familiar with Reality.eth, it is an oracle system based on an escalation game. Anyone can ask a question and anyone can attempt resolve a question by depositing a bond and setting the outcome. After the bond is submitted, there is a timeout window (default is 24 hours) in which anyone else can change the outcome by doubling. Each time the answer changes, the bond doubles and the timeout resets. Game theory dictates that the “truth” should be the Schelling point, and that in most cases no escalation will happen because there is a financial disincentive to set the incorrect result.

For a registry based on this, I imagine there being three public functions, addRecipient(address, metadata), removeRecipient(address), and editRecipient(address, metadata), which can be called by anyone. Whenever one of these functions is called, a Reality.eth question is asked to confirm whether or not the the change is valid/conforms to clr.fund’s acceptance/removal criteria.

The address calling the function should fund the initial bond. Once the escalation game has been played and the result is finalized, then anyone should be able to call an updateRegistry() function to apply the corresponding change to the registry.

Reality.eth is currently deployed on Mainnet, xDai, a handful of public testnets, and could easily deployed to whatever rollup solution we land on.

#2

Overall this makes a lot of sense. However, there are a couple pieces that I think are missing.

There is currently no incentive for somebody to curate the following scenarios

  1. An existing recipient changes its activities such that it no longer meets the clr.fund criteria (e.g. stops working on public goods)
  2. Admin or contact info for an existing recipient changes (e.g. their url or twitter handle changes) such that the current info becomes incorrect or misleading

In both of those scenarios, there is no incentive for anybody other than the recipient themselves to update the listing. In fact, there is actually a cost to doing so, in the form of the reality.eth bond requirement. The health of the registry should not rely on recipients to be honest or on good Samaritans to pay to curate.

One solution to this would be to require the initial addRecipient caller to make a deposit incremental to their reality.eth bond, which would be used to…

  • A) cover the initial reality.eth bond for subsequent challenges (i.e. removeRecipient or editRecipient) stemming from the above 2 scenarios
  • B) reward successful such challenges
#3

In an environment where gas is cheap, I’m not convinced that there needs to be an explicit incentive to maintain the health of the list, since the existing recipients have an implicit incentive to maintain the list in both of the examples you gave; other recipients in the former and the recipient themselves in the latter.

Further, any malicious attempt to change the registry creates an explicit incentive for someone else to correct it by doubling the bond prior to the timeout ending.

1 Like
#4

I still think a small incentive would be a good idea. Just to ensure we break through the apathy barrier, especially as the list of recipients grows larger and the negative impact of an individual error is diffused among many. I could easily imagine a scenario where we have 100 recipients and small errors start to pile up because no single error is worth putting in the effort (and putting in the reality.eth bond) to change.

#5

Yeah, that’s fair. So essentially, you’re suggesting that there is a small approval bond on each project in the registry that goes to whoever initiates it’s successful removal from the registry, correct?

If so, this only solves for 1, which I think is fine, since the implicit incentive to maintain the health of your own listing should be sufficient for 2.

#6

In theory it could also apply to edits on existing listings, too. Though I suppose that’s harder to do – since a listing could be edited many times, you’d need an ongoing bond to reward many edits.

So yea, I think a removal bond should suffice. If there’s something incorrect or out of date with a recipient’s listing that the recipient isn’t updating, then if somebody thinks that’s nefarious or harmful to clr.fund as a whole they can propose to remove it.

1 Like
#7

So the “truth” is determined by the highest bidder? Or am I missing something?

I guess Kleros team will deploy a fork once a reasonably good scaling solution appears (or someone else will do that, because there’s a clear demand for it). On xDai, it seems that Celeste is expected to launch soon. So eventually the problem with TCR will be solved.

But I agree that a short-term solution is needed. An ‘optimistic’ registry with centralized arbitration is probably the easiest to implement:

  1. Anyone can submit a project, but that would require a deposit.
  2. There’s a period during which a trusted arbitrator (multisig) can remove the project if it does not conform to guidelines. In that case the deposit is burned or transferred to the matching pool.
  3. If the project is not removed during this period, it can be registered as a recipient and the submitter gets their deposit back.

The advantage over SimpleRecipientRegistry is that recipients don’t need to ask the registry owner to submit their project. The process is similar to Kleros TCR, but decentralized court is replaced with trusted party.

#8

Yeah, that’s the gist of it. If the game theory holds true, the Schelling point on how it resolves should be the truth and there is a profit motive for users to set the correct answer if it has been set incorrectly.

So far as I’m aware, Kleros is not planning to deploy to an L2, because they don’t want to split their stakers over multiple networks.
Someone could deploy an instance of Kleros on another L2 (could even be us), but that would mean bootstrapping a new token. So far as I’m aware, Kleros requires a native token with some value to function as intended.

TCR is apparently not the immediate focus for Celeste, so even if it launches soon, it won’t be a viable solution for us for some time.

I do like the simplicity of this approach, but I dislike that it would fall-back on our multi-sig for decision making. If we go this route, I’d prefer for the community to make the decision somehow (forum polls, snapshot instance, etc) and the Gnosis Safe to just execute the community’s decisions.

That said, my preference is still for something that we have no privileged control over, which is why I like this reality.eth idea. The other reason is that I know it can (and will) be deployed on any EVM compatible L2, without needing any additional token economics to make it function as intended.

#9

If “truth” is determined by the highest bidder, the game will end with the result he wants, and he has no obligation to give the correct answer. But apparently it is not true and there’s an additional mechanism that developers call arbitration (I’ve found it by clicking on “How it works” button):

Anyone who wants to challenge the final answer can request arbitration. The arbitrator can be any Ethereum contract and may be controlled by a company, a trusted group or individual, a DAO, or any other decision-making process you can code. The arbitrator contract will have a set fee that must be paid to settle the question, but if the winning total is high enough, it can be profitable to challenge an answer via arbitration.

So to be robust against manipulation it still needs a decentralized subjective oracle like Kleros. In the absence of such oracle it needs to rely on a trusted party and therefore it is similar to the mechanism that I proposed, but more complicated and wasteful.

TCR is relatively easy to build. Decentralized court is the hard part but fortunately they’ll take care of it.

#10

But if someone selects the wrong answer, there is a profit incentive to double the bond and set the correct answer. Again, with the Schelling point being the truth.

There is an arbitration option, but as you mentioned, it requires something like Kleros. I was suggesting that we do it without an arbitrator and rely only on the escalation game.

That’s good news. Perhaps there will be an option for us to build our own then.

#11

And then what? The person who selected the wrong answer doubles the bond again? There’s no Schelling point. The person with the biggest pocket wins, that’s all.

#12

If people trust kleros, is there a reason not to use the reality.eth + kleros arbitration setup for this case? In that setup Kleros is only called in exceptional cases, and when there’s already a bond high enough to fund arbitration costs. That stops it being a “who has the most money” competition.

They’ve got a proxy arbitration contract set up on XDai so that the reality.eth escalation game happens on XDai, but if it needs to go to kleros (on mainnet) we do a slightly complicated cross-chain thing. I guess we could do the same thing on other chains, although we don’t have concrete plans.

#13

If Kleros is available, it can be used directly for dispute resolution and the escalation game is not needed. This is what we currently do on mainnet.

That’s interesting. How this cross-chain thing works?

#14

If Kleros is available, it can be used directly for dispute resolution and the escalation game is not needed. This is what we currently do on mainnet.

I read the issue @auryn brought up as being the gas costs, not sure if this applies to mainnet; In the mainnet case I don’t know how their costs compare to ours, although we worked hard to keep ours low.

That’s interesting. How this cross-chain thing works?

It’s a bit of a rube goldberg but what happens is that when you request arbitration on xdai with the reality.eth UI, it prompts you to switch networks and send a request to a contract on mainnet that talks to Kleros. Their mainnet contract then sends a message via the AMB bridge to a proxy arbitrator contract on XDai, which notifies reality.eth that arbitration has been requested. It’s slightly nasty UX TBH, but if you set the arbitration cost very high so it’s just backstopping the escalation game, it should hardly ever have to be used.

#15

Not quite. Currently the whole process happens in mainnet, users are required to put up bonds that cover the cost of arbitration, and gas costs are out of control.

With the setup @edmundedgar suggested , the happy path would require only a small bond on Reality, on xDai, and only once the bond is high enough to justify the costs of arbitration on mainnet would anyone bother to actually call Kleros on mainnet.

#16

The main issue is the gas price. Even if we reduce the gas costs, the tx fee would still be too large for most of our potential users. So we need a dispute resolution system that can run entirely on xDai. The AMB bridge is interesting idea but it’s complicated and doing arbitration is still expensive in that case.

1 Like
#17

@edmundedgar how much of the complexity of the cross-chain arbitration costs are handled out of the box with the current xDai Reality.eth <> mainnet Kleros setup? Would our UI or contacts need to deal with any of that complexity?

It seems like it would be pretty rare for resolution to ever actually go to arbitration, so those gas costs probably shouldn’t factor into the decision too much (so long as the arbitration price is high enough to warrant the gas costs).

#18

how much of the complexity of the cross-chain arbitration costs are handled out of the box with the current xDai Reality.eth <> mainnet Kleros setup? Would our UI or contacts need to deal with any of that complexity?

@auryn You shouldn’t really need to be involved in any of that, provided you’re sending people to use the reality.eth UI for those particular functions rather than calling the contracts in your own UI. From your point of view there would just be an arbitrator address on xdai representing kleros, and you specify that arbitrator address when you create the question. I guess the exception would be if you wanted to do an end-to-end test of the whole flow to make sure everything was working, then somebody would obviously need to use the request arbitration function to make sure it worked
.

#19

The main issue is the gas price. Even if we reduce the gas costs, the tx fee would still be too large for most of our potential users. So we need a dispute resolution system that can run entirely on xDai. The AMB bridge is interesting idea but it’s complicated and doing arbitration is still expensive in that case.

The reality.eth game really is designed such that the cost of arbitration shouldn’t matter to people who are honest+correct, it actually works better if arbitration is expensive. However to work you do require that someone would be prepared to front the capital needed to challenge a wrong answer up to the cost of arbitration (plus gas costs). That doesn’t need to be all of your users - it’s designed so that A can put in an answer with the correct answer, get in a bidding war with B up to a certain point then drop out, but then richer-person C can take over and start paying higher bonds for the answer that A was giving, Provided Kleros rules in their favour (or B gives up) both A and C will make money in that situation.

#20

Categories like ‘honest’ and ‘correct’ rarely apply in our use case because the answer to question about whether something is public good or not is mostly subjective. When someone submits a project to the TCR and another person challenges this submission we only have two opinions. In most cases both sides are honest. And Kleros is really good for resolving such disputes because it gives feedback immediately and the losing side don’t lose much.

Yes, in escalation game it is likely that one side will eventually give up, but not because they are dishonest or wrong but because there’s no certainty in arbitration outcome and they don’t want to lose a lot of money.

1 Like