A Glimpse of Pythia
Now that our project has established a strong foundation of community support, we feel that the timing is appropriate to provide some more information about Pythia: Delphi’s secret weapon.
The Power of the Oracle
If you want a smart contract to know about anything outside of the blockchain it lives on, someone or something has to feed it data. This is the role of the Oracle.
The Understanding Oracles article by Oraclize is an excellent introduction to the subject, and for a little bit deeper of a dive into it, the Ethereum and Oracles article by Vitalik is an exceptionally understandable and insightful writeup.
As Vitalik notes, not every smart contract requires an oracle. For processes where all data is internally available to the contract, no external oracle or data provider is necessary. But even so, for many of the more interesting and profound possibilities, the power ultimately rests with the oracle(s), who decide the results of a contract by controlling its inputs.
At Delphi, we treat the oracle component as all-important. In fact, we believe that the prediction market platform which is able to provide the best answer to The Oracle Problem will likely be the dominant project in the space when all is said and done. Dissatisfied with the approaches of our predecessors, we have decided to tackle this problem in our own way.
From First Principles
Elon Musk argues that “reasoning from first principles” is a powerful way to innovate effectively. We employed this technique when we set out to develop our own oracle solution, and we identified a few core philosophical tenets from which to build:
1) Providing a quality oracle service entails a non-zero cost to the service provider, so any sustainable solution must involve oracle compensation in one form or another. In other words, oracles cannot be expected to work for free, and will necessarily require an incentive or reward.
2) Given the above, the fewer oracle service providers involved for any given event resolution or input determination, the lower the expected cost-of-service should be. To truly minimize oracle-related costs, the system should allow for “localization” of the oracle function; requiring universal (or widespread) coordination or consensus for each oracle event is fundamentally expensive.
3) Reliance upon a single centralized oracle can (in many cases) entirely defeat the purpose of adopting a smart-contract architecture at all, by reintroducing the need for trust. For any smart contract which meaningfully relies on external data of any kind, the contract is only as decentralized as its data provider (oracle). Therefore, any oracle “solution” that involves allowing a single oracle entity to unilaterally decide the result is effectively a total regression to centralization (i.e. it is not a solution at all).
4) Open, free-market competition is the best known mechanism for minimizing aggregate system costs over the long-term. The “invisible hand” of the market is an unrelenting force of optimization, and leveraging this phenomenon (to the extent possible) represents the best possible chance of ensuring eventual platform success. In other words, it is better to allow the market to work for you, rather than trying to individually outcompete it.
We have taken these principles into account when deciding upon our own answer to the oracle question, which we have named Pythia.
The Basic Idea
Pythia is a distributed oracle framework, launchpad, and tool-suite.
The general premise is fairly easy to understand. A “framework” is basically a collection of tools and specifications set up to support the management of a particular type of software. In our case, this is “distributed oracle” software. In other words, Pythia is a platform that people can build and deploy distributed oracles from.
At the most basic level, these distributed oracles will rely on multisignature contracts, where authorization from more than one entity is required to generate an oracle output. Beyond the usual M-of-N multisignature arrangements, however, Pythia will accommodate signature weights and thresholds in a variety of ways. With these simple primitives, an endless variety of oracle arrangements are possible, ranging from the straightforward to the incredibly-complex.
To demonstrate the principle in an understandable manner, let’s walk through one of the simplest and most minimal oracle schemes possible in Pythia (a sort of “Hello World” example). We will establish an arrangement of 5 oracles total, with four of these oracles assigned a weight of 1 and the final oracle ascribed a weight of 3. For an oracle output to be considered valid in this arrangement, it must meet (or surpass) a weight threshold of 4.
In this arrangement, the “alpha oracle” with the signature weight of 3 is able to cosign an output with any of the other oracles to render that output valid. However, the alpha oracle acting alone is unable to produce a valid output (it can sign with a weight of 3, but the weight threshold is 4). Absent the cooperation of the alpha oracle, the “subsidiary oracles” are still able to produce a valid output, but only by reaching unanimous agreement, because it would take all 4 of their singly-weighted signatures to reach the weight threshold.
Even in this incredibly-simple setup, our example oracle arrangement possesses a few interesting (and desirable) properties. No single party is able to unilaterally make an output decision (so the arrangement is not totally centralized). There are reasonable checks and balances in place, keeping power meaningfully distributed rather than concentrated. In most cases, valid outputs can be generated with the bare minimum number of signatures required in a distributed-oracle context (namely, two), meaning that service costs can be minimized (there is no need to bother or coordinate with more oracles than are strictly necessary for the process, and signature transmissions and verifications are kept to a minimum). There are no consensus-critical complexities to factor in (the only form of consensus necessary is trivial: “enough signature weight provided”).
It’s not very fancy yet, and the prior example is by no means an end-all-be-all oracle solution, but we can already see some of the power that the Pythia framework can provide, even in minimal-setup contexts.
Oracle DAOs
In a way, Pythia can be thought of as a platform to facilitate the design, creation, and usage of “Oracle DAOs” (although to be more precise, a better term might be “Oracle DOs” [without the “A”], at least over the near-term). These can be small and static units involving very few parties (as in the previous example), or large complex networks that evolve over time. They can be specific and ephemeral (created to generate a particular output) or general and persistent (offering oracle services on the open market and competing with others doing the same thing). The key takeaway here is that Delphi is not going to limit what sorts of distributed oracles Pythia ultimately generates. Instead, we are working to make sure that users and developers have the tools that they need to freely experiment with distributed oracle creation and management. Ethereum has been described as “The Lego of Cryptofinance” and in much the same way, we want Pythia to represent “The Lego of Distributed Oracles.”
Exploring The Possibilities
Things can get a lot more interesting when we involve more functions, variables, and even feedback loops in the mix. For instance, a Pythian Oracle can be programmed so that each successful output is accompanied by a “re-weight vote” which determines the relative signature weights for each oracle on subsequent outputs (allowing the distributed oracle to internally regulate its signature weighting and even “vote out” misbehaving oracle participants). Oracles could have “decaying weights” that have to be periodically replenished (e.g. via furnishing truthful outputs). Iterative processes (and commit-and-reveal schemes) could be incorporated. Systems as complex as Augur itself could hypothetically be built and deployed using Pythia (though we expect far more lightweight and efficient alternatives to predominate the oracle ecosystem). The possibilities are quite literally endless.
One of Delphi’s biggest upcoming priorities is the completion of a formal and rigorous treatment to the various possibilities within the Pythia framework, which we hope to have published before the final software is even completed. We intend to work towards a universal understanding of the various principles and elements involved, communicating directly with the community (and incorporating the feedback received in the process), so that the Pythia toolset is as robust as possible and everyone interested in using it has a sufficient knowledge-base to work from.
Fortunately, we’re not working towards one particular solution; we are simply providing (and helping to explore) tools and models for the world to experiment with, when it comes to designing and interacting with distributed oracles. This way, we’re not committed to one particular oracle model (which will almost certainly be made obsolete by the inevitable breakthroughs that future generations will make), and can instead position Pythia as a flexible oracle-production platform that can fluidly incorporate upgrades as they are developed.
The Road Ahead
Soon we’ll explain a bit more of how Pythia fits into our Master Plan, expanding upon Delphi’s expansion (and revenue) strategies that revolve around it and providing more details about our expected deployment timeline (for both the formal research and analysis we have been working on, and the software itself). We are extremely excited about the potential that we see in the Pythia approach, and we are looking forward to showing off the work we have done towards making our dream into a reality.
