MakerDAO: Deconstructing the Oracle Stack – Niklas Kunkel

okay cool guys let's get started so this title this I kind of like talk is really about deconstructing the Oracle stack so it's the Oracles that we use in multi collateral die so let's start off with kind of Oracle's be one this is kind of where where we started from what we used in single collateral die and we'll kind of analyze you know what were the properties why was it good but also you know what what kind of problems did it have so what one thing you kind of have to know about our Oracle's is that we have this concept of a feed so what a feed is is its price submitter right so in our system we have 20 feet so essentially 20 individuals or organizations right are pushing these prices and the Oracle price is the representation of the median of all of these prices that are submitted and feeds are appointed by mkr governance so this is the architecture we had for Oracle's v1 you'll kind of see the split between off chain and on chain and that'll be very relevant later so and v1 what we had is every feed right would grab the prices from a set of exchanges and it would push that price to its own kind of price feed smart contract so you could essentially think of it as like its own personal cash and then it would send a transaction to this media Nizer contract which would then take the median of all of the feeds and then that media Nizer is essentially the Oracle for the dice ability system as well as all kinds of third-party applications like compound dy/dx Dharma newest set protocol etc etc now this architecture is what we use for single collateral die and it worked quite well but one thing you'll immediately see that's a problem is that every single feed is sending an ethereal transaction which is not only is it expensive but it also means that there is it makes the oracle price that's on chain less sensitive right because it's waiting for all of these different feeds right to get a transaction through so we kind of talked about this right lots and lots of redundant transactions but the also other thing to note is the operations we were doing were very very expensive so what do I mean by that well every time a feed would submit a new price it would write tell the median Iser okay you need to find the new median of the entire data set well to find the median you need to sort this all the the prices first right and sorting is a very expensive operation is an N log n operation so doing that on chain doesn't scale very well when you start adding more feats right when you have 50 feeds or a hundred fees or even more than that so so those are pretty much the issues that we set up to solve with our new architecture or equals b2 so Oracle's b2 is what we're currently using for multi collateral die so our goals when kind of building this architecture we're really about solving this problem of scalability that we were being held back by by Oracle's b1 reducing kind of the the cost so the the gas costs that we were that we were paying right making the oracles kind of more reliable and resilient and kind of reducing the latency between a price changing you know in the centralised world you know like centralized exchanges right and that being reflected on chain so one of the key pieces of architecture that we integrated was this idea of a gossip network protocol so the one that we're using right now is called a secure scuttlebutt and so it's a peer-to-peer gossip network and so for those of you who don't really know what gossip networks are a really good mental model is to kind of think of Twitter so if you think of like you have a bunch of participants in a network and you post something right you tweet so I tweet the price of eath is something well on Twitter everyone who's following you right can see that and they'll retweet it right on there kind of feed right so the same thing happens in a gossip network where essentially through this kind of retweeting of the people that you're connected to right you can have messages just propagate through the network even between peers that are not kind of directly connected to each other it also has a very similar architecture to a blockchain in that all of these messages are essentially hatchlings and so you cannot really get rid of a message or mutate a message because it would kind of break this this hatchling structure because the hash of the message would change so here's kind of the the overall architecture diagram for for Oracle's b2 so notice that on the off chain side lots and lots of stuff is going on now and on the on chain side right we've kind of shrunken that a little bit so now feet instead of pushing prices directly to the blockchain like they did before right there instead just pushing a price to this peer-to-peer gossip network so in this case skeleton and then we have in the maker ecosystem we kind of have this concept of of a keeper and a keeper is any third party that will run some type of bot you know for profit and so the idea here is that there are certain actors in the system who are incentivized to update the auricle price either directly or indirectly and we can talk a little bit more about that later but essentially what the real layers do is they're constantly scanning this off chain network this scale about network for new price messages and if I were to take the median of all of these price messages is that significantly different from what we currently see on chain and so right if it is significantly different what it does is it packages up all of these prices into a single transaction so it essentially does the sorting off chain right so it'll pass the signatures right so each feed signs this data to prove right I'm you know committing that this is the price right so you pass the signatures and you pass the timestamps and you pass the prices but you pre sort this all off chain because off chain it's very very cheap to sort something and then now you're just submitting one transaction to the meeting at your contract right so essentially we've gone from n feeds you know submitting n transactions to n feeds just submit one transaction and so that you know increases our scalability substantially it reduces the costs we have enormous lis it makes the oracle price more sensitive right because we have much lower costs we can run a much much tighter spread than we otherwise would so and everything's a lot better another unique thing about this architecture is that it's kind of blockchain agnostic right so notice that none of this really touches aetherium right until you the relayer does that one transaction to the median Iser so if you have side chains like say you're working on like a scale side chain or something like that right you know you can just deploy a median Iser on there and for the real Ayres right instead of just pointing them to the etherium maintenance you just point them to the side chain another thing is that not only is a blockchain agnostic its data agnostic right so in this case for multi collateral die we're just using prices but really in scuttlebutt all messages are just JSON so any kind of data that you can represent in JSON you can really use as Oracle data as long as you're able to kind of interpret that in your media Nizer smart contract okay so let's talk about kind of what are still the problems with this so when I when I think of kind of when I think of multi collateral dying of okay what are all the things that could possibly go wrong right so you just start to think of things through this risk of like lens like so okay well what if the scuttlebutt network you know fails what if there's some kind of psyche fault and the whole network goes down right what if the client that these feeds are running what if there is some kind of bug in there and all of a sudden all of the feeds go offline right the client that the real layers are running similar thing right what if there's a bug in there and you know it you know it's hard to find and one day it just pops up and all of a sudden you know we don't have a live stream of Oracle data so what we're working on right now is just kind of redundancy redundancy redundancy just to make this as resilient as possible right another thing that right for example we have a tool that you're using to query the prices right from all the exchanges right right now that tool that we're using is called Setzer what if there's a bug in that tool right what if it you know returns the wrong price from one of the exchanges so this next version of Oracle's that we're working on right now is going to try to basically counter all of those weaknesses so essentially the name of the game here is just find all the areas of risk at just D risk all the things so essentially right the strategies redundancy combined with failover mechanisms create more resilient systems so instead of just having one client instead of just having right the one feed client or the one relayer client right have multiple clients right we've seen that we've seen this actually in the etherium ecosystem right I don't know if you guys were around back then but a few years back there was a bug in the guest code right and all of the guest clients simultaneously crashed and but because the network had both parity and death notes essentially the parity nodes saved the etherium network from like seizing up so we've seen this kind of client redundancy like actually you know in action in in our ecosystem already so we want to apply that same kind of pattern to to the Oracle stack right another thing is right we talked earlier about well you know scuttlebutt is this great transport layer but what if you know there is some kind of bug in that what if there's some kind of error what if you know someone finds an attack vector in into that network right well now we want to have redundant kind of transport layers right so there's a company called hashey Corp that makes a product called Cerf it's usually used for like DevOps II type of stuff so to kind of almost like a heartbeat kind of way to see if to see if like a servers offline or to monitor the the latency in a server farm but essentially it's the same thing of just a distributed network of passing messages right slack just recently came out with their own kind of message passing protocol called nebula right there is ipfs has lit p2p right a little bit more lower-level but could be utilized to an extent as well another thing we're looking at is right the tool you use to query prices right so you want to have we're done and see there as well so instead of just set sir we're creating a new tool called gopher another thing is right new price models these Oracle's are used for multi collateral die to an extent right but they're also used by all kinds of third parties who are using assets that may or may not be part of multi collateral die and sometimes the median is actually not the best way to model the price of something we know what if you have five exchanges but 90% of the volume is happening on you know financed right then the binding strands price you know has a lot more revelant right relevance then say the the ether delta price that has like you know $50 worth of volume or something right so you can do like a volume weighted average price approach you can do a kind of time weighted approach as well I think this one called like cccc a G so you can kind of use these modular kind of price models as well so this is kind of what the architecture for Oracle 3 Oracle's v3 looks like right so you have these multiple kind of clients now right so instead of just subsurf requiring you have go for an Setzer and you know we can release like a reference spec so the community could create even more right you have a bunch of fees that are now using different clients so not everyone is just using the default omnia client or creating a new client and go called ghost and we could release a reference spec for that as well right to incentivize the community to create more clients for even more redundancy right we're using multiple transport layers right so if there's a problem with the scuttlebutt layer right fall back on to surf if there's a problem with surf fall back on to nebula if you know god forbid there's a problem with all three of them right you can even have a centralized server right that's just hosting all of this stuff all the data is signed so there's nothing that you know whoever's running the centralized server could do right and you know even if they take their server offline you know the other three transport layers or you know prioritized anyway so even a centralized server in this case is a really good fallback solution same thing for the real Ayres so each of the ghost Nam Nia clients the real layer functionality you know that will be kind of a result more resilient as well due to the diversification and on the unchanged side everything basically stays the same right you still have the same model of it's still the same messages being passed back and forth on all the transport layers right it's still the same real layers just submitting one transaction of sorted signed data so the model on the blockchain has kind of reached this like much much simpler form and really all the innovation that we're gonna be seeing in Oracle's and not just from us but you know from people like chain link and people like um a and probably all kinds of other Oracle groups that are out there really all that innovation is gonna be happening off chain okay so let's talk about governance because I think there's like a big kind of misconception around you know what is decentralized versus what is centralized in terms of Oracle's and depending on what company you talk to they will just market you and say this is decentralized and sometimes you believe them and sometimes you don't so at maker what we do is we don't hold any of the keys to any of the Oracle stuff essentially that authority has been given over to MKR governance so essentially MKR governance gets to vote on who gets to become a feed if a feed is acting you know has bad uptime or maybe they're posting bad prices or maybe they try attempt to participate an attack right it is up to governance right to remove to revoke that feed right everything goes through MK our governance is what I'm trying to say so we're trying to kind of build out this governance ecosystem around Oracle's more and so there's a bunch of different things that governance has voted on in the past relating to Oracle's so we passed the defy public feed proposal and I'll get into that a little bit more in a second the Oracle incentives restructuring proposal the responsible Oracle migration proposal and the Oracle team mandate proposal and I don't expect you guys to immediately know what those are but we're gonna kind of go into those one by one so when we talk about feeds we really have to talk about two different types of actors and they both have very different types of properties so we have this concept of a dark feed and so dark feeds are supposed to be kind of pseudo anonymous individuals and organizations that submit price data so the you're not supposed to know who they are at least you're not supposed to know right they're based out of you know this country or what their name is or you know you know if they work for some company or whatever and this is kind of this is part of this hybrid strategy of well it is much harder to kind of coordinate between anonymous actors right so if you have a bunch of feeds right that are all anonymous right in order to launch an attack you need to first identify who these individuals even are right which is very very difficult it's kind of what we call like the coordination problem the downsides the dark fees though is that you don't really have a guarantee of civil resistance right so you have what civil means right is you don't really have proof of like unique identity right so for all we know you know all the feeds could be the same person right so so that's that's a risk and another thing is on the user side people don't want to trust an Oracle system that is just run by these anonymous you know people you know for I think a big criticism that's been leveled at us sometimes it's like oh it's got to be like the VCS or like the maker insiders or like the the founder or like whatever so there is this other concept of a light feet I think light feets solve a lot of the problems of dark feeds but they also have their own drawbacks so light feeds are organizations and so they have these public identities you know there tend to be kind of stakeholders in the ecosystem so they have a kind of set incentive to be a good actor right organizations also kind of have reputation right so say if you're a you know say if you are like zero X in the space and if you participate in Norvell attack like your reputation is now ruined in this community you know and from the user side right users tend to trust systems more right that are you know that are kind of distributed in terms of entity like other groups that they trust and this is not unique to crypto this kind of happens in say like the the banking of the banking world as well in the technology world as well in terms of where companies don't really want to buy into systems that are just run by kind of one other company right cuz now they're kind of dependent well so IBM is a great example a lot of people don't want to just buy IBM systems and now be dependent on IBM for maintenance and service and all of that right they would rather you know use some kind of open protocol rather than a proprietary protocol right because nobody owns it it's the same kind of thing right with with the Oracles in terms of nobody wants to use the proprietary Oracle's that you know and trust that one group right when you can say well I trust all of these other organizations and you know defy and in the greater etherium space a little bit but together you know I trust them a lot and so combining kind of dark feeds and light feeds you can get this really cool like hybrid model which is optimal because it kind of preserves the hardness properties of dark feeds right this coordination problem they're really hard to to locate and identifying it's hard to coordinate to get an attack together but it also benefits from the reputation of the light feeds right who are stakeholders in the ecosystem that are public facing so we talked earlier that governance past the defy light feed proposal and so this was the first wave of kind of organizations that were unwarranted to run a feed so dy/dx 0 X the maker foundation set protocol and gnosis so they're all running a feed right now in Oracle's B 2 which is supporting multi collateral die this is also just the first wave we are kind of trying to talk with a lot of other partners right to get even more kind of buy-in from other stakeholders in the ecosystem so if this is something you're interested in doing and you guys have like a good reputation in the ecosystem you know come find me we'd love to talk to you we'd love to get you on board it would be really cool another thing we did was kind of realign the incentives of the Oracles so earlier I said you know I'm trying to look at the multilateral dices them through this kind of risk lens you know where is the risk you know and one of the risks is you know what if the maker foundation were just to disappear tomorrow like would the system still work right is is it truly decentralized and that like you know it could keep going without you know any any kind of other coordinating entity and so one of the things that we kind of saw in the Oracle side was like I mean that from a technical perspective they would still work but the monetary incentives to keep them running or not there and so how can we realign these incentives to make the kind of to make it a to make the Oracle stack more resilient not just through technology but through financial incentives as well so what we said was all right well currently the the foundation is paying feeds some kind of sum of money right and that is to basically fund the servers and their bandwidth and all about right and it you know serves as some form of disincentive right to be a bad actor as well right because you would get cut off from the income stream but to truly make this decentralized right the fees essentially need to come from MQ our token holders right so a multi collateral die we have this kind of buffer which we call the surplus buffer and all of the stability fees that are generated from outstanding die loans go into that buffer so we created this proposal right that MK our token holders will use some of that surplus to pay the feets right so now the feeds have an incentive right to keep running even if the foundation disappears tomorrow so that's that's one side of the triangle that's solved so now you kind of need to give an incentive 10-carat Oken holders to kind of govern this system in a way that it's not just entirely self-serving so what I mean by that is the multi collateral die system right right now it only has aetherium as collateral and brave token as collateral right but there are all kinds of projects right especially in defy that I need Oracle's for all kinds of other tokens and we would love to have Oracle's for those as well but if my would M care holders be paying feeds to submit prices for assets that aren't utilized in the maker system so you need some form of incentivization friend KR token holders so what we've done is we've essentially added like a whitelist to the Oracle smart contract excuse me I'm essentially in order to read the prices from the contract you have to be on that whitelist right and so if you want to get on that whitelist right you have to pay and our token holders some sum of dye be it you know monthly weekly or whatever right so now you kind of have this holy triangle of like incentives where data consumers right can just say okay well we want to have an Oracle for this you know say for X R P god forbid and instead of going to the maker Foundation right now they just go directly to M K our governance they're like hey we want an extra few Oracle you know we'll pay you I don't know there's like 500 bucks a year or whatever the hell it is right and then M Keira token holders vote and right then they they approve it right or they reject it but if they approve it right then they tell the feeds okay feeds you now need to start submitting prices four notches eath and that but you also need to submit prices now for x RP right and so now you kind of have this resiliency in terms of this decentralized system that doesn't actually depend on any centralized coordinating entity you know from the foundation so another thing that we've been dealing with is that makers Oracle's like the Oracles be one that I showed the beginning of the presentation are like highly highly used in the space I almost disturbingly so and I kind of understand why because I think we were like the first kind of main that Oracle's and so everyone just kind of plugged into ours cuz I was just the easiest thing to do but there's kind of a problem with this in terms of that we don't actually know how many people are actually using this thing and you know what kind of chain reaction you know it could trigger of compounding effects if for example we just stopped running the Oracle v1 stack so even though MCD launched back in November and Oracle's v2 launched with it we're actually still running Oracle's v1 in parallel so we know of like tons of organizations that are still on v1 that have come up to us and told us but there's probably dozens more that we have no idea about so this was a proposal right that m'kay our governance passed that said we would keep v1 and v2 running in parallel for at least six months to give everyone time who's running on v1 right time to migrate over to Oracle's b2 the other thing that we said was look like this white listing right is a little bit controversial as well right people are not you know who've been using the service for free you know their systems that they've built up you know maybe they don't have any income right to run to run to get on the white list for v2 so another thing that we said is okay everyone gets free access to the white list for any Oracle's for one year so this gives like you know we don't want to leave anyone like hang them out to dry right this gives everyone the opportunity to okay I have a year to transition to another Oracle stack if I want or I have you know a year to you know figure out if v2 is something I like that I actually think it's worth paying for so this is just kind of another way of kind of like aligning the incentives because we're not trying to like hurt the ecosystem it's just there's like very real costs to running these things especially as you expand the number of assets that you know we support in terms of you know what we provide prices for and so this is kind of like a necessary evil like we have to do and so the best thing we can do is at least make like the transition for the ecosystem like as easy as possible okay so that's kind of if for me if you're interested in maker or in Oracle's we have like a super active subreddit we have a really active forum if you are interested on the governance side of things all of the maker governance stuff really happens in the forums so check out forum maker.com if you have a proposal that you think you know would improve like maker or improved i right you should submit it on the four right generate some discussion and then it can actually become a governance proposal right that can be voted on so even if you don't own any MK I can't actually vote you can still you know be the driver of like change in this ecosystem we also have like you know follow us on Twitter we have an active telegram and you can also you know talk to me and Mariano and all these guys over here on rocket chat cool yeah that's it for me [Applause] [Music] you