Why Web3 Needs More Oracles - Chandler De Kock

Very good. Hello. Um, yes, thank you for inviting me here today. I'm Chandler. I am the growth strategist at UMA.

And today I want to talk to you about something I've been thinking about for a while. And that's the idea behind why Web 3 needs a different design space for oracles. And I want to talk to you about some of the things we've been doing at UMA and give you some inspiration from a development point of view. And also from the developer's point of view at the hackathon to get better ideas about what they can do with oracles, and we're just going to talk about a few things here. So, my claim here is that oracles need to be flexible enough to create widespread hiring beyond just price feeds or data feeds.

The standard way, this is the standard modus operandi of how oracles work today, is that prices are prices and data is put on the chain, and there are some inefficiencies around this that we will look at more or less. To get a general idea of ​​what an oracle is supposed to do, the job of an oracle is really to bring some kind of data into the chain. You can do it without trust. You can do it reliably. And the most interesting thing we've seen with the evolution of oracles so far is that the overall crypto space has moved away from trust or articles, which is a good thing.

But we want to make sure we have an additional improvement in space, and we'll see what we think a different oracle design might have in terms of efficiency alone. And then, something like the concept of having a living oracle above the deterministic consensus layer, is where UML will fit in. So, if you think of a price feed, a price feed oracle is really just a different version of a deterministic consensus mechanism that does n't really deviate too much from its intended use. And that's where the inflexibility of the current implementation of the oracle price feed comes from. So, if we assume that oracles bring data in a chain and you look at all the data that exists in the world, some data is a little more valuable than other data, right?

So, the concept of having long-tail data is something I'll address in a moment, but the current oracle space and what I tend to think of as proof-of-work style oracles are price-fee style oracles. price-fee style oracles. These types of oracles have a chain mechanism that runs the risk of being regularly driven by some kind of decentralized consensus mechanism . These types of oracles have been the driving force behind DeFi. Therefore have been the driving force behind DeFi.

Therefore , most of what we see in DeFi today is due to these price items and they are very valuable and important for maintaining real systems. But these aren't really scalable for things outside of DeFi. They are slightly inefficient at the gas level. And they're not inflexible enough to cover things that maybe not everyone needs, but that they might actually want to have that kind of data for their own specific application implementation. So, if you look at it, I think of DeFi as a small segment of what the entire ecosystem can do.

So, the real trick of what we want to try to do here at UM is to develop what that would look like beyond pricing. And so the idea of ​​having this long history of data that can be efficiently incorporated into the chain is something like what we'll call the optimistic oracle. It's something we've been working on for a while. It is similar in our concept to a change from proof of work to proof of participation. And what we can actually do is incorporate any verifiable state in the world into the chain through a network of proponents, disputants, and applicants.

And this type of approach of having application-specific elements makes it much more flexible and can be adapted to any type of data methodology you want. So, if you think about it from the perspective of what your application needs at any given time, you can incorporate that data into the chain using a methodology that you design yourself. And so you can think of a very large space where you can create what you think you need for your specific application. And the other last but most important thing I want to make clear so that when you see later in the presentation, there's the idea of ​​the resource, right? Price feed implementations usually have one drawback: you either accept that price and that's it.

There's no way to refute it. There's no way to find out if something went wrong. And many people in the ecosystem were affected because, in some cases, the oracle crashed, broke, or was hacked, and there was no mechanism for a consensus layer to say, "Well, something went wrong." Let's try to find a way to secure some funds. And what we're thinking about here is how to capture the entire layer of generalized contracting.

And that layer of widespread contracting, in my opinion, is much bigger than simple price feed implementations . And so, in reality, the value capture that we want to try to provide to the entire ecosystem is to make sure that, whatever you think you can do with your type of application and need to incorporate data into the chain. That's what we try to focus a large part of our time on. So, what is actually included in one of these optimistic articles? Our particular implementation has four specific parts.

One applicant four specific parts. One applicant , one proposal, and a network of disputants. We'll see how it works in a moment. A dispute resolution process , a documented methodology for truth. This is where your application-specific elements come into play , where you define how this data is incorporated into the chain, right?

And then there are also some economic guarantees that we will also review regarding what makes the optimistic oracle protect your data in some way or form. So, the process of how it actually works in this disputation process is: you can ask a question, that question can be answered by someone. And so, when you ask a question, you can say, " Okay, did this event happen? Yes or no Okay, did this event happen? Yes or no ?"

You propose that the answer is yes. Someone might accept it; If it is accepted, it is assumed to be true. That is the optimistic view, and that is the optimistic case. Otherwise, someone can dispute you, and this dispute can, uh, be reduced to another resolution process that we call UM's DVM. And that dispute process is a little slower, a little more thoughtful.

And so you can think of the dispute resolution process as a way of saying that you can start with the optimistic case, but in the event that something goes wrong, someone enters the wrong price, something gets hacked, you have this kind of layer to stop you and go through some kind of dispute resolution process . And what we're thinking about here in this dispute resolution process is where we can file an appeal where you can say something that's outside the standard process of building, uh, sorry, the standard process of resolving a price can be, let's say, a hack. Let's just say it's something no one would have expected to happen through a dispute resolution process. You can reach a consistent consensus and say that this is actually something we never expected to happen and resolve it to a point where users of your protocol are not affected by any kind of data manipulation. And one of the things you might be thinking is that we have this process, this Oracle, it's optimistic this process, this Oracle, it's optimistic , it can solve some pricing issues, , it can solve some pricing issues, what things have been built on top of it?

So we've been operating for about a year now, and what we've quietly built with a couple of teams is a series of projects that address some of these points. So you can make prediction markets. It's quite easy. Ask if this event occurred. Create a market around that.

That's something that's actually happening right now . The other is DeFi insurance. If you think about the concept of insurance, it's a slow process of saying, "Okay, something happened." Is a payment necessary or not? If you have defined the insurance in a certain way, you can create a process in which an oracle, in an optimistic case, can say whether this person deserves to be paid.

Yes or no. If so, there is also a process in which someone can say no. That needs to be discussed, say no. That needs to be discussed, right? The other one, which I think is the least developed at the moment, is optimistic governance, which we have been playing with.

It's great. Personally, I'm excited about that. And then there are the rewards as a service. Rewards as a service are something we created internally at UMAR. Hot Lambert, our co-founder, spoke about this on Tuesday co-founder, spoke about this on Tuesday .

I highly recommend listening to that talk where we tried to find a much more efficient way to create rewards as a service in a way that, if you think about most reward mechanisms, is based on action and reaction. And that way you can reward someone based on their actions in an optimistic way and then have it discussed whether that person is wrong discussed whether that person is wrong . In that case, you can create systems where you don't have to develop the logic for each of the reward mechanisms, like LP tokens, reward mechanisms, like LP tokens, right? Deposit into an LP stock, obtain LP tokens, stake those LP tokens, and earn rewards. Those actions bring me my rewards.

What if I do that without ever having to code that LP staking contract ? That process of having that logic outside the chain and applying it optimistically, I think will be a much more efficient time-saver for the space. If anyone can get code-free versions of the reward KPI options, actually, this is something we're quite famous for, community-based incentive tokens . If you ever want to talk about it, we're always happy for them; There are many KPI options in the world. And then the last one, which he used to be known for, are these synthetic assets where you can create derivatives markets, you can create call option markets, you can create these kinds of assets that track anything.

That's fine, but this is great in one layer, but I actually think this optimistic oracle concept scales really well and efficiently in a layer 2 world, right? Most Ethereum developers are now considering a strategy to deploy to L2. So we did exactly the same thing and created something we think is pretty cool, which is an L2-to-L1 bridging solution that uses our oracle to verify that these bridging actions occurred. So, we think that because of this process of not using AMM and simply using our oracle as this data validation method, it actually becomes a much cheaper and faster way to connect L1 assets to L2. That's one way you can use this oracle in an L2 world.

But another way I've been playing around with, and I'll give an example in a second, is in this data validation between strings, and this kind of thing needs to be explored. I would be very interested in talking to someone at the hackathon who wants to build something along these lines. But the really great thing about cross-string data validation is that it makes it much more efficient for teams to have a strategy that is compatible with L2 while maintaining much of their infrastructure in L1. And if this seems a little confusing to you, let me give you a very simple example. It occurred to me very quickly, but it illustrates some of the potential we can have here.

So, if you have a project, you're at L1, you want to be at L2. I think almost every DA or project in this room and at this event has that kind of problem or thought pattern right now. Do you have a core component of your project that doesn't scale well across chains? Um, one of them is VE tokconomics. If you stake your tokens, you earn more rewards.

Your rewards are based on the length of time you have been staking. Sometimes, governance rights are very specific to the chain you are in. For example, voting rights in UMA have voting rights in Ethereum. So how do you create a capability so that your actions in L2 have the same weight as your voting rights or your tokens in L1? In this specific implementation, you can think of some of us using our oracle to verify that I have a bunch of these VE tokens in L1, but I'm doing my voting in L2.

And you can make a call between strings to validate that fact is true by doing so. That's why we think this relates to some kind of optimistic governance process, but it also relates to a kind of more efficient L2 scaling solution where you, as a project, can keep part of your infrastructure at L1 without ever having to go to L2. And that change in the thinking pattern, I think, will be really efficient for most teams that really want to make sure they capture in that way, so they don't always have to incur the opportunity cost of having to transport from L1 to L2. And so, this idea of ​​cross-invalidation of oracle-like data can have two things. I can test the state of something from L1 to L2 or I can enforce a result from L1 to L2.

So you can think of this as a bidirectional process that allows you to say something like, "Well, this event happened in L2. I'm resolving it in L1, but I'm also enforcing that resolution in L1 back to L2." And so, the voting works well this way. Dispute resolution works this way. Like keeping your big bag in Ethereum while doing your DJing and stuff in L2, this kind of thing can happen.

And I've found teams that really want to explore this. I'd be happy to talk about it. I'd be happy to talk about it. And why does Web 3 need more oracles? This is my thesis.

This is what I want to make sure of, so that by the end of this talk you can at least have these basic facts in your head. With optimistic oracles, you can still create a price feed. You can still create a price feed and introduce some resource level into your price feed. So, the beneficial advantages here are that if something goes wrong, you have some sort of backup mechanism that you can play with in your price feed implementation version. Therefore, it has that flexibility inherently.

You can extend from just prices to capturing all data, the entire range of data types. And these can be on-chain data, off-chain data. This works well in cross-chains. We did it ourselves . The UMA dispute resolution process.

Wherever our optimistic article is in an L2, those disputes are resolved in L1 and we move that application to L2 and this works and we have done it a couple of times. And therefore, the design space for teams to make use of this capability, I think, has much more potential and is much more efficient. I believe that having data constantly sent to what is basically the most expensive database in the world is a really efficient method, and with this concept of having a system of proposals and disputes, prices are only introduced into the chain at the moment they are needed. Therefore, you can think of this design pattern as something different, but much more efficient. Brilliant.

I would like to highlight a few things that happened this weekend. And some reading material for anyone who is particularly interested in this topic particularly interested in this topic . One of my colleagues, Chase Coleman, gave a more detailed talk about what tail resources and tail risk were . That was on Thursday at 2:40. I think it's on the YouTube channel right now.

Well, much of the oracle's design came from Vitalic's Shellingcoin article a while back, so we borrowed that design pattern from them. And then, where we presented the concept of our optimistic article concept of our optimistic article , Hot Lambo wrote a post. It's on our Medium. I'm happy to share and tweet it for anyone who's particularly interested in reading it; you know where this came from. And finally, you can follow me on Twitter.

In fact, I have a Pope if you want to claim him. And then there's a little game we're playing. If anyone here claims five UMA team Popes, they can win some cool prizes. So claim that one and get one out of five. Join us at the UMA stand to chat about some of the things we 've been talking about, and then we can also give you more potatoes.