Article Preview
TopIntroduction
Oracles in blockchain (Wang et al., 2019) function by serving as a bridge between the trusted world of blockchain and the untrusted world outside the blockchain. Although distributed ledger technologies are able to leverage their trust-free architecture to securely process transactions, a major roadblock to their widespread usage is the lack of mechanisms to securely verify and incorporate data that exists outside the blockchain. The inclusion of an oracle helps to bridge this gap between the blockchain and data sources around it. By fetching data from an external source, oracles help to trigger smart contracts that link together the trusted blockchain environment and the untrusted external data source (Wohrer & Zdun, 2018). For example, in a hedging model, nodes in a blockchain (trusted environment) might be dependent on weather data from an external website (untrusted environment) in order to predict future prices for an agricultural commodity. This information cannot be verified using the blockchain’s inbuilt architecture for distributed consensus. As a trusted entity, the oracle fetches this information and supplies it to the nodes, thereby triggering a smart contract.
The implicit assumption in existing literature about blockchain oracles is that of an altruistic oracle. This assumption of an altruistic oracle provides for a high degree of trust placed by the blockchain nodes in the oracle’s services. However, this assumption of an altruistic oracle may be challenged by factors such as computational complexity of the oracle’s tasks and its impact on oracle performance. An oracle that is required to perform computationally intensive tasks to retrieve data from multiple untrusted environments, aggregate and process it for the blockchain is limited by its own computational capacity, the size of the blockchain network that it serves, the quantity of such requests and inter-oracle communication and computation responsibilities. Thus, oracles that are subject to a high volume of computational processing may suffer from degradation in performance in terms of latency, throughput or data accuracy. Additionally, since oracles serve as intermediaries between trusted and untrusted environments, they serve to function as a unique point of failure in the trust model espoused by blockchain environments. An oracle that is manipulated by malware can compromise the integrity of the smart contracts and jeopardize the applications involving such blockchain environments. Such outcomes can then impact the level of trust placed in the oracle by the blockchain and revert the blockchain back to the original state, where the blockchain only trusts data in the ledger and is thus unable to function in hybrid environments that require smart contracts.
Our work studies trust in the institution of the oracle. Specifically, our work seeks to answer the question: How trustworthy is the oracle, and can we use peer evaluations of the oracle’s trustworthiness to assess trust placed by a node in the oracle? To do this, we commoditize trust as a tradeable unit with distinct supply and demand functions. Oracles may demonstrate selfish or fair behavior, where selfish behavior behooves the oracle to conserve its own resources and offer subpar service to the nodes. Similarly, a fair oracle is able to serve the requests of the nodes, even at the expense of consumption of its own resources. One reason for an oracle to demonstrate selfish behavior is the amount of work requested of the oracle. The oracle’s selfishness is dictated by the number of requests it serves. The role of the oracle’s selfishness sets the tone for the number of nodes it can serve. We explore how incentives added to the nodes’ trust valuations can influence the number of nodes that can be served by selfish (fair) oracles.