Blockchain oracles solve the problem of delivering information from the outside world to the blockchain. But it is important for us to know which ones we can trust.
Π about catalog launch we wrote about the importance of oracles for blockchain.
Decentralized applications do not have access to data outside the blockchain. Therefore, small programs are being 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 plane delays. The information comes from online sources, such as APIs, and the oracle retrieves it and puts it on the blockchain. Read about how to make a simple software oracle. .
Hardware oracles track objects in the real world using devices and sensors. For example, a video camera calibrated to cross a line captures cars entering a certain area. The oracle records the fact of the line crossing in the blockchain, and based on this data, the decentralized application script can, for example, initiate the issuance of a fine and write off tokens from the car ownerβs account.
human oracles use data entered by a person. They are considered the most progressive due to their independent view of the outcome of the event.
We recently provided a tool that allows you to write oracle data to the blockchain according to a given specification. It works very simply: you just need to register by completing the specification. You can then publish data transactions according to this specification through the Waves Oracles interface. Read more about the tool in .
Such standardized tools and interfaces make life easier for both developers and users of blockchain services. Our tool is useful specifically for human oracles and can be used, for example, to record certificates or copyrights for any objects.
But when using oracles, the question of trust in the information received from them arises. Is the source reliable? Will the data be received on time? In addition, there is a risk that the oracle will deceive users by deliberately providing incorrect information for its own benefit.
As an example, consider an oracle that provides information about sports events for a decentralized betting exchange.
The event is the main event of the UFC 242 tournament, Khabib Nurmagomedov vs. Dustin Poirier. According to the bookmakers, Nurmagomedov is the clear favorite of the fight. It was possible to bet on his victory with a coefficient of 1,24, which corresponds to a probability of 76%. The odds for Poirier's victory were 4,26 (22%), and the probability of a draw was estimated by bookmakers at 51,0 (2%).
The script accepts user bets on all three possible outcomes until it receives information from the oracle about the actual outcome of the battle. This is the only criterion for the distribution of winnings.
It is now known that Nurmagomedov won. However, imagine that the unscrupulous owner of the oracle, planning the deception in advance, made a bet on the outcome with the most favorable odds - a draw. When the betting bank has reached a large volume, the owner of the oracle initiates writing false information about the supposedly draw result of the battle into the blockchain. The decentralized exchange script does not have the ability to double-check the accuracy of the received data and only distributes winnings in accordance with these data.
If the potential profit from this kind of deception is higher than the predicted revenue of an honest oracle, and the risk of going to court is low, the likelihood of dishonest actions by the owner of the oracle increases significantly.
One possible solution to the problem is to request data from several oracles and bring the resulting values ββto a consensus. There are several types of consensus:
- all oracles provided the same information
- most oracles provided the same information (2 out of 3, 3 out of 4, etc.)
- reduction of oracle data to the average value (variants are possible in which the maximum and minimum values ββare preliminarily discarded)
- all oracles provided the same information with a predetermined tolerance (for example, the values ββof financial quotes from different sources can differ by 0,00001, and getting an exact match is an impossible task)
- select only unique values ββfrom the received data
Let's get back to our decentralized betting exchange. When using the β3 out of 4β consensus, one oracle that reported a draw would not be able to influence the execution of the script, provided that the other three oracles would give reliable information.
But after all, an unscrupulous user can own three of the four oracles, and then he will be able to provide a decisive majority.
Fighting for the honesty of oracles, you can introduce a rating for them or a system of penalties for unreliable data. You can also go the βcarrotβ route and offer a reward for authenticity. But no measures will completely avoid, for example, rating cheating or an unfair majority.
So is it worth inventing complex services, or will it be enough to have a consensus tool that will allow, like on a supermarket shelf, to select, for example, five oracles that provide 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" and make a request.
Suppose the oracles gave out the values: 18, 17, 19 and 21 degrees. A difference of three degrees can be quite critical for script execution. The service processes the result and receives an average temperature value of 18.75 degrees. This figure will be received by the decentralized application script 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 own discretion.
In any case, data oracles are a relatively new field. It is at the stage where the users themselves can determine in which direction to develop it. Therefore, we want to hear your opinion. Is the above tool necessary for oracles? How do you see the future of data oracles in general? Share your opinion in the comments and in our official group in .
Source: habr.com