Scalable Onchain Verification for Authenticated Data Feeds and Offchain Computations

[Music] hello to everyone thank you for having me here today my name is Thomas Burton I'm the CEO of Oracle eyes during this presentation I will start with a brief recap of the Oracle problem and how Oracle eyes is trying to solve it and I will do a deep dive on the authenticity proofs and on how we could verify them on chain so we have already seen in the previous presentations what it means the what the problem the Oracle problem really is so we know that in decentralized networks like on etherium it's really complicated to reach out to external data to data which we find in different contexts is like for example on the web but in general this is something we want because of the centralized applications to have value because those application might depend on external real world data so it's important to define those three different entities as in different Oracle models than others some of those are merged so specifically we know that the data is the any piece of code that requires the external data then we have the Oracle and the data source the data source is not necessarily the same party as the Oracle itself it's easy to define the Oracle as the Oracle is the party that sends the data to the blockchain but the data source might as well be a different party than the Oracle so we have seen in the Thomson Reuters presentation a model where basically the data source and the Oracle are the same entity but in general what we want is be able to reach out to any external data sources without having the data sources to adapt to the blockchain this is because there are so many external data sources available on the internet that is quite quite unlikely that in the short term they will add up to the blockchain they will start signing the data and sending it wherever we need it so the Oracle eyes solution is basically the one of intermediating and so ironically we could say that Oracle eyes is a new type of intermediary in a word that is trying to get rid of them so we see on one side web api so any possible existing data source and on the other blockchains in general so our client stays in the middle and tries to make the two different words communicate so different context is to communicate and exchange data so this is what we call a data transport layer we have seen a lot in previous presentation the problem of trust so of course having a new intermediary implies some trust lines that we have to open we don't want to trust a small startup of 10 people so this is why we add to provide some kind of authenticity pros so a proof of the fact that the data we are sending to the blockchain application is indeed authentic as reported by the external data source and not tampered with by the intermediary which is authorized in that case so in order to do that we send the blockchain not just the result that comes from the external data source but also the so-called authenticity profit so authenticity proofs are a very generic concept what we want to get is just some kind of evidence of the fact that the data fetching from the external data source is indeed honest is not that we want to know that the operator is behaving honestly this is trivial when the data source signs the data unfortunately there are so many different standard standards and proposals to sign data on the Internet that pretty much none of them is being widely used hopefully this will be solved in the future years but in the meantime we know already that some data sources made a choice so for example there is an IETF proposal that is being discussed for several years which is being called cabbage HTTP signatures which is that is seventy duration now this is one possible way to sign the data for the data source there are already several data sources signing the data in this way Oracle I supports it so it means that if the data source you choose on is signing the data in this way you can leverage the Oracle eyes data transport layer and connect this Web API to your smart contrast application straightaway but in general Web API eyes do not sign the data and this is why we need to leverage different techniques we have seen what chain link does with the Town Crier project which is based on Intel SGX this is one possible technology which we can use so trusted computing by Intel SGX but there are many others techniques that can be used Oracle eyes at the moment is using some sandboxing techniques which are backed by software guarantees such as TLS notary and some others that are backed by hardware techniques like Intel SGX or the Qualcomm teehee legend analyst attestation that we have seen yesterday here with Nikolas from Letcher and many others so basically there are many different ways we can give this kind of evidence and this kind of proof and what our class is doing is not using a single technology to do it as as we will see in a minute we believe that that will be a quite a weak architecture so basically what we are saying is that when the data source does not sign the data then we need to use a different technology but which one do you choose well this is a complicated question because every time we use the technology we are really trusting the at the stator so the at the stator is basically whoever designs the technology whoever is providing the technology so think about the Intel SGX case so on paper Intel SGX is very safe for sure is one of the most interesting and flexible technologies for trusted computing that we have available on the market but at the end of the day we need to trust Intel because we cannot verify in our homes if the chip for example is the CPU package is really doing what it is supposed to do we cannot really know if the signature coming from the attestation services is done correctly as intended and in general every time we use one of those technology we are always trusting somebody so Internet even in the case of the ledger proof for example we are trusting ledger in the case of the Android proof we are trusting a Qualcomm and Google for sure so basically by using those technologies to prove the authenticity of the data we are not really giving out a trustless solution we are simply shifting the trust from the central operator which in that case is recognized as most are that startup that we do not want to trust to parties that has something more at stake that have a strong reputation of course if this is all we have this will be quite weak and disappointing as if the solution for the Oracle problem is to trust a single party then we could simply go to that company and ask them to run the Oracle service this would be exactly the same open trust wine and it would be much more efficient however the blockchain was not designed to move the trust away to a single central company right or we will not be here today so by using different technologies we can spread the trust and get more than one proof backing that claim so if we use all the technology we see here for example we are trusting four different companies which in order to provide valid proofs but backed by tamper with data they will need to well basically they will need to lie all at the same time in the same way which is quite unlikely so basically all we're doing here is moving the trust away to different parties by using their technology but without asking them to run the service something that we get asked quite often is wait what but why don't we just ask those companies to come together in a consortium and to provide this as a service they could simply sign the date animalistic fashion this will be trivially doable and this will be much easier right well if they come together in a consortium this is quite weak because by doing that they would show to the world that they have an agreement and if they have an agreement the chain of the different proofs is much weaker as they basically show that they are willing to cooperate so this is why it's much better to have an independent party which is different from all these different technology providers that runs to the service so basically what Oracle Isis is doing is putting in the Oracle eyes engine which is one physical box that we designed all these different technologies all these different trusted computing techniques so that we can provide different layers different levels of proofs and provide this as a service to the blockchain this is something that today we are managing with a distributed network so this is something we fully manage so as we just we have just seen thanks to the authenticity proofs we do not need to trust Oracle eyes but we need to trust all these different artists theaters so the only risk of the central operator of the Oracle eyes service is basically the service to stop running so bad quality of service or maybe censorship or many other of these problems this is why we are working towards a new possibility which is basically delegating the management of the Oracle eyes engine machines to any interested parties that might be willing to contribute to maintaining the service running so this is something that will basically move away the governance of the maintenance of the service from Oracle eyes to a different entity the rest of the presentation is around authenticity proof so I want to dive into the verifications of those proofs so what you see here is the network monitor this is a web-based tool that anybody can use to verify of chain the authenticity of the proofs unfortunately this means that once you have a smart contract like this which wants to reach out to a Web API like crypto compare you specify the proof you want like Oracle is that proof proof type TLS notary so here we are saying we want a TLS notary proof which is software backed and based on the trust with Amazon and we want proof storage AP FS so actually we will not get back the raw proof which will be quite big but just the AP FS multi ash of the same so as a consequence it means that it's not possible to verify with a contract like this the validity of the proof on the contract once it receives the codec function so this is something that is not easier because basically Oracle eyes could potentially send back a Bronk proof and you will just notice afterwards so the interesting part is that anybody can check for the last two years and all all the 300,000 proofs we are sent on chain and you will see that there is none which at the moment is not passing unless there was one while it was on stage but in general what we want is a stronger guarantee where basically the authenticity proofs can be verified by the receiving contracts so let's see what the authenticity proof contains first of all so basically this really depends on the sandboxing technique being used because different techniques need different verification steps however they are all basically a collection of signatures and data to verify some kind of attestation some kind of claim coming from the artists theater still those proofs are general purpose so they have nothing to do with the blockchain in their format we are investigating use cases also outside the blockchain space and they are self-contained so it means that once you have the proof you should be able to extract the full message from the proof itself there should be nothing outside the proof that you need to verify the validity of the proof itself however giving that nature of the proof they might be quite big depending on the data you are trying to fetch from the external data source so this is why we cannot send them every time on the blockchain because it will be a very high cost and well given the gas limit of course this is something that it's not possible above certain sizes so I'm intent is the proofs that we have designed such as the ledger proof for the random data source and the native proofs like the ones where the data source signs the data are trivially verifiable on chain so this is for example a very short piece of code which verifies native proofs on chain as we expect this is nothing really complicated but we see there are different steps like we need to check that the answer is fresh that is authentic and that there is integrity of the proof and other steps for the alleged proof it's even more complicated because we are checking basically that the trusted computing device is really executing the correct code that we expect it to be executed so you see in the code that there is for example our code ash which is the ash of the code being executed which being open source you can verify yourself of chain once there is the public key of ledger which is the one sign the attestation claim and much more both these are already working on chain and the cost is quite reasonable so it's around the 50 thousand gasps 60000 gasp but to be for bigger proofs where we have bigger messages it might not be possible to it to do it so in those cases um we have to think of something different and this is what the proof shield is so the proof shield is basically a new concept where we take the same trust model that we explained before we use exactly the same technology to reduce the complexity of the proof verification down a single signature so basically this is a different application running on trusted computing devices or on other tanks and boxing techniques that we are using so that the complexity of the proof the proof the raw proof we had before is the input of this software and the output is a simple signature which we can easily verify on the blockchain from the calling smart country like with native proofs or with alleged proof so in this case it means that the receiving contract is not the raw proof but the proof shield proof so it's a different problem we solve but when we keep the same open trust line the security model doesn't really change so for example if we have TLS not reproof which is based at the end of the day given its nature to unopened restrain with Amazon Web service well if we somehow leverage a fully lockdown approvable machine running on amazon web service which converts this proof to a single signature then we are still trusting Amazon for that convention for that transformation and the optional verifications becomes possible though so this is something we have written in C is quite modular and portable architecture you can run in different contexts --is it will be open sourced very soon it supports basically all the existing proofs provided by Oracle eyes so all you could put actually use I don't know like ledger device to run the proof sheet to verify an android proof but of course in that case you open a new additional trust range so the optimal case is going to use exactly the same technology and the first prototype will be released on test net before the end of year and it's in the first implementation will be based on as a bolus up so basically it's running on a ledger device and the verification cost again are in the fifty sixty thousand gas range and it can be reduced even more so that basically the transaction verification itself so the signature showing that transaction is coming from a given sender it can be a ready the verification step so in a version two of the proshield we will be able to reduce down the cost of the proof sheet proof verification to basically zero so that is also a really compatible with a ready deployed contract which now are several hundreds on the main chain so so far we are the most widely used Oracle service on the blockchain we yes and three hundred thousand over three hundred thousand queries on the main net and today the range is typically between one and five thousand the transactions per day on the main not only we have integrations also with other blockchains as you can see here but a Tyrian is where we started from and where most of the usage at the moment comes from we are using different technologies and attestation techniques and this is something that we still have in the working sister continues the research problem so these are the things we have in the working for the future so basically we will facilitate with Stargate D using private chains and for in-memory executions and simulations the proof shield I've already talked about the decimal deployment and the version show that we have in the workings and Newton disapproves the reduce the centralization points of the operators of us of our service via the delegation of the management machines to external nodes and tomorrow downstairs in the breakout hall at 3:45 p.m. I will do a deep dive around the oracle eyes offering computations and i will show you something which is quite interesting or the using of this the same technologies and the same trust model to execute obtain any piece of code and say no change as the result also for like non-deterministic pieces of code thank you for attention [Music]