Blockchain oracles resolve the issue of delivering external data to the blockchain – but we still need to know which of them we can trust.
In our article on the launch of the Waves Oracles directory, we discussed the importance of oracles for the blockchain. Decentralized apps cannot access data outside the blockchain. This problem is resolved by using oracles.
The issue at stake is quite straightforward. If the execution of a dApp requires outside data, it has to be stored on the blockchain. To achieve that, small programs called oracles are created, which access relevant data from the outside world and record it to the blockchain.
By the type of outside data source, all oracles could be divided into three categories: software oracles, hardware oracles and human oracles.
Software oracles obtain data from the internet, such as temperature, prices for goods and services or flight and train delays. Information comes from online sources, such as APIs. An oracle extracts relevant data and records it to the blockchain. You can learn how to make a simple software oracle here.
Hardware oracles trace real-world objects using devices and sensors. For instance, a video camera calibrated for line crossing traces vehicles entering a certain area. An oracle records the fact of entering the area to the blockchain. Based on that oracle's data, a dApp's script can, for instance, issue a ticket and deduct tokens from a vehicle owner's account.
Human oracles operate with data entered by humans and are considered most advanced because they offer an independent view of an event's outcome.
Recently, we introduced a tool that enables writing data to the blockchain under a set specification.
The tool is very straightforward. You register an oracle card by filling out the specification and can then record data transactions to the blockchain under that specification. Read more about the tool in our documentation.
Standardized tools and interfaces of this kind make life easier for developers and users of blockchain-based services alike. This tool is especially useful for human oracles in areas such as recording certificates or an author's rights to some objects.
However, data provided by oracles has to be trustworthy. Using just one oracle could cause problems. It's vital to know if you can trust the source and if the data is up-to-date. Otherwise, there is a risk that an oracle can deceive users by deliberately providing false information to gain a profit.
Let's consider the example of an oracle providing information of a sports event’s outcome to a decentralized prediction market.
The event in question is a UFC 242 fight between Khabib Nurmagomedov and Dustin Poirier. According to bookmakers, Nurmagomedov was the favorite with odds of 1.24, corresponding to a 76% probability of victory. Poirier was given odds of 4.26 (22%). The odds of a draw were 51.0 (2%).
A script accepts bets on all three outcomes until it receives information on the actual outcome from an oracle. That information is the only trigger for distributing the winnings.
We know that Nurmagomedov won the fight. But let's assume a dishonest oracle owner planned a fraud and placed a substantial bet on the most profitable outcome, a draw. Once a large sum of bets has been accumulated, the dishonest oracle owner initiates recording of false information about a draw to the blockchain. The decentralized exchange's script is unable to check the accuracy of the data and can only accept it. Subsequently, the script distributes the winnings between the bettors in accordance with the outcome data it has received.
Fraud of this kind could potentially be highly profitable for a dishonest oracle creator. If the anticipated profit is higher than an honest oracle's predicted revenue and the risk of legal consequences is low, the chance of fraud could substantially increase.
One way to address this is by requesting data from several oracles and establishing consensus from the received outcomes.
There could be several types of consensus:
- All oracles supplied the same information.
- The majority of oracles supplied the same information (2 out of 3, 3 out of 4, etc.).
- The median of the oracles' data is calculated (the maximum and minimum outcomes could be discarded before calculating the median).
- All oracles supplied the same information within a previously agreed deviation. For instance, exchange rates from different sources could differ by 0.00001, and obtaining exactly the same data would be impossible.
- Only unique outcomes are selected.
Let's apply this to our example. If a ‘3 out of 4’ consensus type is used, false outcome information on the Nurmagomedov vs. Poirier fight from one oracle would not have an impact on script execution. It would be executed based on information about Nurmagomedov's victory, with the winnings distributed based on that data.
However, if a dishonest person owned 3 out of 4 oracles, it would be still possible to rig the outcome data.
To maintain oracles’ integrity, various concepts for oracle rankings or fines for providing false information, as well as incentives to provide accurate information, could be introduced. But none of them would be protected from ranking rigging or a dishonest majority.
So, do we really need more complicated concepts, or would it be better simply to have a consensus tool that allows us to take five oracles supplying relevant data – as if off a supermarket shelf – set the consensus type and get a result?
For instance, a decentralized app needs Celsius temperature data. We will find four oracles supplying that data in the oracle directory, set the consensus type as «median» and make a request.
The oracles provide values of 18, 17, 19 and 21 degrees. There is an apparent discrepancy in the data, and a three-degree difference could have an impact on script execution. The service processes the received data and comes up with a median of 18.75 degrees, which is sent to the dApp’s script.
In any case, the decision of whether to trust data from a single oracle or build a consensus from several oracles is up to the user.
Overall, data oracles are a new field. This is currently at a stage where users can have an impact on the direction in which it will develop. We would therefore like to hear from you. Tell us if you think a consensus tool described above is needed and share your ideas about the directions in which the oracle field evolve.
Provide your feedback in comments and in our official Telegram group.
