The Oracle of the Kleroterion
Research update on Kleros-based price oracles for smart contracts…
A classic obstacle in applying smart contracts to many common problems is that most useful contracts in the real world require access to values that cannot be verified by computation. A smart contract that sells rain insurance to farmers needs to be able to determine whether it rained. Many financial contracts that one would like to implement on Ethereum require the price of 1 ETH in USD, but this is not a value that natively lives on the chain.
An “oracle” is a mechanism that can be consulted to provide this outside, real-world information. Many major blockchain projects have built oracles designed for their specific applications. The stablecoin created by Maker DAO uses an oracle to ensure that sufficient collateral is held to cover the DAI in circulation. Prediction markets like Augur and Gnosis require oracles so that the blockchain knows the result of the market.
The resulting oracles are often well adapted to the specific needs of these projects. Indeed, the proposed oracle of Augur offers a fully decentralized solution that works particularly well when the real-world value you are trying to determine takes discrete outcomes. However, there still has not been an oracle capable of providing a fine-grained estimate of a price of a generic asset, as for use in a financial contract, in a satisfying, fully decentralized way.
At Kleros, we are building a platform for crowdsourced justice. On our platform, disputes are decided by randomly selected jurors who are incentivized to vote honestly through game theory. Already such a dispute resolution platform is a kind of oracle; it brings onto the blockchain the external information of who is the honest party in some dispute. We propose to leverage this ability for use in more general oracles.
In this vein, we are sharing the current state of some of our research on how to apply Kleros to create an oracle that estimates a real number value. Thus, this proposition could be used as a price oracle, such as in the applications discussed above. Even more general oracles are a subject of future work.
For our proposed real number valued oracle, in addition to the jurors who are always present in Kleros, we have actors called respondents. They provide the initial input estimates of the value to the system. Potentially, the respondents will provide conflicting information. In this case, they become parties to a dispute that Kleros will resolve in order to determine the value.
Roughly, respondents will submit an interval — a lower and an upper bound — where they think the true value lies. As they do so, they also place a deposit. Those whose interval contains the ultimate value that is output by the system are rewarded while respondents whose intervals don’t contain the output value are punished.
Of course, respondents could try to place a really large interval to ensure that the output value will be within the limits. Imagine a respondent who submits an interval for the price of ETH from 1 USD — 10 million USD. While likely true, this wouldn’t be very useful . But the rewards and punishments are weighted so that correct respondents who submitted smaller intervals receive higher rewards than those who submitted large intervals.
One could imagine that whoever needs an oracle (e.g., for a hedging contract), would pay the respondents for their work. However, this poses several challenges:
- A widely used oracle such as for the value of ETH in USD may be paid for by one party, but nothing prevents a parasitic party from pointing its contract at that value without paying for it (see similar concerns in the work of Augur).
- If you let anyone submit a response for a reward, users will tend to submit the same response many times to get a large reward while only performing the required work to determine the value once. On the other hand, if you restrict who can submit a response, it can become difficult to ensure with high probability that someone will submit an honest response at all.
For now, we assume that the respondents are not, on average, compensated. Instead they only receive rewards drawn from other respondents’ penalties. In this model, someone may nonetheless submit (honest) responses through self-interest if they have a financial interest in the oracle producing honest results. In future work, we will consider how to properly compensate the respondents for their efforts in a way that is resistant to attack.
Using a sort of modified binary search, we ask Kleros jurors a repeated number of times whether the true value is higher or lower than some test value. Rather than test against the median of the list of responses, as one would do in a typical binary search, we detect points in the list of responses that are preventing the system from coming to a consensus answer. Then we test against the median of the list of these “points of incoherence”.
We prove that our proposal has some nice properties. Namely:
- The number of times Kleros must be called scales with the square of the log of the resources of parties that are ultimately ruled to be wrong. Thus, even if there are many, many responses, they will only cause extra appeals to Kleros to the degree that they disagree with each other. In fact, if all the responses are coherent (no one’s lower bound is bigger than someone else’s upper bound) then no calls to Kleros are required at all.
- The amount of precision of the final output is tuned in accordance with how large or small the intervals of the respondents are. In particular, we prove that if a user submits an interval that contains the true answer, and if we assume that Kleros itself works in an ideal way — that the decisions of the jurors are accurate — then the output of the oracle is in the user’s interval. So a single user that is confident in the value she is submitting and that wants to make sure that the oracle produces a very precise answer can simply submit a very small interval.
For more detail, check out our draft technical paper. Feel free to send us your comments, criticisms, or questions, which will be helpful as we continue to develop this work.
Learn More
Join the community chat on Telegram.
Visit our website.
Follow us on Twitter.
Join our Slack for developer conversations.
Contribute on Github.
