 The problem we're going to be discussing is what needs to happen for smart contracts to make meaningful events happen in the real world and how those smart contracts can know that contractual performance has happened. This is really important because without contracts knowing what's going on in the real world and without contracts being able to affect real events, they're limited to tokenization and they don't really reach their full potential in our opinion. So to grasp kind of the full value we see in solving this problem, I think it's useful to take a look at this from a historical context. So from a historical context, we all started out with kind of multi-signature as the model for smart contracts back when basically Bitcoin existed. Then we moved to a protocol level or opcode level version of smart contracts where smart contracts were written into a protocol in the form of up and so you couldn't really go beyond what the protocol allowed you to do. It took months to get new functionality into a protocol and if you wanted to write a new contract, you were kind of out of luck unless the opcode for your contract type already existed. So this was called, you know, the Swiss Army Knife approach and so there was a large incremental gain when we went from just signature, multi-signature type of contracts to an opcode-based contract. Then Ethereum does deserve a lot of credit for taking contracts from the protocol opcode level over into the world of scriptable smart contracts which is the world we're now becoming more used to and this world of scriptable smart contracts provides a lot of flexibility and a lot of new features that have pulled a lot of people and created a lot of useful use cases, right? So you no longer need to ask somebody to add a smart contract type at the protocol level, wait months for it to get merged in, experience a hard fork possibly to get it working. You can now code up a contract without having to do anything at the protocol level and this conference and the wide kind of panoply of projects building different things speaks to the benefit of these additional features, right? So smart contracts in our view keep getting up to more and more the more useful features they have, right? So this is the most recent development for how smart contracts have leapt forward. We feel there's another leap forward. So the next leap forward is taking scriptable smart contracts and allowing them to meaningfully interact with external information and events. So basically you can write a scriptable contract right now and it'll look very similar like the one I have here up the screen where it's basically tokenization and movement of tokens among parties and that's what your contract will be limited to today. Now the next leap forward in actual value and features and capabilities that we're hoping to help people attain is the ability for scriptable contracts to know what's going on in the real world and for those contracts to also be able to do whatever the application that the centralized application wants them to do. Whether that's sending payments, notifications, affecting real world events we think this is the next large leap in value that's going to take us from smart contracts seem only to be useful for tokens to smart contracts are the standard form of agreement for securities, derivatives, prediction markets, insurance, trade finance all these industries that require their contracts to know what's going on and require their contracts to be able to make useful events happen. Now to get to that value we basically have to look at the smart contract connectivity problem or the oracle problem or whatever you want to call it it's basically the problem that neither Ethereum nor any other chain you basically work on right now is going to allow you to reach out and know what's going on in the real world. So if you have a contract for delivery your contract can't know that a delivery happened. If you have a contract for something related to market data your contract can't know that happened. That's why everybody's building tokens because that's the out-of-the-box functionality they have to work with and when they start to try to go beyond that functionality they hit a wall. That wall is basically the smart contract connectivity and the oracle problem and we are very interested in seeing if we can get the space beyond that wall to see a lot of useful use cases actually do useful things in the real world. So that is kind of the body of work we're engaged in and that we're hoping to see moved forward to the point that there's actual practical implications of real world events being triggered by smart contracts. Now the solution for this problem sounds sort of mundane but it's actually very important. So the solution is essentially blockchain middleware. So what you need to do is you need to designate essentially a trusted third party that acts as the source of data inputs and acts as an off-chain agent for executing various events on behalf of the contract off-chain. Due to the way that decentralized consensus arrives at blocks and putting data into blocks, it isn't really possible for the current mining schemes or the decentralized consensus schemes of today to enable this, right? So you basically need a middleware, you need a third party that's responsible for giving your contract what it needs to know and that's responsible for acting on your contract's behalf to do what it needs to do in the real world. This can be called an oracle, blockchain middleware, a chain link, those are essentially synonymous. So this would allow contracts to know what's going on in the real world, contracts to generate real world events of significance such as bank payments, whatever other events and whatever other system the end user cares about. And it also allows contracts to sign and send transactions to other chains. Now, I think the really important thing to keep in mind whenever evaluating or looking at a system that's responsible for making sure your contract gets what it needs to function and that's responsible for making sure your contract affects real world events is the reliability of that system, right? If we have a secure middle piece, kind of the smart contract language network is where the state is and then we have an insecure triggering mechanism, the end-to-end reliability, the total kind of average determinism and usefulness of a smart contract remains too low in our opinion. It remains so low that it will not be used in many use cases that benefit from the value of the deterministic and highly reliable nature of contracts. So if you're going to trigger contracts using whatever system and you're going to have contracts do meaningful events in other systems, the mechanism by which you do that needs to maintain the overall reliability of your contract. If it doesn't do that, then essentially your contract devolves into something else. It's no longer a deterministic, highly reliable digital agreement, right? It becomes something that is easily basically taken down by either messing with the method of input or however the output completes the contract. So I think what it's useful to do is to quickly look through what are the ways to approach this, what are the wrong ways, what are the right ways. One of the ways we don't think people should approach this is we don't think there should be a single node, right? We're all saying that smart contracts are highly reliable because they're redundantly executed on thousands of nodes according to a protocol. And so because thousands of independent node operators have executed the contract code, what we call decentralized computation, that has made the highly reliable, highly deterministic kind of digital agreement that we're all excited about. If you have that highly reliable agreement triggered by single node, all you have to do is you have to take out that one node. This is kind of the fundamental problem that basically needs to be solved because knocking on the data providers that have been around for 30, 40 years is really difficult knocking on the smart contract network has its own challenges, but taking out a single node that triggers your contract and tells it something happened is not a particularly difficult proposition, right? So the logical approach from our space's perspective to this problem is basically the essential. Just like you pay thousands of nodes to do redundant computations to guarantee determinism of your contract code, you should be able to pay hundreds or however many nodes you want to pay to guarantee the quality of an input and to guarantee that that input is going to reliably trigger your contract. Essentially, that's the basis of our approach. The basis of our approach is people should be able to pay for however much decentralization they want to pay for to reliably trigger their contract, right? However many nodes they need to be comfortable about triggering their contract, they should reliably say, I want this many nodes to reliably trigger my contract on the basis of this or that or whatever collection of data. Now, I think the useful thing is to look at how this would function in practice. So in practice, as an example, if we take a contract for payment, excuse me, we'll see that basically we can, even today we have multiple chain links up. Two of those chain links can verify that something has been delivered, verify that a contract has indeed been fulfilled. You can have them both verify as a condition. Excuse me. You can have one of them verify and another one be a fallback or an error-checking system. Basically, you can reach out to multiple data sources to make sure that the event contract is about actually happened. Verify that the event the contract is about has actually happened. You commonly need to calculate a price you're going to pay. You need to know market data. You need to know how much should I be paying for this contract to be finalized. On that dimension, we basically, even today, can provide you with three or more separate independent, independently run nodes that provide market data. And those market data kind of inputs can be aggregated into a highly reliable proof of what the price actually is. So in this example, you see highly reliable proof that something has happened that the contract really cares about. Essentially what the contract is about, basically delivery. And then you can see that there's multiple data providers and multiple node operators providing a highly reliable input about how much the contract should pay. And then you would need some kind of node that's responsible for paying in the relevant system. In this case, if you wanted to pay out the contract in Bitcoin, you would calculate your Bitcoin at the time. You would know how much you have to pay. And you would be able to sign a transaction that pays out that contract in Bitcoin or dollars or yen or whatever currency you want. So fundamentally, this is kind of the base use case of I've reliably proven that an input is true. And I have functionality to pay people and enact contract outcomes in places that people want me to have those outcomes happen. So this is kind of the fundamental initial value. And the focus of our work at this point is basically creating hundreds upon hundreds of chain links that present every service that a smart contract developer want. So the way the world really should look is very similar to the web development world. So in the web development world, if I want to build Uber, I write my core Uber code and I go to a GPS API and SMS API and a payments API. And in a week, I have some VP of Uber running, right? You can't do that today in smart contract land. We're basically saying that's the problem. The problem, there's a lot of people that want to build great things that are Uber-like or better or, you know, fantastic applications. But they're at the point where they can write their core code and they don't have a GPS API or SMS capability or payments capability and they have to figure all that out. And that's just too much, right? So if we can just give them all the inputs and outputs they need to combine around their core code, we can get to a place where smart contract development happens as quickly and at as high level of quality as web development. And then we can just see a lot of interesting use cases come to life in days, weeks. How long does it really take to build an MVP of Uber with some APIs, right? It doesn't take that long if you have the necessary building blocks. So the basis of our approach is decentralization and then making sure that smart contract developers have the large collection of inputs and outputs they need to build something that truly provides value. And the second part of our approach, in addition to decentralization, is the use of trusted execution environments. So trusted execution environments will provide an additional level of reliability and they will basically harden each individual chain link node against many different attack vectors. And this hardening and additional reliability basically makes the entire system more reliable, more something that can provide provable security guarantees that it can reliably trigger your contract. So it's a very early technology but we think it has a lot of promise. The approach that we've been using and working on together with people is something called Town Crier. So Town Crier was developed by Cornell and IC3 and it was put together by some of the best academic minds in the space like Ari Jules and a lot of other great folks that basically put a great approach together and put it out on production over a year ago. So this is a functioning, well-made, secure approach that reliably triggers high quality contracts like the gas token. So it's, in our opinion, the best use of trusted execution environments in the blockchain space today because it works on production and it's made by some of the best academics in the field. Now, what we're glad to announce today is that due to our very successful collaboration with the folks at Cornell and Town Crier and IC3, the Town Crier is basically going to be joining Chainlink. So what we're doing is we're combining two of the best projects that are focusing on getting data to contracts and we're basically combining them into one great project, essentially Chainlink. Now, the way this really looks from a value perspective is that Town Crier and the academic minds that have put that together have done a fantastic job at making trusted execution environments useful, practically immediately useful and secure on production. That's not something many other people could say. And Chainlink has a unique and high quality approach for making sure that decentralization is a key part and is a way to provide genuine guarantees about reliability. So through the combination of Town Crier and Chainlink we basically arrive at a provably secure, decentralized oracle network. So this combination of features is basically allowing us to arrive at a place where reliably triggering contracts and solving the oracle problem is as close to solved as it ever has been. Right? Thank you. So I think it's useful to, you know, in the time we have left to consider what the actual value of this is and maybe dive into the approach we're talking about here. So the fundamental value of an approach like Town Crier and the use of trusted execution environments is that you have a much smaller trusted computing base, you have a much smaller attack surface area. So instead of an application going into the OS or the hypervisor and then injecting malicious code into your application, you now have something that has a separate memory and processing capacity that is at the hardware level. So now you have hardware level that basically talks to your application through separate call gates and basically a separate hardware level that doesn't touch the OS, doesn't touch the hypervisor code and provides a new level of security. Right? So the fundamentals of the approach can definitely work. There's a lot of smart people working on it and in our specific case I'm just going to quickly walk through some of the key benefits we gain from including something like Town Crier in Chainlink. Now one of the first things to do is to quickly understand how it works. So Town Crier basically works like most oracles. There's a chain contract that's queried by user contract. Then there's a code running in the enclave that retrieves data and uses a TLS scheme to prove that something is happening. And then it sends the signed data from this secure hardware environment back into the contract. So you have the ability to prove that TLS works. You have the ability to sign from a secure, reliable trusted execution environment. Now one of the first great things this does for us is it makes each Chainlink node even if it's run by an independent third party, even if it's run by somebody we don't know or just a node operator who may or may not be malicious, it gives them something that is much more secure than if it was running in a standard setup with Docker or something like that. Basically it gives them a hardened setup with its own hardware that they as a node operator cannot even get access to. So in the scenario where Chainlink node operators are running an SGX node, they no longer have access to what they're running. All they can do is shut themselves down which immediately shows them to be a bad node operator. So what this does is it hardens, it creates confidentiality basically against even the node operator. So that you can have thousands of node operators and all those thousands of node operators could be doing computations, retrieving data, but the only control they have over how that computation actually turns out is zero, short of just shutting themselves off. Now, some of the other large benefits are things like credential management. So if you want a Chainlink node to sign Bitcoin transactions or to send payments into bank systems, that's going to require credentials, passwords and user names and all kinds of credentials that basically affect payment. The more secure environment you have to hold those credentials, the better off you're going to be because those credentials are worth a lot. Those credentials are worth the money they control. So this basically creates an environment that adds another level of security and increases the overall reliability of the network. The other really interesting thing is that this gives control of private keys to third parties that can use those private keys to sign transactions on other chains or other infrastructure on behalf of the contract. So now a smart contract can have a Chainlink node that holds private keys that it's responsible for using on behalf of that contract, which is a pretty unique piece of functionality that we don't have time to go into all the benefits, but if you've ever thought about using that, you'll see it's a big deal. So the other thing that this provides is it provides an off-chain code execution environment. So basically, you now have a place to execute smart contract code privately. You have a place where you could take smart contract code and you could run half of it on-chain and you could run half of it off-chain. And if you run it off-chain, you run it in the secure environment. In this environment where you could send it out to 50 nodes and the off-chain code you sent out encrypted to the 50 nodes, those 50 node operators won't even know the code they're running. And you'll get the scalability benefits and the confidentiality benefits of being able to use a system that isn't the very costly on-chain system. So you basically get an environment where you can do some computation in a Layer 2 system that initially is focused on the data but can expand to whatever computation you feel is useful. Now, the other really, really big benefit of having a trusted execution environment how is your off-chain agent? I mean, really, that's probably the best way to think about this. There's an off-chain agent that's responsible for making sure what your contract should do actually happens. And we want that off-chain agent to be as reliable as possible. Now, one good example just to put this in context is if you had something like a lottery contract which was a large amount of current mainnet traffic and you wanted randomness, you could have that randomness generated right in the trusted execution environment using the most common best-tested libraries. You would generate that randomness and you would send it back into the contract from this highly reliable environment which would give you the randomness that the contract needs to basically function. I mean, a lottery contract is basically just taking people's money and guaranteeing them some amount of randomness. Now, let's say you were able to get this set up and you had the randomness number going into your contract and generating the randomness you need for people that your lottery contract is reliable but realistically, you wanted to have a level of decentralization that provides even more guarantees. Those additional guarantees is basically where the chain-link approach really comes in. If you want multiple independent node operators to guarantee the quality of a critical input into your contract, such as randomness, you can now purchase however many independent node operators you feel you need to have the security you need about an input. This is a big difference. This is a big difference from I can only use one node or I can run an Oracle or I don't know what I'm going to do so I'm not going to build the application I want. This is, okay, I can give people a reliable contract in this system over here and now I have a system that can reliably trigger that contract in a way that maintains its overall security. And then I have systems that can reliably pay and affect the contract's settlement and outcomes in all the places that I want it to happen. That takes us from let's write contract code that moves information and tokens around to let's write contract code that reacts to valuable external events and affects valuable external events. So the fundamental gist of the approach is decentralization, multitude of inputs and outputs, allocation of trusted execution environments through Town Crier, which we're very happy about the fact that they're able to join us and that we're able to together work on a much better and much stronger approach. And fundamentally speaking, the next steps for us are continuing to include other great developers in the project, continuing to build out the core functionality, a large collection of chain links and making sure that when a smart contract developer sits down and wants to build a complex, externally connected application, they can do that in a day. Somebody can sit down, write their core code, and in one day they can get all the inputs and outputs they need connected to their contract code and broadcast and have that contract working. And then also turn around to whoever they want to show that contract as being reliable and say to them, here's why you should believe that my contract is reliable. It runs in this reliable way. It runs in this reliable system. And then I can provably and reliably tell you that it's going to actually conclude and pay out the way it should. So that's... I mean, yeah, that's the body of work where we're very focused on basically getting people to the point where they can do that as soon as possible. And if you folks here need some functionality like that, we're thrilled to talk to you. We're doing all of this basically with applications. Really, that's what our team is excited about. We want to wake up one day and we want to see like hundreds or thousands of great contracts that do something really meaningful in industries other than token movement. That would be a great thing, in our opinion. So, thank you.