Blockchains form consensus when all the nodes agree on the data they process. This depends on the condition that the computation at each node should be deterministic. That means each node should arrive at the same output, for a particular set of inputs, no matter what hardware they are using.
The deterministic nature of blockchain logic ensures strong consensus. For this reason, blockchains work on the data that is already on the chain or supplied by the transactions from the users as input. By design, blockchain don’t depend on external data sources when executing transaction logic.
However, in several use cases, external data is needed to be supplied to smart contracts to execute the end to end logic. Let’s take an example. Let’s say we have an insurance use-case implemented using smart contracts on a blockchain. The insurance amount is held in the smart contract as an escrow, and it would be paid to the user/customer only when certain conditions are met. The data about these conditions and their status is in an off-chain database. How would the smart contract know if the condition is met?
This is where oracles come in. An oracle is a service that provides external data to the blockchains. Using oracles blockchains can query data from external services or databases for consuming in the on chain logic. In the example I shared about, if an oracle is used, it would provide the data about the insurance payout conditions to the smart contract, and based on that the amount would transferred to the recipient.
Oracles generally work in an asynchronous manner. That means they are not directly called by the smart contract just like any other code. Instead, oracles are configured to listen to specific events from the smart contracts. When the smart contracts need data from the off-chain databases, they emit certain events and the oracle is triggered to fetch the data. Once the oracle gets that data from the data source, it then submits it to the smart contract as a transaction input.