Why Web3 Needs More Oracles - Chandler De Kock

ETHDenver 2022 · February 2022 · 16:56

Chandler De Kock, growth strategist at UMA, argues that Web3 needs oracles flexible enough for generalized contracting, not just price feeds. He explains UMA's optimistic oracle: a requester asks a question, a proposer answers, and the answer is accepted unless someone disputes it, sending it to UMA's slower DVM resolution process. That dispute step gives protocols recourse when data is wrong or a hack occurs, and data only goes on chain when it is needed. He lists uses such as prediction markets, insurance, rewards as a service, KPI options and synthetic assets, then turns to layer 2: a bridge verified by the oracle, and cross-chain checks that let projects keep vote-escrowed tokens on Ethereum while voting on L2.

Speakers

Topics

From ETHDenver 2022, hosted by ETH Denver.

Transcript

all right hello um yeah thanks for having me here today i am chandler i am the growth strategist over at uma and today i want to talk to you about something that i've been thinking about for a while and that is the idea of why web3 needs a different design space for oracles and wanted to talk through some of the stuff that we've been doing at umam and give you some inspiration from a development standpoint and also kind of yeah and also from developer standpoint on the hackathon to have a kind of better ideas on what you can do with oracle's and kind of just yeah we're going to chat about a few things here so my statement here is that oracle's need to be flexible enough to create a

generalized contracting uh past just kind of price fees or data feeds the the standard mode the standard modus operandi of how like oracle's work these days is that prices are prices and data are placed on chain and there are some inefficiencies around this which would kind of like walk through so for like a general understanding of what an oracle is meant to do um the job of an article is really to bring some sort of data on chain you can do this trustlessly it can do this in a trusted way and the most kind of interesting fact that we've seen with the evolution of oracle so far is that the general crypto space has moved away from trusted oracles which is a good thing but we kind of want to make sure

that we have like a further improvement on the space and we'll kind of walk through what we think a different oracle design can have on just the efficiency layer and then kind of like the the concept of having an oracle like live above the the um the deterministic consensus layer is kind of where uh um will fit in so if you think of a price feed a price feed oracle really is just a different version of a deterministic uh like consensus mechanism that really doesn't deviate too far from just what its one intended use is and that that's kind of where the inflexibility of the current price feed implementation of oracle's kind of like stems from and so if we kind of just assume like

oracles bring data on chain and you look at like all the data that exists in the world some data a little bit more valuable than others right and so really the the concept of having like long tail dead is something i'm going to like touch on in a little while but the current like oracle space and what what like what i tend to think of is like proof of work style oracles are the pricey style oracles these kind of have a mechanism on chain data being pushed regularly using some sort of decentralized consensus mechanism these type of articles has been the powerhouse of defy so most of what we see in d5 today are because of these price feed articles and they're super valuable and they're super important for maintaining like

true systems but these aren't really scalable for things outside of just d5 they're slightly inefficient on the gas level um and they're not inflexible enough to come encompass things that everyone might not need but they might actually want to have that sort of data for their own application specific implementation and so if you look at that like i kind of think of just defy as a small segment of what the whole ecosystem can do and so the real trick of what we want to try and do here at uma is build out what that would look like past just prices and so this sort of idea of like having this long tail of data being able to be brought on chain in an efficient way

is kind of what we're we're going to term the optimistic article it's something that um has been working on for a while it's similar in our concept from like a change from proof of work to proof of sake and what we really are able to do is bring any verifiable state of the world on chain um through a network participation of proposers disputers and requesters and um this sort of like approach of having application specific elements makes it a lot more flexible and you can adapt to any sort of data methodology you want so if you kind of think of it from a perspective of like what your application needs at any given point in time you're able to bring that data on chain with

by using a methodology that you design yourself and so you can kind of think of like a very wide space of where you can kind of create what you think you need for your specific application and the other last most important thing which i kind of want to make like like known so that when you see further down in the presentation is this idea of recourse right price feed implementations typically have one floor is that you either accept that price and that's it there's no way for you to dispute that there's no way for you to kind of figure out if something went wrong and so a lot of like people got wrecked in the in the ecosystem because in some instances like the oracle went down was broken or there was some version of like a hack that happened and there was no mechanism for

like a consensus layer to say all right something actually went wrong let's try and find a way to secure some funds and so what we're thinking about here is how to like capture the whole generalized contracting layer and that generalized contracting layer i would argue in my opinion is a lot bigger than just simply price feed implementations and so really the value capture that we want to try and provide to the whole ecosystem is to make sure that like whatever you think you can do with your kind of application and you need to bring data on chain that's what we're trying to like focus a lot of our time on so what really goes into one of these optimistic articles right um our our particular implementation has like four particular parts a requester a

proposal and a disputed network we'll run into how that works in a bit a dispute resolution process a documented methodology of truth this is where your application specific elements come in where you get to define how this data comes on chain right and then also some economic guarantees which will also kind of run through as to what makes like the optimistic oracle kind of secure your data in some way shape or form so the process of how it works really on this like disputed process is you can ask a question that question can then be answered by someone and so when you ask a question you can say all right did this event happen yes or no so you propose that the answer is yes

somebody can either accept that if it's accepted it's assumed to be true that's the optimistic sense and that's the optimistic case if not somebody is able to dispute you and this dispute can get boiled up to another resolution process which we're calling out uma's dvm and that process of disputes is a bit more slow a bit more thoughtful and so you can kind of think of the the dispute resolution process as a way of saying you can start off with the optimistic case but in in the event that something goes wrong somebody inputs the wrong price some something gets hacked you have this kind of layer to stop and go through some sort of like dispute resolution process and what we're thinking here on this like dispute resolution process is where

we can bring in recourse where you can say something that's like outside of the standard process of building um sorry the standard process of like resolving a price can like let's say it's a hack let's say it's something like no one would have expected this to happen through a dispute resolution process you can get to a consistent consensus and say actually this is something that we never expected to happen and resolve it to a point where the the users of your protocol aren't actually affected by some sort of like data manipulation one of the things that you might be thinking about okay we've got this process this oracle it's optimistic it can resolve some prices what what what are the things that have been built on

it so we've been around for i think roughly around a year um and what we've been quietly building with a couple teams a series of like projects um that kind of like touch some of these points so you can do prediction markets it's a fairly easy one ask did this event happen create a market around that uh that's something that's actually quite that's live on the moment on um the other one is defined insurance if you kind of think about like the concept of insurance it's a slow process of saying all right something happened does a payout need to happen or not if you've defined insurance in a certain way you can you can actually create a process where an oracle in an optimistic case can say does this person deserve to be paid out yes or no if yes then

there is also a process where somebody can say no that that needs to be disputed right um the the other one which i think is like the least built out at the moment is optimistic ovens which we kind of like been playing around with really cool um i'm personally excited about that rewards as a service so rewards as a service is something that we've actually built in the house at uma um heart lambo our co-founder spoke about this on tuesday i'd highly recommend listening to that talk where we're trying to find a far more efficient way to kind of create rewards as a service in in a way that if you think about most reward mechanisms it's action reaction based and so you can reward somebody based on

their actions optimistically and then have it be disputed if that person is wrong in that case you can then build systems where you don't actually have to develop the logic for each of the reward mechanisms like lp tokens right deposit into an lp share get lp tokens stakeholders i'll be tokens earn rewards those actions give me my rewards what is if i did that without ever having to code up that lp taken contract that like that process of just having that logic live of chain and be enforced optimistically i think would be quite a like a far more efficient like time saver for the the space um if anyone can just kind of have like no code versions of of rewards kpi options actually this is something

that we're quite famous for uh community-based incentive tokens if you ever want to chat about those we're always happy for them there's a lot of kpi options running out there in the world and then the last one which um used to be kind of known for is these synthetic assets where you can create derivative markets you can create call option markets you can kind of create these assets that kind of track anything all right but this is kind of cool in like one layer but i actually think this optimistic oracle concept really scales well and efficiently in a layer two world right most of ethereum developers now are looking at a strategy on deploying on l2s and so we've done the exact same and we've kind of created something which we think is pretty cool

which is a cross um it's an l2 to l1 bridging solution that uses our oracle to verify that these bridging actions happened so we we kind of think because of this process of not using amms and just using our oracle as this data validation method across actually becomes a far cheaper and faster way for you to bridge assets from l1 to l2 so that's one way that you can kind of like use this article in an l2 world but another way that i've been playing around with and i'm going to go through an example in a second but it's in this cross chain data verify validation and this kind of is needs to be explored i'd be very interested in chatting to somebody at the hackathon who wants to build something along this line but really the cool part about data

validation across chain is it makes it far more efficient for teams to have a strategy that is l2 compatible while maintaining a lot of their like infrastructure on l1 and if that's kind of confusing to you let me run through an example like very simply i came up with this like very quickly but kind of illustrates some of the potential that we can have here so if you're a project you're on l1 you're wanting to be on l2 i think almost every dao project in this room and in this event has that kind of problem or thought pattern at the moment you have some core piece of your project that does not scale well across chains um one of the ones is the ve tokenomics you stake your uh you stake your tokens

you earn some more awards your awards are based on how long you've been staked sometimes governance rights are very specific to like the chain that you're on uma's case like voting rights on umo very specifically uh has um voting rights on ethereum and so how do you build an ability for your actions on l2 to have the same weight as what your like voting rights or your tokenomics on l1 have and so in this specific implementation you can kind of think of some of us using our oracle to verify that i have a bunch of these ve tokens on l1 but i'm doing my voting on l2 and you can do a cross chain call to validate that that fact is true when doing that and so we think that this

kind of ties into some sort of optimistic governance process but it also ties into like kind of a more efficient l2 scaling solution where you as a project can actually keep part of your infrastructure on l1 without ever having to go to l2 and that pro like that change in thought pattern i think will be really efficient for most teams that really want to make sure that they capture like that that they don't have to always lose the opportunity cost of having to transport from l1 to l2 this oracle kind of idea of crosstaling validation can it has two things i can prove the state of something on l1 to l2 or i can enforce an outcome from l1 to

l2 so you can kind of think of this as a two-way process of being able to say like all right this event happened on l2 i'm resolving it on l1 but then i'm also enforcing that resolution on l1 back to l2 and so voting kind of works well this way dispute resolution kind of works this way like holding your big bag on ethereum while kind of doing your djing stuff on youtube kind of these sorts of things can play out and i kind of find um teams that really want to explore this i'd be happy to chat about that and so why does web3 need more oracles like this is my thesis statement this is what i want to make sure that it at the end of this talk you can at least have these core facts in your in your head optimistic oracles you can still build a

price feed you can still build a price feed and introduce some level of recourse in your price heat so the beneficial advantage here is that if something goes wrong you have some sort of like fallback mechanism that you can play around with on your version of implementing price feeds so it has that flexibility in it in itself you can extend from just prices to capture the whole data's the whole data type range and this can be unchained data of chain data this works well cross-chain we've done it ourselves um um dispute resolution process um wherever our optimistic oracle is on an l2 those disputes actually get resolved on l1 and we push that enforcement back to l2 and this works

and we've done it a couple times and so the design space for teams to make use of this like capability i think has a lot more potential and it's a lot more efficient i kind of think that having a data being pushed to the basically what is the world's most expensive database consistently is a really efficient method and with this concept of having a proposals and dispute system prices are only brought on chain at the time when it's needed and so you can kind of think of this design pattern as like somewhat different but very specifically a lot more efficient cool so i'd like to highlight a few things

that happened over this weekend and some just reading for anyone that's particularly interested in this topic um one of my colleagues chase coleman gave a gave a more in detail talk about what recourse and tell risk was that was on thursday at 2 40 i believe it's on the youtube channel at the moment um a lot of the design around the oracle came from the shelling coin article from vitalik a while back and so we borrowed kind of that design pattern from them where we've kind of introduced the concept of our optimistic article hot lambo wrote a post it's on our medium i'm happy to share and tweet that out for anyone that's particularly interested in reading like you know what what where this kind of came from and then lastly uh you can follow me on

twitter i actually have a pope if you want to claim that um and then there's a little bit of a game we're playing if anyone here claims five popes from the uma team you can win some given some cool prizes so claim that one get one out of five meet us at the uma booth to chat about some what we've been we'll chat about some stuff and then we can also give you some more popes [Applause] you