# How to design Auditable Offchain computations via Oraclize

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2018-10-07
- Duration: 15:33
- Watch: https://streameth.org/watch/yt-T7g8UcLlNm4
- YouTube: https://www.youtube.com/watch?v=T7g8UcLlNm4

## Description

While implementing complex blockchain applications, developers have to face a variety of scalability limitations proper of decentralized networks. Delegating some executions to a provably-secure offchain context helps to address some of them. The Oraclize auditable computation datasource is a way to execute any piece of code in a provably fully locked down environment. Thanks to various sandboxing techniques (i.e.: those used by the authenticity proofs), it becomes possible to execute the code one and to verify its output easily later on, even straight on the EVM.

Speaker: Thomas Bertani

## Transcript

basically enables the execution of any piece of code in an off chain context so that the result can be sent back to the to a contract on the blockchain and in the future will be possible to verify it there so we will show what the proof is and how it's possible to design one option computation archive so the concept around the replies has been already explained yesterday but briefly the idea is that basically on we enable the communication of existing Web API is over external context is like ipfs and swore with any blockchain most of the users of oracle eyes at the moment are in the etherium space and along with the data that we sent to the blockchain we also attach the authenticity proof which is basically a collection of signatures and data that anybody can use to verify that we are behaving honestly so that while intermediating here we we are not operating in a malicious way we are not tampering with the data so the waiver class works is a synchronous so basically you have a contract like this which includes the Oracle AERS API this is a solidity contract very simple one and you can call out to the Oracle eyes query by Oracle eyes query to the Oracle eyes engine and you specify a data source which in this case is URL it means that you want do an HTTP GET request and you specify the actual query so the endpoint you want to call in this case is crypto compare.com so this is basically the reference to the data you want our allies to get for you Oracle eyes does it and it sends back a new transaction so this is the second transaction the first one is the transaction that the user does that maybe calls the update method and starts the call-outs to the Oracle eyes engine the second transaction is this one basically when we send back the result and the authenticity proof to the coaling contract so this is a transaction that typically calls the callback method you see here you have a query ad you have the result and the proof and then you do whatever your contract needs to do with the result that work Eliza sent back so basically what we want to talk about in this presentation is how to solve this problem and so we know that we have different limitations on the blockchain due to constraints of the EVM like missing floating point support for example the gasps limits which in some cases for complex computations restrict the applicability of some algorithms high cost for example we might have something which is doable on chain but it's not really convenient because maybe it end up costing you know three million gasps or something like that so it might be very expensive and of course due to solidity and EVM we cannot use traditional libraries think about financial libraries or all the libraries that have been designed in the last decades also we know we have no confidentiality privacy there are new techniques to get some but they are still quite new and the scalability problems of you know doing everything on the blockchain which typically is not a good idea so we want to solve this and there are different a scalability solutions that we have seen with previous presentations for example true--but is one way to solve this by an iterative process that I've been presented ready the approach I'm going to present now is a bit different it's based on the same security guarantees that Oracle is provides so it's all about proving that a given piece of code has been executed as intended in our notching context without needing to execute the code again so if you think about true--but the way it works is that there is a verification that some operator some agent needs to do so that basically you find out where there is this where the disagreement is on the result so you need to basically execute the code again and again which might be impossible if the process for example is deterministic in in the case in in the design that I will explain in a bit what happens is that the execution is done just once so it's not necessary for the code that we write to have any special property or even to be deterministic we just try to prove that the computation was done in a provably fully lockdown environment that nobody could control so basically what we want is to overcome the limitation that the limitations that we have just seen possibly without bringing too much complexity without filling up the block so without using too much gas basically because we want to keep it cost-effective so we do not want to break the viability of most apps with transaction that cost you know $60 or something like that and we want to keep strong security guarantees or we wouldn't use the blockchain in the first place and yeah we want basically verification without execution so the I will show you first how it's possible to do it so how it works in practice our developer can write a competition archive for the computation data source and then we will see some properties so basically the way on it works starts like this so you need to write down a docker file pay attention because the docker file is not used here to give insulation I statically we have seen that toker does this quite badly so we have seen different different vulnerabilities of docker itself and the solution techniques being used doctor is quite a mess for this design but the reason why we use it here is that it's pretty much the de facto standard for describing an execution context so basically if we wants to write a recipe that describes how we want to execute a given piece of code docker is widely adopted and widely used so here this is very simple this is like five lines of code here we are just saying that we would like the codes to be execute and executed in that reference you know dog here so I want to blah blah we say how we want to initialize the context so we need Python and here we are just describing with one-liner what we want to execute so here we are saying okay I want to execute Rand int function in Python and I want to print the standard output a random number between 0 and 100 so this is very simple but it could be as complicated as complicated as you would like it to be so it could depend on external files on external libraries it could even just be a binary I mean it doesn't really need any special you know configuration due to the architecture this is a very traditional way to execute a piece of code what we do next is just putting the dockerfile and any other file dependency that we need into a very simple archive so into a zip and what we do next is distributing it somewhere so this somewhere could be basically anything but for now what we support is just a PFS or swore so what you see here is basically it being uploaded on a PFS as you know this doesn't guarantee the persistency of the content so you need to guarantee that if I will be available by keeping a node up and by pinning it or by pinning it to a running instance so what happens next is that basically anybody could potentially knowing the ipfs multi-edge in that case could download the content of the zip file will check the docker file and understand understand what we want to execute so this is basically what we need to tell or alkalis so we just say ok here the data source is computation so here we don't want to call out to an HTTP API we want to execute a piece of code so you describe next as one argument the DiMucci hash or a reference of the zip file it doesn't really need to be over ipfs it can even just be you know the sha-256 of the archive and if for reasons oracle eyes already knows because you sent it off chain for example what is if file contains then we'll be able to resolve it so basically here we just need to reference the code you see that this enable basically anybody to that has asked us to the correct zip file to verify that we are referencing exactly that content here potentially you could specify more arguments in case you need it but this is not mandatory I mean it depends on the code you are executing if we look again here we see that there is basically no argument we are just saying we want to execute to get around the number between 0 and 100 if for example 100 was to be an argument then we could refer to it and specify here the input argument so this is just an execution with browser solidity you see here that basically the code was executed the result was 46 and since in solidity we didn't really do anything else this is why we we stood in we saved in storage the random number so yeah this typically takes a couple of minutes to execute and the overhead for the execution is because of the way it works so at the moment the the way it works is quite simple so it's based on the concept explained on Bitcoin talk I think in 2012 or 13 the first time which was called the Amazon Web service sandbox so basically the idea is that by using some API is provided by Amazon Web service we can prove to a third party that a given machine our given instance we spin up is really based on a publicly verifiable snapshot and we can prove basically that according to Amazon the code that executes the machine that executed that piece of code is really fully locked down and there is no way for the operator for whoever created the machine to get access to it and to tamper with the result so for example when you started SSH is disabled the password of the root user is randomized and so on and the doctor file is executed in a way that the input ash that we have specified is verified so basically these are all pieces that anybody can verify and if you trust not a relies in that case but Amazon then you are 100% sure unless there are some bugs in the code that the D result is really coming from there this is based on the assumption that we trust Amazon and this is again as I explained yesterday the same trust lines that we have with authenticity proofs so what we can get to lower the trust involved is using different techniques so for example in that case we can we could use Azure or other cloud platforms that provide similar guarantees and basically the user can choose to execute that piece of code on different contexts we can get the authenticity proofs from each of those and if the result does match then we know that according to three different artists taters the the execution was really that one so this is a compromise that today basically provides a simple approach to delegate of Chino computation of course this is not as trustless as it could be but it has some nice properties basically it being so simple and generic and it was any piece of code to be executed with no constraints of using a custom virtual machine or custom architecture docker which is pretty standard can be used today this is being used already by some projects and it has a very broad approach applicability like before the last art fork we were using it to enable some contrast to use an essay signature verification now this is what is possible to do it natively but it did enable some project to use crypto that was not natively available on aetherium it can be used and it is being used by some banks to integrate into their proof of concepts financial libraries that they are already used to and of course the alternative will just be to have on a centralized server that they managed to execute the same piece of code giving any guarantee at least in this way we prove that according to a different party the execution was correct so we can move the trust away and spread it among different parties the future works on the computation data source are all based on the feedback that we will get we already got some very good ones so please come to me if you tested it or if you plan to test it something that we already have in the workings is as I said the execution in different contexts is so that we can provide different at the state or guarantees and the unseen verificar bility of proofs as we announced yesterday will be available on chain on test mass very soon before end of year so this is already that we already is already pretty much works and it enables the receiving smart contract to verify the proof before using it before using the result long running instances are something else that is quite interesting we already did some tests so basically for example there was a a project where we tested the PayPal payment being done via this system so that a smart contract could prove that there was a fiat payment with some parameters received by a user and it could maybe you know release a token or do something like this accordingly but there are many other possibilities for example the a2 project is using this - in the decentralized exchange at their bidding to prove that the order matching of the decentralized exchange that typically is done of chain is fair so for example you want to prove that you are not doing any front running you are not censoring orders and so on this is something that not even centralized exchange are doing and then supporting different architectures if you don't want docker file to describe the execution context maybe you want to execute something in solidity on the IBM or you want to use the Moxie v8 or CPU or other architectures thank you for your attention you [Applause] [Music]