 So during this presentation, I will speak about the Oracleize Oracle solution and some of the things that we have in the workings. So given the circumstances, there are many smart contracts that need to get external data, think about web APIs or from any data source. Still decentralized networks like Ethereum have the inherent limitation in not being able to reach out the internet. So smart contracts live like in a world garden and they cannot simply open a socket and fetch external data. So this is why there are many different solutions called as Oracle's to pull or push data, external data to the blockchain. So we'll focus during this presentation on the first approach listed in this slide. So this is the one used by Oracleize. 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 it 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 attestators are. So this is the logic flow. What you have is smart contracts sitting on Ethereum that can reach out the internet via Oracleize. The way they do so is simply by using the Oracleize query function. So this function essentially is an event. So our off-chain engine can listen to these events and fulfill the request. So essentially we are the one opening 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 there are different approaches actually to implement these authenticity proofs. So these authenticity proofs are cryptographic 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 Oracleize initiate a TLS session with a web service, the client's secret is split in half so that Oracleize just has half of it and the other half is secured by 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, you can check out the paper that we are releasing this afternoon, is based on a different approach. So the first one, the TLS notary one, is essentially a software attestation. This one is an outdoor 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 solution, and Android safety net. So by using both of them, we can basically verify that there is an open source piece of code fetching the data from the web service, which is running in a secured, outdoor backed, 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 Criplets presentation. Intel SGX, again, is capable of verifying that a given piece of code, a subset of C, essentially, is running in a secure Intel CPU backed sandbox. And there is the Intel signature on the correct execution of the code. So this process is essentially called Enclave Remote Attestation and works via the Intel Attestation service. And we use this to solve one of the very issues that we have seen in the last few days in many talks, which is the difficulty of getting reliable on-chain random data, random numbers, right? So with the random data source that you can use via replies, 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 random if you do trust the Intel solution. So again, here, we have just seen two different attestators, so Google or Qualcomm, if you want, and Intel. So what we have seen so far with all these three different authenticity proofs is attestation as a service, essentially. So different kinds of 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 trusted companies or attestators, in this case, are less likely to act all as backed actors compared to a network of untrusted anonymous players. So via 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, et cetera, on the same request, meaning that if all the proofs are valid and the result has still been tampered with, it would mean that at the same time, at the same exact time, 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 and that it's available in our documentation is the off-chain computation. So this is yet another solution to the limitation, the constraints of DVM, 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. And what we do essentially is extending the base Amazon Web Service Sandbox concept introduced by TLS notary, and with this extended concept, you can execute in a safe Amazon Web Service backed lockdown instance any piece of code, and you can get out on authenticity proof. So this authenticity proof can be verified by anybody, and the way it works is that you define a receipt. So there is an example here using, for example, the Python NumPy library, and we can get the result out. We distribute it over IPFS, and in the Oracleized query, we specify as data source the computation meta data source, and as query, we specify the IPFS multias. So what happens is that Oracleized that does initiate the secure instance, generate the honesty proofs, and the verification steps are essentially based on an extended verification of the authenticity proofs that I have just explained before. 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 challenge game, but it's more like an auditor-based approach. So thank you 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. Thank you very much, Thomas.