Oracle Working Group Notes — Scaling Ethereum
tldr: Given the high cost to providing constantly available, accurate data, we describe a strategy with a two layer arbitration system — a cheaper and more frequently used price feed, and a more expensive fallback system with stronger correctness guarantees. We concluded that the best oracle strategy will be a dual system where a liveness-focused and correctness-focused oracle are used in conjunction.
After a full morning of Oracle and DEX focused talks, attendees of Scaling Ethereum, including representatives from ChainLink, UMA, and MakerDAO, settled into a basement room of the University of Toronto for more productive conversation.
We tossed around a bunch of topics — what oracles are good for, steps in the process of getting information from off-chain to on-chain, what end users might be willing to pay for that process, and finally what makes a good oracle. We eventually found a framework we liked and distilled the landscape into two categories.
Before we dig into I’d like to note that I divide the Oracle Problem into two distinct challenges.
- The first is an engineering problem of moving data from outside of a blockchain to on-chain. This has been addressed by projects like TownCrier and Provable (used to be called Oraclize).
- The second is ensuring that the information that ends up on-chain is correct. For more details about this distinction, check out UMA’s second Whitepaper. This second piece to the Oracle Problem puzzle was the focus of the workshop.
I’d also like to note that the examples in this post use DeFi specific examples and terms. Oracles are of course not specific to financial applications, but price feeds are much simpler to wrap your mind around than more abstract off-chain values.
Ok, back to working group stuff!
In an ideal world, an oracle is both highly available and highly accurate. DApps that rely on off-chain data need to be guaranteed access to information, AND guaranteed that the information is correct. Unfortunately, nothing is ideal in Blockchain World and there’s a cost to constantly verifying and updating information.
Oracles, in a sense, are like a consensus mechanism for off-chain data. The consensus mechanisms we’re used to are not just paid in miner fees, but heavily subsidized by block rewards, so it seems likely that end users will be unaccustomed to or unwilling to pay for the real value of an oracle service, even if that means compromising sometimes on accuracy.
Given this constraint, we think there are two types of oracles that achieve a useful balance between availability and accuracy.
1. Happy Path 🌻Oracles — high frequency/low value (emphasis on liveness)
2. Arbiter 🏛Oracles — low frequency/high value (emphasis on correctness)
Happy Path Oracles
The first kind is closer to a data feed — its updated regularly — meaning it has to be inexpensive or it won’t be used. That’s what makes it “low value”. It’s cheap to use, but also cheap to attack. This kind of information source is vital to keep costs down so we can start building things. Maker’s oracle is a great example of this — it’s not the most secure or decentralized, but it is sufficient for now. Projects like MakerDAO and ChainLink focus on liveness in their oracles because to them its more important to make off-chain data easily and affordably accessible on-chain. Some smaller scale applications have no need for highly accurate data, and don’t have the size to merit paying for such a service. For these applications, a Happy Path oracle does the trick!
Arbiter Oracles
As blockchain applications scale (and we lock scary amounts of value up in magic internet money), it becomes increasingly important to have a dependable arbitration layer to settle large contracts. At this level, paying more to access reliably accurate information is worth the cost of avoiding faulty settlement. Arbiter oracles are beyond the scale of testing and pet projects. They should be used for (and their cost is only justified for) large scale financial applications that rely on highly accurate data to settle. UMA’s oracle falls into this category, which is why we’ve been building tools for financial products alongside the robust, correctness-focused oracle.
The coolest part about this split system is that the two categories of oracles complement each other really well. The expectation is that dApps will use Happy Path oracles as a price feed and only resort to the fallback arbitration system in one of two cases. Either their Happy Path oracle is broken or corrupted in some way, or they have one high stakes moment of settlement that requires increased incentive for accuracy. Since we can’t have a single oracle emphasize both liveness and correctness, this dual system of a regular and fallback oracle means that we can have our oracle cake and eat it too. 🍰
The blockchain universe is blossoming (and State of the Dapps is getting ever longer and more complicated). Different applications have different needs and willingness to pay and we need an equally diverse oracle system to support them, even different actions within the same dApps.
In just one 3 hour research workshop we couldn’t possibly cover all the different ways of dissecting the oracle problem but we like this framework of 1) two parts to the problem and 2) two kinds of solutions. If you love it or hate it, let me know — I’d love to continue the discussion!
