To simplify, the blockchain oracles are third-party services that provide smart contracts with information from external sources. Technically, it’s a kind of intermediary between the blockchain and the outside world.
Due to their structure, decentralized networks cannot access information that they have not downloaded. However, very often for their effective work these data are necessary.
This is where the oracles come into play. They do not provide data on their own, but they can request, analyze, verify and transmit further information from external sources. Sensitive receptors of the human body can serve as a good analogy - they also respond to external stimuli in the same way, transmit information to the analyzing center (brain) in the same way, and are just useless in isolation from this center.
The analogy can be continued further, since some oracles can send data to the external environment - as a reflex reaction of an organism to some kind of impact.
Therefore, for the effective operation of blockchain networks, oracles are necessary. It is they who are responsible for the ability to automatically perceive changes in some external events and the network reaction to them.
Oracle use Example
Let's say someone Sam and Nick argued about who will become the winner of the World Cup. They discuss all the conditions of the bet and record their funds with the help of a smart contract, which will then be sent to the winner. This is done so that no one then could unilaterally refuse to bet. Theoretically, a proxy could be used for the same purpose - this is exactly how many bookmakers work, but our participants decided to do without intermediaries who needs a commission to pay and who do not have much trust.
After the end of the World Cup, the smart contract sends a request to a trusted application, which reports who has blanched. And depending on this result, funds are automatically sent to one of the debaters.
Types of oracles
Depending on certain qualities, oracles are divided into different categories. Therefore, each can be described in several terms. The most commonly used properties are:
- Source. Is information obtained by software or hardware?
- Direction of transmission. Reception, transmission, and both?
- The degree of trust. Is the trusted application centralized or decentralized?
- Authentication. Automatic or human?
Let's consider each of these groups more similarly.
Software/hardware. The first interact with online sources of information. That means - with the Internet, private servers and databases, to which there is access. Usually, they interact in real-time. Their goal may be exchange rates or current flight data. The second receive information from hardware sensors and respond exclusively to it. In fact, they transform real events or changes into an information format. They don’t work constantly, but upon request or respond to a changing situation. An example is an automatic report on the entrance of a vehicle transporting goods.
Incoming / Outcoming. The first receives information from outside, reporting, for example, on temperature changes. The second can additionally transfer data to external sources. So, for example, if funds are transferred to some account, using the outgoing oracle, you can automatically unlock the smart lock that is blocked until these funds are transferred.
Centralized / decentralized. The first receive information from one trusted source. In simple situations, such as a reaction to a sensor, this is useful, but in more complex situations it opens up space for abuse due to the presence of only one point of failure. The second use data from several sources, giving the result based on a specific consensus algorithm. This method is more resistant to errors and external influences, but more expensive, slower and more complicated. However, he does not eliminate the problem of trust, but simply redistributes it between sources of information.
Contract / Human. The first provides exclusively oracle-smart-contract interaction. Typically, one oracle is associated with one contract. Not the best way if you need to get information from different sources, but such an interaction is much easier to adapt to different requirements at the time of development. The second allows you to verify data through human efforts. The trustee verifies the authenticity of the data and transfers them to certain smart contracts. And due to the fact that a trusted person can use cryptographic methods of confirmation, fraudsters have practically no chance to influence this data.
Existing problems
- "The Oracle Problem." If some oracle is compromised, then the smart contract associated with it is also. Since there is no trust in the incoming information. However, just disconnecting a smart contract is problematic if it is not provided at the time of its conclusion.
- Weak defence. Oracles are external algorithms, therefore, they are not protected by the internal blockchain protection mechanism. Therefore, it is they who are most often chosen for attacks. Especially “outgoing”.
- Man-in-the-middle attack. If an attacker gains access to the data channel between the oracle and the smart contract, he can introduce distortions into it or completely falsify them.
Conclusions
Blockchain oracles are a necessary element of the functioning of decentralized networks, seriously expanding the potential for their use. However, their safety, reliability and fault tolerance are still worth working on. For example, by creating the so-called “decentralized oracles”, which have many properties that are characteristic of blockchain networks.