Oracles from the Ground Truth to Market Manipulation

ETHCC 4 · July 2021 · 43:54

Shayan Eskandari examines the trust assumptions involved in bringing external data into smart contracts through oracles. He organizes oracle design alternatives, illustrates attacks against those systems and discusses strategies for reducing manipulation risks.

Speakers

Topics

From ETHCC 4, hosted by Ethereum France.

Transcript

thank you um so welcome everyone um this talk is a 40 minutes talk so i'm going to try to make it exciting um we're going to talk about the oracles in general not anything about it just price oracles and other things which we'll get into before that and just a bit about myself i'm a security engineer and smart contract auditor with consensus diligence in a parallel life i'm doing my phd right now at concordia university my thesis is molly on new technology or old crimes

how um crimes are using blockchains and cryptocurrencies to evolve into new forums and we can read more about these at my website previously i was working at startup which were making these bitcoin atms if you have seen this orange interface probably you've seen um some of my code out there um and it was a really interesting experience and from that company that triangle that you see up there gonna evolve which was another project which i'm gonna start talking about that and lead to the actual oracle talk so back in those days and

i just want to like talk about before getting to oracle let's talk about one of the experiences i had in real life and mainly to say that i believe rethinking the way we are doing oracles and d5 and other blockchain space is really important aspect and we should make sure as a whole ecosystem we talk about it more often um so it was 2016 my boss came back to me and he was like there's this thing there's this thing called block ethereum do you know about it and i was the only blockchain engineer in the whole company and i was saying yeah i've read about this one and there they were like having this idea of having a decentralized derivative market

on blockchain which then was ethereum and um me being this naive bitcoin only blockchain developer was like cool just give me two days i'll learn smart contracts and make a simple application to store the price from the exchange api just simple as that and i was mostly working with python back then on clouds so in python it's just two lines you import the library you read my idea of um writing new solidity was really similar it's like i just need to get an api and just to give you some context this is before even pragma was a thing for solidity and i think the last update on my code was 0.4.1

the compiler so it's pretty old so i was like trying to figure out how to write this and after a day i was like wait who's calling this api like everyone's calling this api at the same time who's storing it what's happening and that's where i realized oh wow like this is this ethereum and smartcon is much bigger than i thought similar to cloud so let's just give you some context on like what we were trying to build so we were trying to build this decentral derivative market and so basically we need the smart contract for the code logic that holds the funds we needed a price feed and for proof of concept we just wanted ethereum to bitcoin price

and more context there was no stable coins yet then um tether became a silicon on ethereum in september 2017 maker dao white paper came out in december 2017 so a year and so after all these and we needed a ui and users so for makers we just got brought in users for take care we were using the smart contract as taker i'm not sure how many of you have been around back then but there was this project by around devcon3 called prism by shapeshift which was a similar idea and if you think um because amms automatic market makers

were not also a thing and i don't remember reading about bonding curves back then and so like if you see this as uni swap which is a two pair prism by shapeshift was like a balancer so you could have like a basket of things um so i don't want to get into details of this but it was a colored option contract meaning that you could bet you could go long or short and you would profit from that up to double that your amount so just um a simple logic in the contract and we wanted this price fee so what option we had um so only a few projects existed back then and it was a lot of them were buggy so

we had this smartcontract.com which now is known as chain link so back then they had this uh price feed and it was only updated at 12 a.m midnight every once a day so it was not really what we wanted to go for we wanted to go for it so for an optional time a day so you could choose any expiry date and your price and just buy the option for that there was this other project called oracle is it now is known as provable things and it was more of a request response to fetch any api and this was more of what i was looking for

so just to give you an idea how oracle has it worked um so on the bottom side you see the oracle is a server so the server and they had this smart contract on top on the blockchain so um your smart contract would send the request as a transaction to oracle is its smart contract archaeology server was monitoring this smart contract for events and when a request comes with fetch the api using a server send it back to this oracle is a smart contract and then send it as a transaction to your contract so a callback um so i remember i implemented this whole thing it seemed to be working and um ethereum was cheap so we were just using mainnet

tests which was okay and one of the last interactions i had with oracle is it um i'm not saying bad things about them just seeing implementation in 2016. um so it was a friday afternoon i was like trying to open some options and try to wait wait for them to settle and i waited for hours and nothing happened i tried to debug everything i said overnight it didn't work so i was like okay i don't know i just emailed oracle i did support describing it a problem i was like i have this problem what can i do and on monday morning when i came back to work i saw that all the callback transactions were in every all the options were settled and i got an

email from oracle this support saying that oh there was an issue with the server it should be working now don't worry and in my mind it was like it took two days to settle like this is not acceptable i need my own price fee so that's what's the motivation of creating this project called price get which and this is again back in 2016 which was really similar to how um oracle does it work but it was a price fee so there was this component called price fetcher which was basically storing the price every second it was monitoring death for new blocks and whenever a block

came so it would just send the price at block time with block type block number as the index to the blockchain so to the smart contract and so eventually you would have this price get which is a price feed smart contract and also a history card price ledger for anyone to read so um if this architecture is like familiar to you uh probably you know about time crier which uses sgx in to make this more secure or one of the reasons more recent oracle's called dr thing which is pretty close to the same design yeah so this was the interface we

created this interface that as you can kind of see it's a bit more concluded the price feed was following the actual price so everything was working we're like so what's what now should we do an ico like what what's going on um but we had some trust issues so we were like we don't want to be trusted in the system and in late 2016 basically like we shut down the project even though everything worked for proof of concept uh price get was okay for proof of concept but we wanted a decentralized system we didn't want to be trusted to have the risk of um liquidity providers being exploited

for any reason and it was centralized like we were running the price feed and that was not really um accessible to us and this is actually an article from newsbtc and this last sentence is from that article saying uh it is too early for financial derivatives in the ethereum ecosystem it seems technological restrictions are to blame in this regard overall it was a fascinating experience so as i put my academic hat on and wrote this whole experience as a paper which was published at financial cryptography in malta um i suggest you if you do trying to design a system read this some parts might be a bit outdated but overall it's still like a

really good read and you may know one of the co-authors as mitha koven or the owner of people 5000 days good old times and for the lords like this paper is also available as an nft i don't own it anymore someone bought it from me but if you want to poke around it's on zola and the link is at the bottom you can check it out um so this was the story i want to tell you to like what i went through early on with oracles and five years later we are here oh actually yeah five and a half years later because i also did my

comprehensive exam of phd on oracles and mainly the title was oracles without them smart contracts are lost and it was mainly focused on the academic work in oracle so looking at projects like town crier deco australia and i really tried and i fit in chain link in their chaining wasn't really an academic paper but it was popular enough to be included um so now now we like this whole talk is surrounded surrounding this paper which we released recently and it's on the review but it's a sok paper if you know sop if you don't know slks is

a systemization of knowledge meaning that it's a comprehensive research on the state of oracle so everything about oracle's that we know in a systemized way um and we came up with this modular framework to be able to analyze oracles think about oracles and systemize the design alternatives and we talked about a lot of attacks in the paper some mitigation strategies and mainly how to rethink oracle design and the paper is available online if you want to read so back to the subject oracles let's just define this what is an oracle what is the context

and what are we doing here so um we define oracle's as an oracle is a bridge or a gateway that connects the off-chain real-world knowledge to unchained blockchain network so just this connection on the bridge is an article we do not limit this definition to price discoveries which is the most recent narrative about oracle's in the context of defy we just talk about oracles in general and the oracle problem which is if the oracle is trust is trusted why not just give all the calculation and computation to the oracle and how to solve this work problem is still real still an open problem

but i believe we are really close to the solution we'll see uh we're pretty close so the prophecy of decentralization as morpheus once said the prophecy will be fulfilled soon but before it can be the oracle must be consulted um based on this research like we learned interesting things that a natural question that a small contract developer should ask is if i'm trusting the oracle why not just have it compute everything and a lot of these oracles that we looked at um there's a deep centralized point somewhere in there like almost all of them but we'll get to those points there later on um as i said like oracles mostly

nowadays are used for price discoveries which include their stable synthetics assets its derivatives even some prediction markets use that and also the text texas but there's so much more that oracles can do um like as an example for provenance systems like for supply chain to identify with where an item is or for identity a government or an institute an incident can run its own oracle to do kyc do some kind of like identity on on the blockchain um as you may know blockchains are um deterministic so no randomness so for randomness we have

projects like chaining vrf uh verifiable functions that offer this service some less explored places like dynamic nfts most famous example which is on the i think it's on the chain link blog is about like if you have these nfts of a soccer players they could change based on how that player is doing in real life um so these are all use cases of oracles that are out there and there are so much more so um basically here we came up with this modular workflow i have breakdown the oracle system and

design into modules and just a disclaimer for the audience if you've never thought about creating or understanding or even analyzing an oracle system the next few slides might seem to seem kind of irrelevant to you but toward the end it will all come together and give you an idea on how to think about internals of an oracle this is more systemizing and rethinking oracle design so these modules that i'm i'm getting into could be unchained of chain in different orders but any like all oracles even the future oracles should be able we should be able to

define them using these modules and this framework that in this paper so there are these main six modules here are the core parts of like the oracle design but also consider that we have we have to get that data to a smart contract so there's a whole part of interacting with blockchain and as we get later in this um talk there are so many parts that depending on the design you have some aspects of how the blockchain works can have impact on that and you you probably need to redesign some parts to make sure you're not vulnerable to

those kind of attacks so let's get into this so um the first thing is ground to truth like any oracle designer should ask this philosophy called millennium holds question that what is truth um or has some known truth with capital t um so is this like objective subjective like as an example if i ask all of you here what is the real price of ethereum to you now probably you're going to have some numbers that deviate from each other it's not going to be exact same number and so basically we're trying to solve here that what is the best way to collect raw data from sources and aggregate them to have reasonable data quality um

so the next step is would be um data sources like these passive entities that store measure uh measure the representation of grand truth and we have these common types like database or apis similar to centralized exchange prices you have sensors which could be used for blockchain supply chain and humans for prediction markets some oracles use like human judgment uh small contracts which are unchained markets such as can you swap being used as oracle or a combination of them or we can be like two smart contracts like two different combinations we have really interesting uh details

and attacks about these in the paper but it's i don't think you have enough time to let go through them um so the next one is data feeders so basically these entities who gather and report data from the source to the oracle system so a common configuration would be similar to the price fetcher which i mentioned like external feeder which gets the data from off chain data source and feeds it into unchained module and in case there is the data source is a smart contract the data feeder would not exist because everything's on that part is unchained and in this module there is no attempt to determine if the data is falsified or malicious

we deal with them in later modules and this is mainly to tunnel the data through the feeder with some useful security provisions so as an example like source authentication is one of the most common ones and is really important meaning that to establish data integrity to prove that this this data that you're showing is coming from this this source that you're claiming so project like deco or tls notary they use https data and use the tls handshake to prove that this this data is coming from the server um some of the projects like time crier basically put down the trust in the trusted environment execution environment and

as an example intel sgx so basically pushing the trust assumptions to this technology and ultimately intel the chief manufacturer and some other aspects that um are in the paper so the next one is selection of data feeder so from here on things get tricky things you have to figure out how to define these if you define designing an oracle so how would you select legitimate data feeders and read out less qualified participants so um like early oracles like oracle id to price get you just use a single data feeder there were no selection but we learned that to increase the

resilience of the system and availability we need more data features so one of the first methods would be a centralized loudness selection meaning that you have a list of legitimate legitimate data feeders which you're selecting from so maker dao oracle version one was using this so the list was approved central in a centralized way and we learned that by decentralizing decentralizing the selection process we can distribute this trust from a single entity to a collective essential governance and um comparing these two like the central approach

uh central approach has a more optimal speed but um it really depends on the design so for the decentralized allow this selection it's possible to do voting which um similarly maker make it down oracle version two users voting to add um legitimate data feeders to the allow list but also consider that it introduces the threat that an actor can accumulate voting rights to sway away the vote or even destroy the system um i think it's called think goldfinger attack um and there are some incidents like um make her down

there was this incident i think last year that b protocol team used a flash loan to pass their proposal which enabled them to be added to their loud list this is not considered attack because it was not malicious and the vote was already kind of passed but you get the point and the other method is like using staking for the selection and the mechanics are different than voting meaning that the data feeders would post collateral against the data that they provide and it's basically being in dispute phase later on if they're malicious they would be punished by using some of their collateral which is called slashing

and know that like we also consider reputation based selections and that change leaderboard to be similar to staking because the loss of reputation will result in reduced income from future jobs and the main challenge here is what is that in the setting for enough punishment uh to slash that to punishment slash to toward malicious actions like um like a part like omar project basically tries to define this as cost of corruption to be higher than profit from corruption which

we discussed it later in the in this talk that it's really actually hard to measure that um and additionally some projects cannot include randomness on top of all these and like teller adds uses kind of a proof of work style algorithm to for each round of data to select five feeders or band protocol which uses a random validator from top hundred state participants when i was writing this paper i checked and banned protocol only had like around 70 state participants so it wouldn't be that hard to

have 30 chance of being selected as a validator just mainly to say that this level of decentralization and the algorithm really requires some network effect to actually kick in and work and regarding the level of decentralization also something to consider outside this framework is where are the data feeders getting the data from so one of the examples that jeremy my phd supervisor uses is if there's a nigerian election and we have all western data feeders in like canada united states probably would you use like wikipedia to get the data source as a data source so

that is again a centralized point in your system oh i forgot to put this on on the on the slides so we use the framework to basically measure and score some of these different type of selections so uh so one of the most important parts of this the design is also aggregation phase which mainly means the process of synthesizing the selected data feed into one single output so um just to highlight the importance of

this um aggregation method there was this incident of for synthetics which is a trading platform um that used basically two the average of two data points to two data feeders as their aggregation method and basically the attacker could manipulated one of the two feeders which inflated the reapplies by a thousand eggs and the aggregation averaged them out and still resulted in the loss of a few million dollars of synthetics because um basically it was deviated from the actual price so there are like different methods as i said like

statistical measures using mean median can be used if you believe like your data feeders are feeding a distributed normally distribute the data with possible outliers maybe the median can work but it really depends on the type of data you work with um in order to make that more secure and resistance to market manipulation and the synthetic attack that i mentioned you could use weighted methods using time volume other things and like as an example unisa v1 only had like a spot price which you had to do something with to make sure flash loans cannot be used to change the price and other

things and unisa version 2 started adding this whole top or time weighted average price for the price and now in v3 they added like other things it could include liquidity volume or some improved to average to have an optimized way of getting the price getting the average price and also you can use random selection like as i mentioned you can randomness as some kind of security but also you have to see what is their set you're working with um the one last thing about like the aggregation phase that you have to consider is what happens if the data is expired or stale should it be removed should you actually

use that digital data or use the old one we've seen a lot of like designs that um they don't check the timestamp or anything and it's possible that the system that you're designing uses an old oracle price so one example is the black thursday may 2020 which the price crashed the mark the network was really congested with high fees transactions which resulted in delay in oracle price updates and make your dow oracle price update and given the configuration of making our auctions the like short time frames and some of the factors it resulted in massive liquidation and um another issue was mainly like

not having dynamic fees which we talked in later slides so the last module that you want to talk about is the dispute phase so um this is mainly to safeguard the quality of final output and give the stakeholders a chance to mitigate the wrong data i think i'm like really behind my time so i'm going to go faster here and maybe just skip some details so uh the first is to distinguish the provided level wetting versus data level i think meaning that you could detect and remove bad data providers or vet the data

itself so um like as an example like the provided oriented one could be like a centralized allowance that the provider can be removed or chain link which the person could be removed or go lower on the reputation based lower leaderboard on data level letting um so we can it's slower because you have to have the data staged and could be disputed but just to like illustrate what i mean by this as um like teller when the data is staged for 24 hours before finalization and if it's this deep disputed this period

could could go up for seven days to actually dispute similarly augur is using a similar approach and so after you know that after there is a dispute you have to figure out how to determine the truth and you need a correct data as a reference but of course if you have the correct it has a reference where you can let you just use that as like oracle so there are different approaches like you can do statistical approach plus the collateral staking that any feeders would put collateral and if they're not the honest one they get like slashed um also although considering like a

challenge is challenges setting the accessible threshold for slashing like if you have a large threshold and it could moderately incorrect data could go without punishment if you have a small threshold and honest data but honest but faulty or slow data could just or even volatile markets could be slashed um the next one is like using voting similarly like all year or austria uses they use voting to vote on the tentative outcome if it's false um compared to these two like a statistical mechanism

can be applied automatically nearly instance um but the voltage might take some time for the situation to work out and one of the last methods is like arbitrage it's it's mostly used for the exchange rate between two unchained tokens and one example is nest oracle which basically data feeders asserts the correct exchange rate between the two tokens by offering the minimum amount of both tokens at the same time so if the price is not right someone else can come in are buy eth let's say with the lower price and offer the real price after so this is really similar to like on chain exchanges getting the price for

manchester just because someone can manipulate the oracle by spending money um just like a downside um just to like wrap up the dispute phase so when you have the correct data what would you do with incorrect data so you could either revert or correct meaning that reversion is this whole data would be annulled and the system would restart and start from the scratch to obtain the data correct would try to reflect the new undisputed value the main difference is the complexity of the dispute resolution but mainly it impacts the finality of data meaning that

it could introduce delays much longer one example that was a bit surprising to me was uh regarding augur uh which is a prediction market on binary events like zero one years now and any observer in the system can just dispute around by staking rep tokens um on the on the other opposite outcome and when the dispute happens it it's the window is 24 hours but it can be extended up to seven days on dispute of these on disputes so uh dispute inception kind of but it's interesting that if the total stake amount on one issue exceeds two point five percent of

the rep token top total supply the whole market everything about an auger enters into a 60-day six zero uh settlement phase called the fork window where all the rep holders could be it should stake on the outcome and so this is one of the parts that dispute phase in it gets tricky because it could be used to halt your system or even attack correct data or mainly just to delay a finality of data and one last one the consequence for data feeders it could be banned slashed and on so we have like all these implementations in one chart um please look at this at the table and

if there is anything on the project you're working with or anything that here you seem to be like it's not quite right let me know as you may know projects evolved much faster in this ecosystem and this table has a limited shelf life of usefulness however the whole workflow itself modules of modules and the design decisions are based on the general principle and they have to they intend to have a long lasting usefulness so now we want to enter the dark ways so depending on the oracle design you could have a different off-chain data off-chain components um we shortly talked about this but it really

if you have like a using smart contracts as your data source you might not have some of these but you still probably have some off-chain components for monitoring but that's that if you're using unisop you don't have anything there uh so i'm going to go fast on these because there is not that much time um the option infrastructure usually consists like of a single server like tom crier or sometimes many nodes that intercommunicate to the consensus protocol like chaining ocr and the main ports main important parts about these is like availability and the os dynamic assist denial of system service

resistance um connection to the data source you could use the source authentication to prevent some of the attacks and data feeder network like ocr chaining ocr uses this leader that gathers all the signatures and when the contest is achieved on the aggregated data it just sends the data with the signature to the blockchain so it reduces the cost significantly while maintaining similar security because of the digital signatures but as i said availability is really critical here maker dow oracle v2 uses a similar off-chain network of feeder network and

in december 2020 they had an a few hours outage uh do the bug on their peer-to-peer data feeder network stack and the system could not work so there's so much literature on the peer-to-peer network like civil attacks and attacks that we point out in the paper and the last one here is like the transaction creation which is another important aspect here like that you need to keep this private key secure and the signing process secure because if anyone can compromise this they can impersonate the oracle which is a big deal here and positive balance for gas or dynamic and dynamic gas fees

which like an example is in september 2020 nine chain link operators were attacked through the spam attack and they lost around 700 in gas fees so it's really important to keep the monitoring of the network state and make sure the fees are set and again availability here is the main key uh the blockchain infrastructure i won't get into that much detail here right now but you need the blockchain node synced and available possibly possible that there would be network partitioning attacks or other kind of attacks um the block creation we have front

running uh possibility of front-ending attacks or um if minor like it i would say transaction reordering when the miner that reorders that or mev or maximum um extraction of value when um for maximum extractable value when it's on the flashbacks or similar to that and the last one is in the consensus level actually it's not last yeah which the uncle blocks could be used or small reorgs could be used to attack your oracle meaning like one example is the ether role reorg attack which ether role isn't this unchained gambling

game where users bet by sending a number and wait for the oracle random number to have a specific condition um in april 2020 the ethereal team detected that there is like this front-running attack on their platform and it was really interesting attack that the attacker was betting constantly and just waiting for small small forks or some uncle blocks coming in and in those uncle blocks the original bet was there also the oracle random number response and because of their reorg they would just go back to the mempool and the attacker would just replace its own original bet with a winning bat and with high gas feed it let's just run from its

original bed and basically win the rounds there is like extensive research on consensus mechanism and how to attack them that we won't just discuss here um so we have two different kind of designs and then in itself design which is like a smart contractor designed to be an oracle and a means to an end which is somewhere called that it by product of an oracle another application um i'm just going to go faster here so the interaction models we have like a feed which publishes data for others to see there is no additional transaction needed although there is an interval to update

we have requests and response which is really similar to client server api requests and at least two transactions are needed uh to get there we have this other possible design it's called subscribe and response which is similar to requests and response but doesn't need to have a transaction to request it could be of chain agreement or oracle's can subscribe to the event and these kind of things so oracle smart contract which can include the data feeder selection aggregation mechanism dispute resolution also if it's a feed a data feed storage authenticate or also authenticate oracle response

this is really important because i've seen some projects even uh once it was seen that um like i think it was i forgot what project was a nexus mutual that uh under code hope gladly was not attacked but they were not checking the callback that is coming from actual oracle and anyone could just call that function and update the values um so yeah i'm just like passing by these because i see that i'm not going over time so the main points here um anyways was too fast at the end sorry about that and the main points here is like there are some learnings from this whole research

and one is like the oracles use their governance token for staking at all times and there are two necessary conditions here one uh the market capitalization of the token should stay material um the token it should be evenly distributed and i know vitalik had this blog that talked about this system like using uni as this such a token um also bitcoin could be used and now maybe fox even but consider like collapsing the value of this governance token threatens the entire system so i'll consider that and we need a way to like be able to incentivize unchain oracles for use cases with no director of any move

like if you need weather data on chain how would we be able to incentivize users for that because there is no direct income from the value from the trades or anything and the third is diversity in software promotes resilient in the system so if there is one project that everyone really relies on failure in that project have a cascading failure across defying the whole ecosystem we should consider that and the last one which i wanted to get more into more details but there is no time is you can't capture the full extent of profit from corruption because that corruption that profit could be outside ethereum outside all the places that you're looking into

um and so yeah i would be happy to like continue any of these discussions over twitter or feel free to email me um and without a conclude my presentation and open for questions [Music] and i would be happy to answer on

twitter and email anything there so thank you thank you hopefully see you there next year