Oracles
A core tenant of the design of a Blockchain, is that the Smart Contract logic is deterministic. That is, it can be executed multiple times, at any point in the future, and the result will be the same. In an Ethereum based Blockchain this requirement is enforced by having the guardrails of a purpose built execution environment, called the Ethereum Virtual Machine (EVM).
Every node in the Blockchain network independently executes the transaction to confirm the outcome is the same.
The execution can emit the events that we discussed in the previous section. But it cannot make requests to external systems, such as a Database, or an external REST / SOAP call to the internet or a private core system.
This appears problematic when the on-chain business logic needs to act differently depending on the current state of another system. For example, if an on-chain Smart Contract needs to validate the state of an Order/Invoice in an external CRM system, the current price of a Commodity, or sensor readings from an IoT network.
The solution is to bring the data on-chain using an Oracle.
There Are Two Categories of Oracle
Push Model / Curated Oracles
A source of truth off-chain is specified/configured to push data on-chain at regular intervals. This allows on-chain logic to query the most recent copy of the state, and relies upon the reliability of the off-chain oracle service. The Oracle might be built bespoke to the private network, or use an established hosted Oracle solution like Rhombus.
A connector could also listen for state changes in an external system, and stream those changes into the chain, providing a more targeted stream of data than a regular polling approach.
Pull Model / Configurable Oracles
The logic on-chain is broken down into multiple transactions. One transaction emits an event that requests an Oracle (or even multiple decentralized Oracles) to perform an action, such as a make a REST call to a core system. The Oracle then submits the data back on-chain, and triggers the next transaction in the sequence that requires that data.
This event-driven approach allows on-chain logic to integrate data from core systems, or the internet, on-demand. The request can be customized with parameters, to pull specific information on-chain. Chainlink provides a well established set of Solidity code libraries, as well as a highly configurable job specification language, to orchestrate off-chain actions in response to on-chain logic.