On-chain Oracles

Definition

With the rise of DeFi apps, the need to get trusted pricing data has grown substantially. The only issue is that a Tezos smart contract cannot, by default, receive any data from outside the blockchain. Oracles, therefore, offer a way to obtain data from off-chain sources and to make it available on-chain.

FIGURE 1: Illustration of an oracle providing online data to a smart contract.

How it works

An oracle is made of multiple pieces of software, both on-chain, and off-chain.

FIGURE 2: Data flow of an oracle request. In blue are on-chain entities and in purple are off-chain entities.

When in need of off-chain data, your smart contract will call the oracle smart contract with an API URL to be fetched. The oracle smart contract will emit an event that can be detected by an off-chain architecture connected to a blockchain node. Typically an oracle node will pick up such event and process it to create a web service request. For simple HTTP API requests, the oracle node can fetch the data itself. But, for more complex tasks or requests, an adapter might be needed. An adapter is simply software running on a server capable of executing complex tasks. Oracle nodes have a set of pre-determined available operations, e.g. fetch an API, parse a string, generate a random number, etc. Anything out of these simple operations will require a developer to code an adapter, tailored, to the specific needs. In this case, the adapter will fetch the external API, make operations on it, and then send back the data in serialized format (typically in JSON) to the oracle node. As the oracle node is connected to a blockchain node, it can send data to the oracle smart contract. The user smart contract can then retrieve the data from the oracle smart contract.

Fig. 2 represents the complete data flow. To learn more, you can check out this white paper. Note that this is one way to implement oracles, there are multiple other ways with different features [5].

Aggregators

Oracles can aggregate data from multiple sources to guarantee the quality of the data. For instance, consider a decentralized application (Dapp) that needs the exchange rate of XTZ/BTC to perform a trading operation. The smart contract has to contact an oracle that can provide such information to get the exchange rate. The oracle can, for instance, fetch the exchange rate from Binance and offer it, as is to the smart contract. However, if Binance gets hacked, the Dapp would be compromised as well. To prevent this, an oracle can fetch price information from multiple sources. e.g. Binance, CoinMarketCap, Dexter and Quipuswap, then compute the median and exclude outliers (prices that are too far from the others are likely from a compromised source). The chances that all four sources are compromised at the same time become increasingly improbable. The price provided to the Dapp is therefore very trustworthy and can be used for financially critical operations. Notice also that price feeds can be signed in order to guarantee the source of the data.

FIGURE 3: Illustration of an oracle filtering outliers.

Note that oracles are not limited to fetching price data. Any online API can be called on by an Oracle, e.g. payment data (Paypal, VISA), bank data, air traffic schedules, IoT data, weather forecasts, etc. Some applications even provide on-chain insurances, based entirely on real-world data fetched by oracles.