Dispute Models in Blockchain Oracles
Dispute models give users (this could be any participant like data source, customer, reporter, oracle service, or any external stakeholder) the opportunity to complain about perceived wrong data. If a dispute has been filed, the oracle has to decide whether the original data is correct or the disputer is right.
In this topic, you learn the basic principles of dispute models.
Majority Vote
The most intuitive way to solve a dispute would be to ask all reporters to vote for a result if there is a dispute. The result with the most votes wins. The idea is that if the majority of reporters are honest, the correct result wins.
But there is a problem. If cheating costs nothing, then it is easy to convince formerly honest reporters to change their minds. A bribe could incentivize them to report incorrect data. If the attacker convinces most of the reporters to vote in his favor, they would not even suffer a loss of reputation because the wrong result would be considered valid. Instead, they could even harm the remaining honest reporters.
And if it is costless to become a reporter, the attacker could set up a battery of own reporters and influence the election. This is known as Sybil attack.
Another problem is, that reporters rely on the honesty of the data sources from where they fetch the data. If their data source is corrupted, they might vote for an actual wrong result.
Bond voting
Other services introduce bonds to mitigate Sybil attacks in the dispute phase. Each reporter has to deposit a certain amount of coins or tokens before participating in the oracle.
This bond can be used to calculate the winner of the election. If the majority of bonds vote for a particular result, this result becomes the correct answer.
The problem with that is similar to the majority election. If an attacker is equipped with a large number of tokens, it could overbid every other reporter. And if this is not the case, it could still bribe other reporters.
Overbidding is easy when only a few reporters exist, and not many participants are interested in the outcome.
Punishments
In the two schemes above, it was costless to cheat. And even honest reporters would not have an incentive to file a dispute because they don’t win anything from it. It is obvious that this is not incentive compatible.
That’s why some blockchain oracles introduce punishments for reporting wrong data and rewards for correct disputes.
Reporters have to deposit a certain amount of tokens or coins to be allowed to submit data. If the reporter is found guilty of cheating, the deposit gets slashed.
To incentivize participants to observe the provided data and raise the alarm if necessary, they get a reward. Such nodes are called watchdogs. The reward structure is essential to make bribing the watchdogs prohibitively expensive.
Let’s say reporter A is not honest and has a bond of 100 coins and there are five watchdogs. If each watchdog receives an equal share of the bond as a reward for raising the alarm, the attacker (reporter A) would have to pay every watchdog at least 20 coins to ignore this incident (100/5 =20).
If the reward structure is changed the way that only the first reporting watchdog receives the full bond as a reward, then the attacker would have to pay every watchdog at least 100 coins. The total cost would be in our example 5*100=500 coins. The reason is that if only the first complaining watchdog is bribed, the second watchdog will raise an alarm. And if the second watchdog is bribed too, the third one will raise the alarm. And so on.
The exact amount of the total bribe depends on the ramifications of the alarm. If the watchdogs decide in a majority vote which result is true, then the attacker only needs to bribe the majority of the watchdogs. In our case, three out of five. This would cost him at least 300 coins.
But this can lead to a paradoxical situation if the watchdog gets only paid if it successfully convicts a perpetrator. As long as there are watchdogs on guard, no cheater will try to cheat. And as a consequence, no watchdog will ever get paid. But as soon as the watchdogs turn off their service, it is easy to cheat.
Augur’s Dispute model
Now we will look at the Augurs reporting and dispute model, which is more sophisticated than the approaches before. The complete model is described in its whitepaper. [https://www.augur.net/whitepaper.pdf]
Augur is not only an oracle but also a prediction market that uses an oracle. Participants can set up markets (=bets) for many future events. To settle a market, data from real-world event need to find its way into the smart contract. The oracle is used to feed the prediction market with real-world information to determine the winner.
The oracle part can be described by the following flowchart.
There are six fundamental stages:
- Designated Reporting
- Open Reporting
- Dispute Round
- Waiting for Next Fee Window
- Fork
- Finalized
We will have a look at each of these stages.
Designated Reporting
Market creators choose a designated reporter. The designated reporter is the default reporter who provides the necessary data. When determining the designated reporter, the market creator has to lodge a deposit, the so-called “no-show bond”.
If the designated reporter reports on time, the no-show bond is returned to the market creator. To report, the designated reporter needs to lodge a stake. If the finalized data is different from the reported data, the reporter loses its stake. This incentivizes the designated reporter to provide a true answer.
In case the designated reporter fails to report within the given timeframe, the market creator loses its no-show bond. The market then proceeds to the Open Reporting stage.
Open Reporting
If the designated reporter doesn’t report within the allotted time, the system enters the Open Reporting stage. Here, everybody can submit the requested data. The first reporter who submits the data becomes the first public reporter and receives the no-show-bond from the designated reporter as a stake on the reported data.
The consequence of using the no-show bond as a stake for the reported data is that the first public reporter can only pocket the no-show bond if its data become the finalized data.
The first public reporter doesn’t need to stake its own tokens. Hence it has nothing to lose when reporting. This is designed as an incentive to act quickly and speed up an initial reporting.
Once an initial report has been submitted (by the designated reporter or by the first pubic reporter), this data becomes the tentative data, and the market enters the third stage, “Waiting for Next Fee Window”.
Waiting for Next Fee Window
The fee window is not that important for data verification. It is there to collect fees that are distributed to reporters and disputers.
Dispute Round
After the stage “waiting for the next fee window” is completed, the dispute stage begins. Here, everybody can utter doubts on whether the tentative data are correct. If such doubts are uttered, this is a dispute.
The dispute round has a fixed length. If nobody should dispute the data during the given time, the data becomes finalized.
If someone disputes the tentative data, he needs to submit his own alternative data and stake some of its tokens on the correctness of these data. This is the dispute stake or dispute bond. If there is more than one person who thinks the newly proposed data are correct it can contribute to the dispute stake. A dispute is successful if the dispute stake size is larger than the required dispute bond size.
There are three possible outcomes, depending on the stake the disputers lodged.
- The lodged dispute stake is not enough, and the dispute is unsuccessful: The tentative data becomes finalized. All unsuccessful dispute stakes will be returned to their original owners at the end of the dispute round. So, there is no risk in launching a dispute.
- The lodged dispute stake is higher than the required dispute stake’s height but below the fork threshold: Another dispute round starts. The data of the disputers become the new tentative data.
- The lodged dispute stake is higher than the required dispute stake and above the fork threshold: The system enters the fork stage.
There is one important thing to notice. Even if you report a successfully disputed result or you unsuccessfully dispute a tentative result, you won’t lose your dispute stake. This encourages people to participate in the data verification and utter their opinion without facing the risk of a financial loss. But this is only true if no fork occurs.
Fork Stage
The fork in Augur’s model is deemed as a scarce occasion. It is said to be the very last resort if a reported result is disputed. Here we only touch on the functionality of a fork because its details are not essential to understand the result determination of the oracle. A fork happens if the dispute stake is above a certain threshold (more than 2.5 % of all REP Tokens need to be staked). In that case, all other participants of other markets need to decide which outcome they support. This is done by locking all markets in the current universe. A universe is the collection of all markets. After the lock of the current universe (we call it from now on parent universe) for each possible outcome of the disputed market, a child universe is created. Now the members of the parent universe have a few days to decide to which child universe they migrate.
This process is not reversible. Once a member has decided, all funds from the parent universe are migrated to the chosen child universe and only to the chosen child universe. If a member of the parent universe doesn’t decide within the decision period, all funds will remain locked in the parent universe forever.
The idea behind this is that no member wants to support a child universe where a malicious oracle/ reporter is active and successful.
Members of the parent universe are free to choose which child universe they migrate to. But there is one exception. Those members who supported a certain result are bound to this decision. The funds are migrated automatically to the universe, which supports their result.
So, this gives a strong incentive to report and support only results you are certain, that they are correct. Otherwise, the reporter would face a huge risk of losing everything at stake.
Finalized
If no tentative result has been successfully disputed (or no fork has occurred), the market enters its finalized stage. The result is called final outcome. Market participants can now settle their market.
Assessment of Augur’s Model
This model tries to create a trustworthy setup to get real-world data into the blockchain.
From a game-theoretic perspective, the model should work fine. Reporters reporting wrong data risk losing their stake in case of a fork. This should incentivize them to report correct data.
The correctness of the data is based on the participation of aware users who check the outcome and intervene if they disagree with the reported result.
Real-world events that are easy to observe the dispute mechanism should work fairly well if there are sufficient trustworthy participants. But with more hidden data, you might have to trust the reporter, which could be biased. And also, markets that attract only a little attention can be compromised by malicious actors more easily. This is not an Augur-specific problem but a problem for all oracle types.
Data security, however, comes at the cost of speed. The dispute round lasts at least seven days. And if the data should be disputed, it can take even longer. For the purpose of a prediction market, this slow resolution speed is acceptable but for time-critical applications like decentralized exchanges it is most likely too slow.
