The term “oracles” in cryptocurrency is not new but has become increasingly relevant as the decentralized finance (DeFi) space expands. To those who are unfamiliar, an oracle may bring to mind a prophet or messenger from ancient times. However, in the crypto world, an oracle is simply a messenger between real-world data and blockchains. Keep reading to learn about DeFi oracles.
An oracle in cryptocurrency terms is a service that provides real-world, off-chain data to be used by blockchain smart contracts. For example, if you were to build a betting app on Ethereum that utilized smart contracts as an escrow, Jake and Sally would deposit ETH into the contract and bet on specific parameters concerning the BTC/USD price over the span of one month.
If at the end of that month, Sally says the price will be above $10,000 while Jake says it’ll be below, they’ll lock ETH into this smart contract. Then, at the end of said month, the automatic dispersal of locked funds to the winner will occur.
Amazing! With blockchain technology, there’s no need to trust a third-party escrow bank to confirm that funds were distributed correctly. Even though this may seem like a small matter, getting rid of intermediaries in finance has monumental consequences for the freedom, accessibility, and privacy of products built on blockchain. One question remains–how does the smart contract know the value of BTC/USD?
The Ethereum blockchain does not store that information. It is instead referenced from a major crypto exchange, like Coinbase or Binance. These exchanges have APIs people can use to query the data- this process is called an “oracle.”
Smart contracts on Ethereum are cut off from any information or access to data not stored directly on the blockchain. This means that some types of smart contracts need an external provider, called an “oracle,” of off-chain data points in order for them to work correctly–and this is known as the “oracle problem.” decentralization.
Fortunately, people have come up with solutions for this issue by creating crypto assets that can interact with existing (“real”) world assets. Now Oracles enable the potential of allowing access use cases that would be otherwise impossible, thereby merging and expanding new crypto worlds possibilities beyond those found in our physical reality today.
DeFi oracle designs
Most oracles in use for DeFi can be classified as centralized, decentralized, distributed, delegated proof-of-stake (dPoS), or prediction markets.
The simplest form of oracle only entails one party who provides the data. This can be done by a third-party provider that you whitelist, or through the same protocol (by yourself). Generally speaking, centralized oracles are faster and more proficient than decentralized options.
However, this creates a decentralized smart contract infrastructure (the protocol) with a centralized key point of failure (the oracle). This means that you must place a lot of trust in the central party.
They could theoretically censor data whenever they want, or go out of business and shut down their servers, which would leave your smart contract without any data. In crypto-speak, we’d say that the oracle has no liveness guarantee.
Distributed Multi-Sig Oracle
This type of data handling is when a set number of parties are allowed to input the data on-chain. After that, the user can change or modify the data however they want (average it, take the median, etc…).
The main problem with this system is that there’s still a high level of centralization present. It works better than having one centralized party handle everything, but it’s just as easy to rig and manipulate. There are also limited guarantees that this process will even work correctly.
This system operates similarly to how a blockchain reaches consensus by using game theory and economic incentives. Decentralized oracles are more secure, but also slower and expensive. Part of the reason it is difficult to decentralize off-chain data usage onto a chain is because of the process required to do so–making it part of a gradual plan for decentralization.
Decentralization isn’t an all-or-nothing characteristic — rather, it’s a spectrum. This means that projects can start out with only partial decentralization and then transition to complete decentralization later on. In fact, many DeFi protocols wouldn’t be able to use a decentralized oracle without negatively impacting their product’s user experience — so they prefer to gradually move towards decentralization over time.
One argument against this approach is that once a project becomes established, it can be hard to break away from centralization unless it’s built into the design from the beginning. With existing incentives usually benefiting centralized models, breaking away from centralization often requires heroics (either financial or technological).
A variation of this oracle is to use a relaying mechanism, where multiple parties sign prices, and then one party (or a list of few parties) pushes the value on the chain. However, adding a relayer centralizes the entire design, making it more vulnerable to manipulation and decreasing the liveness guarantee gained in the original multi-sig oracle design.
This system has whitelisted staked nodes that can lose their stake if they provide bad data. Arguably, this is better than a multi-sig since there are economic incentives for the data providers to act correctly. Although, with this system, the parties have to be very attentive to the whitelist and how it operates.
They should also constantly monitor the security mechanism slashing as well as how new nodes get added to Whitelist Process can they un-whitelist everyone at will? As in any dPoS system, it is important to communicate between all of the nodes often so nobody falls out of sync and to prevent collusion among them.
Prediction Market Oracle
To put it simply, this is where users predict the right outcome by gambling on it. If we assume that 51% of people are honest and parties don’t want to lose money, then this system works just fine–and it’s decentralized.
This method has a higher chance of being accurate than a centralized oracle does, but unfortunately, there are many concerns (for example regulatory issues, speed, liquidity)that have made them impractical for most DeFi needs.
This is a system that uses game theory and economic incentives to reach consensus in a similar way to how blockchain reaches consensus. Decentralized oracles are slow and often quite expensive, but they can be very difficult (and therefore costly) to manipulate.
Consequently, they tend to provide a higher degree of a guarantee than other options. It can be tough to decentralize the process by which data from offline sources gets used online, which is why this approach is often part of plans for gradual decentralization.
By starting as only partially decentralized, we open the door to testing a wider range of ideas. In fact, many DeFi protocols would greatly reduce the user experience of their product if they used a decentralized oracle, so they prefer to slowly move towards decentralization over time.
The opposing idea is that once a project becomes established, it can be difficult to move away from centralization. There typically aren’t enough incentives to do so unless those incentives are designed and put into place from the beginning.
To put it plainly, DeFi is using two oracle structures that are only somewhat decentralized. Augur, Gnosis, Band, and DIA are a few examples of other old and new projects not mentioned above that use oracles– but when including only the ones with some level of volume in the market, the aforementioned list is all-inclusive.
The community will gradually become more knowledgeable about the importance of oracles as well as their designs and how they pertain to security measures for funds kept within these systems. Consequently, DeFI will slowly start transitioning towards solutions that are entirely secure and decentralized.