Smart Contracts and Fake News: Insights from Blockchain Presence
Smart contracts, deployed on distributed ledger systems such as the Ethereum network, get their traction mainly from being able to condition their behavior on informational input that comes from sources external to the network. While blockchain oracles that feed such information into smart contracts seek to establish the authenticity of their data, any such authenticity proof is generally of little value―unless (i) the oracle has a decentralized governance, and (ii) the smart contract itself is able to verify that authenticity.
Oracles are software systems that are not fully integrated into the trusted blockchain environment. There are various forms of oracles based on different use cases. In this blog entry, I focus on so-called inbound oracles, for which the problem of trust is most self-evident.
Inbound oracles
In principle, inbound oracles may deliver data of any type, for example about the weather or regarding financial market developments. Presently, however, most users of blockchain oracles query either random numbers or exchange rates, such as between the US dollar and the legacy cryptocurrencies Bitcoin and Ether.
The smart contract that conditions on the data could be one where for example a balance in the cryptocurrency Ether is released once the temperature reported by the oracle falls below a certain value. Or a smart contract could be triggered to buy an amount of a particular stablecoin provided that the exchange rate between the US dollar and Ether crosses a certain threshold level. An obvious challenge with inbound oracles is that they need to be trusted sources of information.
Governance of blockchain oracles
Common blockchain terminology does not distinguish between smart contract oracles and their providers. However, to understand what matters for the choice of a truly reliable oracle, it is crucial to make this distinction.
While a smart contract is entirely governed by the trusted blockchain environment, this is not the case for a blockchain oracle. To the contrary, an oracle is always governed to some extent by its provider. Therefore, the trustworthiness of the oracle is inherently interlinked with the reputation of its provider. The latter, however, is difficult to ascertain given the short-term planning horizon typical in the blockchain world. For this reason, providers have an intrinsic interest to look as detached from the operational part of their oracle as possible. One way to convey this impression to market participants is it to refer to the concept of an authenticity proof.
In a recent post, Chainlink’s remarkably active marketing unit describes a verification method for its random numbers generator that attempts precisely this. In fact, I wonder if the claimed verifiability is even impossible at the theoretical level, because…how could you prove that a random number that I deliver to you was manipulated? This is like tossing a coin in secrecy, noting the outcome on a piece of paper, and sending the note in a sealed envelope to the smart contract. The contract (i.e., you) can never check if I noted the true outcome or faked it in my own interest. Having the envelope sealed twice obviously wouldn’t help either.
Off-chain authentication
Also for other use cases, providers of blockchain oracles tend to offer some way to establish the authenticity of their data. Provable, for instance, allows developers to request authentication via TLSNotary against a fee, which is essentially the https protocol used for accessing websites in a secure way. For example, this protocol is what you would automatically use when you do online banking.
However, checking if the protocol was actually applied to the transmitted information is not feasible for the smart contract. This can only be done ex-post, when the contract has already received and processed the informational input. Given that the smart contract transaction creates an immutable consensus on the blockchain, there is no way for a contract party to make use of this authenticity proof. Unless someone intends to go to court, of course, but this is just what smart contracts are supposed to render superfluous. The situation amounts to the absurd scenario outlined in the movie “The Live of David Gale” in which relieving evidence is brought to the court after the death sentence has been executed. Chainlink works with trusted execution environments (TEE), a hardware analogue of a secured internet protocol, but ultimately this approach has the same problem.
On-chain authentication
From the discussion above, it should be clear that any proof of authenticity, and likewise any claim of not being able to tamper with the data via a trusted hardware environment, ultimately remains a fig leaf if the governance of the oracles is not decentralized or the smart contract cannot verify this on the go. The way to resolve these problems entails devising a decentralized protocol by which the smart contract conducts the on-chain verification without the involvement of the oracle provider.
Blockchain Presence (BCP), a start-up initiative at the University of Zurich, has conceptualized and implemented this type of on-chain authentication for smart contracts over the course of the year 2019. A test version of the BCP Smart Contract has been implemented and deployed on the Ropsten network in May 2020.
Feedback to the Blockchain Presence team: If you have any suggestions or comments, we would greatly appreciate your feedback, as we are very open to ideas for improvement.
Email: info@blockchainpresence.net
Visit our website or follow us on Twitter and LinkedIn for more information!
