State of Oracles in the Space - Brenda Loya

We're going to switch gears a little bit here and look at a topic that's very near and dear to my heart. At a shape shift last year we contributed to a project called micro tick that is designed to act as a trustless Oracle and had a lot of fun exploring different projects and approaches to the to the Oracle issue. Just a quick primer for those who are not familiar. You know, the the idea of an Oracle is where you really have to bring in information from the real world into blockchains. Blockchains have no way of knowing this.

On the other hand, you want to have to do it in a do this in a trust minimized fashion where you're not counting on like you know one party saying telling you that the the Buccaneers won last night or that you know what the Dow's at today. You need to do this in a trustless fashion. Today, you know, we've seen chain link do quite well in the space. However, there's a lot more approaches and I think this is an area that's going to really just see a lot of burgeoning experimentation and interesting building. So Teller is a great example of of a project that's doing just that.

Had a chance to talk to Barbara last year a little bit and learn what they're doing, but she's going to tell you what Teller's up to and explain some more concepts about what what's happening with with Oracles right now. Hey Kent. I did not include micro tick in this talk. Now I feel bad about it. I just mentioned it.

It's all right. It's it's not meant to be exhaustive. It's just meant to be an overview for any any builders out there to actually start thinking about this beforehand and not as an after effect. Um after thoughts. So with that, let me know if you guys can hear me and see my slides and if everything is all good.

Everything is great Brenda. Perfect. I'll get started. Thanks everybody for joining. I am Brenda from Teller.

And um Let me know also if I I'm I'm juggling a few screens here, but hopefully everything goes smoothly. So anyway, why are Oracles important in blockchain and um As I Kent already mentioned, what really makes the blockchain interesting is that that intersection of the off chain data and on chain data and that merge of the real world like it's really what makes it interesting. But before I get into that, when you're you know, if you're a builder and you're just starting to build or maybe you already started because the weekend it is started over the weekend, but some of the things that you need to think about when you're designing your protocol is what properties of the blockchain make your app actually better to be run on as a dab rather than on a centralized database because it will be slower and it will be more expensive. Also, what level of decentralization are you willing to negotiate on? And always remember that your dab is only as decentralized as the least decentralized aspect of it.

And that's really important because that's where Oracles come into play. Sometimes if they they are an afterthought to many protocols because they are so you're way more focused on on the product that you want to provide and the UX that you're trying to give your users. But anyway, this this talk is going to talk mainly about designs of Oracles in general and what's being used on D5 currently and why you should keep it keep it in uh as part of your thoughts as part of your design structure. So As I said, Oracles are super important because they make things way more interesting and more tangible. It was really fun to play around I guess with blockchain data and assets, but it really you know what really brought it to life is the ability to merge both worlds together.

And that intersection is what brings the most interesting use cases on chain and what really what actually brings true competition to the traditional centralized way of doing things. And competition is extremely important because it keeps innovation going and it pushes businesses and states to do better. And because when left unchallenged, you know, without checks and balances, the imbalance of powers can potentially be devastating. So this merge between decentralization and the real world is what really makes the blockchain truly powerful in my view. And and with that, as you know, off chain data with off chain data and all of these use cases um that it was able to bring on chain, it also brought a lot of basically potential profit making, right?

Cuz a lot of the things that this use case bring in are really worth trillions like financial, you know, in the traditional financial system when you're talking about derivatives, that's a big portion of the economy. And so when we start looking into the blockchain and its possibilities, right away people start thinking, you know, derivatives, stable coins, prediction markets, gambling protocols. And all we can do as entrepreneurs is like we're going to build things to meet that demand because we're in the space, we like it, and as soon as we start building, we start realizing very soon that it is very hard to create products and settle those bets and those derivatives to data that can't be gained. We very quickly go from like how fun it is to build something to oh wait, can we actually get data on chain that is as trustlessly as as as we reach consensus on the state of the blockchain. And you know, for the blockchain, the state of the blockchain is just determined by whatever the majority determines to be true.

And it's easy, you know, we say well, easy, right? It took it took a lot to get there, but once we're there, we know that you know, it's easy to reach consensus on who's sending what to whom and for on chain and then reach that consensus on chain. But for off chain data, there's no really pre specified mechanism to reach that consensus consensus because it's completely unrelated to the blockchain. And the big difference is that now the consensus layer is on chain for this data and it you know, it it determines, you know, who can push data and whether or not that data is correct. And that's really hard to do in a secure way.

So the first way that we as a community when I talk about the community, I don't just talk about Teller. I'm talking about the whole crypto community. It's like the very first and easiest way that we thought about like how to tackle this problem, fairly simple, right? You just you know, have one person either enter the data either you yourself or you white list somebody to enter the data to your smart contract. And for anybody that doesn't know, the biggest name in this basic and I know they've done different iterations of their product, but the biggest name on Ethereum for this type of design is actually provable and in the past they were called Oracleize.

And they're really great to do an MVP, but it is centralized and they are high risk to do with with that because basically when you do design like this that central party can actually manipulate your data very easily easily. And also, even if they're not malicious, if they go out of business or shut down their servers, then your your contract gets no data. And we call that a liveness guarantee issue. And so that's one of the first designs and one of the first ways that we actually as a community tackled it. Um Well, it was actually an Italian guy that came up with that, but it was cool.

Anyway, so the next design is actually having a multi sig um type of design. And for this, you don't just white list one person, but you white list a handful of parties and they all pay data on chain and then you can take the median average, whatever you want for your contract. And as you can tell, it is a little bit better. More like a proof of authority version of an Oracle. We're kind of trying to correlate them to layer one solutions, but it's still pretty I mean, I think it's a better definitely a better option than just having one party enter the data.

And it puts a lot of the design back on your court as the developer. Another is a slightly modified version of the multi sig is when you have multiple parties provide the data, but then you have one relay or actually push the data on chain. And I actually think this is a slightly worse version of it just because now you're kind of centralizing all of that data that's coming from different parties. Um And but the good thing about this is that it does separate the risk. So in this case, one of the groups, the group that provides the data, they can you know, you you separate like they can manipulate the value, but only the relayer can censor your system.

So it's it kind of splits the the the risk. So you know, that's something to just keep in mind. But either way, you do you are back to being centralized. Another um design and it's kind of a version of of a proof of authority system, but more like a delegated proof of stake, uh, system where you have a white where where you have an entity white list nodes um, and they can deposit a stake and they can lose it if they actually, you know, provide you bad data. And this is way better, I think, uh, than the previous designs, but you also have to pay close attention to how the white listing works.

Um, is it, um, really centralized? Can they really just un-white list anybody in in in the group of entities that you need information from? And how, you know, how centralized that entity is or, you know, if it's centralized, if it's a DAO, that has big implications on what happens to your data. Uh, for any of these, though, you also want to make sure that you know, you know, the or possibly know or have an estimate of the cost to break and also how easy it is for nodes to communicate and collude and manipulate your data. Uh, so for these type of systems, it's just good to do your research and um, just keep those things in in the back of your mind because they do seem a little bit more decentralized, but you just have to keep those in mind those things in mind.

Um, another and and those I think are more of a more centralized type of type of designs. Um, one that was very, I guess, early on that is a little bit more of a decentralized design it was actually prediction markets. And they're not as popular as they used to be now, but basically they work by simply you place a bet or and then, um, or, you know, and then people vote on the right outcome. And if you assume that the majority of the people are honest in the system and they don't want to lose their money, um, if you penalize them if the if their answer is considered wrong, then it works and it's pretty decentralized. And it's a pretty cool design, but it's also, um, you know, it's also pretty slow.

And, you know, there's a lot of regulatory issues with that and speed, liquidity, and even cost concerns, um, especially since now, you know, gas prices are so high, um, that it it's it's really hard to be able to use this in in DeFi, but I do think that the concept of it is going to be really useful and I think eventually, maybe as things get faster, it'll be used more often, I don't know. Uh, but that this was one of the very first designs that were, I think, were truly quite decentralized. Um, another design that is, you know, despite of of, you know, everybody trying to come up with other designs and coming up with decentralized ways of of basic providing off-chain data, um, the truth is that we have we've known how to cryptoeconomically validate data for a while. And we do this a lot with, um, every 10 minutes with Bitcoin and and in Ethereum every time that we reach consensus on one block. Um, you have, you know, basically you have a way to pick some anonymous person or group of people and then they enter information and then you add in some form of probably stick finality so that it makes it really expensive for them to break your system for a while.

And then, you know, uh, validators can collectively agree on whether or not to accept that data as true. And as long as you make it really expensive to pretend to be be the majority of the system, then I think that's a pretty robust way of doing it when we already do it, uh, with blockchains in general in layer ones. So, that's actually how people are now, I think, are starting to look more into providing data on chain and that's actually the way that a teller is built, um, but definitely, um, it's going to be slower than some of the other options because it's more decentralized. So, there's, you know, there's obviously those drawbacks that oracles, just like the blockchain, they face the scalability trilemma. And if it's and that's just something you're going to have to negotiate based on whatever you're building and the design for it and whatever it is that you're actually doing and whatever you value most.

But if you take anything from this talk, I mean, just realize that the scalability trilemma also holds for oracles as well. It's not just something the blockchain deals separately. Um, if you're really fast, you're probably not decentralized. Um, and also, I mean, just keep in mind like it just doesn't make sense that when you have a consensus layer on chain, you're not going to be be able to reach consensus just as fast as a blockchain reaches its own consensus. So, just keep those things in mind when you evaluate these things.

Um, but um, in terms of overview of designs, there's a lot of flavors and sprinkled with a lot of different things because everybody's really working on this and trying to make it better. But that's pretty much it for what I'm going to go over, um, as an overview. Um, I'm sure there's going to be a lot of other designs that are going to be really interesting in the future and I cannot wait to see them. Um, we're iterating, you know, every day as well and trying to meet our our use our users' needs and I'm sure everybody else is as well. But as for now, I think those are the the main basics of designs out there.

So, now that you guys have the models there, then let's try and go ahead and go through what's actually being used on DeFi right now. And for DeFi, although it sounds like it's really really really big, um, there are, you know, maybe like 10, 20 projects that really drive the entire space. And that's just, you know, the nature of it. Like everybody Well, one, they've been there for a long time, they trust them and um, that yeah, I it's just the space is still very young. So, it, you know, it's just looking at this like we're just going to go through some of them because it would be, you know, it would be way more than 20 minutes if I don't and I'm going to try to hurry cuz I'm looking at the time right now.

Uh, but basically, um, Maker's at the top of the list and for one thing, they are, you know, one of the biggest if not the majority of DeFi at the moment and they had to face the oracle problem very early on because they depend on on it, you know, so they have a system a system that is similar to our very one of our designs above, but um, the one thing to keep in mind in terms of, uh, Maker is that they developed their oracle for themselves, but now a lot of other projects, smaller projects and big ones, use them as their data feed because they just, you know, they they're consistent, they're there, and that's, you know, what they're currently have is basically a proof of authority model, basically. Uh, they recently moved to a model where anybody can be a relayer, but and and which is I think it's really great because now there's going to be, hopefully, more transparency as they move to that towards that, but there's still a lot of of centralization, um, because it's theirs, you know? They designed it for themselves. Um, but they do follow a lot of really great practices. Namely, uh, the 1-hour delay, uh, to update their oracles is was instrumental for them to be able to, um, handle Black Thursday last March and to have, you know, their their holders actually have a say as to whether a bad value there's a bad value on on chain and they can freeze the system.

And I think those are really good things that, you know, they are able to have those fallbacks in place and make their system, you know, take ownership and control of their system when their oracle fails. Um, but yes, if you're using DAI, token holders, you know, being able to freeze their system is going to be hard and I think I'm running out of time cuz I just heard somebody. Um, but, um, uh, so another very similar design is, uh, the Open Oracle system from Compound and they also use it for themselves. And then Chainlink is also a really big name in in oracle in the oracle space and some of the, you know, of the few other projects that also have a lot of volume, they use them as well. Um, just as as a disclaimer, this is how I think, um, um, Chainlink currently works because there is a discrepancy between what they have built and what's, you know, the cool stuff that's on their white paper, but right now they just white list nodes and, um, they control that.

Um, but, um, they are still being widely used by some of the, you know, the bigger players. Um, and I am not sure if I have enough time, but thank you guys. Um, I will share my presentation and you guys are welcome to go through it. I don't think I lost anything uh, too big here, but I hope you guys got a gist of all the designs that are out there and I can't wait to see what you guys build. Awesome.

Thank you for the the talk, Brenda. And I think you said two things that are really truisms in this oracle space. One is it it really is a trilemma. There's no there's no free lunch in the oracle space and be suspicious of projects that make that it seems too good to be true because there's probably some important sacrifices they're making along the way. We to get this right is tricky, but I think all the hard work is paying off.

And then also you mentioned how the space is very young. That is absolutely the case. It's going to look vastly different, I think, in you know, even like 2 years. So, thanks for the insight. Yes, I can't wait to see what people build cuz I feel like it's in these hackathons that you get so much more innovation.

When you Once you're in the space for a little bit, it's just like I think you start losing losing sight, but um I can't to uh innovating cuz you're like so focused on researching and making it faster and trying to make what we have work and trying to make it better that we forget that, you know, there's there's things to be built and there's things to be imagined. Absolutely. Thanks again. Thank you, Kent. Take care.