October 14, 2018
In ancient Greek mythology, oracles were known as spiritual beings & sources of infinite wisdom & knowledge due to their connection communication with the gods on Mount Olympus (the spiritual world). The most well-known is the Oracle at Delphi — popularized by the now-revered classic, Oedipus Rex. These oracles often provided information to protagonists & travelers when consulting for critical decisions.
Blockchains, much like the mortals depicted in these greco-roman classics, by design, do not have a way to readily access information outside of the chain — they cannot access data outside their network.
Oracles aim to allow blockchain contracts to interact with the outside world.
Every transaction since the origin block is recorded on the blockchain; every transaction is inherently linked. Since every transaction is in many ways a reflection of all of the previous transactions, it can be said that every new transaction is in fact, determined by the previous transaction. A blockchain is deterministic.This deterministic property leads to immutability, one of the very best features of a blockchain; however, the tradeoff becomes a reduction in flexibility with new data points…
99.9999% of events in the real world, however, are not sequentially-recorded; all the unrecorded data points without the slightest inkling of measured determinism make up a non-deterministic environment. While not immutable, since literally anybody or any thing (IoT) can create completely new data points, the infinite flexibility of off-chain activity makes it difficult to sync up with a blockchain. The data that stems from the usual API fetching requests developers are so used to simply isn’t compatible with a blockchain. Let’s re-frame this in terms of Ethereum:
How can smart contracts execute based on real-world conditions, such as price changes, game outcomes, or physical properties if the Ethereum blockchain has no way of directly accessing these data points through popular 3rd-party APIs?
An oracle, in blockchain world, is an one-way digital agent that finds & verifies real-world data & cryptographically submits this information to the querying smart contract. An oracle is not the datasource itself but the layer that interfaces with data-sources & the blockchain; it’s a translator for information provided by a 3rd-party API that’s to be added to a blockchain. With oracles, smart contracts have a pathway to interacting with data outside of the immediate blockchain environment.
Oracles are categorized by two main factors: type & direction. An oracle can take on the form of either software & hardware. Through one of these mediums, the oracle can either bring data inside the blockchain (inbound) or inform an entity outside of the blockchain about a specific event (outbound).
Software oracles, as you can imagine, are meant to handle all information currently available on the free web. Oracles directly interact with data feeds such as APIs, scrappers & web hooks to extract, verify, & push this data to smart contracts on a number of blockchains. Examples of data that’ll eventually be oracle-ized are vast in range stemming all industries from music concert ticket sales, to the price of collectibles, to campaign donations to previous real estate transactions.
On the other hand, a hardware article directly interacts with the physical world — ideally inputting that data before it hits the rest of the internet. What kind of hardware oracles will prove value-adding? The largest planned use case so far is barcode reading & RFID sensing within an operations & logistics framework. An interesting use case comes in the form of environmental data transcribed at the point of measuring. This way ,scientific research can progress globally without giving power to any one, single, government institution to alter or delete said data.
Inbound oracles will provide smart contracts with data from the external world when called. An example use case is automated Ether sell orders based on the current price. Another example is gambling-dapp payout based on a real-world event. The use cases for inbound oracles is near-infinite.
On the other hand, an outbound oracle (certainly rarer) uses internal blockchain data to trigger an external event. Say, for example, if a smart locker is awaiting a set amount of Ether at a smart contract address. Or if an external lottery payout is based on the last block published.
Oracles are still a fairly new development in the blockchain ecosystem. Not too many teams are pushing the engineering further along despite the very real growing need of 3rd-party data sources to Etheruem (and other blockchains) smart contracts. Fortunately, a few market leaders are quickly rising to the top, most notable is Oracle-focused startup Oraclize.it. If you’re interested in peeking at a few sample oracles such as a Wolfram Alpha or Kraken Cryptocurrency Price Tracker, just click on links!
Smart contracts live like in a walled garden,
they cannot fetch external data on their own.
Oraclize is here to help. We act as a data carrier,
a reliable connection between Web APIs and your Dapp. — Oraclize.IT
In order to build robust smart contracts & dapps capable of dealing with complex & changing datapoints, the blockchain community has no option but to figure out how to interface within a blockchain to exterior data points. Apps usually ask for these data points from databases or APIs through a process called querying.
Blockchains, due to their deterministic properties, need a special way to query data from the outside world & import it in a blockchain format. Oracles have the single purpose of filling this role as an interface between the blockchain world & the outside world — with oracles, blockchain developers will one day be able to import & act on real-time data that’s currently not possible.