A long time ago in a galaxy far away, there was just Bitcoin. It could only do very simple UTXO stuff. Then came V2 blockchains, which enabled smart contracts, tokenization and basic escrow payments within closed systems. This is where we sit. The next phase is the connected blockchain. V3 will be streamlined and scalable networks that allows users to connect to outside data, other blockchains, servers for large off-chain operations, and even physical assets in the real world that are tracked by the network. At the current moment it is a big open research problem (BORP) to make it secure and decentralized.
Luckily for us though, the upgrade to V3 is not a discrete event, but rather a continuous process where we can grab certain functionalities from the future and implement them on our current, proven systems. For us at Tellor, we’re working on Oracles.
Purpose and expanded use of oracles
‘Oracle’ is a pretty all-encompassing term currently. Want to query your plasma chain, oracle. Want to read API data, oracle. Want to deposit Bitcoin in your smart contract, oracle. Basically an oracle is the term given to anything that grabs off-chain data and puts it on chain. This is a very broad concept and for us, usually means something along the lines of:
- Defi (e.g. ETH/USD price from some exchanges)
- Connecting Chains (e.g. BTC block headers)
- Scaling / Off-Chain Computation (e.g. store only validated results on chain)
- Privacy (e.g. ensure data availability/validity without data)
What’s open research?
There is a reason that smart contracts can’t read API data. The redundancy built into current systems requires that every node and person who downloads the list of transactions can come to the same conclusion as to the end state. To give an example: If we have a smart contract that says “get BTC price from coinmarketcap.com”, you should be able to run it and validate it today and then I should be able to look at those same instructions in a week, run it and get the same answer. This is obviously impossible since the BTC price will change and we’ll get different answers.
To get around this, we need someone (or something) to simply enter the value on-chain. Now If instead of reading from coinmarketcap, you just said, BTC price equals 8,000, then the smart contracts just sees that someone entered it as 8,000, something we can all validate. The only problem of course is that now it’s centralized.
If only there were a way to validate a set of data in a decentralized way….
Of course the answer is a blockchain, but in case you haven’t heard, they’re kind of slow and cumbersome. Just putting each piece (e.g. all coinmarket cap data) on the blockchain really doesn’t get us very far in terms of scalability or usability. And this is the point.
The infamous scalability trilemma applies to oracles as well
Any Oracle provider that claims to be able to query any data (blockchains validate very specific data points) in a semi-quick fashion (consensus is slow) is either unsecure or centralized. To say that they’re not would mean that they solved a way for blockchains to validate arbitrary inputs without access to the reference data.
Decentralized Data Validation = Slow, Expensive
The takeaway here should be that just because you call it an oracle or the data is free to view on a website, there’s still no good way to input this in a blockchain. In the same way a blockchain needs to validate every transaction, you need to do the same thing with outside data. Any one can send a transaction to Ethereum that says “send Bob 1000 Ether”, but miners will reject this if you don’t have 1000 Ether and accept it if you do. Now we want a system that says “the price of BTC is 8,000.” This is almost the same problem as validating a transaction; how do we all agree on what is valid?
Current Solution(s)
So the basic way that you can currently get around this problem is by making reporters liable. To simplify, a reporter (person in oracle system grabbing off-chain data), can just deposit X dollars into a smart contract and say that it is valid. Then if they lied, the system has some mechanism for voting and saying that they lied and should lose their X dollars. Whether you’re actually losing money or some form of reputation, the difference doesn’t really matter.[1]
The real tradeoffs are between what data you’re going to have your system validate, how you limit which parties can act as reporters, how you force them to have skin in the game, and what specific mechanisms you use to dispute/penalize malicious reporters (i.e. the voting mechanism).
Current issues
There’s a few current issues with our (and other) solutions.
So, the first is market cap limitations. The basic use case is financial products. So you can imagine a simple bet where two parties bet on if the price of BTC goes up or down next month. The size of this bet is limited by the security of the Oracle. Like all blockchain systems, there’s always a ‘cost to break’. In Bitcoin, if you buy up enough ASICs to get 51% of the hashrate or in a PoS model where you would just buy up enough tokens to stake 51% of them, you could just break it. Since most oracles now use some form of voting, ~51% of the market cap of the token that is used in voting is the hard cap on the max it would ever cost to break one of these oracles. Now this may seem huge, but when you look at the fact that some stablecoins have market caps well above double those of Oracle protocols, then it gets pretty obvious that the smaller oracles will likely not be able to be the sole price provider for certain large financial products.
Another issue is latency. Blockchains are slow by design. Unfortunately, people don’t like slow. Many trading and other real time applications require very fast data inputs, and in our opinion, they’re just not suited for current blockchain structures. Many individuals in the space are trying to recreate traditional applications on top of a blockchain and they just don’t fit.
From dealing with miner front-running to clunky interfaces, the few currently deployed projects trying to mimic fast databases are nightmares. Lucky for us, this doesn’t necessarily mean we can’t build anything. Higher latency applications (specifically financial projects in our mind) are great use cases and can still be built. For instance weekly financial contracts, insurance systems, or even stablecoins with built in mechanisms to handle slow networks are all still great use cases.
The near-term outlook for Oracles
So our oracle, or any, may not be perfect for all use cases or even secure enough for the big ones….so now what?
The first solution to overcome the market cap / security problem is the amalgamation approach. For this simple trick, you just take all of the decentralized Oracles out there and you either layer them on top of each other or take a median of the group. So for instance, if some giant stablecoin needed an ETH/USD price, they could just use Chainlink first, move to Tellor in case of a dispute, to Augur if that get’s disputed, to Witnet if that still fails, and then even loop back around if you still can’t settle it. That way an attacker would need to literally break all 4 of the protocols to get a bad result. You could also just take a median of the bunch or use a randomly selected decentralized Oracle for your settlement. Once again, it makes your system much more secure than just using one of the solutions.
Similar to the amalgamation approach, you could also have a specific token secured Oracle. This system can be set up based upon the principle of it being hard to break a system forever. A company could utilize a smart contract to pull Tellor values, but the values that go into their smart contract are accepted by some form of vote by their own token holders. So now, parties could use Tellor to get values on chain, but ultimately security of the Oracle is provided by your own token holders rather than Tellor. If you utilize a structure that is flexible on timing, then even if someone breaks Tellor for a few values, you can reject them in your system and pull the next good value that Tellor’s system provides (malicious parties would need to actually have 51% of the tokens to do a long term attack). Systems like this can also be good for pulling down centralized sourced values. If you have an API at Coinbase you specifically request, the Tellor system is programmed to pull that specific API value (not really say if it’s actually what you want). If you want the ability to handle a malicious attack by Coinbase itself, you would need to have a mechanism for voting if the value is correct (versus just the pull).
The next thing we think will happen for most applications is the optimistic oracle. For the optimistic oracle, you simply have a centralized party place in the data and then use the Oracle as a fallback if someone disagrees with what the central party entered. For most financial contracts, this is an excellent option as a central party can likely be trusted, but it’s just in those odd cases where you need true decentralization. Game theory would dictate that the central party will be honest since they will likely want the lower latency for their products and customers.
Other oracle pieces that we can definitely do now include getting exchanges to start putting data on-chain. You can have an oracle where a whole bunch of centralized parties put data on-chain and it takes the median. Decentralization is a scale, so if you have enough verified and/or competing parties, the system can be sufficiently decentralized. You can even use some form of on-chain governance to decide who gets to be part of this system, but this kind of system would go a long way to getting usable applications up and running quickly with semi-familiar data input times. When you start seeing centralized parties really embrace the decentralization of the EVM, then we may not have to rely quite as much on the true decentralization of the anonymous validator. Other off-chain aggregation and decentralization methods can be used for better data security. Bringing on results from scuttlebutts, other gossip networks, or even other decentralized blockchains can be done in the very near term.
Conclusion
Oracles are here to stay, but they’re very simple at the moment. Don’t let someone shill you into buying their token or building on their protocol until they have something launched and secure.
[1] A subset of companies using a form of this are Augur, Witnet, Chainlink, and of course Tellor.
