Onchain Oracle Design, Security Considerations, and Cost of Manipulation

Transcript

everyone and I'm shin and I'm a researcher at unisoft Labs today I'll talk about the economic security of unchain oracles let me just quickly flip through the slides so you kind of know the structure of the talk and then we can come back and revisit so the first oh how do I this one the big one okay uh so I'm gonna start by motivating why we are talking about this but given that people are coming to this particular conference I'm assuming people know the importance of the on-chain Oracle

security then the second part will be analyzing the exact cost of manipulating a particular on-chain Oracle given that you know everything about the pool and how the Oracle is designed which will serve as a foundation for the third part which is if you know the exact calculation you can then evaluate the security of any particular pool combined with a particular Oracle design uh this will be an incomplete framework but it serves as a starting point to asking the question of how do we design better oracles and enhance the the

manipulation resistance of a particular Oracle the fourth section will just be some stylized examples of how do we think about designing Oracle and Implement better ones and the last one will just be some recommended best practice in terms of having your own you know oracle design that's manipulation resistance so let me go back to the beginning now whoops okay so we know that a lot of protocols use launching oracles to function specifically lending Protocols are a prime example there's hundreds of

billions of dollars and you need to know whether their collateral is enough to kind of collateralize the debt that people are boring specifically chain link is a very popular Oracle that feeds into them partially because it's seeing it as this more manipulation resistant Oracle well ironically because some of it is somewhat centralized uh and then there's newer Landing protocols like uh Euler who experimented using unit swap protocol as a decentralized price feed but they did switch to chain link after the switch to ethereum switch to proof of stake which I'll talk about why

but these even chain link is not a hundred percent safe and we we have seen these highly profitable trading strategies executed against it mostly because some pools are there's only a few venues so the price feed can only come from certain areas and if you basically manipulate the entire market then there's no way of being uh kind of manipulation resistant because there's no other source of Truth and specifically proof of stake changes things for a simple implementation of for example t-wop um or unit swap because previously if you if you

manipulate a pool in one block you don't know who's going to control the next block so it effectively has to defend your position through somewhat of a priority gas auction and you might have to pay back all your potential profits by bidding the next block and so it it's effectively impossible to to keep a manipulation going for more than three blocks whereas in proof of stake you kind of know that the The Proposal of the next 32 blocks in ahead of time and some of the large uh validation pools or staking pools they might even control quite a few blocks in in

sequentially so it's very easy to um for them to do it you know assuming that they're not behaving but evidently or anything and that's kind of the concern uh that drives Euler to I think that drives Euler to switch to chain link post POS so let's let's look at one example that demonstrates why so assume that you have a particular Target let's say there's a uniswell pool and you say hey I want to manipulate the 30 minutes t-wop by 20 percent what do I have to do well first of all you need to know how the 30 minute t-wop

is calculated and specifically it's a geometric mean of kind of a snapshot at the at the end of every block of where the tick is in the pool um so if you want to manipulate a 30 minute average what the geometric meaning of it by 20 you effectively have to let's say you control one block then you have to move uh the tick within or the price within that block by some what's near the scale of 250 000 ticks within one block uh which is a which is a lot of money for uh for a deep pool uh and as SDM or basically as

the number of blocks you control increase uh this this amount kind of decrease pretty fast so if you if you control let's say 10 blocks in a row and you can basically keep that you can basically censor all background transactions or sensor or Arbitrage and keep that manipulated price in place then you just need to move it by one-fifth of what you have to do or actually maybe one tenth here um so the point is that to demonstrate that as you control more blocks the cost of manipulation is reduced drastically um the tricky thing is uh at any point in time the distribution of liquidity

within a pool is is unknown right so this is showing the the distribution of liquidity in uh through time and so it's not the most straightforward thing to know exactly how how far you need to move the price uh within the pool to achieve certain amounts of of manipulation um about we we did have some tools internally to figure it out so this is the amount of weed that's required to manipulate the the usdc with Oracle t-wop by 20 throughout time so as you see like the pool has been initiated there's some initial instability period but after which it costs on the order of

hundreds of millions of dollars to to attack um granted that that's a very very deep pool uh it it might be pretty costly but if it's a it's a shallow or a pool or if you somehow control a lot more blocks then it's definitely uh achievable Target okay so now that we know the the foundation we can look at some Frameworks so in my mind the the trade-off that you're making when you're designing oracles is you're trying to trade off uh between a few parameters so let's say your your liquidity is fixed you kind of take the amount of liquidity you can gather as a given then uh you're making

a decision between achieving a more live Oracle meaning it reacts faster to to a new data point uh versus the cost of manipulation right and if you if you want your Oracle to be more sensitive to new data points then it's it's inevitably going to be more uh subject to you know a big data point that's not kind of right uh the second thing is and and this shape uh they're kind of like into intuitive shape they're not really the the scale here uh the second thing is uh if if you have a latency in mind that you you're willing to tolerate then your

game becomes how do I gather more liquidity in my pool and uh and this is something that prompts maybe a design space which is uh kind of Oracle uh sorry a protocol owned defensive liquidity so you might even create a landing pool where you say Hey you lend me money which I put in the pool as a defense against my uh my own Oracle and you're paid this much over time for providing protection of of my Oracle from manipulation the third thing is how much how much deviant dvas uh you can sorry how much deviation you can tolerate for the

Oracle price to be moving away from the true market price and that's kind of interesting because there is somewhat of a optimal distribution once you have an exact uh deviation tolerance in mind because you can kind of just concentrate your pool to the extent that it becomes uh overly expensive to manipulate but beyond that point if there's no liquidity in the pool or at least assuming there's no defensive liquidity in the pool then it's kind of trivially easy for people to just push price uh farther out when there's no liquidity um Okay so

uh how to make better oracles uh these are all kind of hand wavy ideas I'm happy to talk about the more uh offline if you want to hit me up on Twitter or anything but the first thing is this is a case-by-case analysis so the first thing you want to know is what's your objective are you making a Perpetual Oracle for Perpetual protocol lending protocol nft I think they all kind of learn different type of design uh you also want to know your constraint so um how far can you tolerate your Oracle to deviate away from the current market mid for example um and how much liquidity do you think

your pool will attract over time and finally how live do you need your your Oracle to be uh you need to assume that someone is out there who will always try to execute some highly profitable trading strategy as soon as it's profitable right um so it's kind of not okay to say oh yeah like most of the time it won't get hacked because that's not how it works and finally get audits audits involve audience of your codes as well as some sort of Economic Security analysis um and Mark has just talked about uniform V4 hooks we believe that uh

there's there's abundance of design in in custom designed hooks that can sort of um expand the design space of oracles or on-chain oracles vastly some of the ideas that my colleagues and we at Labs have explored are for example truncated oracles which is basically an oracle that whenever they're faced with a big kind of Oracle price update I will say whoa whoa whoa let's let's take it take it easy and slowly you have this price change of say 500 percent in one block let me gradually take that information in right maybe five percent block ten

percent a block and if if it's somehow immediately goes back to the previous level I only taking how much I have taken so far and I just I kind of throw away the rest of the update so that's one way that's kind of sacrificed a little of latency um or or maybe liveness but on the other hand you can say wait like if things are immediately reverting back to normal maybe that data point should be thrown out anyways um so yeah try V4 hooks so here's one example that I've written out and that you start with your objective that you want the highest resistance against attack to move 30 minute tea off by over 20 percent your

constraint is you have a liquidity of of 20 million dollars and you assume that's like the profit of a successful manipulation it scales linearly with with an attack of like your TBR or whatever and then once you know all of this you can say okay if if this is what I'm working with as parameters maybe I can kind of find the optimal defensive liquidity distribution in my pool or maybe I can find the best like truncated Oracle design or medium Oracle design something like that um and it's basically just solving a constrained optimization problem and

check if the cause of manipulation is greater than the gain um buy some margin you know and the last thing here I want to talk about is uh uh I guess I'm just kind of re uh reiterating some of the design space that's maybe new in unisport V4 so for example you can uh well this is this is available you just want V3 as well which is you can kind of generate your own defensive liquidity and use it as a as a means to defend against these attacks and bear in mind the the really kind of convenient thing or things are number

one it's a it's a geometric being at least in unit 1 V3 so as you push price farther away uh from from your current uh current mid price it's kind of mechanically true that it becomes exponentially more expensive the further out you go and also there's a there's a fee component so uh it might be only a 30 basis point pool but if you're buying eth for like a billion dollars per each then it's really really expensive to push price marginally further um the second thing you can do to increase your liquidity is you can first start

bootstrapping your protocol around pools that are well established right so for example like with usdc pool or usdc usdt pool these are pools with very deep liquidity and if you start with those pools you don't have to boost track your liquidity from from zero and you can just say hey you know uh here's my V4 hook that implements this very stable Oracle why don't we try that that's a good starting point the second thing you can do is increase latency tolerance in your Oracle design and that's really up to the product that you that you're trying to push to Market based on the Oracle right so I've run this pool a poll of um

of like which uh which use case has the highest demand for Oracle liveness I think it's just related to the inherent leverage in those products and perpetuals won't the the race I guess but again like these things you can kind of design them around the most feasible Oracle that you can come up with and there's truncated medianized and many more type of design that you can Implement in unison V4 through hooks [Music] um yeah same thing you can kind of increase the max deviation tolerance again here's what V4 hooks good place to to start

and that's that's all I want to talk about today um oh sorry I just realized um I added some lines for other talks at unisol Labs uh if if you want to watch them maybe just check their Twitter account I'm sure there's a calendar out but yeah otherwise feel free to DM me on Twitter or through my own personal website I'm happy to look at your design thanks thank you [Applause] hi hi amm's arguably can't represent the whole Market no

matter how close tracked they are with Sport price is manipulatable and the top price is not accurate enough what do you think at the industry we should just drop the idea of using amm's at oracles at all uh I think it's a radical idea uh as saying yes I agree that amm is not the entire Market but also like no other Market really is and it's really just compare again like the the whole point of this talk is to say you know you can't just wave your hand and say hey this is the best possible it never it's never going to be manipulated but rather it's really a like a a cost versus benefit comparison

in the mind of the potential hacker and you have to be one step ahead and say hey I know this is what you're going to do but every time you do it you're going to lose money so you might not do it um and so again like amms they are not the entire Market but they're subject to to Arbitrage and so their price is basically tracking the global price somewhat and working with that design you you kind kind of work out and back out your math of saying this is really you know a constrained optimization that I'm doing and my Oracle is somewhat close to the to the true price and it definitely brings the benefit of decentralization and and all that and I'm sure you know of any other questions

all right oh over there hi um are you familiar with Anja Finance any chance it's a random new protocol uh not yet okay yeah so they have basically it's a borrower Market I'm not super familiar with it but they actually are Oracle free and I think they use some kind of Arbitrage for that which is specific to their protocol but I'm curious if protocols could use maybe amms or even centralized oracles but then have some kind of fallback mechanism where you can have some kind of Arbitrage if the Oracle is like wrong basically uh yeah I mean uh it is one of the

design a lot of optional oracles are trying to build uh basically this Market oriented approach and say we're Oracle free but you know just as unusual pools Oracle free kind of means that we just don't update and we wait for the market participants to update us so if you're working with that assumption then you have to know that you know just as there's some toxicity flow discussion uh you know occurring on universal pools all the time that might happen to your own design depending on how you have incentivized people to participate so no Oracle just means there's an inherent Oracle of like not updating yeah all right

I think I'm time is up so uh maybe everyone give it up for Jen thank you very much [Applause]