# Overview of Blockchain Oracle Research
## 2 Literature Background  
The power of Bitcoin lies not only in its decentralized features but also in its programmability. Experts, such as [PERSON], address it as \"programmable money\" [26]. Just by using \"scripts\" and without the intervention of third parties, premade \"agreements\", such as timelocks, Pay-to-Script-Hash, and multi-signatures, can be executed on transactions [27]. However, because of [PERSON] and the introduction of the Ethereum virtual machine with smart contracts, blockchains became more developer-friendly and could be easily programmed for applications above the simple exchange of cryptocurrencies [5]. Nonetheless, the Ethereum blockchain needs to be a closed ecosystem operating on data that are already on the blockchain to reproduce Bitcoin's trustless and deterministic setting [5]. This condition is necessary to ensure that all the required data for smart contracts are publicly verifiable and auditable by all nodes [5; 28]. Without data coming from the external world, the range of possible automated contracts would have been extremely limited [29]. Therefore, a means to deliver extrinsic data to the blockchain was needed to broaden the use of smart contracts [3; 30; 31]. This method is called an oracle. The oracle is an entire ecosystem that permits the collection from and the transfer and insertion of external data to the decentralized application [32; 33]. As displayed in Figure 1, the oracle ecosystem usually comprises the following three parts. Data Source: This is the source from which the data are collected and stored. It may or may not eventually be used by a decentralized application. The data source can be a Web Application Programming Interface (API), a sensor, or a human aware of a specific knowledge or event [34]. Communication Channel: This is usually referred to as \"node\". It collects data from the data source and delivers them to a smart contract so that the latter can be executed. Sometimes, oracle nodes coincide with blockchain nodes, but this is not always the case [29; 35]. Smart Contract: This contains the code that establishes how the collected data can be managed. Usually, it has prespecified quality criteria for data to be accepted or rejected. If necessary, it may also perform computations to deliver the appropriate data to the contract [36; 37]. Figure 1: Oracle ecosystem. Depending on how these three parts are organized and interact with each other, multiple types of oracles can be designed [12]. These three parts of an oracle are not always separate from each other, as the same entity may sometimes cover two or three roles at once. A human, for example, can serve as a data source and communicate the data directly to a smart contract [38]. In actuality, having more than one entity that covers the role of data source/node is possible and desirable. Relying on multiple entities is, in fact, crucial to ensure the execution of smart contracts, especially when one or more data sources/nodes are malfunctioning or offline [39]. The above-described oracle ecosystem is typical of blockchains that support smart contracts (e.g., Ethereum and Tron). Instead, oracles are implemented differently for blockchains, such as Bitcoin, where smart contracts (apart from a few scripts) are unavailable. If smart contracts are unavailable, oracles are usually implemented through M-of-N (e.g., three out of five) multi-signature wallets, requiring more than one signature to broadcast a transaction [40]. Therefore, the owner of a key plays the role of an oracle and executes the transaction when a certain condition is met. In that case, the oracle covers both the role of the node and the data source--for example, an agreement that sets a payment upon the delivery of a parcel (Figure 2). A multi-signature wallet must be set up in which one of the keys has to be entrusted to a third party that performs the role of an oracle. When the buyer acquires the product, she signs the transaction with her key.