Blockchain technology is heading towards a new wave of technological change that will turn around the way we do things – how we manage our money, how we monitor goods in transit, how we record asset ownership, and more.
Oracles are third-party services that enable smart contracts within blockchains to get external information from outside of their ecosystem. They serve as a data source that can be fed into a smart contract, which allows them to access real-time data that isn’t stored on the blockchain – usually the real-time price of assets. Although they aren’t data sources themselves, they are layers that check on-chain data linked to real-world events and then send the gathered data to smart contracts.
What are the Types of Oracles?
Oracles are labeled based on the source of information, the direction of the data, and the degree of trust. The source of information can either be hardware or software, while the direction of data can be either inbound or outbound. Inbound oracles enable the network to send data from external information sources to smart contracts, while outbound oracles allow smart contracts to send data to external sources.
Centralized oracles operate as a single entity offering data from an external source to a smart contract functioning with a set of security features. However, this type of oracle is less secure and more prone to be corrupted and attacked because it only has one responsible node.
On the other hand, decentralized oracles depend on multiple external sources to enhance the credibility of the information provided to the smart contracts.
What are the Risks of Using Oracles in DeFi?
The oracle issue and latency are the major risks of operating oracles on a blockchain. These arise because of a trust conflict that centralized third-party systems bring to smart contracts and blockchain networks that are decentralized.
Oracle solutions can be split into two categories: fast but insecure and secure but slow. The first category usually applies to decentralized oracles, as they have low waiting time rates. Because of a flaw in numerous game theory attacks, most DeFi applications operate on centralized or semi-centralized oracles.
The majority of decentralized oracles use a mechanism wherein independent sources report the information without matching with other sources. Because of the absence of this contact, these sources or agents report ‘true’ data to the best of their abilities while anticipating other sources to do the same. However, this system is vulnerable to various issues, such as collusion between parties, signaling, and bribing.
Centralized oracles are categorized as ‘secure but slow.’ When put against decentralized oracles, the centralized ones are steady with aspects of game theory. They use manual voting and ‘dispute rounds’ to prevent attacks that try to manipulate their data. However, because these techniques involve longer latency, sometimes even weeks, DeFi applications are usually advised against using them as their oracle of choice.
Still, in spite of their protection against game theory attacks, they have counter-party risks and possess a higher chance of efficient hacks because of a single point of failure, reducing the security of DeFi applications in this particular aspect.
How do DeFi Applications Subdue Oracle Limitations?
Tight security based on game theory in disputes can provide feasible solutions to the oracle issue. Blockchain oracles are vulnerable to attacks from hackers that want to take advantage of the pricing irregularities by targeting oracles.
Oracles are prone to be attacked like this because they are, in theory, outside the consensus mechanism of the blockchain, and therefore, the security systems of the blockchain cannot protect them.
There are numerous platforms driving the domain of oracle development. There are also lots of open lending or borrowing protocols that use oracles to bring up data while operating on various blockchains.