 Hello, everyone. My name's Lawrence. I'm head of research and development at Chainlink Labs. And yeah, today I'm excited to tell you about improving the Oracle infrastructure on Ethereum. For those of you who don't know, Oracle infrastructure connects smart contracts with the rest of the world, with the world outside the blockchain. And so let me start by talking about the most prominent use case of Oracle's data feeds. I'll start by reading a quote. We'll play a little game. You guys can, while I read the quote, guess where the quote is from. I'll give you a few more seconds after I'm done reading the quote, and then I'll reveal the answer. So the quote is, for example, one powerful use case of an Oracle contract would be a hedging contract, where A and B put in $1,000 worth of Bitcoin. And after 30 days, the script sends $1,000 worth of Bitcoin to A and the rest to B. This would require an Oracle to determine the value of one Bitcoin in US dollars. Sounds a little bit like DeFi. The terminology is a bit different from what we would say today. So the solution is it comes from the Ethereum White Paper all the way back in 2014. So already back then, it was clear that Oracle's are required for certain types of applications. And indeed here, we have an example of a price feed or data feed Oracle. And if we think a little bit about the properties that this implies that we need our Oracle to have, there's two things that stand out. So first of all, we need reliability. We need to make sure that when the 30 days are up here, indeed, the Oracle supplies the exchange rate between Bitcoin and dollars so we can fairly settle the hedging contract. And then we also need security and integrity, right? The price that is provided here by the Oracle will be used to settle the contract. And so if the price is incorrect, then we won't be able to settle the contract fairly. So it's essential that we have an Oracle that provides these properties. And I think if we think about the history, since then, billions of dollars have been stolen in Oracle manipulation attacks. So Oracle security is paramount for DeFi. So let's have a look at how one might construct such a data feed Oracle. And I'll start with a strawman construction, and then I'll evolve that construction into what I would say is the state of the art today and is what Chainlink does today. So here in this strawman example, we have a data source that the Oracle observes. In this case, the data source says, hey, $10 is the price. The Oracle will sign that price, and it will then provide it to a contract running on Chain, and then a DAP contract can read the price from our data feed contract. But if we think a little bit about the two properties I had just mentioned, reliability and security, then this system does not achieve them, because we have a single point of failure. If this Oracle goes down or fails to provide the price, then the system on Chain won't work. And similarly, if the single Oracle here is compromised or malicious, then it can feed a false price to the contract on Chain and cause the contract to be settled incorrectly unfairly. So how can we solve this problem? Well, there's a few different approaches that people commonly take, but I think the most common one today is to say, let's decentralize the Oracle. So let's have a bunch of independent Oracles all provide the system together. And so what we've done here is we now have multiple Oracles that each fetch a price from a data source and then send their individual signed observations to a contract running on Chain. And that contract on Chain stores the observations until there's a sufficient number of them, then aggregates them into a single price using a robust aggregation for these data feeds. The typical aggregation one would use for numerical data is to take the median, because that's a robust statistic that doesn't respond to, for example, false outlier values or things like that. And then once we have medianized our value, we can expose it to the TAP contract downstream. And this is nice because we can now handle subsets of Oracles being faulty. So if some of the Oracles here do not send a price, or if some of them send false data, that's OK. If they don't send a price, our data feed contract can just handle that by ignoring a certain number of missing submissions. And if they send a false price, as I had mentioned, we use the median, which is a robust statistic and which ensures that as long as no more than half of the Oracles here are faulty, the aggregate price still lies within the interval of prices reported by correct Oracles. So this works well in terms of giving us the security properties and reliability properties we want. But there's a problem here. If you're familiar with smart contract, notice that we're sending one transaction per Oracle here. We store the submissions in state, and we compute an aggregate on chain, all of which are expensive things to do. And indeed, this is how chain link used to work in the past with a system called Flux Monitor. And indeed, that became prohibitively expensive. And so we moved on to the next generation, which I'll describe now. So I would say that the state of the art then is to say, let's move as much work as possible off chain. The less we need to touch the chain, the more efficient our system is going to be. But we'll want to do this in a way that preserves the security and reliability properties that we desire. And so roughly speaking, what we do here is we again have our Oracles observing prices from their respective data sources. But now we have the Oracles communicate with one another using a peer-to-peer network. And we, for the distributed systems folks out here, have them run a Byzantine fault tolerant protocol. Byzantine fault tolerant means that they can handle arbitrary faults. So any of these Oracles could be malicious or faulty or down or whatever else. And as long as some subset of them is affected by this, depending on exactly how you set up the assumptions, either less than a third or less than half of the Oracles, the overall system will keep functioning correctly. Chainlink's version of this is called the off-chain reporting protocol. And indeed, it's far more efficient than the predecessor I had just showed you. So we realize something like 90% on-chain cost savings. And this is good for security because it means that with the same security budget, we can have a lot more Oracles. So we can tolerate more faulty Oracles in the system. And it's also good for reliability because in this system, at the end of the off-chain protocol, every Oracle ends up with a identical copy of the report, which is signed by a quorum of the Oracles. And the contract will then validate that the report is indeed signed by a quorum of the Oracles. And what this means is that as long as a single Oracle is able to get a transaction on chain, the overall system will keep functioning correctly. And so for example, during times of chain congestion, this is very desirable. Indeed, as I mentioned, this is how the off-chain reporting protocol works. And it's been very successful. So we designed it for powering data feeds on EVM chains. It's been running reliably and securely for, at this point, one and a half years in production. It secures roughly $20 billion of value across all the various chains that chain link is active on. $14 billion just on Ethereum. There's more than 1,000 feeds across all the chains we're active on. And more than 290 of those are on Ethereum. And I think the reliability and security of the system are also shown by the fact that we have major, major DeFi protocols relying on this system, like names such as Aave, Compound, and Synthetics all use this. Cool. So I told you about data feeds. But now I want to tell you that Oracles are about a lot more than just data feeds. They enable, in the general sense, interactions of smart contracts with the outside world. That is to say, things that are outside the blockchain a contract executes on. And so they empower smart contracts to reach their full potential, because now I can do a lot more interesting things with my contract than if I'm just isolated on the blockchain and cannot interact with the outside world. So here are some of the capabilities that are enabled by Oracles. Data feeds I just talked about. Proof of reserve, I can ensure that on-chain assets are sufficiently collateralized by some off-chain reserve of funds by having independent Oracles monitor that reserve of funds and report how large the collateral is. Secure randomness, contract automation, and cross-chain interoperability. I'm going to talk about more later in the talks. I won't go into them now. Fair sequencing, I can use an Oracle network to protect users from toxic MEV extraction by fairly sequencing transactions. I can outsource computation and storage so that I can enable contracts to scale beyond what the EVM provides. As much as we all love the EVM and as much fun as gas golfing is, there are some things that are just a little bit hard to do on the EVM. And then finally, I can also enable Oracles to perform real-world actions. So we actually had a hackathon a couple of months ago inside Chainlink Labs, where we had contracts ordering pizza via the Pizza Hut API to people's houses. So I think that's a pretty neat use case that is enabled here, and that would not be available to contracts natively. And then finally, we can also provide privacy-preserving access to almost any Web 2.0 data. And I'll cover that also towards the end of my talk. So this gives rise to this notion of hybrid smart contracts. And when I say hybrid smart contract, what I mean here is a hybrid system that partly operates on-chain in the form of a smart contract running, say, on Ethereum, and partly off-chain, operated by a network of decentralized Oracles. And so this overall hybrid smart contract is now able to interact with the real world. And so this enables me to do all sorts of interesting things. And let me give you some more specific details on some of these. And I'll start by talking a bit about secure randomness and what that enables contracts to do. As you're probably familiar, there is two on-chain native ways on Ethereum these days to get random values. One of them is the block hash upcode. And that's audit findings. 101 do not rely on the block hash upcode for randomness. Any block producer can easily tamper with that. And now since the merge, there's also a second upcode, prev-randow, which is a little bit better than block hash, but which is still manipulable by block producers. So the output of both of these can be biased. So if your contract needs secure randomness, for example, for running a lottery or for doing a NFT mint where you assign valuable random attributes to your NFTs, these are not good enough. And so on-chain, there's no native capability to get good randomness. And this is where Oracles come in, and Oracles can provide that functionality. So we have a cryptographic construct here that's called a verifiable random function. And that enables an Oracle to provide tamper-proof randomness. And let me explain how that works. So we start here with our DAP contract that if it wants some randomness, can request from another contract on-chain that's part of this VRF service some random words. The contract will emit an event with just telling the Oracles that randomness has been requested. The Oracles will evaluate the verifiable random function, which is based on deterministic public key cryptography. That is to say, the Oracles actually have no ability to change the output. It's deterministic. So based on a given key pair and a given blockchain state, which is used as the input for the VRF, we will always get the same output value, the same randomly distributed output value. And the Oracles will then provide a cryptographic proof that they correctly evaluated the VRF, will send that cryptographic proof to our coordinator contract here, which can cryptographically verify the proof. And if indeed the verification succeeds, then finally the coordinator can send the random output here to the DAP contract, which can then, for example, run its lottery or whatever else. And this is live today in production. If you are writing a contract and you need this functionality, you can use it. And I think there's over 1,400 unique contracts that have used this in the past 30 days. So OK, randomness is cool. Now let me talk to you about yet another use case that is live today and that enables contracts to do more interesting things. And that is contract automation. Once again, I'll return to the quote from the original Ethereum White Paper in 2014. But this time I'll highlight a different part. So here we have, after 30 days, the script sends $1,000 worth of Bitcoin to A and the rest to B. So how does the script do this? How can the script or the smart contract send those funds to A and B? Contracts do not have an ability to initiate their own execution. And of course, I could say, well, I'll just have my users A or B here call the contract after the 30 days are up and then I'll do a payout. And maybe if I just have two users, that's fine. But now let's say I have a lot of users or I want to sweep a bunch of tokens from different contracts into a single pool or whatever other expensive maintenance action my system requires to run, then that will lead to a very poor UX if I put the onus of performing those maintenance actions on the users interacting with my DAP. Because if I'm a user, I now have a non-deterministic gas price. Once in a while when I interact with a DAP, it's going to cost me 100,000 gas. Another time I need to maintain some expensive maintenance on the side and suddenly it's going to cost me 500,000 gas. That's not great. It's also unreliable because I can't really rely on my users calling the contract at a specific point in time. So this is where contract automation comes into play. So once again here, we have a set of oracles or automation nodes that are monitoring the chain. And the upkeep contract here is the DAP contract. And the upkeep contract is just any regular smart contract written in Solidity or Viper or whatever programming language you prefer. And it has a special function called check upkeep. And that function will be evaluated by our oracle network here whenever a new block is mined. But it will be evaluated in a simulated environment using the, say, F call RPC endpoint of an Ethereum node. So we never hit the chain with these evaluations. No transaction lands on chain. And so we can call this on every block without incurring any cost. And so then the programmer of this upkeep contract can basically come up with any arbitrary predicates to decide whether their contract ought to be called or not. And if the contract says no, I don't want to be called. No problem. We just check again in the next block. But if indeed the contract wants to be called, it can indicate so to the oracle network, which will then send a second or will then actually send the first real transaction to the chain that's not simulated with a perform upkeep call for upkeep contract here. And now this contract on chain can take whatever logic it wants to. So for example, in the previous case, at this point, it could have paid out our two users A and B, depending on the outcome of this hedging contract. And again, this functionality is live today. There's over 250 unique upkeep contracts that have been active in the past 30 days. And if that's useful for your smart contracts, then I would encourage you to check that out. OK, so I've been talking a bunch about data feeds and about other oracle capabilities that are live today. But I'm from research, so I'm particularly excited about the future and what future capabilities we're actively working on to bring to market. And I'm going to present two exciting capabilities. And both of them are in an alpha state with partners. So both of them are already working in some form, even though they're not quite ready for mainnet production yet. And the first of these is cross-chain interoperability. So the problem here is that smart contracts cannot natively interact with smart contracts running on other blockchains. But we live in a multi-chain world now, right? There's dozens of chains out there. It's a very heterogeneous environment. Some are L1s, some are L2s, some use the EVM, some don't, and so on and so forth. And so indeed, there's also a lot of demand for bridging between contracts on different chains. So to date, something like $168 billion of value have been bridged. Just in the past 12 months, we've seen over 2 thirds of the total volume ever bridge for something like $115 billion bridged. But also, we have a challenge with security in this cross-chain space. So to date, $2.5 billion have been hacked from cross-chain protocols. And just this year, over 70% of all values stolen in the blockchain ecosystem is from cross-chain hacks. So I think once again, this indicates that security is paramount, but that unfortunately, the current solutions are not yet up to the task. And so we at Chainlink are also working on a solution to this problem, which we call the cross-chain interoperability protocol, CCIP. And so here, we're working on a programmable bridge that enables a smart contract, that contract here, say, on Ethereum to send a message to a contract running on some other chain. And it could be talking to multiple other chains. So here, I have it sending a message from Ethereum to this other chain, B. And the message can carry both data, so some kind of arbitrary binary payload, as well as value, so say tokens. And again, I need oracles for this, because inherently, the other chain B or Ethereum have no way of knowing what happened on their counterpart chain that they want to talk to here. And so oracles can bridge that gap and they can transport information about what happened on one chain to another chain to enable contracts on different chains to interoperate. This is, again, as I mentioned, it's very important that this is done securely, because for some reason here, I were to get false information about what message was created on Ethereum. Then that could, for example, lead to funds being moved on this other chain here when they shouldn't be, and I would have a security breach. If you want to learn more details about this, we just had a talk at SmartCon roughly two weeks ago where we went in more detail about the architecture of CCIP. And it's on YouTube, so I'd encourage you to check that out if it's interesting to you. The second oracle-enabled capability for the future that we're working on is about providing privacy-preserving access to web 2.0 data, to almost any web 2.0 data, to smart contracts. And this is, I think, a super cool capability. At first, it sounds a bit unreal, like, how does this work? How could this be? So let me show you what I mean here. So the fundamental problem is that the vast majority of data is private and is therefore not publicly accessible in the web 2.0 ecosystem. So for example, my online bank account, my Twitter profile, my Facebook profile, my Amazon account, some government website, none of these are accessible by smart contracts on chain, because all of them are behind some kind of authentication wall, right? And I would argue that's a good thing. I don't want my bank account information to be just visible to any contract on chain. But still, it would be kind of cool if there were a way to expose in a privacy-preserving information just the information required to smart contracts on chain, because that would unlock, I think, many interesting use cases, things like decentralized identity, risk scoring, where I can use information about my off-chain behavior to score how risky of a borrower, say, I am, consequently under-collateralized lending, where maybe in order to borrow $100 worth of assets, I don't have to put up $200 worth of collateral on chain or private DeFi instruments where I can have a DeFi instrument where only the parties that are participating in that instrument need to learn what exactly the conditions of it are based on what condition it settled, and so on, to improve privacy on chain trading. And more things that I probably can't even imagine yet. This is a very general technology. And so the technology we're working on here to address this is called DeCO. DeCO was originally researched at Cornell University and IC3, the Initiative for Cryptocurrencies and Contracts. And since then, Chainlink has pushed the project forward, is actively developing it and further researching it to make it efficient and practical. And so I'm briefly going to describe to you how DeCO works and what properties it avoids, first in the abstract and then by going through an example. So we have three off-chain parties here. We have a web server. We have a prover or a user. And we have a bunch of verifiers or oracles. And so now what DeCO enables the user to do is to prove to these verifiers and then, by extension, to the smart contract that some data indeed comes from a certain web server. So for example, I can show that indeed, bank.com made some statement. We assume that this web server runs TLS, which is the standard protocol for securing communications on the web today. Whenever you go to some website, you'll probably see a little lock icon in your address bar indicating that the connection is secured with TLS. So I can prove provenance. I can show that the data indeed comes from a certain source. But I can do this in a privacy-preserving way, where I can run a zero-knowledge proof protocol to only reveal the information, the minimal information, that I want to reveal to the verifiers and then, by extension, again, to the contract. And so the web server, obviously, if it's, for example, my bank knows my balance and my password. I, as the user, also know my password and my balance. But the verifiers or oracles, for example, should definitely not learn my password, right? And Deco enables me to do this in this privacy-preserving way. And then finally, and I think this is actually the coolest property of Deco, it's compatibility. So it's compatible with the existing TLS web ecosystem. And that means that there's no need to get, for example, the data holder here, the web server, to change anything about their API or their stack. They don't even need to know that Deco is being used to prove something. And if you, for example, look at how hard it is to get the internet migrated to IPv6, you know that protocol upgrades are very difficult. So it's, I think, a game changer here that this works with the existing web 2.0 ecosystem without requiring modifications on the part of the web server or the user. So let me show you an example. So I'm the prover. I'm the user here. My name's Lawrence. And I want to show to a contract on chain that my bank account balance is greater than $1,000 without revealing anything on top of that. So what I'm going to do is I'm going to connect using TLS, indicated by the green locks here, to the API of my bank using TLS. So I'm going to say, hey, I'm Lawrence. My password is Hunter 2. What's my balance? And now the bank API will respond, hey, Lawrence, your balance is, say, $5,000, which remember I do not want to reveal to the firefighters or to the contract. As part of the way the handshake works here between me and the banking API, I'm also able to, just as part of this TLS exchange, ensure that the verifiers or oracles here get a cryptographic commitment to the data that is being exchanged. That commitment is, as we say in cryptography, binding and hiding, which is to say so you can think about it as an envelope where I put some data inside. If you just have the envelope, you cannot see what's inside, but you also cannot switch the contents without somebody noticing because you kind of tore the envelope. And this is basically a similar thing here. So the verifiers hold a cryptographic commitment about any data that was exchanged within the session. So I, as the user, cannot alter the data after the fact. But the verifiers do not see what's inside the commitment. The commitment is hiding. So they have not learned at this point any private information, any information at all about what was in the TLS session. And so now we get to the final step, which here I'm abbreviating with ZKP magic because I have like two minutes left on this talk. But the way this works is that we now run an interactive zero-knowledge proof protocol between the prover user, so myself, and these oracles. And as part of that ZKP protocol, I can convince the oracles cryptographically that indeed, for example, this statement holds so that my balance is greater than $1,000. But that is the only thing they will learn. They will not learn my credentials and they will not learn my precise balance. The oracles can then cryptographically sign an attestation that they have successfully verified the zero-knowledge proof. And this attestation can be forwarded to our smart contract on-chain here. Again, signed by a chroma of oracles and then we can verify in the contract that indeed those signatures match. And so now I have convinced the contract on-chain that I have at least $1,000 in my contract and I've done that without having revealed any additional information. And you can think about this in a far more general sense because this zero-knowledge proof, I could basically prove almost any statement about the data that was exchanged in almost any TLS session. So this is a very general and very powerful technology, I believe. And I'm excited to see what people are actually gonna build with it because I think due to its generality, I personally have a hard time imagining what's gonna be enabled by it. So yeah, thanks a lot for listening to my talk. There is three things I'd like you to take away. So first of all, security and reliability are paramount for oracles. Second of all, oracles are about a lot more than just data feeds. I think I've shown you a bunch of exciting applications of what oracles can do. Yeah, and third of all, I think we have an opportunity to make contracts more exciting, more interesting to empower them to reach their full potential beyond just doing things within the closed on-chain ecosystem that they would naturally operate in without the data of oracles. So yeah, thanks a lot. And if you have any questions, I think I'm over time, so just come and find me after the talk, and I'd love to chat. You have time, actually. You have time, actually. There's time allotted for your Q&A. So there's room for questions right now. In contract automation, how are the guys' fees paid? Ah, I see, I see, I see. So basically what happens is that the DAP that relies on contract automation, we'll maintain a balance. I don't know whether I can go back to that slide. No, no more. Anyway, so it maintains a subscription balance with an automation registry contract that sits on chain. And then when the DAP is invoked by the oracle network, that automation registry will keep track of how much gas is used as part of that transaction, the perform upkeep transaction, and will, you know, build the user subscription for that. So, and when I say the user here, I mean the upkeep contract. So in that sense, as long as the subscription is funded, we will just automatically, you know, have the contract deduct the price of the upkeep from that. Does that answer your question? Yeah, yes. So you showed us that diagram where the user and the bank API exchange those messages, right? So this is about Deco, right? Yeah, yeah. Too bad we can't show the slide, yeah, okay? So the bank says that the balance is $5,000, and the oracle sees that, but without seeing the balance, right? And then- So the oracle does not see the- The balance. $5,000, right? Yeah. The oracle just has a cryptographic commitment against which we can then perform an interactive $0.00 proof. Yeah, exactly. I'm just wondering how the oracle then can verify that the balance is over $1,000, without like showing that the balance is $5,000, right? Because the exchange was only like containing information about $5,000, and not about like $1,000, right? Right, so my short answer, and forgive me, is just gonna be magic's your knowledge proofs. Basically, that's what DKPs are about, right? I can prove statements about data in sort of very counterintuitive ways without revealing anything beyond the statement. But I think we probably don't have time to go into the details of how that works, unfortunately. But come find me afterwards, and I'm happy to talk more. So I have a question about the OCR, the off-chain oracle reporting protocol. So with the blockchain, it's easy for the different node to reach consensus, right? Because I can check the transaction signature, they can rerun all the bytecode of smart contract. But with the oracle, how does the different node reach a consensus? Because if it's a data feed, then it cannot compute, right? It cannot compute whether a data feed is cried or not. So I believe that the answer to your question is, OCR is a Byzantine fault-tolerant protocol that is actually the same family of protocols that consensus protocols are from, right? It uses similar techniques, it just has a different goal. Its goal is to provide reliable and secure reports about some data observed from off-chain to contracts on-chain. But it's similar techniques, and so you kind of, as part of how that protocol works, I get that property that the oracles communicate with each other over the peer-to-peer network, and that some of them can be faulty and so on. So you broadcast things, you converge-cast things, you use digital signatures, the usual type of things you would do in BFT protocols. Yeah, I mean, let's say if there's Ethereum or if the other blockchain are different nodes, just have to have a similar result from executing the transaction, have a similar result if a two-third of a node have a similar result, then can reach a consensus, right? But I understand you can use that for the consensus layer, but how could you have Byzantine fault-tolerance for the data field, right? Data fate, for them, but one node say the price of Ethereum is 1,000, another node say the price of Ethereum is 2,000. You cannot, how can them reach the consensus? I think what you're asking is how we reliably aggregate the data inside OCR, is that correct? No, for computation tasks, it's very easy to reach consensus between different computers, because as long as your, as long as the result or computation is the same, if two-third of node computer agreed, like the computation result of one transaction is the same, then you have a consensus, you are fine, you are good, but with data fate, like let's say if one-third of a server or node, China node think the price of Ethereum is 1,000. I see, I think now I get the question. Okay, so basically inside the OCR protocol, which I did not have time to explain in detail here, there is a phase where the different oracles converge, cast their individual observations to each other, and at the end of that phase, every oracle will have assigned observation from every other oracle. So if we have a bunch of oracles in here, every oracle will know what all the other oracles think the price should be, and at that point I can then have everybody compute the same kind of deterministic aggregation function, and I will end up with the same outputs and so I can reach agreement between the different oracles. No, that's not true. Thanks, everyone.