Blockchain oracles solve the problem of delivering information from the outside world to the blockchain. But it’s important for us to know which one we can trust.
In the article about launching the Waves Oracles catalog, we wrote about the importance of oracles for the blockchain.
Decentralized applications do not have access to data outside the blockchain. Therefore, small programs are created - oracles - that gain access to the necessary data from the outside world and write them to the blockchain.
By type of data source, oracles can be divided into three categories: software, hardware, and human.
Software oracles receive and process data from the Internet - such as air temperature, commodity prices, train and aircraft delays. Information comes from online sources, such as an API, and the oracle extracts it and puts it on the blockchain. Read here how to make a simple software oracle.
Hardware oracles track real-world objects with devices and sensors. For example, a camcorder calibrated to a line intersection captures cars entering a specific area. The oracle records the fact of the line crossing in the blockchain, and on the basis of this data, the decentralized application script can, for example, initiate a fine and write off tokens from the account of the car owner.
Human oracles use data entered by humans. They are considered the most progressive due to an independent view of the outcome of the event.
Recently, we have provided a tool that allows you to write oracle data to a blockchain according to a given specification. It works extremely simply: you just need to register an oracle card by filling out the specification. You can then publish data transactions according to this specification through the Waves Oracles interface. Read more about the tool in our documentation .
Such standardized tools and interfaces simplify the life of both developers and users of services on the blockchain. Our tool is useful specifically for human oracles and can be used, for example, to record certificates or copyrights to any objects.
But when using oracles, the question arises of trust in the information received from them. Is the source reliable? Will the data be received on time? In addition, there is a risk that the oracle will deceive users by intentionally providing incorrect information to obtain their own benefit.
As an example, consider an oracle that provides information about sporting events for a decentralized betting exchange.
The event is the main battle of the UFC 242 tournament, Khabib Nurmagomedov against Dustin Porrier. According to bookmakers, Nurmagomedov is a clear favorite of the match. It was possible to bet on his victory with a coefficient of 1.24, which corresponds to a probability of 76%. The odds for Porrier's victory were 4.26 (22%), and the probability of a draw outcome was estimated by the bookmakers by a coefficient of 51.0 (2%).
The script accepts users' bets on all three possible outcomes until it receives information from the oracle about the actual result of the battle. This is the only criterion for the distribution of winnings.
Now it is known that Nurmagomedov won. However, imagine that the unscrupulous owner of the oracle, planning the fraud in advance, made a bet on the outcome with the most profitable odds - a draw. When the betting bank has reached a large volume, the owner of the oracle initiates recording in the blockchain of false information about the allegedly draw result of the battle. The decentralized exchange script does not have the ability to double-check the accuracy of the data received and only distributes the winnings in accordance with these data.
If the potential profit from deception of this kind is higher than the predicted revenue of an honest oracle, while the risk of going to court is low, the likelihood of dishonest actions by the oracle owner increases significantly.
One of the possible solutions to the problem is to request data from several oracles and bring the values obtained to consensus. Several types of consensus can be distinguished:
- all oracles provided uniform information
- most oracles provide unified information (2 of 3, 3 of 4, etc.)
- reduction of oracles data to the average value (options are possible in which the maximum and minimum values are previously discarded)
- all oracles provided unified information with a predetermined permissible deviation (for example, the values of financial quotes from different sources may differ by 0.00001, and obtaining an exact match is an impossible task)
- select only unique values from the received data
Back to our decentralized betting exchange. Using the “3 of 4” consensus, one oracle who reported a draw was not able to influence the execution of the script, provided that the other three oracles would provide reliable information.
But an unscrupulous user can own three of the four oracles, and then he can provide a decisive majority.
Struggling for the honesty of oracles, you can enter a rating for them or a system of fines for data inaccuracy. You can go along the path of the "carrot" and offer a reward for reliability. But no measures will completely avoid, for example, a rating increase or an unfair majority.
So is it worth inventing complex services, or is it enough to have a consensus tool that allows, like on a supermarket shelf, to select, for example, five oracles providing the necessary data, set the type of consensus and get the result?
For example, a decentralized application needs temperature data in degrees Celsius. In the oracle catalog, we find four oracles that provide such data, set the consensus type to “average value” and make a request.
Suppose the oracles gave out values: 18, 17, 19 and 21 degrees. The difference of three degrees can be quite critical for the script. The service processes the result and receives an average temperature value of 18.75 degrees. The decentralized application script will receive this number and will work with it.
Ultimately, the decision remains with the consumer: whether to trust one oracle and use its data, or build a consensus of several oracles chosen at their discretion.
In any case, data oracles are a fairly new area. It is at a stage where users themselves can determine in which direction it should develop. Therefore, we want to hear your opinion. Is the above tool needed for oracles? How do you see the future of data oracles in principle? Share your opinion in the comments and in our official Telegram group.