# A Provably Honest Oracle Model: Auditable Offchain Data Gathering and Computations - Thomas Bertani - Speakers: Thomas Bertani - Channel: [Devcon](https://streameth.org/devcon) - Date: 2017-10-09 - Duration: 10:20 - Topics: blockchain, smart contracts, distributed ledger - Watch: https://streameth.org/watch/yt-9pDUobV8geI - YouTube: https://www.youtube.com/watch?v=9pDUobV8geI ## Description Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/2/a-provably-honest-oracle-model-auditable-offchain-data-gathering-and-computations Providing offchain data to Ethereum contracts is hard. The model we present enables an offchain party to act as a provably honest oracle which can give strong authenticity guarantees for both data and computations. This novel approach prevents it to tamper any data, while being able to deliver them to the blockchain. This is possible thanks to an extensive use of smart HW and SW techniques based on TLSNotary, Intel SGX and Qualcomm TrustZone among the others. Speaker(s): Thomas Bertani Skill level: Advanced Track: Developer Infrastructure Keywords: oracle, solution, APIs, external, data, attestation, oraclize, authenticity, verification, tlsnotary, AWS, pagesigner, server, qsee, android safetynet, android, intel, sgx, sandbox, google, trust, offchain, evm, proof Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 2 was held in Shanghai, China on Sep 19 - 21, 2016. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/ ## Transcript So, during this presentation, I'll speak about the Oraclize Oracle solution and some of the things that we have in the workings. So, um given the circumstances, there are many smart contracts that need to get external data. Think about web APIs or from any data source. Um still, decentralized networks like Ethereum have the inherent limitation in not being able to reach out the internet. So, the smart contracts live like in a walled garden and they cannot simply open a socket and fetch external data. So, this is why there are many different solutions called as oracles um to pull or push data external data to the blockchain. So, we'll focus during this presentation on the first approach listed in the in this slide. So, this is the one used by Oraclize and as we speak, this is the most widely used on the public blockchain. So, one of the pros of this approach is that it's fully transparent in the sense that both the query and the results are permanently stored on the blockchain. Another advantage is that we can use any data source available on the internet. So, any web API potentially. Since there is no need for them to adapt to the blockchain, they have no knowledge of the blockchain and they doesn't have to. And another advantage is that there is no trust line open with the Oracle. So, the Oracle cannot simply tamper with the data as with attestation, we can move the trust away from the Oracle to attestators. We've seen a bit who these attestors are. So, this is the logic flow. What you have is uh smart contract sitting on Ethereum that can reach out the internet via Oraclize. The way they do so is simply by using um the Oraclize query function. So, this function essentially is an event. So, our off-chain engine can listen to these events and fund feed the request. So, essentially we are the one opening uh the connection with the remote web service. We get the result along with what we call authenticity proof, and we send both of them back to the contract. So, this is asynchronous. And um there are different approaches actually to implement these authenticity proofs. So, these authenticity proofs are cryptographic um signatures that can enable the smart contracts and any external auditor to verify that the data being provided by the oracle has not been tampered with, and that the result that the smart contract is receiving is really the one sent by the external data source. So, the first one is based on an external project called TLS Notary. This is the only one available today on the Ethereum mainnet since September last year. And the way it works, just briefly, is that when the client, the client being Oraclize, initiate a TLS session with a web service, the client secret is split in half so that Oraclize just um it just has half of it, and the other half the other half is secured by um a piece of code whose correct execution is ensured via the Amazon Web Service sandbox concept. So, the way it works is that we get a cryptographic proof out, which doesn't prove that the data has not been tampered. It just proves that there was some kind of cooperation between the notary server running on Amazon Web Service and Oracleize. So, this means that if you do trust Amazon being honest, then Oracleize is being honest as well. So, there is a trust in Amazon with Amazon being an attestator. Another approach that we are presenting today, um you can check out the paper that we are releasing this afternoon, uh is based on a different approach. So, the first one, the TLS Notary one, is essentially a software attestation. This one is an hardware-backed one. We call it Android proof. And essentially it does leverage two techniques, technologies. The first one is QSEE, which is the Qualcomm TEE trusted execution environment uh solution, and Android SafetyNet. So, by using both of them, we can basically verify that um there is an open source piece of code fetching the data from the web service, which is running in a secured hardware-backed um Android-based device. The third one that we are presenting is slightly different because it doesn't prove that the data has not been tampered with when fetching data from an external data source, but it's based on Intel SGX. So, we have already seen it with the Cryplet, um with the Cryplet's presentation. Intel SGX, again, is capable of verifying that a given piece of code, a subset of C essentially, is running in a secure um Intel CPU-backed um sandbox, and there is the um Intel signature on the correct execution of the code. So, this process is essentially close called enclave remote attestation and works via the Intel attestation service. And we use this to solve one of the very issue that we have seen in the last few days in many talks, which is the difficulty of getting reliable on-chain random data. Uh random numbers, right? Um so, with the random data source that you can use by Oracleize, what you get out is a random number which is generated by a low-level Intel SGX backed instruction, and you can verify the correct execution, meaning that the random data was really um random if you do trust the Intel solution. So, again here, we are we have we have just seen two different attestators. Um so, Google or Qualcomm, if you want, and uh Intel. So, what we have seen so far with all these three three different authenticity proofs is attestation as a service essentially. So, different kind of um software and hardware attestation that we can use to move the trust away from the untrusted small startup Oracle to a trusted entity, which is a much bigger company. Of course, you don't want to trust a single corporation, but the assumption that we are making here is that few uh few trusted uh companies or attestators in this case uh are less likely to uh act all as bad actors compared to a network of untrusted anonymous players. So, by Oracleize, you can specify the proof that you want to get out. So, the kind of authenticity proof that you want the Oracleize infrastructure to generate to fetch this kind of data. And of course, you can specify more than one proof. So, you can get the Android proof, the TLS notary proof, etc. on the same request, meaning that if all the proofs are valid and the result is still as still been tampered with, it would mean that at the same time at the same exact time um Android, Qualcomm, Amazon, and Google were all providing the same wrong data. Which is pretty unlikely. So, the last thing that we are presenting today, um and that it's available in our documentation, um is the off-chain computation. So, this is yet another uh solution to the limitation, the constraints of the EVM. Meaning that if you want to execute any piece of code, if you want to reuse any library, external library, or if you have concerns related to the gas limit, in some cases you might want to delegate to an off-chain context the execution of this code. And the approach that we follow here is again the one based on attestators, so attestation. Uh and what we do essentially is extending the base Amazon Web Service Sandbox concept introduced by TLS Notary. And uh with this extended concept, you can execute in a safe um Amazon Web Service-backed lockdown instance any piece of code, and you can get out an an authenticity proof. So, this authenticity proof can be verified by anybody, and um the the way it works is that you define a receipt. Um so, this is There is an example here using, for example, the Python NumPy library, and we can get a result out. Um we distribute it over IPFS, and um in in the Oracleize query, we specify as data source the computation method as data source, and as query, we specify the IPFS multihash. So, what happens is that Oracleize uh that does initiate uh this secure instance, generate the honesty proofs, and the verification steps are essentially based on an extended uh verification of the authenticity proof that I I I just explained before. Um so, what you get out is the proof that the result is really coming from a correct execution in an off-chain context of a single instance of this piece of code. So, there is not anymore this chal- this challenge game, but it's more like um a auditor-based um approach. So, thank you all for the attention, and I will be around, so come find me if you have any question. We are looking for feedbacks, and we are releasing, as I said, the Android paper later today. So, please give us some feedbacks, and thank you for the attention again. Thank you very much, Thomas.