The Problem with "The Problem with Oracles"

Many of the innovative proposals for blockchain technology reach their potential by leveraging what is commonly called a “smart contract”, a programmable contract which can be executed and enforced automatically on a distributed ledger. Using a ledger simply as a record of ownership does not capture the full potential of distributed ledgers; in their most useful incarnation, this software can automate transactions with programmable ownership. A ledger can only achieve sophisticated transaction logic and automation through smart contracts, which can create robust conditions for execution specific to certain actors. 

Smart contracts have generally been discussed in the context of decentralized systems such as Bitcoin or Ethereum. These decentralized systems deal with anonymous parties and, thus, take great care in minimizing the amount of trust which must be extended to any given party. Typically, confidence is achieved by introducing a set of financial incentives (e.g., fees paid to miners in the Bitcoin network). Simple smart contracts, which execute upon references to internal ledger data (e.g., multi signature schemes), thrive in decentralized systems. Once a smart contract is written to interact with external data, whether it's a weather report or the LIBOR rate, an "oracle", or external data feed, must be introduced. In decentralized systems, oracles break the property that the actors do not have to trust third parties to operate. 

Once the integrity of a transaction is exposed to a third party, it creates significant vulnerabilities. There have been a number of proposals to solve this, such as the Schelling point mitigation proposed by Vitalik Buterin whereby validators of an oracle-based transaction are given financial incentives to come to popular agreement. Yet even sophisticated counters to corrupt oracle attacks can be belied by simplistic acts of collusion. That said, it's important to remember that the nature of these issues are highly localized to the actors in a transaction. The integrity of a ledger is not compromised by the introduction of an oracle. 

Smart contracts have also been proposed in the context of private distributed ledger applications within capital markets. With less tech savvy audiences, conversations about these applications sometimes come to a halt at the mention of oracles. One popular conjecture is that the possibility of a bad or inaccurate oracle would cause irrevocable damage, rendering smart contracts unsuitable in a financial markets application. This concern reflects a superficial understanding of smart contracts, trust, and the nature of existing systems. 

Within "permissioned" or known-participant systems, issues such as fraud and malicious attacks become much easier to police. Both parties to an agreement would agree upon the integrity of an oracle, which we imagine to be from a reputable institution such as Bloomberg or Reuters in a capital markets context, with an understanding that mass fraud would be easily detectable and swiftly punished by the law. Smart contracts cannot mitigate the collusion of major financial actors (see also: the latest LIBOR scandal), but to conflate the risk of introducing oracles in decentralized systems with oracles in permissioned systems is to fundamentally misunderstand their purpose. 

There have been many estimates about the potential cost savings from "blockchain" and/or distributed ledger technology in capital markets. Many of these figures are driven by the assumption that ledger integration will automate or obviate the need for many back office processes. At present, the use of smart contract-enabled distributed ledgers are the best way to introduce this automation, making them an attractive area of focus for financial institutions.