Smart Contracts and the Oracle Problem – explained by means of Real Estate Deals
Smart contracts or distributed contracts were created out of the desire to automate and to solve the trust issues related to contracts. But what exactly is a contract anyway? Speaking from an abstract point of view, a contract is an agreement between at least two parties, that have to commit to the agreement. If one of the parties is in breach of the contract, there are external instances that audit the procedure and state as well as execute consequences in case.
Smart Contract explained with Real Estate Deals
A practical example for a contract is a real estate deal: the seller and buyer agree to a contract of sale. The buyer will be stated as the new owner in the land register, as soon as the price and the transfer tax are paid. Since a notary is involved and certain laws must be considered, the seller cannot for instance sell the property to several buyers (double spending problem). Neither can the buyer be stated as the new owner without paying first. In this simple example we already have to deal with several involved parties additional to the buyer and seller:
- the notary
- the land register
- the tax office
and in the case of law suits we have to include and trust the jurisdiction as well.
Smart Contracts and the Oracle
Now, to process a contract successfully, we have to trust several external parties – the so called oracles. Smart contracts reflect the desire to simplify this process and to eliminate the centralized external parties all together (trustless):
- execution and enforcement of contracts become impartial and are executed automatically in the system
- no centralized external parties, especially not the jurisdiction are involved
Therefore, the user of the smart contract does not have to trust anyone – besides the programmer of the smart contract itself, who hopefully managed to consider every special case in her code. In fact, the ‘smart’ part of the smart contract is actually not related to the contract itself, but rather to the ‘smart’ programmer, who translated all the rules, terms and edge cases of the contract deterministically into a programming code. So when you think about it, the utilization of a smart contract is nothing more than a shift of the trust to different instances. In a smart contract, the programming code is the irrevocable, non negotiable law.
What role does the Blockchain Platform play?
Before we come to the matter of the oracle, a few words about blockchain platforms. You also have to trust the people or institutions who run the blockchain platform when executing a smart contract. Here the word decentralization is always a selling point. But decentralization is a very hard concept:
- the data has to exist on every node and therefore the whole network has to be synchronized (scaling problem)
- the program, which is the smart contract, decides which data is written out into this database (blockchain)
Here we distinguish the following:
- strict decentralization: no single organisation, instance or group of people is able to influence the blockchain substantially. A 50% attack can be ruled out for the foreseeable future. An example for this is Bitcoin.
- weak decentralization (or simply inefficiently distributed systems). Here single organizations, instances or a group of persons are able to control the blockchain substantially. Or a hostile 50 % attack cannot be ruled out for the foreseeable future.
We conclude, that with a strictly decentralized blockchain you trust the whole community and the node infrastructure, like for instance with Bitcoin. However you immediately face the difficulty, that the source code of the smart contract has to be 100 % bug free when it is published, since bugs cannot be fixed afterwards in a simple way. In the best case, the iterations of the program are very slow. As an investor you therefore trust the impeccability of the programmers. The DAO case of Ethereum makes these problems very clear. More over it becomes clear, that Ethereum did not fulfill the criteria of strict decentralization at that point, since the makers of Ethereum did a rollback of the DAO case transactions and Ethereum Classic emerged out of this.
If the structure has a weak decentralization, you trust a single organisation or a handful of programmers or you hope, that the blockchain is not interesting enough for a 50 % attack. What does trust mean in this context? Well, someone with enough influence is able to double book transactions in the background (double spending) and can fill her pockets this way. Or in the case of a controlling organisation, partisanship can emerge and friends of the organisation can be preferred in transactions (like in the DAO case described above).
As an investor in crypto currencies you should ask yourself, what use cases the smart contract on the crypto currency tries to solve and if a strictly decentralized structure is really required to solve that problem. If you consider use cases, where only a single organisation like a state should control the blockchain, then why do you want to throw the immense complexity and unscalability of a blockchain on your problem? Since this case is centralized by definition it could be realized by a classic solution way more efficiently. For instance a redundant database with signed in- and output might often do the job. The argument, that everything is stored in the blockchain forever is not valid any more in such a case, since the single controlling instance (here: the state) has full control over the blockchain and can therefore undo or change entries in the database (like in the DAO case described above).
The Oracle Problem
Back to our real estate deal example: let’s assume, the purchase was done via a smart contract on a strict decentralized structure (reminder: no single instance is able to influence the blockchain substantially and a 50 % attack can be ruled out). Now, how does the digital world know about the state of the real estate? And what happens, if the new owner idles his token away? To whom does the real estate property belong then? Do we need the jurisdiction again, that we wanted to eliminate from the whole process in the first place? This is the so called oracle problem.
In a smart contract, the oracle has the function to provide and to take data. The oracle always has the last word on everything in the smart contract and has to be therefore 100 % trustworthy. Because in a strictly decentralized structure an external jurisdiction is not able to intervene. All involved parties consequently have to accept the verdict of the oracle – no matter what it is. This leaves a broad attack surface for oracles:
- who is controlling the data streams?
- can the data streams be hacked?
- is there a large incentive to compromise the oracle directly or indirectly?
Let’s assume, the purchase of the real estate property was performed using a smart contract and the oracles were the notary, the tax office and the land register. All three of them would have to exchange digital data in a secure and infallible way. Furthermore, the smart contract as the implicit executive should take care that the former owner is not able to enter the property anymore and that the new owner should get the keys. Now, the first thing that comes to mind are smart door locks in smart homes that might be able to approximate this requirement. But at the moment one of these new data providers (e.g. the smart door lock) fails or is compromised, the whole contract falls apart, since no reliable data is coming in any more. To be very clear here, this means that the oracles themselves should have a strict decentralized structure so that the smart contract would be able to receive reliable data.
This example shows a fundamental difficulty to process contracts for physical goods via smart contracts. If you think about it, there are similar problems, if you would trade gold bars via smart contracts. Of course you could sign them with a signature in the hologram, which is related to a token. But again we need the functionality of automatically transferring a gold bar from one owner to the other without involving an external instance. And what happens if you melt down the gold bar? And who will manage all the gold bars and makes sure they are genuine?
Since we are already at it, let’s also think about digital services or goods. Let’s assume we want to apply smart contracts to sports wagering, we then would have to make sure, that the results of the games arrive reliably in the blockchain. In this case, the oracles are the ones who determine and digitalize the sports results. This again would have to happen in a strictly decentralized context, which is hard to realize for obvious reasons. And since a strict decentralization for these oracles is not realistic, immediately the question arises, how large the incentive for manipulation is.
Conclusion
While the fundamental idea of smart contracts seems very alluring, the reliable and secure execution of them is a pretty big challenge. Especially the oracle problem is a big obstacle. If you are interested in a cryptocurrency that uses smart contracts, you can ask yourself the following questions:
- How complex is the contractual problem and what is the connection to applicable laws?
- Does the solution require a strictly decentralized structure and if yes is it guaranteed?
- How secure and reliable are the oracles in this system? Are they strictly decentralized?
Due to the complexity and the oracle problem we can hardly expect real estate purchases being performed via smart contracts in the foreseeable future (or via NFTs, which always face the oracle problem for that matter). And if it happens anyway, then it will likely be a mixture of solutions, which then would be much more efficient and scalable without a blockchain in the first place.
Do your numbers get out of control sometimes?
