- What are the oracles and why they are hard to automate?
- How the Amoveo oracle answers questions. Some examples
- How Question Oracle determines a winner in prediction markets
- How to challenge oracle answers
What are the oracles and why they are hard to automate?
One of the key elements needed for smart contracts is an oracle, a mechanism that provides external information to the blockchain network. When network participants enter into a contract over the outcome of some event, the network needs access to information about the outcome. This information may be related to outside (external to the network) events, so oracles are required.
For example, in Prediction Markets (PMs), such an event may be the price of oil or gold getting over a certain threshold. The problem is, those prices are determined in commodity markets, not within the network. These prices can be obtained from financial websites like bloomberg.com, finance.google.com, finance.yahoo.com. Therefore, one of the simplest examples of an oracle is a program that can retrieve information from such sites.
The first problem is the reliability of the information source. The information on source websites has to be correct. When contract terms are rather simple, like the aforementioned price of oil, retrieving this information is usually not a problem. But as the task gets more complex, collecting the relevant information becomes commensurately difficult.
Let us suppose that an oracle needs to determine the market capitalization of some European or Asian company. In such cases, incorrect information is quite common, even when it comes to top financial sites. For instance, in 2018 many UK companies on msn stock screener had the market cap specified in the trillions, which is obviously incorrect. For example, in November 2018 the market cap of BP was stated as 10.53T (trillions). This has been fixed since, but it shows how different sites can provide substantially varying information, even when it comes to the biggest companies of financial powerhouse countries like Great Britain.
For an oracle to avoid providing erroneous information to the network, it should compare data from several financial sites and trust those where information is confirmed by other sources. But even that does not always solve the problem. If you’re trying to retrieve information about revenue or dividends of a mid-sized company from a country that is not considered a financial leader, you are more than likely to get different values from different sites.
Automatic searching for information on other events can be even more challenging. For example, if the objective is to determine where some politician stands on a particular issue, different sites can quote him/her differently.
The second problem lies in the processing of information. The task doesn’t always come down to simply finding the correct numbers and letters.
In PMs, one can imagine a joke bet: “will the next Chinese Leader have hair or be bald?” In that case, the oracle will have to not only track the presidential elections (from news and government sites), but also make decisions regarding the winner’s appearance from photographs or otherwise. This task would be so difficult that you would struggle to find someone seriously willing to risk their money on such a wager if all an oracle is capable of is analysing websites.
Someone may say “Let us not ask the oracle dumb questions”. But thinking impartially, a good oracle should be able to answer such questions as well. It needs to be as universally capable as possible.
The third problem lies in the difficulty of correcting oracle’s mistakes. As oracles are still prone to mistakes, some kind of an error detection and correction mechanism might be required.
Evidently, oracles can make mistakes both when choosing their source and when detecting the relevant information. At times, oracles can avoid making mistakes by eliminating sources with substantially varying data from consideration (as in the case of multi-trillion capitalizations). Still, it’s easy to imagine a situation when an oracle makes a mistake despite all the precautions.
If a mistake is seen by the network participants straightaway, they can notify the developers hoping for some quick algorithm improvements. Nevertheless, they will have to close the smart-contract ‘manually’ by either invalidating it or by engaging the network’s users in its correction, which would render the oracle not fully automatic.
In case the mistake remains unnoticed for a while, the smart-contract will also be closed incorrectly. For instance, this could result in PM winnings being distributed improperly. Later on, when that mistake will become public knowledge, the network will be discredited, which might result in a hard fork (see section 4) which, when it comes to fully automated oracles, is still not going to be enough to solve the problem. Those kinds of mistakes will happen again.
And as long as artificial intelligence processes information worse than a human being can, it would be unwise to exclude the latter from the equation. That is why Zack Hess set up a completely different model for oracles within Amoveo network than the ones described above. The oracle does not search for information by itself, but rather requests an answer from the users, keeping in mind that they can lie, the system also uses market methods to minimize bad actors.
How the Amoveo oracle answers questions. Some examples
There are two types of oracles in Amoveo: Question Oracle and the Governance Oracle. The purpose of the first one is to deliver information about past and present facts, thus ensuring the operation of the prediction markets and other smart contracts. The purpose of the second is to manage the development of the Amoveo network via futarchy: network participants collectively determine the answer not by voting (the answer that gets the most votes is True), but by betting (the answer that gets the most total amount wagered for is the True outcome).
Both oracles rely on the futarchy method to answer questions. In this and subsequent sections we will primarily discuss the Questions Oracle, and in section 4 will show how Governance Oracle implements similar mechanisms.
Even outside of a smart contract any participant can ask a Questions Oracle anything. For instance, to test it, from the command line it looks like this: “api:new_question_oracle(Start, Question)”. Where the word “Question” should be replaced with the actual question.
The AmoVEO oracle will not search for answers on external sites, instead it will redirect the question to network participants. They can choose one of three answers: “true”, “false” and “bad question”, or elect not to answer. A participant backs his answer with a wager, which points to the degree of his confidence in the answer. If there are no more bets after a certain period of time the oracle closes the question. The oracle sums and compares the amounts wagered on each answer, the answer with the most amount of bets determines the winner. The other bets are divided between those who bet on the winning answer.
The gaming theory dictates that, if the answer is well known, participants are unlikely to lie, as they will probably find themselves in the minority and lose. If the answer is not well known, then the majority will likely choose not to answer and so the true answer is determined by a smaller group of “experts”. And, if the answer is accessible to anyone, but requires a bit of work, such as comparing information from various sources, financial interest will motivate the participants to carry out diligent analysis to be confident in the winning outcome.
Such an approach does not guarantee that all the answers will be genuine, but, at the very least, can ensure the degree of probability of reaching the correct outcome is increased in comparison to a a “public opinion” scenario (net sum of user opinions regardless of their competence level). At the same time, it is simple and straightforward.
Example 1. A network participant asks a question: “Is the current U.S. president bald?”
The oracle won’t search for the president’s photos but will redirect the question to the network participants. Suppose that three users bet 5 VEO each on “false”, one as a joke bets 1 VEO on “true” and another to express his displeasure with the question bets 3 VEO on “bad question”. The total bet on “false” comes to 15 VEO and this answer is determined TRUE (winner). The remaining 4 VEO is divided amongst the users who bet “false”. Donald Trump is not bald. The author of the question gets an answer and thus can judge the efficiency of the oracle.
Example 2. A network participant asks a question: “Is the current Russian president bald?”
Here the answer is not obvious. Strictly speaking, Vladimir Putin is not bald. But as per a Russian joke Russian heads of state alternate between bald and “haired”, many consider him to be “bald”. Depending on how the question is perceived, literally or as a joke, the answers can split unpredictably. With that in mind, the majority of network participants will likely choose not to risk their money. But, let’s suppose that one user, disregarding the joking nature of the question, bets 5 VEO on “false”, another, being aware of the joke puts 5 VEO on “true”, yet other two users realizing the inherent ambiguity wager 3 VEO each on “bad question”. In that case, the winners by a narrow margin will be users who bet on the third option and win they will win 5 VEO each.
Though, the losers may not be happy with the result, as they answered truthfully, even while not realizing that their opponents are right in their own way. They can challenge the outcome, which we will discuss in section 5.
Example 3. A network participant asks a question: “Is the present King of France bald?”
This is no longer a joke, but a famous question posed by Bertrand Russell in his article Philosophy of Science as meaningless. France no longer has a King, and therefore he cannot be bald or not.
This isn’t a question people are going to guess about. Even those, unaware that it’s been a while since France stopped being a monarchy, may hardly venture an opinion about the King’s hair. Most likely, this bet will be placed only by people who know that France doesn’t have a king. And the majority, say 5 users, will bet from 1 to 8 VEO on “bad question” option. We can also assume that 2 people bet 2 VEO each on “false”, mistakenly thinking that “if there is no king, he cannot be bald”. Nevertheless, the “bad question” option will win and it’s hard to argue against that.
Though, this example is given with the assumption that most of the network participants are reasonably smart. It is possible that the same question posed to elementary school children would get more “False” answers due to their lack of logical thinking at that age.
How Question Oracle determines a winner in prediction markets
Even though the Amoveo Question Oracle can answer questions, its primary objective is to ensure network functions, which includes Prediction Markets (PMs).
Suppose that two PM participants, (we’ll call them players) are arguing: “Will the market cap of BP be above or below 150B pounds by year end?”. Both bet 1 VEO each on it. At the end of the year, the winner should get 1 additional VEO and the loser will have 1 VEO less.
When the time comes to close down the contract, the oracle asks the network participants: “Does the current BP market cap exceed 150B pounds?”. Those willing to answer (reporters) go on financial sites to find the correct information and answer the question by placing bets. The option on which they bet the most amount of money is considered the winning one. The winner among the players is determined on those bases. The reporters that voted for any other answers lose their stakes, which are then re-distributed among the supporters of the winning option.
In a sense, we have two nested contests here. The first one begins between the PM participants when BP’s end of year market cap is unknown. The second one goes on between the reporters, when the end of year market cap is already known, and the winner of the PM needs to be determined. However, strictly speaking, there is only one contest happening here: between the PM participants. When it comes to the reporters, if the oracle is operating normally, their only function is simply to report BP’s end of year market cap to the network. If the BP’s market cap clearly exceeds 150B pounds, then most bets will be placed on TRUE, if it doesn’t — most reporters will bet on FALSE. If a reporter accidentally makes a mistake, he or she will just lose their bet.
Nevertheless, in theory, there could be a situation when the reporters will begin an actual contest. As a result, a controversial or an outright incorrect answer could “win”. We will discuss such cases in section 4.
How to challenge oracle answers
Not all oracle answers will be well received by network users. In the case of the Question Oracle, there could be at least two potential issues.
The first negative scenario might unravel if the oracle will make a decision that is clearly incorrect due to the incompetence of reporters or their desire to compromise the network. For instance, by placing a huge bet on Hillary Clinton winning the presidential election.
The second negative scenario is possible in case the smart-contract included an incorrect wording of the question in the first place. Take the BP example. It might just happen that BP’s end of year market cap will be higher than 150B on some exchanges, but lower than that on others, while the contract didn’t specify the exchange. The experienced market players understand the importance of correct wording, but sometimes it’s impossible to foresee such situations.
When it comes to the Governance Oracle the conflict of interest is even easier to imagine, with a deliberate attack on the network attempting to halt its development and growth being the worst-case scenario. In order to prevent attacks, Amoveo developers are planning on making the governance system more complicated by creating a full-fledged decision market (DM) — a particular prediction market (PM) used for changing the network’s variables through the Governance Oracle. The current Governance Oracle mechanism and the coming reforms are described in detail in a separate article about decision markets and futarchy.
To ensure the system’s flexibility, Amoveo users can see current bets before the oracle closes the question. If a user sees that their bet is on the losing side, they can double the stake. If the network is under attack from a single participant, all the other users can also double-up on their bets.
Moreover, in an extreme scenario, users can opt to fork (split the network in two) as it happened with Ethereum in 2016 in light of The DAO scandal. Due to the contract’s vulnerability, many Ether holders lost their assets, and therefore a decision was made to split the currency in two: Ethereum (ETH) and Ethereum Classic (ETC). In ETH, the blockchain blocks accounting for a loss of hacked funds were deleted while ETC remained unchanged. The users were given a choice of which blockchain they wanted to proceed with.
Similarly, in case of a conflict that can’t be resolved otherwise, some users may elect to go a different direction by creating a new version of the blockchain that would be “rolled back” to pre-conflict state. Obviously, the success of a fork is never guaranteed, as everything will depend on how active the users will be within the old and the new networks. In case of Ethereum, the modified version of ETH became more popular, because the consensus was that the hack and loss of funds was detrimental to the network.
The Amoveo Oracles are a great example of an elegant solution to a complicated technical issue of fetching information from the outside world to a blockchain platform.
Despite all the complications discussed in section 1, some blockchains are still using automated oracles. For instance, DAI stablecoin utilises Target Rate Feedback Mechanism (TRFM) to stabilise its exchange rate, which is pegged to the US dollar. The mechanism detects when DAI’s rate deviates from the price of dollar and adjusts it accordingly.
Still, exchange rate adjustment is a very specific task which only requires fetching financial information about a single asset — the US dollar. In contrast, Amoveo’s oracles are a vastly more complicated tool tasked with answering users’ questions. That is why Zack Hess chose not to rely on automated oracles, and instead opted to incentivize the network’s participants to act as reporters. To facilitate this, he set up a betting system that incentivises users to only report the truth and most of the time leaves dishonest reporters on the losing side. Moreover, he also created additional means of correcting mistakes, such as doubling a bet and forking the entire network.
The concept of incentivising users to fetch information to the blockchain network isn’t new, a similar concept is implemented in Augur (REP). However, Augur is built on the Ethereum (ETH) blockchain, which makes Augur’s oracles expensive and almost completely rules out the possibility of solving conflicts through forking. That would require forking the entire gigantic Ethereum network, which definitely will not be supported by the vast majority of its users.