Chronicle Protocol: Decentralised Oracle Network - 0xHack S02E03 p.1

so there were some spoilers here but okay so as you've heard i'm pavel uh and i'm gonna tell you about oracles maybe oh there it is yes i'm going to tell you about oracles so the first question you might have what are oracles so this no not about this today and also some of you may know this movie and this is the oracle from matrix but also not this it's not going to be the topic of our discussion uh these this is a representation of mythical oracles which is almost the thing we're gonna talk about but uh not exactly and blockchain oracles are exactly what we are going to talk about so both mythical oracles and blockchain oracles know the truth that's the idea behind oracles they tell it to anyone who asks and sometimes requires sacrifice in the case of medical oracles and some payment may be in case of blockchain oracles but first let's talk about the oracle problem what is it and why do we actually need oracles so we know that blockchains are very nice and we love them because we are working with them every day they are immutable and secure so we no one can change the data and we always know that once verified the data is stored and secure but they are also isolated the problem with isolation is that we cannot do the the blockchains but by themselves by themselves don't have any ability to contact the outside world and we have a lot of data outside of blockchains and we want this data inside blockchains so we can operate on them and write for example smart contracts that do something with it so anyone claiming that they have solved the oracle problem is full of assumptions let's say because for example who are we going to allow to update the oracle let's say we have a smart contract on the blockchain side and we allow someone with a specific key to update the values of uh of the oracle for example price data like let's say uh the price of uh heath or price of something else uh pen pineapple apple or something else so the problem with having only one person update this oracle is trust we don't want to trust only one person that's why we built blockchains in the first place then we can have multiple feeds multiple people that are updating the the oracle contract by but here there's also a problem how do we know which update to take and how do we know if someone is actually not not genuine with us with their information that's why we need some kind of a conflict resolution so to resolve this conflicts we implement some kind of consensus mechanism for example with prices it is very common and usual usually projects implement a median they take the values from multiple feeds they then calculate the median value and that is stored on chain as the actual price for this period of time but this actually at least with the current gas prices is very expensive because having this median calculation done separately for each feed that means we have multiple transactions that need to be verified and then this costs a lot so what we could do is actually uh introduce a third-party relay that gathers all the information from the feeds that post data about prices or anything else actually and we let only one entity post data on the blockchain but this on the other hand uh introduces us to a different problem which might be censoring so the single relay that we implement can be censoring other feeds so we need something more sophisticated let's say so we try to decentralize the relays also so we have multiple feeds on one side and multiple relays on the other side and each of this relay has all the data that other feeds have provided and at least one honest relay is enough to make sure that we post the data to the blockchain and no one is censored because and of course projects need to incentivize positive behavior and maybe use some kind of slashing or something if someone posts uh not proper data so first we have the off chain side which is quite important and for example we can have a feed that communicates through a peer-to-peer network with relays with uh this this is a signed price message an example from assigned sprite price messages in their maker oracles as you can see we have the type specified we have the version of the software used we have the price and then we have some hex data and we have hash a hash and the signature of the feed that has actually created this message uh and i will i will not be going into the detail of the off-chain site today uh because there's a lot of it and if you would like to see the software that is actually doing it for maker protocol you can go to these addresses so first oracle's v2 is the second iteration of oracles that were implemented by maker and it's an orchestration tool let's say that utilizes other projects other other software to create the whole oracle system so we've got omnia which is the software for feeds and relays and we've got the oracle suite which is a re-implementation of this software in go and also uh it has a very modular structure so any project could actually be using some parts of oracle suite to use for their advantage and on the change side so we have smart contracts that need to realize a few functions so we need to make sure that only some trustworthy feeds are posting data to the chain so a smart contract needs to have some kind of authority authorization then we have the consensus protocol of course in the case of prices or other numeric values it's usually common and makes a lot of sense to use a medium of the values because any outliers any values that go way beyond what we would consider correct value will actually be filtered out by this kind of consensus but we could actually implement something else we could implement let's say a majority vote for some values that are not so easily quantifiable so feeds could actually attest to something that happened a fact from any domain actually and then the consensus method would be to have a majority vote from the from the feeds and to choose that to store in the oracle and one additional step is crucial for most projects for the step is delay usually when feeds post data to to store it on chain it's immediately accessible by anyone and anyone can use it but since we have very volatile prices of most of the assets in blockchains it is actually not a very good idea to use this value directly because this data about uh about prices is actually public so anyone can take it put it together with a transaction that actually does something with this price and they can use and front run uh the the protocol or some other projects with the data they have off chain and then they can use it together with some other functions that they can call on contracts so for example if a price falls very rapidly but this is due to some tampering with the with the prices on the feed side having a delay always is a last resort and you could stop the the project for actually being uh ragbolt or something in time so usually it is a good idea to have a delay implemented within the whole oracle system to be able to counteract this malicious behaviors and maker implemented the median and the delay solidity the first is available at this address so this is the the medianizer that the contract that takes all the values provided by feeds verifies that they were actually signed by allowed feeds and then stores this data and osm means oracle security module which actually introduces this delay so let's go into code this is a solidity contract for the midianizer we can ignore the lymph node class because uh it's just uh a small detail that we are not concerned about right now but as you can see the neon contract has some authorization methods and fields which are utilized to control who can write and who can read to this contract for example we have words that determine who is the admin of this contract so who can change values uh like parameters in it and also have a list of oracles of uh so these are the feeds and their public addresses that we allow uh to that we allow them to push uh the data to our midianizer contract and then we have [Music] we have addresses of contracts that that can read from the the median contract so as you can see here we have we have a modifier that's called tall so we require the message sender to be in the list of the buds or bodies and if not the transaction will be reverted and then we have the whole update function it's called poke by the way it's part of the taiwanese language in used in maker protocol in multiple contracts which means that like for example most many of the functions or most of the functions are uh four-letter words so we poke the comp to update the data let's quickly go through the whole function so first we require that the length of the right that we provide so the list of the prices that we provide is exactly what we determined to be the bar so for example in maker we the bar is usually at 13. so out of the 26 feeds that we have we need at least half of them to to be used in an update so we can reliably determine the price for the for the asset and then we loop through the whole list of prices with signatures and we recover the address of the signer using a recover functions function which i will talk about later and then we required the signer of the message to be in the list of oracles and we also require that the every data point that we use to update the contract is actually younger than the latest medianizer update and then we make sure that the list is already ordered so we can choose the middle value as the median of an uneven number of items in an array and then we just store it so we've got the two uh crucial um parameter functions of of our oracle uh here so we verify that the data is correct and signed by allowed feeds and then we determine the median so this is our consensus and we store it on chain and now about recovering the signer address so we've got a simple function that actually uses uh ethereum's ec recover function and it's it's capable given the signature which is divided into vrs parameters given the signatures and the values that were signed uh it's capable of uh determining who actually signed the the list the the this particular price so then if we uh have this address we can compare it with the array of uh with the list of addresses that are allowed to update the contract and this part is used to introduce the one-hour delay we have defined some constants and some values some fields that determine how often was how long ago was the medianizer updated and then when we poked the osm i'm sorry so when we poke the osmiu update that the values into uh the security module we take the current uh we can we take we set the current value as the next one and then we we say set the next one as the value that has been provided in this update so as you can see we have implemented a way to make sure that we know in advance uh what price will the oracle system as a whole show to the external contracts to to be used for for anything they actually want and this is a small dashboard that was created by the community of maker [Music] and it shows the median energy price as it is stored in the medianizer contract and then osm price the current and the next osm price as you can see uh it was updated eight minutes ago here and for example usdt was updated 133 hours ago that that actually is because we have disabled updating usd tv because we are no longer using it so if you have any questions i'm open to to them and looking forward and this is a qr code for this presentation actually do we have any questions uh we don't have any questions at the moment uh very well the only thing i would like to say is that of course as most of the projects we are hiring so if you are a back-end developer mode in go or a smart fax developer or a front-end developer just contact me and i will forward your uh your call to whoever is responsible for handling that on our site so thank you i'm looking forward to any contacts from you you can see my twitter handle here and my blog address there's nothing really up to date there but anyway so thank you very much and hope to see you next time