If a blockchain oracle retrieves its data from multiple data sources, it needs to aggregate them. In this post, you will learn how blockchain oracles aggregate data.
The aggregation consists of two steps:
- Data cleansing: Outlier detection and type checks
- Data aggregation
Data Type Checks
Incoming data need to be checked if their data type is correct. If you expect a number, you will reject any letter. Besides a simple data type check, it is possible to verify whether the pattern is correct or not. A typical example is the zip code or bank account number that has a fixed number of characters. If the submitted value is too short or too long, it will be rejected.
Pattern and data type checks help to protect against typos or bugs in the code where erroneous messages are sent.
Outlier Elimination/Data Cleansing
The first step is to detect and eliminate outliers. Outlier detection is an important part to keep the data reliable. But since oracles don’t know what data is right or wrong, it can only apply very rough measures.
The most straightforward approach is to cut off the n lowest and n highest values from the data set. You find this often in jury decisions in sports where the lowest and the highest scores are removed to eliminate biased jury members.
Let us consider the following example. There are ten different data sources. Each of them reports one value. We want to set n = 1.
First, we sort the values.
Then, we delete the highest and lowest value. These are 1 (reported by data source 9) and 8 (reported by data source 3).
The resulting table looks like that:
The threshold n can be given absolutely or depending on the number of sources.
Another similar approach is to calculate quantiles and eliminate them. A common threshold is the first quartile and third quartile. Everything below or above is ignored in the following aggregation step.
Some oracles use absolute values as threshold. They provide an upper and lower bound in which the reported values must lie. This is useful to eliminate nonsense data like negative sizes or prices. Chainlink is an oracle that uses this approach.
Besides absolute values, relative values are possible too. Data that stray more than x percent from the average, are not considered.
Here, we explain in short how to calculate the quartile. When calculating the quartiles, we need to sort the values first and calculate the cumulative percentage.
|data source||Value||cumulative percentage|
There are different methods (See https://en.wikipedia.org/wiki/Quartile) how to determine the exact value of a quartile that yield different results. We use the cumulative percentage to determine the quartiles.
The first quartile consists of all values that receive a cumulated percentage of at least 25 % (0.25). To achieve this, we need to include the values 1, 3, and 3.
The third quartile consists of all values that receive a cumulated percentage of at least 75 % (0.75). This comprises the values 1, 3, 3, 4, 5, 5, 5, and 5.
Since we want to delete all values below the first quartile and above the third quartile, we get the following table:
Besides those rather simple methods of outlier detection, there are more sophisticated mechanisms like support vector machines, k-nearest neighbor, hidden Markov models, etc. However, they are difficult to perform on a smart contract due to its limited computation capacity.
After eliminating outliers, the oracle has to condense all data into a single value. First, we look at methods that can be used to aggregate values. Later, we learn how to aggregate values on-chain and off-chain.
Again, we have different methods here:
- Mean: average
- Median: the number in the middle of the sorted values
- Mode: the most often repeated number in our data set
The following example shows the calculation of mean, median, and mode with the data from a sorted and cleaned table.
Average = (3+4+4+4+5+6+6+7)/8 = 4.875
Median = (4+5)/2 = 4,5
Mode = 4
The mode can be considered as a majority voting.  However, it can be difficult to determine, if there is no single most value.
In an on-chain aggregation scheme, all data sources send their data to a smart contract. To mitigate the last actor problem, oracles could introduce a commit-reveal scheme with a deposit that is burned if the data source doesn’t report in time.
Such an on-chain aggregation scheme is independent of a centralized authority. But it is expensive since every reporter has to create a transaction and pay for it. This becomes more severe if a commit-reveal scheme is used, and each reporter has to make at least two transactions.
Oracles can decide to collect and aggregate data off-chain and only report the result to their smart contracts. The first way to do this is that the data sources report to the oracle. The data oracle cleans and aggregates the data. After it is finished, it sends the data to the smart contract.
The problem with this is that neither the reporter nor the data consumer can be sure whether its data got aggregated correctly unless the raw data is provided to the smart contract.
To avoid this uncertainty, reporters can coordinate themselves avoiding the oracle. To prove that the values are submitted correctly, they could use threshold signatures like Schnorr signatures. To create a threshold signature, you need at least k out of n participants. This makes the signature resilient against not responding data sources.
In this setup, reporters exchange their values and aggregate them to a value A. Then, every data source signs the value A. If a majority (k out of n) of data sources signed the same value A, it is considered as correct. In the next step, this value A is sent to the smart contract.
However, the tricky task is to provide an infrastructure where all oracles can exchange their values and signatures. And finally, one participant has to create a transaction and send the signature to the blockchain. This requires a centralized authority again.
Besides the issue regarding the communication infrastructure, freeloading is a problem too. Here, reporters can simply copy the data from other reporters and thus save data retrieval costs.