Are Oracles necessary for blockchain for real world applications?
From a technical perspective, a blockchain is something very interesting because it combines so many technologies (cryptography, communication protocols, consensus algorithms and many other). But from a business point of view a blockchain – or any other technology – has no value if it cant be used to solve problems, or phrasing it better, to find real world use cases.
There are some problems coming with blockchain(for example scalability, cost). But often one problem is overlooked (or at least not discussed so much). This problem stems from the nature of Virtual Machines(VMs) – or scripts for chains that do not have smart contracts. We are going to focus on chains that have a VM, that is, they support smart contracts.
Virtual machines are an isolated environment into which code (smart contracts) are executed. The results are verified in a decentralized way. The problem is that the VM cant access any data outside its environment directly. This “outside” is the real world that we care about. Any real application must have access to these data. For example a trading software client must have access to stock prices at real time, an accounting software must get data about invoices of the company, employee’s salaries etc. Off course the smart contract can get data manually from anyone who has access to trigger functions of the smart contract. The data are passed as arguments to the functions, feeding that way the smart contract the desired data from the outside world.
So the problem seems to be solved. But the whole point of blockchain is decentralization, or put it another way, to build trust in a trustless way. The users shouldn’t be required to trust anyone. In the above scenario the users must trust the entity that feeds the data to smart contract. This defeats the purpose of the use of blockchain in the first place. Here comes the oracle(s), trying to solve this problem.
What is an Oracle? Oracle is an entity (usually a server) or a group of entities that is independent from the smart contract owner and feeds the smart contract with specific real world data, usually in real time.
The most common data that needed for smart contracts are:
- Exchange rates between cryptocurrencies and fiat money, stock market and commodity prices
- Random numbers. Maybe it seems strange that the VM cant produce random numbers be it real cant because it is a deterministic machine. For the same input the output must match between all verifiers (nodes), so no random element can be produced. The randomness must come from outside as an input.
- Athletic results
- Any other data which are needed for the decentralized application to function. This kind of data vary much between applications.
Oracles can be centralized or decentralized. Centralized oracle is an entity, which can be a server or a group of servers which belong to the same owner. To be successful, the centralized oracle must have at least the following properties:
- Be completely independent from the smart contract owner and also from the users of smart contract. The oracle must have no incentive to cheat (to feed wrong data).
- It must have a long and clear(honest) history. It must operate according to the protocol, feeding correct data on time.
- It must have the infrastructure (hardware and software) to do this.
- It must be highly reputable; The higher the reputation, the lower the chance for the oracle to destroy its reputation with a wrong action.
It is clear that a centralized oracle suffers from the problems of the “single point of failure”. But it also carries the benefits of it: It is fast and very low cost.
A decentralized oracle is, actually, a group of oracles. There is no rule of thumb or standard architecture how this can be achieved. The basic property of the decentralized oracle is that the data that feed the contract must first past a consensus. Not the blockchain consensus but a separate one. Some mechanism (algorithm) decides the final value of the data, considering all the values submit from the oracles. Some strategies that can be used to achieve a degree of decentralization for oracles are:
- a) Oracle list : There is a known group of oracles, which have the right to vote. To incentivize them to act honestly, there is a score attached in the storage of smart contract, measuring their honesty. The correct value is decided by voting (all oracles vote). The rejected values carry a negative score for the oracle while the correct ones a positive score.
This score can be used in two ways. The first is to change the weight of the vote. So the votes are not equal but carry the weight of the honesty score. The second way is to financially penalize the bad actors. So the oracles deposit a guarantee inside the smart contract. If the score is too low , or for every wrong answer they can loose some coins. If the guarantee reaches zero or the score is very low the smart contract can completely remove them from the oracle list. - b) Anyone can be an oracle: It is like the above solution but anyone can be an oracle. It is not forced to vote each time like the (a). Every time it wants to participate it can win (or loose) some coins. So for participation he must first send coins to smart contract as a guarantee. That way anyone has the motivation to submit the correct value.
- c) An independent system with its own consensus : The oracles have their own network (usually a blockchain) with its own consensus algorithm and coin. So the decision is taken inside this other system. This system must have finality. After the value is confirmed and finalized by its consensus algorithm the value is directly submitted to the smart contract of the blockchain it belongs to. In this occasion the smart contract trusts this other system, so no guarantee is needed. The decision is taken in a decentralized way inside another blockchain.
There are many details, types of attack and trade-offs for the above solutions. Because of the complexity of the subject we are going to refer in detail to each of these approaches in other articles. Here I’m going to mention only one common vulnerability which all decentralized oracle systems can suffer: freeloading. Any oracle can just read the proposed data of another oracle, copy the value and submit it. He has an intensive to do so: he can get the value for “free”, that is, no need to have its own infrastructure. It bypasses its own operating costs and steals the info. This is very dangerous because it undermines decentralization and makes attacks much more easy and effective.
Fortunately, there is an easy solution against this, using cryptography. We split the committing in two phases. The oracles are forced to commit the hash of the answer in the first phase and the final answer in the second phase. That way no oracle can copy the value from another oracle because it is committed in the first phase.
Which strategy for an oracle functionality is most correct? Obviously there is a not fit all best solution. The correct decision depends on the nature and needs of the application.
All the above is just an introduction for oracles. More analysis will come in following articles.