Customized oracle to access and make changes to data on a cloud service

Question

Although, there is some literature mentioning the possibilities of oracles to supply external data to smart contracts in a blockchain, I am a newb and was wondering whether there is a successful implementation of this.

I am aware of services like Oraclize and Reality Keys which provide data from "outside world."

What is the most developed and documented service for oracles?

In what kind of projects are these oracles being used?

There is a list of Dapps which were developed using Oraclize and Ethereum. But how exactly is an Oracle being used here?

Consider a scenario where a Smart Contract from a private Ethereum blockchain needs to read/write data to a cloud service. Can I design my own oracle to do this? If yes, where can I get more information regarding this?

Blockchain services are used to achieve trust-less peer-to-peer transactions and a secure distributed storage of these transactions. Won't the concept of oracles contradict this, because we're "trusting" a single source for our information? Or is there a way to implement oracles on a consensus-based system?

Please provide any useful sources to better understand Oracles. Thanks in advance.

Answer 1

Marco from Oraclize here :)

I think this blog post by Thomas Bertani it's a good primer on what Oracles are and what they can do. As a short summary, an Oracle is a third party that offers to fetch a data that you need and that you cannot get for yourself. This is exactly what Oraclize is being used for in the Ethereum ecosystem. Smart contracts are blind to the external world and, often, data needs to be throw in at them to make them do something useful. We provide that service and at the same time we are also able to provide a cryptographic proof of our honesty, i.e of providing you with an unaltered data from the datasource. Although not a perfect solution, TlsNotary is a first step in the right direction of removing the trust in the Oracle service and move it to much bigger actors, like Amazon in this case, which runs the notarize servers, and to the data sources themselves.

As Edgar mentioned, the ability to verify directly from within Ethereum smart contracts a cryptographic proof of Oracle honesty before accepting that data, it’s going to be a huge step forward for oracle services. It’s a feature that should come before the end of the year, with the next Ethereum hard-fork. At Oraclize we are now working on expanding our cryptographic proofs beyond TLSNotary and other software based approach, and we will be using hardware based solutions in the coming months. As contracts grow in value and utility is going to become more and more important to provide extremely robust and attack-resilient Oracle services.

To answer your other questions, you can see how our services are used in the dApp list you mentioned, by checking their smart contract code in our GitHub repository. The basic mechanics is that we connect to the APIs of those services and we use the callback method _callback to send the data back to the contract requesting it.

Oraclize also works with private blockchains. If you are interested, you should directly contact us and we can discuss of an integration. If instead you would like to build your own simple, ad-hoc Oracle solution, there are some open-source resources here to start with.

Answer 2

Edmund Edgar from Reality Keys here. A good example of Reality Keys in use is EtherOpt, which is a decentralized options exchange. You can see their source code here.

You're right that using an oracle fundamentally requires some kind of trust in the oracle, and avoiding this kind of trust is one of the main reasons for using blockchains in the first place.

This implies the standard "Trusted third parties are security holes" vulnerability: If Reality Keys is hacked or successfully bribed, the wrong people will get paid by EtherOpt. The history of trusted parties in crypto-currency is that our trusted third parties often do get hacked (or "hacked", it's hard to say) so this isn't a purely academic concern.

The obvious mitigation is to combine multiple oracles, as it's less likely that all will be compromised simultaneously. This is very valuable and greatly reduces the risk, although not quite as much as it might sound, because the oracle risk is somewhat correlated; For example, if there's a serious zero-day in some core piece of free infrastructure like SSH, it increases the chance that both Thomas and us will be hacked simultaneously. Also, if one of your oracles is compromised, that increases the value of a successful attack on the remaining ones.

An interesting approach that Thomas has been working on is to use TLS notarization to prove cryptographically that the data he's reporting is what was published by published by the HTTPS site he got it from. IMHO this is currently mainly developer pr0n rather than actual security, because contracts can't actually check the proof, so all you do is get to satisfy yourself that he's been compromised, but since oracle data is generally public and somebody generally has a stake in each outcome and an incentive to scream blue murder if they're robbed, that solves a problem that we never really had, without solving the one we do have: If he gets hacked, you lose your money.

It becomes more interesting if and when Ethereum does a hard fork that will allow contracts to verify the proofs directly; However, even there what you're really doing is moving the oracle: You wouldn't need to trust me or Thomas to provide the right data, but you do need to trust the original data provider to provide the right data. The advantage of this over trusting me or Thomas is that the feed provider may be a bigger company with a brand to protect. However, there are still serious risks, particularly if the data provider isn't really intending for it to be used in the way we're using it, in which case they may fail to secure it appropriately or just yank the API keys your contract needs to access their feed...