Data Verification with Blockchain Oracles

Blockchain oracles provide sensitive data that smart contracts rely on. Manipulating data like price feeds can cause big turbulence with the data consumers. That’s why oracles have to make sure to provide correct and unbiased data.

There are different ways to deal with potentially malicious data sources. In practice, we see the following approaches:

• Take no action
• Trusted sources
• Reputation and dispute options

Take no Action

Taking no action to deal with potentially malicious data sources is the simplest approach. Data provided that way should not be used for important decisions. The data consumer should at least implement sanity and plausibility checks to avoid unexpected behavior.

Trusted sources

Some oracles rely on trusted hardware like Intel’s SGX or encryption techniques like TLS to ensure data got processed correctly. Each method has its weak points. TLS, for example, only allows ensuring that the reporter took the data correctly from a specific website. But it doesn’t prevent tampering with the content of the website in the first place. If the website provides fake data, the oracle would consider this as correct. That’s why reporters should always mistrust data sources and have fraud detection in place.

Reputation

Oracles like Chainlink rely on the reputation of their reporters.

Data reporters build up a reputation if their data were not successfully disputed. The idea behind that is that the longer the history of truthfully reported data is, the more trustworthy the reporter is. And the higher the reputation, the higher is the influence of the reporter on the final result. Reputation can also be a means to calculate the reward for the service.

Some oracles model the reputation as a (tradeable) token.

Metrics that could influence the reputation score are.

• Total number of assigned requests
• total number of completed requests
• total number of accepted requests
• Time to respond: Average or with a standard deviation
• Number of penalties
• Amount of penalty payments

From these raw metrics, users can calculate ratios to make them comparable.

However, reputation systems have a major problem. In the best case, they are accurate only retrospectively. It is dangerous to infer the future from the past. If the incentive to cheat is strong enough, it does not matter how honest a data source has been in the past.

This problem is also called an exit scam, where cheaters try to make a big win with one fraudulent transaction and don’t care about future business.

Dispute Options

A reputation system only works if there is a chance to dispute apparently wrong data. But creating a dispute system is not easy. It touches on the same issue each decentralized network has: How to know who is right and who is wrong

Authentication proofs

Instead of using a consensus mechanism to validate data of several sources, oracles can try to prove that the data fetched from the original source is untampered. This is done by so-called authenticity proofs that are delivered along with the data. Such authenticity proofs can come from TLS or secure execution environments like Intel’s SGX.

The problem is that smart contracts cannot check these proofs due to their limited functionality. This leaves the smart contract vulnerable to tampered data.

But these proofs can be verified off-chain. And together with a dispute and staking scheme, authentication proofs could at least create some incentive for the oracle to act honestly.

It must be said that research and development teams work on solutions to check authenticity proofs on-chain.

While proofing that the data was not tampered with on the way from the source to the smart contract is important, it is no guarantee that the data source reported correct data in the first place.