Economic obstacles to a decentralized oracle

An oracle is a mechanism that summons real-world data to the blockchain, for example, the usd price of some asset, an outcome of an election, or an output of some costly computation. It’s difficult to imagine blockchain applications breaking out of its speculative nature and doing something truly useful without making use of oracles.

The existing projects sometimes employ centralized oracles, i.e. a trusted source that commits to sending the correct information to the blockchain. Even the projects that are in part oracles themselves, TrueBit¹ and Augur, still employ a centralized oracle within their design. The reason we’re not seeing applications adopting a fully decentral approach is that the problem of creating a functional decentralized oracle is genuinely tough.

In this post I look at the subject of oracles from the perspective of mechanism design and describe a couple of problems of economic and game-theoretic nature that I believe to be the primary obstacles to a functional decentralized oracle. The post is intended in part as a motivation to my own proposal.

I thank Computable Labs for giving me an opportunity to work on blockchain research this summer, and for allowing me the intellectual freedom to pursue my interests. (They’re hiring!)

Let’s start with stating some assumptions that span various possible applications. I’ll use the term task for a question that task-creator wants to answer using an oracle (Who won the election? What is the market price of REP?). By workers I would mean people or machines that are performing the work of fetching the information to the blockchain.

Assumptions

• Truth-value of tasks is universally accessible — given the willingness to expend time/resource, all participants will come to the same conclusion about task’s true value.
  I’ll also assume that no answer to the task is overwhelmingly likely to be correct, to avoid Verifier’s Dilemma( I suspect that almost every question that doesn’t satisfy this condition has a formulation that does, e.g. instead of asking who won the election you can ask how many states have the candidates won).

- Fetching information from the real world is labor — it entails costs and will be performed only if those costs are outweighed by the benefits. Depending on the application, the cost can be measured in the cpu cycles, time spent looking something up, the capital cost to build/update/run software that interacts with API of an online service, or the opportunity cost of not doing something more profitable.

- Workers and task-givers are rational. Given the mechanism, the costs and the state of the market, participants will do the thing that makes them most money — e.g. splitting their accounts into multiple ones, pulling together with other participants, misreporting or just not participating at all.

There are also a couple of properties tasks commonly have that I think are of great importance.

- Tasks may have large underlying stakes and adversaries. The outcome of a task may have a financial value for some agents that is significantly larger than the cost of fetching the data. For example an outcome of a prediction market can decide a fate of 50000$ in pot money, but fetching the outcome is a job that people would be willing to perform for about 2$.

- Task hardness is variable and invisible. It takes much more effort to report how many House representatives won their districts by more than 10% margin than it does to report who won the US presidency. But the information about hardness of a given task is itself part of the real world thus inaccessible from the blockchain.

Low fees vs Security

In terms of core dynamics underlying a decentralized oracle, Schelling point game seems to be the only way to go. If I ask many participants to report some real-world outcome, and reward the ones who voted for the most popular option, the true outcome is a point of salience that is easy to coordinate around. Vitalik describes this idea in detail here.

The first proposal for a decentralized oracle, SchellingCoin, which is essentially just the simple Schelling point game I described above, lets me illustrate an important issue. Imagine the cost of answering a task is small (for example, 1$ to name the current US president), but the underlying stakes are high (100000$ of stakes on a prediction market). An ideal outcome here is prediction market fetching the truth-value while paying only a few bucks for it, but it doesn’t work out this way in case of SchellingCoin.

If the task giver sets the reward at 5$, then only a few outsiders are going to participate, as after that the marginal utility of joining is going to be too low to attract more voters. The total amount staked is thus going to be low (say 100$), and so is the amount an adversary needs to shift the outcome of the oracle to the desired option. Alternatively, one can set the reward to 20000$, thus getting many outsiders to participate in the oracle and avoiding subversion by an adversary with limited funds. But this security comes at a hefty price — a large portion of the winnings would go towards oracle fees rather than to market’s winners.

Large fees are bad in themselves, but they also create an additional hazard of parasitic markets that arises due to blockchain’s transparency: anyone can set up an application (e.g. a prediction market) that uses the oracle’s output without paying the fees. As participants switch to a less costly parasitic application, the imbalance between oracle’s fees and underlying stakes grows larger, thus making the system even less secure.

We want an oracle that makes tasks cheap to execute and expensive to subvert. The only way I see of achieving this property is entangling many tasks together, so that subverting a given task costs as much as the total reward pool of all tasks. This can be done by assigning workers to tasks randomly.

Free market vs Security

Random assignment of workers to tasks is in the nutshell the recent proposal for a modification of TrueBit. When a new task comes along, the mechanism randomly elects a few workers to submit their answers, with matching probability proportional to worker’s stake. To overwhelm a given task, an adversary needs to win several voting spots in a particular task, and doing so with a non-negligible probability requires stake that is comparable with the total stake in the system, which itself is proportional to the total reward pool of the tasks.

Random matching, at least when employed at scale, seems to solve the problem of cheap and secure tasks, but another issue now pops up. What do we do with the workers who were assigned to a task but didn’t submit an answer?

If we punish the slackers by burning their stake (as the paper suggests), then a worker is essentially forced to process all assigned tasks, even if they come with unfair rewards (TrueBit avoids this issue by having a centralized oracle that prescribes a reasonable computation price. )

On the other hand, if we don’t punish the slackers, task-givers have an incentive to price their tasks fairly — otherwise it wouldn’t get processed. But workers are now encourage to stake as much as they can afford, and only process the tasks that are most profitable for them. This can result in tasks taking forever to resolve (as we need to pick new workers after the current ones have timed out) as well as decreased security.

This is a trade-off between free-market economy and security: random assignment decreases the threat of adversaries, but strips workers of their freedom to pick their workload, which in turn is crucial for incentivizing fair reward-setting.

Social layer dependence

I also wanted to discuss how Augur’s oracle works. Although the team initially seemed to consider the random worker-task assignment scheme, they eventually landed onto something different. Every prediction market has a dedicated reporter who is to determine the outcome. Any owner of REP can then challenge the outcome reported, effectively starting a stake-weighted vote open to all REP holders.

Augur’s mechanism suffers from some of the problems I described above — for example, the appropriate rewards for tasks are hardcoded rather than discovered via a market mechanism.

But the issue that is unique to Augur is its implicit dependence on social layer. Imagine the platform has grown to having thousands of ongoing markets, and my friend and I create a market on some obscure issue(say, predicting how many restaurants will open in Toronto in the first week of October 2018), assigning my friend as a dedicated reporter.

A sore loser, he reports the wrong outcome to grab the pot money. If the platform is functioning well I shouldn’t expect some passerby REP holder to check if the reported outcome is correct — doing such spot-checks is not going to be profitable for REP holders. Instead I should somehow find a sufficiently wealthy REP-holder and get them to challenge my friend, and for this I’d have to resort to off-chain communication.

Such dependence on social layer is not a critical flaw, but it makes the oracle considerably less predictable, especially as the market scales up.

Taking the right trade-offs

To summarize, the only known way of trustlessly getting stuff onto blockchain is playing schelling point games. There are at least two major economic problems left to resolve then.

First one is making cost of subverting the task much higher than than an appropriate reward for performing the task. A promising path in achieving this seems to be assigning workers to tasks at random, effectively pulling tasks’ security together. Second challenge then is to simultaneously with this grant workers freedom in picking which tasks to process, as this is essential for incentivizing task-givers to set competitive rewards.

In the next post I describe my own proposal for a decentralized oracle that I believe do just that.

¹ Although TrueBit is not an oracle per se due to its use of verification game, it is useful to think of it as one. More precisely, it can be viewed as an oracle with an additional property that the correct value is established whenever at least one worker reports it (whereas in normal oracle we would need at least the correct outcome to be reported by at least the majority of voters)