Distributed ledger oracles are third-party services that provide smart contracts with external information. They intend to prevent another possible cause of the garbage-in, garbage-out problem, i.e., when off-chain data from unverified sources or data providers become input to smart contracts, which could give rise to incorrect processing and related results, with potentially dangerous consequences for both the system and its users. An oracle for a given decentralized application intercepts data originating from one or more sources, possibly processing such data and then delivering them to the smart contract application along with an authenticity proof, a cryptographic guarantee proving the reliability of such data production and that no one tampered with it. Data collected by oracles can originate from databases or other online software sources of information and physical devices, such as electronic sensors, barcode readers, and robots; in some cases, humans can pass data as inputs to oracles directly.
An essential aspect of oracles is the trust model they implement concerning the multiplicity and heterogeneity of the data they feed a given decentralized system. The oracles needed by smart contracts and their relative trust models can indeed strongly influence the type and level of decentralization implemented at the core system level. Consider, for example, a blockchain system aimed at tracing and guaranteeing the quality of products for a specific production chain. Suppose each party that executes a part of the process independently certifies the quality of their sub-process or by-product through a dedicated and autonomously managed oracle. In that case, the resulting system maintains the degree of decentralization initially provided by the blockchain architecture. Things are pretty different if, on the contrary, a single company acting as a certifying body manages all the oracles used by the system. In the latter case, the system preserves decentralization only if the oracles themselves implement this model of trust.
The blockchain ecosystem currently already provides for both centralized and decentralized oracles. For the first ones, a single entity acting as a trusted third-party controls them, while the latter implement some form of DLT to increase the reliability of the information provided to smart contracts by not relying on a single source of truth. In order to preserve decentralization, it is clear that the former kind of oracles requires a smart contract that compares multiple sources and selects the data items to be taken into consideration by the majority.
Provable (https://provable.xyz, accessed on 15 October 2021) is an example of an attestation-as-a-service company that delivers the data a customer needs along with proof of their authenticity. Provable provides platform-agnostic oracles possibly integrated with centralized or decentralized systems at the customer side. Integration is currently achievable with the smart contracts of some major blockchain platforms, such as Ethereum, EOS, Hyperledger Fabric, and R3 Corda.
Some of the authenticity proofs provided by Provable are [52]:
- TLSNotary Proof; which relies on a feature of TLS 1.x protocols to enable the splitting of the TLS master key among three parties: the server, an auditee, and an auditor. Provable is the auditee in this scheme, while a locked-down instance of a specially designed, open-source virtual machine on Amazon Elastic Computing Cloud (https://aws.amazon.com/ec2, accessed 15 October 2021) acts as the auditor.
- Android Proof; which makes use of a software remote attestation technology developed by Google, called SafetyNet [53], to validate that a given Android application is running on a safe, non-rooted physical device connected to Provable’s infrastructure. It also remotely validates the application code hash, enabling authentication of the application running on the device.
- Ledger Proof; which leverages a trusted execution environment comprising an STMicroelectronics secure element, a controller, and BOLOS [54], an operating system developed for hardware wallets by Ledger (https://www.ledger.com/the-company, accessed 15 October 2021). BOLOS exposes a set of kernel-level cryptographic APIs, including attestation: any application can ask the kernel to measure its binary and produce a signed hash.
Provable’s authenticity proofs can be either delivered directly to a smart contract or uploaded and stored on some alternate storage medium, such as the interplanetary file system (IPFS) [55], a P2P file system that combines a distributed hashtable, an incentivized block exchange, and a self-certifying namespace so that its nodes do not need to trust each other.
ChainLink (https://chain.link/, accessed on 15 October 2021), on the other hand, is an example of a company that is revamping in a joint effort with academia, with the goal of approaching decentralized oracles. In the recently updated whitepaper [56] concerning ChainLink goal and architecture, the authors envision an increasingly expansive role for decentralized oracles thanks to a broader oracle notion and a new definition for the oracle network concept previously introduced in [57]. In this up-to-date design, an oracle is a general-purpose, bidirectional, and “compute-enabled” interface between on-chain and off-chain systems, while a decentralized oracle network (DON) is a set of oracles provided by third parties and maintained by a committee of Chainlink nodes through a consensus protocol. A DON supports a range of oracle functions chosen for deployment by the committee, acting as a blockchain abstraction layer and providing interfaces to off-chain resources for both smart contracts and other systems. Its goal is to enable a flexible and secure combination of on-chain and off-chain computations connected to external resources, resulting in the hybrid smart contract-oriented architecture sketched in Figure 7.
Figure 7. A hybrid smart contract consists of a smart contract component and an off-chain component that executes on a DON. The DON connects the two components and the hybrid contract with off-chain resources, such as web services, databases, other blockchains.
Ultimately, the ambition of the above design is to push the degree of abstraction achieved by Chainlink to the point of implementing a layer of meta contracts that abstract away the on-chain/off-chain distinction for all classes of developers and users, allowing the seamless creation and use of decentralized services.