Bitcoin popularized the decentralization paradigm with the concept of programmable money. The bitcoin (cryptocurrency) transfers are transparent and occur in a peer-to-peer fashion without requiring any intermediaries. Further, Vitalik explored the technology behind- blockchain and unleashed its true potential by showing how programmability can be incorporated into it using smart contracts. A technology once considered a digital currency is now researched worldwide, and many potential use cases related to various domains not confined to the financial sector, have been developed.
Smart contracts were the ones which helped widen the application domain. But smart contracts have severe challenges and boundaries, unlike other programming languages.
How does blockchain work?
A blockchain network is a decentralized network of participants. Each participant will have an immutable ledger for recording the transactions. Every transaction within the ecosystem will be received and verified by all the participants in that system. The blockchain will have a well-defined consensus mechanism- a rule for deciding which transactions should be recorded in the ledger. Based on the consensus, verified transactions are added to the ledger. The essence of decentralization lies in the consensus mechanism, which ensures an unbiased decision verifying the transaction and ledger updates.
There comes our first challenge. A blockchain can verify the transactions only if it has the background data for verification. For example, if a cryptocurrency transaction needs to be verified, it should have the earlier balance of the sender and recipient of that transaction. This is possible in the case of token transfers since all the transfers occur only via blockchain, and smart contracts can access these. But what about the transactions in a supply chain? How will blockchain verify a transaction that needs to record a fact like“ Vehicle A has reached the location ABC with X kg of mangoes”?
Blockchain creates a restricted system environment which is separated from the real world. Smart contracts are programs running on a blockchain which can only passively receive the data into the chain but cannot actively obtain the data out of the chain. A large number of blockchain use cases are based on retrieving and storing real-time data: like location, temperature, price, quantity, quality etc. For this, we need specific services which can feed real-time data onto the smart contracts. They are termed Oracles.
Oracle
Wikipedia defines an oracle as a person or thing that provides wise and insightful counsel or prophetic predictions. The word is believed to be related to Greek culture, referring to divine revelations given by priests or equivalent persons as a response to an inquiry.
A blockchain oracle is defined as an external data agent that observes real-world events and reports them back to the blockchain to be used by smart contracts[3]. Oracle comprises an entire system that collects off-chain data, verifies it and transmits it to smart contracts on the blockchain. An oracle may consist of three elements, as shown in below figure.
The data source can be a sensor (measuring temperature, humidity etc.), a Web Application Programming Interface (which provides access to data recorded in other off-chain applications like stock markets, crypto-exchanges), manual data entry, etc. They are considered trusted data sources. The oracle nodes (service) collect data from the data source, certify accuracy, and convey reliable data to the smart contract. It can be a node, a group of nodes or any trusted environment. A smart contract in the blockchain will have a code that governs the processing based on input data.
These three parts may not exist separately from each other. Oracles are classified based on these entities’ organizations and their tasks.
Types of Oracles
Oracles are classified based on various properties[3].
- Data Source: Depending on the external data source, oracles can be classified into hardware, software, and human. Hardware oracles use specific devices like sensors and scanners to gather data. Software oracles use programmed interfaces to collect data like schedules, price data and exchange rates. Human oracles refer to the manual entry of data.
- Trust Model: The number of nodes in the oracle network defines the trust model of an oracle. A centralized oracle may be depending on a single source, whereas a decentralized oracle gathers data from multiple sources and reaches a decision based on a consensus mechanism. Provable and Town crier are centralized oracles. Chainlink is a decentralized oracle which acquired Town Crier.
- Design Pattern: Oracles can be designed in a request-reply setup, where the smart contract initiates a request serviced by an off-chain element. In a publish-subscribe design pattern, an oracle keeps track of fluctuating data like market prices, temperature etc. Updated data will be broadcasted to its subscribers. The immediate-read pattern is helpful in quick response scenarios like academic certificates or dial codes.
- Interactions with external data sources: Interactions can be classified as inbound or outbound. Inbound oracles feed data from external sources to the blockchain (eg reading input data from a sensor and storing it in the blockchain). In contrast, outbound oracles allow smart contracts to deliver data to the external world (eg sending a notification once a blockchain payment is received).
The Oracle Problem
As mentioned before, the consensus mechanism is responsible for the trustless data on the blockchain, which confirms their reliability. At the same time, Oracles skip the consensus mechanism and provide external data to the blockchain without any standard verification. This license gives oracles the privilege to insert arbitrary data on the blockchain.
Since oracles operate separately from the blockchain, they do not guarantee the decentralization, immutability and transparency of the blockchain environment. If any trusted third party is providing the oracle service, it raises some serious questions like
- Can that third party be trusted?
- What if the data provided is incorrect?
- What if the data was recorded correctly but edited by attackers?
- Won’t that be a single point of failure?
The Oracle problem puts forward these concerns that question the inclusion of oracles which make blockchain adoption risky for specific real-world scenarios. Thus the centralization of oracles raises the Oracle Problem which brings the puzzle between efficiency and decentralization when oracles fetch real-world events data from external data sources [3].
So if a smart contract-based application uses oracles to access external data, proper audit measures should be incorporated to ensure security. If the external data source is not trustworthy, it will affect the credibility of the entire smart contract, which works based on that data and even questions the role of blockchain.
References
[1] Lin, SY., Zhang, L., Li, J. et al. A survey of application research based on blockchain smart contracts. Wireless Netw 28, 635–690 (2022). https://doi.org/10.1007/s11276-021-02874-x
[2] Caldarelli, G. Overview of Blockchain Oracle Research. Future Internet 2022, 14, 175. https://doi.org/10.3390/fi14060175.
[3]H. Al-Breiki, M. H. U. Rehman, K. Salah and D. Svetinovic, “Trustworthy Blockchain Oracles: Review, Comparison, and Open Research Challenges,” in IEEE Access, vol. 8, pp. 85675–85685, 2020, doi:10.1109/ACCESS.2020.2992698.
[4]https://ethereum.org/en/developers/docs/oracles/
Image Courtesy: Flaticon
(By Sumi Maria Abraham, Research and Development Engineer, Kerala Blockchain Academy)
All Comments