The Oracle Problem…How did we get here?
The Tellor Machine series of blog posts is an in-depth look at how Tellor works. Along the way we will look back at some early social media posts about the oracle problem, examining what a truly decentralized oracle should be. Enjoy!
7 years ago, a reddit post by u/dalovindj started (possibly) the first significant social media conversation about “the oracle problem”. At the time, Bitcoin was an obscure curiosity worth a few hundred dollars, and something called “Ethereum” was in development. “Smart contract” was a term being discussed in public for the first time.
u/dalovindj, without the benefit of having seen the EVM in action, introduced something he called “the oracle problem.” (The term “oracle” was already well defined as it applies to computer science prior to the invention of Bitcoin.) They knew that smart contracts running on a blockchain would not be able to access the internet, and obviously centralized / trusted oracles would be problematic:
“In the case of prediction markets or gambling, for example, how does a system without a central oracle determine that the Red Sox won last night? Or that a stock went up or down? You can build in API feeds…from trusted sources, but if those ever go away your system breaks…”
Part of what makes smart contracts amazing is the fact that they can be designed to function without human help indefinitely just like the blockchains they are built on; However, if the application is built using trusted oracles, it will be broken the moment that the trusted oracle operating individuals (for whatever reason) stop writing the data to the chain.
Fast forward to today and…
Online conversations concerned with the oracle problem have changed in a big way. There are now multiple dev teams dedicated to tackling the oracle problem, and the demand for secure blockchain oracle data is growing. The conversation has shifted away from how an oracle should work, towards a discussion of why one project is better than another.
Of all the oracle options available for EVM smart contracts today, the one that stands out for most people is Chainlink. Launched in 2017, Chainlink positions itself as the “industry standard” putting oracle data on-chain using a decentralized network of nodes. The nodes report data to a set of aggregator contracts that write the data to a public on-chain database.
On the surface this system certainly looks decentralized, and there are quality controls used to stop inaccurate data from being submitted to the database. Anyone can run a node..but not everyone can submit data to the official aggregator contracts. There is a whitelist, and the system is administered / upgradable using a multisig signer.
Fans will undoubtedly continue to ferociously defend LINK online, while some writers continue to point out it’s flaws. For our purposes, let’s just agree that (for better or worse) Chainlink’s security is based on trust in the Chainlink multisig signers and their whitelisted node operators who have control of the data that gets put in the database.
Looking at this system through the eyes of our 2014 Bitcoin Redditors, one might wonder: Why can’t someone come up with an oracle protocol that doesn’t require so much trust in the company running the thing?
This is exactly the thought process that inspired Tellor. Tellor’s creators originally set out to build a decentralized derivatives protocol. They found that the only viable options for oracles at the time were completely centralized / trusted oracles. (Chainlink had not launched any price feeds yet) It seemed that the oracle problem had to be dealt with first.
Solving the oracle problem means more than just providing accurate data. The way that the data gets put on chain matters. A truly decentralized oracle should not only be open and immutable, it should:
- Have no single point of trust or failure
- be censorship-resistant so that users can never be denied access to the data that the oracle provides. (if the people running the network are compromised, new participants should be able to replace them quickly and permissionlessly (like miners on a proof-of-work network))
So…is that how Tellor works?
Since it went live in mid 2019, the code on the Tellor github has been tested, audited, re-tested, broken, (migrated) fixed, adopted, optimized, updated, made multichain, and improved constantly. What began as a proof-of-work oracle has evolved into the new (at time of writing unreleased) immutable Tellor 360.
Tellor assumes that in any given scenario people can really only be counted on to act in an economically rational way:
- How do you get people to write oracle data on-chain? (You pay them.)
- How do you make sure they only submit accurate data? (You require that they stake a bond that can be lost if they submit inaccurate information.)
The Tellor oracle is a bit more complicated than a trusted oracle, and it requires trading-off speed for the security and censorship resistance it provides. It is a machine with a few unique moving parts working together to help solve the oracle problem. The Tellor oracle smart contract is the “body” that all the parts plug-in to. The three main parts are:
- Autopay: a structure for incentivising reporters to submit specific data.
- Telliot: open source reporting software that connects to Tellor’s open database.
- The Data Feed, etherscan, and the Disputable Values Monitor: tools that anyone can use for viewing, checking, and (if necessary) disputing data in the Tellor Database.
Each of these parts will be the subject of separate Tellor Machine blog posts coming soon. We hope you enjoyed this one! If you’re interested in learning more in the meantime, check out our blog, follow us on Twitter, or join the Discord!
If you’re interested in using Tellor oracle data, we have a standard data request form here. Tellor can provide any type of data as long as you can tell our reporters where to find it.
Thanks for reading, and have a great day!
