Oracle-based recipient curation

general
#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
#21

I’d argue that this is the mechanism doing it’s job correctly.
If you do not believe that arbitration will rule in your favour, then you shouldn’t play the escalation game.

Essentially, because of the arbitration option, there is a financial disincentive to set the outcome to anything other than what you believe arbitration would resolve it to. In the vast majority of cases, this means that the outcome is only set once, never doubled, and arbitration is never called.

More than likely, the nuance is in setting the arbitration price high enough that it justifies the gas cost, but low enough that it’s still affordable to most individuals.

#22

(Jimmy from Kleros joining the thread here.)

I agree that the more subjective your question is, the less well an escalation game backed by Kleros will work compared to just using a direct application of Kleros.

As I replied to Auryn on Twitter, we’re open to deploying a version of Curate on xDAI (with arbitration going straight to mainnet with no escalation game). It seems workable for clrFund because the rate of submissions being flagged for arbitration is not too high.

Our current mainnet<>xDAI proxy is using proxies specific to Reality.eth/omen use cases, but we can either customize them for Curate or generalize them. I’ll give you more details once we discuss it internally tonight.

When is the next CLR fund round?

2 Likes
#23

Great!

I guess it will start somewhere around March 5-7.

#24

My main concern with this approach is that the barrier to entry is still quite high because each submission needs a bond that is high enough to cover the cost of arbitration in the case that someone does challenge, otherwise there is an economic disincentive to challenge projects. At the time of writing, this means that each submission would need a bond worth several hundred dollars.

Reality provides a nice way to lower the barrier to entry as the initial bond just needs to be enough to disincentivize spam and incentivize someone to change the answer for projects that they don’t think meet the acceptance criteria. On a network with cheap gas (like xDai or a rollup) that bond could be just a few dollars.

#25

Moving Curate to xDai as-is would at least spare the grant creator and/or challenger the non-retrievable gas fees which are already close >$100 at a gas price of 150 gwei.

I understand the need to lower the initial bond but our experience and user research on “The Challenger’s Dillemma” shows that if the challenger bounty too low, and it would be too low starting with bond escalation , incorrect submissions will not be flagged for dispute.

We’re diving more into this dilemma in the “The Submission Challenge Bounty” section of this post and here.

We are of course currently working on selecting which L2 we would deploy our Court V2 on this year but it’s more likely to be a rollup than xDAI. So, in the meantime, the hybrid solution of Curate on xDai and Court on mainnet seems the most appropriate in the short term.

Let’s set up a quick call this week to discuss this more deeply if needed.

2 Likes
#26

But what is “too low”? My assumption is that there is some significant breathing room between enough to incentivize someone flagging for dispute and enough to cover the arbitration and gas costs (especially at the 100-1,000 gwei range of late).

There is no reason that the registry could not require a minimum bond size, even if Reality does not. So any attempts to add a recipient on Reality with a bond lower than the minimum would just result in the item not being added to the list.

#27

I’ve implemented the proposed optimistic recipient registry. There’s no UI yet, only contract. See PR description for details.

The process of reviewing recipient’s registration request may involve some formal procedure. For example, the decision can be made using a poll, and then the multisig will enforce the outcome.

Preparing for xDai funding round 05
#28

Oh nice! This is really cool.

It would be great if there was an updateRecipient() function, so that you didn’t have to remove and then add a new recipient to update.

A nice-to-have feature would be if there was a way for parties to resolve disputes before calling arbitration.

Recipient data storage
#29

This function can be added, but it won’t work for all types of registries. For example, Kleros TCR doesn’t allow updates.

For each request, there are only two parties: requester and registry owner. The registry owner is more like a gatekeeper than arbitrator.

I see this contract as a temporary solution until we find something better. It is deliberately made very simple, so that it could be used in Round 05.

#30

Actually, I had a call with the folks from Kleros late last week, they are planning to add this functionality very soon.

Yeah, I think that this is a fair compromise.

Kleros is planning an xDai deployment of curate, that will bridge back to mainnet for arbitration, via the AMB.

So perhaps this will be an option for round 6, depending on whether round 6 happens in xDai or a rollup. I’m hopeful that we can migrate to a rollup by then though, so we may still need a different solution, unless a similar Kleros curate setup is also deployed to whatever rollup we choose.

#31

I deployed a new recipient registry to Rinkeby: https://rinkeby.etherscan.io/address/0xd1bFd2Fe7C928e3C1E87c52832977dEde26B58D0#code. Deposit amount is set to 0.1 ETH and challenge period duration is 1 hour. The contract is verified on Etherscan so addRecipient() and executeRequest() methods can be called via their UI. Recipient ID can be found at ‘Events’ tab: it is the value of topic1 of RequestSubmitted event.

There’s a test round that will run for 1 day: https://ipfs.io/ipfs/QmfAJKeiUSmFU2quAYRM3rfKQXNS7B5qGWorzU7Cq4NCVG/

1 Like