Blockchain oracles address the issue of delivering information from the external world to the blockchain. However, it's crucial for us to know which of them we can trust.
In on launching the catalog we wrote about the importance of oracles for blockchain.
Decentralized applications do not have access to data outside the blockchain. This is why small programs—known as oracles—are created to gain access to the necessary data from the external world and record it on the blockchain.
Based on the type of data source, oracles can be divided into three categories: software, hardware, and human.
Software oracles gather and process data from the internet, such as temperature, product prices, and delays of trains and planes. Information comes from online sources, like APIs, which the oracle extracts and places in the blockchain. Read about how to create a simple software oracle .
Hardware oracles track real-world objects using devices and sensors. For instance, a camera calibrated to detect line crossings captures cars entering a specific area. The oracle records the fact of crossing the line in the blockchain, and based on this data, the script of a decentralized application can, for example, initiate a fine and deduct tokens from the car owner's account.
Human oracles utilize data entered by people. They are considered the most advanced due to their independent perspective on the outcome of events.
Recently, we provided a tool that allows recording oracle data to the blockchain according to a specified specification. It works incredibly simply: you just need to register , filling out the specification. After that, you can publish data transactions according to this specification through the Waves Oracles interface. Read more about the tool in .
Such standardized tools and interfaces simplify life for both developers and users of blockchain services. Our tool is particularly useful for human oracles and can be used, for example, to record certificates or copyrights for certain objects.
However, when using oracles, the question of trust in the information they provide arises. Is the source reliable? Will the data be received on time? Moreover, there is a risk that the oracle could deceive users by intentionally providing false information for its own benefit.
As an example, let's consider an oracle providing information about sports events for a decentralized betting exchange.
The event is the main fight of UFC 242, Khabib Nurmagomedov vs. Dustin Poirier. According to bookmakers, Nurmagomedov is the clear favorite of the match. A bet on his victory could be made at odds of 1.24, corresponding to a probability of 76%. The odds for Poirier's victory were 4.26 (22%), while the probability of a draw was assessed by bookmakers at odds of 51.0 (2%).
The script accepts user bets on all three possible outcomes until it receives information from the oracle about the actual result of the fight. This is the only criterion for distributing winnings.
It is now known that Nurmagomedov won. However, let's imagine that a dishonest oracle owner, planning a deception in advance, placed a bet on the outcome with the most profitable odds—a draw. When the betting pool reached a large amount, the oracle owner initiates a record in the blockchain with false information about an alleged draw result. The decentralized exchange script has no means to verify the validity of the data received and simply distributes winnings according to this information.
If the potential profit from this kind of deception is higher than the expected revenue of an honest oracle, and the risk of going to court is low, the likelihood of dishonest actions by the oracle owner significantly increases.
One possible solution to the problem is to request data from multiple oracles and bring the obtained values to a consensus. Several types of consensus can be distinguished:
- all oracles provided the same information
- the majority of oracles provided the same information (2 out of 3, 3 out of 4, etc.)
- bringing oracle data to an average value (options are possible where the maximum and minimum values are preliminarily discarded)
- All oracles provided unified information with a predetermined allowable deviation (for example, financial quote values from different sources may differ by 0.00001, and achieving an exact match is an impossible task).
- Select only unique values from the obtained data.
Let's return to our decentralized betting exchange. When using the '3 out of 4' consensus, one oracle reporting a draw outcome of a fight would not be able to influence the execution of the script, provided that the other three oracles provided accurate information.
But a dishonest user could own three out of four oracles, and then they would be able to secure a decisive majority.
To combat the dishonesty of the oracles, we could introduce a rating system or penalties for inaccurate data. We could also take the 'carrot' approach and offer rewards for accuracy. However, no measures will completely eliminate, for example, rating manipulation or dishonest majorities.
So should we invent complex services, or would it be enough to have a consensus tool that allows one to select, like on a supermarket shelf, for example, five oracles providing the required data, set a type of consensus, and get a 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 returned values: 18, 17, 19, and 21 degrees. The difference of three degrees could be quite critical for the script's execution. The service processes the result and calculates the average temperature — 18.75 degrees. This figure will be obtained by the decentralized application's script and will work with it.
Ultimately, the decision lies with the consumer: to trust one oracle and use its data, or to build a consensus of several oracles chosen at their discretion.
In any case, data oracles are a relatively new field. They are at a stage where users themselves can determine the direction in which they will develop. Therefore, we want to hear your opinion. Is the above-described tool for oracles necessary? How do you see the future of data oracles in general? Share your thoughts in the comments and in our official group on .
Source: habr.com
