 Thanks, thanks, Ming. Hi everyone. So the problem that we're focusing on is one which we think keeps 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 tokenization, 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 on-chain can interact with and you have the middleware provide those inputs to the contract, those inputs can be any kind of data feed, the IoT input about delivery, 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 tend to draw on my mind is in the web development world when you want to build an application you have a ton of APIs you can connect to a contract, right? In the smart contract development world right now due to the lack of on-chain 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 Uber or any number of other web applications, they put a GPS API, any number of other APIs 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 make the relevant outputs without them figuring out how to make that connectivity work at a very deep level, right? That's what blockchain middleware as a general solution provides, right? The benefit of 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 the contract, the contract itself and the output can all be trusted at a very high level of tamper-proofness. 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-proofness and the security guarantees we all value in that contract while the centralized oracle triggering this highly tamper-proof decentralized computation is not tamper-proof, right? So the setup 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 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 the attack vector that we think is 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 approach that we advocate to this problem is two-fold. The first part of it is decentralization. So we apply the idea of decentralization to oracles to blockchain middleware 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 node operators as they want two, five, ten, fifty, a hundred. However much decentralization they want at this level of middleware they can now acquire to give them guarantees about tamper proofness 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 decentralized oracles, they can all acquire data from five separate data sources. If that's something that your use case needs. So there's going to be an entire spectrum of use cases that do and don't need this but in our opinion the high value use cases are going to want to provide a high level of tamper proofness through decentralization which is what 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 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 on-chain contracts and the off-chain implementation of the middleware and we believe that a shared large community of people working towards a blockchain middleware that can solve this problem will make a blockchain middleware that payments processors, data providers, e-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 centralized manner that allows the people with the data resources, payment resources, e-signature resources, various other APIs to be able to provide those services to contracts so those contracts can then do something much more meaningful. Now the second part of our approach after decentralization in open source is the application of trusted hardware. So trusted hardware provides certain tamper-proofness guarantees. In this case applied to oracles, those guarantees extend as far as the node operator will not know what they are running, the node operator will not be able to tamper with the data, the node 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. So the application of trusted hardware and its new recently evolved form in terms of Intel SGX is something we think has a lot of merit and is an approach that can create a decentralized oracle network where you can sufficiently trust the independent node operators to execute the acquisition of data 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 off-chain computation in this same oracle network. So the oracle network can now become a layer of off-chain computation around the data it acquired for intensive computations that you can't or don't want to do on-chain. So to dive a little deeper into trusted hardware and why we think it's an interesting approach, the main premise on 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 enclave and it can decrypt it and run and make outputs and the operator of the node running something like Intel SGX can't tell what's going on, they can't acquire private information and once again all they can really do is turn it off which becomes immediately apparent. Now the approach 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 we're very lucky to be working with 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 oracles. It basically allows a contract to talk to an 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. In this case the requesting contract is the Town Crier contract which then kind of is the on-chain bridge from the enclave into the user contract. It's a very common oracle setup but the difference is that the enclave provides this tamper proof guarantee. In our opinion when you look at how do we make smart contracts useful? What is their unique value? It's the fact that they're tamper proof, tamper resistant, kind of these unstoppable financial agreements and as tamper proof as we can make something like the triggers of those agreements is probably the right direction to go in 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'll 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 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 oracles 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 going to execute at time X? At that point the counterparty in this case Bob receives back an encrypted blob which he can decrypt because he has the relevant private key. So 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 a format they're already used to working with that that compiles down to EVM bytecode. They've put those oracle instructions into the the 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 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 check that anytime I would like they can go submit the query ID and receive both the encrypted blob and then attestation 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 whatever 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 given under certain conditions of encryption or other things. Due to the privacy of SGX you can basically acquire some amount of surety that 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 contracts 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 solidity you're gonna have an off-chain part the off-chain part is gonna is gonna make all kinds of off-chain requests that will 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 EVM bytecode. You're going to run it into an SGX enclave and then that SGX 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 thinking here is that you don't learn a new language for oracles or anything super specific 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 any other system that has their own blockchain middleware that represents their services right and then also 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 your off-chain 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 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 decentralized consensus about about the execution of 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 proofness 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 on-chain contract to represent an off-chain resource so that a smart contract developer no longer needs to learn APIs they have an entire list of contracts on chain which we call chain links but you know are basically oracles that represent every type of data off-chain payment mechanism e-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 the world of secure end-to-end smart contracts is the world we'd 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 to discuss this and we're also working on this in an open-source manner and looking for for interested folks to join us to solve this problem so thank you