This article was brought to our attention: https://blog.aeternity.com/blockchain-oracles-657f134ffbc0
Network load
We always want to have our networks be as high-throughput as possible - that is, to be able to accept as many transactions and smart contract invocations as possible per unit time.
On-chain transactions to use oracles are a form of bloat. Simply put, if I want to run a smart contract that will make use of one oracle, and oracles interact through on-chain transactions, then my smart contract will have to make a transaction with the oracle, and the oracle will have to respond. If I wish to use several oracles, several transactions/smart contract invocations will have to occur. Additionally, each oracle has to publish their data on-chain, so if we’re using several oracles, then the chain will contain several copies of the same data. If this is avoidable (it is!) then it’s highly desirable to only place one copy of the data on-chain.
Incentivising Honesty
We want oracles to be incentivized to give ‘good’ data. If we’re using prediction markets for each event that we’re interested in, then this is difficult - if there is a small market for some data, then there is little reward and also little risk for an oracle. Oracle’s incentives may shift towards behaving dishonestly if a suitably large position is taken based on a small data market.
Note that this also affects centralized/trusted oracles for small data markets, since even if they behave dishonestly, it may be that the majority of users do not care. As an example, consider an oracle that gives sports results - if this oracle gives ‘bad’ data regarding the outcome of a minor game, it may be that the majority of the network, who are not interested in this minor game, do not take action so long as the oracle reports good data for more important events. A solution to this is to have ‘large commitments’ - that is, instead of requesting the result of a minor game, to request the results for all minor games. This means that the oracle cannot determine which results the requesting party is interested in, and so must provide ‘good’ results for all games. However large commitments also contribute to blockchain bloat if the commitments are raw data.
Resistance to attacks
A party may be financially incentivised to ensure that an oracle provides ‘bad’ data. It’s important that it be difficult to attack an oracle mechanism and cause it to provide ‘bad’ results. In particular any ‘on-demand’ oracle will be vulnerable to ddos attacks, both on the oracle and on the oracle’s data source. Since ‘on-demand’ oracles are usually centralised*, they also present a target for malware. Prediction markets suffer from low difficulty of attacks for small data markets, making them practical only for major events. Oracles that regularly report on the same data set are more resistant to ddos attacks, since they are incentivised to maintain ‘good’ network connections to their data providers, whereas ‘on-demand’ oracles cannot do this since they do not know ahead of time where they are supposed to recieve data from. ‘on-demand’ oracles are also heavily exposed to API changes - if I set up a contract which requests stock data from Bloomberg, and Bloomberg’s API changes, my contract will need to be updated or will not work. If an oracle regularly commits to Bloomberg stock data, then the oracle is incentivised to maintain compatibility, and the user does not need to worry about how the oracle obtains this data, as long as it is correct.