Secure Decentralized Oracles: Applying Intel SGX and TownCrier to external data...

[Music] thanks.thanks me hi everyone so the the problem that we're we're focusing on is one which we think keep smart contracts limited to tokenization right if the native functionality you have when you start working with a smart contract network is the ability to make tokens that's the functionality you'll start working with and you'll do a lot of interesting things with it but the capabilities of smart contracts go far beyond to organization there's enough logic to mimic and eventually replace the majority of digital financial agreements those agreements as they're structured will need triggering events so they'll need inputs into the application and they also need to have outputs as a form of payment right so in our opinion one of the very large limiting factors for the creation of interesting real-world use case smart contracts is their ability to step beyond tokens and interact with external inputs and external outputs in a meaningful manner right so the approach to solving that problem is basically middleware you create a piece of middleware that takes the external inputs turns them into something that the contract Unchained can interact with and you have the middleware provide those inputs to the contract those inputs can be any kind of data feed IOT input about delivery any any input that application needs likewise the middleware can provide outputs into relevant payment systems now right now there isn't a large amount of these capabilities and the parallel I tread tend to draw in my mind is in the web development world when you want to build an application you have a ton of api's you can connect to a contract right in the smart contract development world right now due to the lack of unchained contracts that represent off chain resources it's very difficult for a smart contract developer to get access to the inputs and the outputs they need to make an application right like the people that made Ober or any number of other web applications they put the GPS API any number of other api's together with their core application and then they had a payments output in a payments API right it should be just that easy for a smart contract developer to take inputs combine them with their core application in the form of a smart contract and then have that smart contract to make the relevant outputs without them figuring out how to make that connectivity work at a very deep level right that's that's what blockchain middleware as a general solution provides right the the benefit of a blockchain middleware for a smart contract ideally would be that it maintains the same level of security as the contract right you don't want a contract that's highly secure that's triggered by a highly insecure system and that pays out through another highly insecure system if you have a very secure middle part of the end-to-end setup and the inputs and the outputs are insecure it's unlikely that digital financial agreements of large value are going to transfer from the legacy world into the smart contract world right so as a community or at least we as a group of people are very interested in solving this problem of how do you get a smart contract to do something meaningful relative to the real world but also to do it so securely that the input of the data that triggers their contract the contract itself and the output can all be trusted at a very high level of tamper-proof enos so to understand what our options are in this problem it's good to look at like what is some of the current approaches one very common approach is basically the use of a centralized Oracle so that is the approach where either an individual in the contract runs an Oracle one of the counterparties or possibly a service in any case there's a single centralized Oracle that acquires data as a trusted third party and gives that data to the decentralized computation Network to process it right the problem with this in our opinion is that the decentralized computation network has thousands of nodes which provide the tamper proof nests and the security guarantees we all value in that contract while the centralized Oracle shrivelling triggering this highly tamper proof decentralized computation is not tamper proof right so the set up end-to-end at this point is not tamper proof it's not going to appear very secure it doesn't provide the tamper proof guarantees that that we think are important for smart contracts to have a unique value right and so this attack vector of how do you attack a contract that has one node triggering the key events is is the attack vector that we think is worth worth seriously considering everything from DevOps problems with that one node to somebody genuinely attacking a single node to stop a contract from running on you know could be a million nodes it doesn't matter how many nodes are in the decentralized computation environment if the trigger is attacked and compromised and doesn't happen the contract won't trigger so the the approach that we advocated this problem is twofold the first part of it is decentralization so we apply the idea of decentralization to Oracle's to blockchain but aware and we create an Oracle network that is able to process and acquire the data using multiple independent node operators those independent node operators can be selected by the person making the contract and they can select as many note operators as they want to five 10 50 100 however much decentralization they want at this level of middleware they can now acquire to give them guarantees about tamper proof venus in terms of their inputs this ability to decentralize the blockchain middleware layer the Oracle layer also gives you the ability to now contract with multiple data sources in our opinion it doesn't make as much sense for one node to use five data sources you centralize the data at the level of the origin but it's still going through one point of failure now once you have for example five separate decentral doricles they can all acquire data from five separate data sources if that's something that your use case needs so it's there's gonna be an entire spectrum of use cases that doing don't need this but in our opinion the high-value use cases are going to want to provide a high level of tamper-proof eNOS through the centralization right which is which is what we we'd like to enable so that the end-to-end setup is sufficiently secure for people to trust it to put actual money into a smart contract for things to go to production the the other part of our approach is that it's open source and we believe very strongly in open source and security reviews through open source both on the level of the Unchained contracts and the off chain implementation of the middleware and we believe that a shared large community of people working towards the blockchain middleware that can solve this problem will make a blockchain were aware that payments processors data providers these signature providers various API services will adopt because they don't want to build their own middleware they just want to sell their services and they constantly buy things that just let them sell their services so what we should do in our opinion is that if we as a community are interested in this problem we should solve it in the decentralized manner that allows the people with the data resources payment resources each signature resources various other api's to be able to provide those services to contracts so those contracts can then do something much more meaningful right now the second part of our approach after the centralization and open source is the application of trusted hardware so trusted Hardware provides certain tamper proof nice guarantees in this case applied to Oracle's those guarantees extend as far as the note operator will not know what they are running the note operator will not be able to tamper with the data the note operator will really only be able to turn off their node and that will be an immediate signal and with even basic reputation systems they won't participate in future inputs into high-value contracts right so the application of trusted hardware and its new recently fall form in terms of Intel SGX is something we think has a lot of merit and and is an approach that that can create a decentralized oracle network where you can sufficiently trust the independent node operators to execute the acquisition of data and the act and the execution of payments while not knowing important things like your payment credentials or what data they're executing another very large benefit is the ability for you to do all chin computation in this same Oracle network so the Oracle network can now become a desire of all the same computation of around the data it acquired for intensive computations that you can't or don't want to do unchanged so to dive a little deeper into trusted Hardware and and why we think it's an interesting approach the the the main premise underlying trusted hardware is that compared to previous approaches like various HSMs various data rights management modules it has a smaller trusted computing base so what that means is that privileged system code like the OS and BIOS are no longer attack vectors for something like an Intel SGX Enclave what that means is that you can give even encrypted code into the the Enclave and it can decrypt it and run and make outputs and the operator of the node running something like until SGX can't tell what's going on they they can't acquire private information and once again all they can really do is turn it off which becomes a me immediately apparent now the the approach that that we're adopting towards trusted hardware in the context of a decentralized oracle network with the help of the very smart folks at ic3 who were very lucky to be working with our is called town crier town crier basically applies Intel SGX which at this moment appears to be the leading trusted Hardware approach to the problem of secure tamper-proof Oracle's it basically allows a contract to talk to an INT SGX enclave that then using the existing TLS scheme can acquire data from a data source and then provably return only the value that it acquired from the Enclave into the requesting contract right in this case the requesting contract is the town-crier contract which then kind of is the unchained bridge from the Enclave into the user contract right so it's it's a very common Oracle set up but the the difference is that the Enclave provides this tamper proof guarantee right so in our opinion when you look at how do we make smart contracts useful what is their unique value it's the fact that their tamper proof tamper resistant kind of these unstoppable financial agreements and as as tamper proof as we can make something like the triggers of those agreements is probably the right direction to go in and and those two approaches once again one is decentralization and the other one is the application of trusted hardware now how this would look if trusted Hardware works and everything works out properly is that a user shows up and says I have a very large computation that needs data I'm going to give that computation into the the relevant node the relevant node is going to take that computation and run it in the Enclave inside an EVM right so there'll be an EVM running inside the Enclave the EVM will run the computation and it will run it privately such that even the node operator can't acquire the data if and then they'll return a query ID the query ID is what's used to pay the contract and it returns relevant information for payment after that well what happens is let's say one of the counterparties wants to know what is this Oracle doing what is this decentralized oracle network or this set of Oracle's that is that are going to trigger the agreement that I'm a part of what actions are they actually going to take can you please return to me the code that you're gonna execute at Timex at that point the counterparty this case Bob receives back an encrypted blob which he can decrypt because he has the relevant private key so in in this scenario what's been done is that the creator of a smart contract has written in Oracle instructions in this case in solidity so they've written Oracle instructions in in in a format they're already used to working with that that compiles down to EVM byte code they've put those Oracle instructions into the V Enclave they've set it up to trigger their contract without the node operator knowing they've done this with anywhere from 5 10 15 20 in the individual node operators so that if one fails or if one is attacked it doesn't it doesn't compromise the execution of the contract and then they've done it in such a way that if their counterparty wants to know what is the Oracle setup we're using going to do at time X let me randomly checked at any time I would like they can go submit the query ID and receive both the encrypted blob and then anta station from the Enclave proving to them that the execution that is supposed to happen at time X is is going to happen right so at this point we we have multiple node operators executing a valuable off chain operation and we have them being able to prove it to the other parties in the transaction the the benefits of this approach in our opinion are basically that you can have very scalable execution off chain you can put put a well not anything but but definitely much more much more intensive computations into SGX and very possibly things you would never want to be public of and under certain conditions of encryption or other things due to the privacy of SGX you can basically acquire some amount of surety that's the node operator that you've given the code to hasn't hasn't acquired it and you can also do very interesting things such as have smart contract control private keys so how we think this is going to evolve is that you're going to write one big one smart contract in in two parts right you're gonna have an off chain part both of them written so that you can have an off chain part the off chain part is gonna is gonna make all kinds of all chain requests that look like this and require all kinds of computations you're gonna write it in solidity or whatever language you'd like that goes down to the VM bytecode you're going to run it into and and an SGX Enclave and then that as G ox Enclave will have capabilities such as the control of a private key or the ability for the SGX Enclave to make a direct request to a native OS library for something as useful as randomness right so the the thinking here is that you you don't learn a new language for Oracle's or anything super specific you you continue writing in the language that you're writing your contract in but you have an off chain portion the off chain portion relates to your acquisition of data and your computation around that data and then the on chain portion is what you have on chain that is presumably triggered by that on chain data but by the off chain data that that reaches it and then presumably you have another section to the contract where you have off chain payments where you want the contract to send some kind of payment message to a payment network or a bank or or any other system that has their own blockchain middleware that represents their services right and then also if if you want if you want key resources such as randomness or any other number of resources that can be provided from a native OS library that's been widely used and tested you can acquire it by directly messaging within the Enclave so there's there's entire subsets of of what you're all chained computation can have within the Enclave by having it message something like a native OS library from randomness eliminating certain scenarios where you would ever need to use a service and you you kind of get the tamper proof guarantees both on the level of the data acquisition and also on the level of this native OS library once again also very possibly run in multiple nodes and those nodes being able to come to the centralized consensus about about the execution of of that computation and even the acquisition of randomness now the the reason we're we're kind of applying this level of stringent security and tamper proof Ness is that the world we'd like to be in in a year or two years relatively soon is is the ability for a contract to reach out to another contract on chain and for that Unchained contract to represent an off chain resource so that a smart contract developer no longer needs to learn api's they have an entire list of contracts on chain which we call chain links but you know are basically Oracle's that represent every type of data of chain payment mechanism is signature basically any any web service that a web developer gets access to to build their application is a service that a smart contract developer should be able to get access to from a contract on chain and and that's the that's the quick prototyping world we want to be in for people to build killer applications of smart contracts by focusing on their core application and getting all the inputs and outputs they need while making sure that those inputs and outputs are sufficiently secure that their end-users the other parties in the agreement trust that the source of the inputs the method of input the contract itself the method of the output is is sufficiently secure to trust that end-to-end setup right the the world we want to avoid is one where you have a highly secure decentralized computation that is then triggered by highly insecure services which once looked at lead people to not put any real value in the contract right that's the world we want to get away from and the world of secure end-to-end smart contracts is the world like to approach if you'd like to know more you can find the technical details in these two papers and we're always happy to discuss this and we're also working on this in an open source manner and looking for we're interested folks to join us to solve this problem so thank you [Music]