If you’re reading this article, you probably already realize that smart contracts have incredible potential to improve the way we do all sorts of things. But a fact which we rarely acknowledge is that for most of the really “interesting” stuff, a smart contract alone won’t cut it. You need a smart contract plus a good oracle.
First, What Is An Oracle, Anyway?
An oracle is just a provider of data. An oracle gives smart contracts answers to questions about the world. In most cases, without an oracle supplying information, there would be no way for a smart contract to be able to know the things it needs to know in order to do its job.
Oracles Are Important
Since an oracle determines what a smart contract sees (i.e. it controls the inputs to the smart contract) it also holds the power to control what the smart contract does in response to these inputs. This means that oracles possess an enormous amount of power when it comes to smart contracts (especially in prediction market contexts). If the oracle is compromised, so is the entire contract; this is one reason why centralized oracle services are not considered a serious solution to “The Oracle Problem” in most cases. To put it simply, as soon as you make a smart contract rely on a single central oracle, you have totally sacrificed any decentralization-related benefits (which makes it arguable whether you should be using a smart contract at all).
In Search of The Perfect Oracle
The Augur team has spent years working towards a decentralized oracle solution. They have developed an intricate model in which token holders can “vote on the truth” and then other token holders can dispute the results of that vote (which is a process that can be iterated). They have also presented relatively solid arguments that this process will reliably converge to truthful oracle outputs, although the model isn’t perfect and unsurprisingly, there is room for improvement.
On the other end of the spectrum there is Gnosis, who have neglected to give a serious treatment to The Oracle Problem at all, instead defining generic “oracle interfaces” and leaving specific implementation details open for others to experiment with. They seem to be hoping (perhaps overoptimistically) that “someone will figure something out eventually” and that they will simply “plug their solution into Gnosis” when everything is said and done. While this approach does have the nice benefit that it makes the Gnosis platform more flexible and future-proof, by not tying them to one particular implementation, it means that if Gnosis are not able to provide a practical initial distributed oracle foundation to build from, it is highly unlikely that the project will ever be able to get past the early stages and grow into something truly useful for the world.
As of right now, Gnosis basically has two “answers” when it comes to The Oracle Problem:
1) Use a centralized oracle (which they expect to be used >99.99% of the time).
2) Use the “Ultimate Oracle” (AKA the “Fallback Oracle”), which ultimately represents Rule By Wealth (where the rich get to bully the poor without any repercussions) rather than any serious attempt at realizing a truthful decentralized oracle solution.
Neither of these options are satisfying, and we don’t think it’s a safe assumption that the market will solve the problem on Gnosis’ behalf, because the fact of the matter is: building a good oracle solution is really hard.
Even so, we think we have an idea of how to do exactly that. On a high level, we’re doing the same thing as Gnosis (providing general oracle interfaces so that our protocol is flexible enough to support any solutions the market is able to come up with), but we’re taking it a step further by laying the foundation for a truly decentralized oracle framework, and providing a robust set of tools for exploring the possibilities within that framework. We call this initiative Pythia.
