As decentralized finance grows we’ve seen an explosion in the number of companies that use smart contracts in their business models. Business logic that is deployed on top of a blockchain now governs an increasing number of assets and transactions. Some of that logic, however, depends on receiving information from off-chain sources, such as share and commodities prices. But how can we know if this data is reliable? To have a useful blockchain-based application, this app has to use an oracle to collect external data.
A bit of background
When Satoshi Nakamoto invented blockchain technology, he solved a fundamentally difficult problem. His design ensured information validity between multiple parties that don’t trust each other and don’t communicate over secure channels.
The way that Bitcoin and other subsequent blockchains solved this problem was through the use of public key cryptography when constructing transactions. The user that sends a transaction defines the conditions for accessing the money transferred in the OPCODES that construct the transaction. If one can display the possession of the right key they have a legitimate claim to the funds that are locked with that key. This removes the need for trust as any member of the network can verify the legitimacy of any transaction that has taken place.
A blockchain starts from a genesis block. Each block includes chronologically advancing transactions which can be traced down all the way to the genesis block. This creates a source of trust for the validity of the transactions that are included on the blockchain.
This means that when it comes to transactions a blockchain is a closed system, where the information is structured and verifiable. We can be reasonably certain that the transactions that are included in the blocks are secure as the security is dependent on the consensus mechanism itself. However, it is possible to include external information on transactions as well. This means that whereas a transaction itself may be valid it may store information that is not.
Already since block 0
Recording external information on a blockchain is nothing new however. The following message was recorded in the genesis block of Bitcoin:
“The Times 03/Jan/2009 Chansellor on brink of second bailout for banks.”
As we are able to write logic such as executable code to the blockchain it’s possible to make conditional actions based on this type of arbitrary data. This, however, brings a need to be certain of the validity of the information that is being included in the transaction.
So let’s evaluate the case in point. In order to verify that the article really exists anyone can go to the archives in their nearest library and verify that the article actually has been included in the published issue. Whereas we can be quite certain that our own sensory experiences allow us to accurately measure if the article was really printed in Time Magazine, let’s consider a different scenario for a second.
What if we had to send another person to the library to check out the same information could we be certain of its validity? What if we sent the same person a hundred times over the course of a year to check the if a selection of other articles that were included in different blocks existed. The person we sent could make an honest mistake and miss the article that we asked for, or in a worse case perhaps they could be bribed by our competitors who also happen to run the same lucrative business of checking newspaper articles included in blockchain transactions. This is what is at the heart of the oracle problem: verifying the validity of arbitrary data that is communicated through untrusted channels.
How is this relevant in the ‘real world’?
We can also look at a more realistic scenario through an example that we have seen on multiple occasions in decentralized finance. Imagine a binary options contract on the price of bitcoin reaching 10,000 USD on Binance by the end of the week. For the sake of argument, we can imagine that the contract is deployed in ethereum and it pays out 2:1. This means that if a user wants to take the contract they will transfer some ether to the option’s smart contract address. The contract then records the address of the sender and at the end of the week, the user can call the contract to determine if they won the bet or not. If the price is higher than or equal to 10,000 USD on Binance the contract pays out twice of what the user sent to it.
In this case, we have two sources of information, one that is verifiable through the Ethereum protocol and one that is not. The information that is verifiable by the protocol can be, for example, who is the rightful owner of the options contract. This can be verified by anyone as Ethereum supports this in its protocol through the way that transactions are constructed with public key cryptography. Because of this, every member of the Ethereum network can verify if claims to the option’s reward are legitimate or not — only the account that can prove possession of the same account that sent the initial funds to the contract may claim the reward. But what about the price information of Bitcoin on Binance — how can a node in the Ethereum network be sure that the information regarding the price of bitcoin is correct?
Making sure that the contract receives correct information is vital as it has direct financial consequences to the user that took the option. How this can be done is quite a challenging task, however. There are different aspects to consider: how is the data proven to be accurate and not tampered with? Should the oracle that passes the data be centralized or decentralized? What kind of data sources can be used? If a blockchain is deterministic, how can random data be created?
All these questions boil down to the fundamental problem with blockchains and oracles. How to ensure that a valid transaction does not include information that is structurally correct, but informationally untrue.
In the next post we will take a look at one of the most important architectural considerations when building an oracle: decentralization versus centralization. Stay tuned and hope to see you next time!