barparameter is the minimum number of prices necessary to accept a new median value.
read- Gets a non-zero price or fails.
peek- Gets the price and validity.
poke- Updates price from whitelisted providers.
lift- Adds an address to the writers whitelist.
drop- Removes an address from the writers whitelist.
setBar- Sets the
kiss- Adds an address to the reader's whitelist.
diss- Removes an address from the readers whitelist.
valueor fails if it's invalid &
peekgives back the
valueand if the
valueis valid or not.
wards(usr: address)- Auth mechanisms.
valwriters whitelist / signers of the prices (whitelisted via governance / the authorized parties).
val- the price (private) must be read with
age- the Block timestamp of last price
wat- the price oracles type (ex: ETHUSD) / tells us what the type of asset is.
bar- the Minimum writers quorum for
poke/ min number of valid messages you need to have to update the price.
medianis the smart contract that provides Maker's trusted reference price. Authorization (auth) is a key component included in the mechanism of this contract and its interactions. For example, the price (
val) is intentionally kept not public because the intention is to only read it from the two functions
peek, which are whitelisted. This means that you need to be authorized, which is completed through the
budis modified to get whitelisted authorities to read it on-chain (permissioned), whereas, everything of off-chain is public.
pokemethod is not under any kind of
auth. This means that anybody can call it. This was designed for the purpose of getting Keepers to call this function and interact with Auctions. The only way to modify its state is if you call it and send it valid data. For example, let's say this oracle needs 15 different sources. This means that we would need it to send 15 different signatures. It will then proceed to go through each of them and validate that whoever sent the the data has been
auth'd to do so. In the case of it being an authorized oracle, it will check if it signed the message with a timestamp that is greater than the last one. This is done for the purpose of ensuring that it is not a stale message. The next step is to check for order values, this requires that you send everything in an array that is formatted in ascending order. If not sent in the correct order (ascending), the median is not calculated correctly. This is because if you assume the prices are ordered, it would just grab the middle value which may not be sufficient or work. In order to check for uniqueness, we have implemented the use of a
bloomfilter. In short, a bloom filter is a data structure designed to tell us, rapidly and memory-efficiently, whether an element is present in a set. This use of the bloom filter helps with optimization. In order to whitelist signers, the first two characters of their addresses (the first
byte) have to be unique. For example, let's say that you have 15 different price signers, none of the first two characters of their addresses can be the same. This helps to filter that all 15 signers are different.
liftfunctions. These functions tell us who can sign messages. Multiple messages can be sent or it can just be one but they are put into the authorized oracle). However, there is currently nothing preventing someone from
lift'ing two prices signers that start with the same address. This is something for example, that governance needs to be aware of (see an example of what a governance proposal would look like in this case in the Gotchas section).
val = uint128(val_[val_.length >> 1]);); this code snippet outlines how it works, which is by taking the array of values (all the prices that each of the prices signers reported, ordered from 200-215) and then grabbing the one in the middle. This is done by taking the length of the array (15) and shifting it to the right by 1 (which is the same as dividing by 2). This ends up being 7.5 and then the EVM floors it to 7. If we were to accept even numbers this would be less efficient. This presents the issue that you should have a defined balance between how many you require and how many signers you actually have. For example, let's say the oracle needs 15 signatures, you need at least 17-18 signers because if you require 15 and you only have 15 and one of them goes down, you have no way of modifying the price, so you should always have a bit more. However, you should not have too many, as it could compromise the operation.
spotter, as DSS operates in a pool-type method (doesn't update the system/write to it, you tell it to read it from the OSM).
lift'ing two prices signers that start with the same address
peek, telling us to not trust the value.