Security Discussion 2

Transcript

we're going to bring everybody up for a panel and then have everyone ask their questions of whom they wish so they need to please take a seat mudit tarun I encourage you to sit okay so I have a few questions but I want to hear from everybody we covered a lot of ground does anybody have questions for any of our speakers please so yeah so I was saying my understanding is the

analysis showed that it was safe like the attack was not viable and therefore you could go and make the proposal to remove the pool or whatever the uh solution was yeah I was wondering did you have a path in case you found that the attack was actually possible and what would you have done in such a scenario yeah that's great that's a good question um and that that scenario I think we're just basically in the same process in tandem basically talking to uh people who were lending a next sushi and basically telling ex-sushi lenders who are actually at risk in the sense that they're the ones taking the biggest loss to just withdraw their assets so it was kind of two things in tandem

one trying to analyze security figure out uh if this could happen and then making sure the proposal was safe but then two uh yeah like trying to encourage people to not lend in next sushi and I think that was successful I think I mean you were around too so he can also yeah I can add a little on that so there was one possible path which is fdh using their Sushi to exploit it we figured it was not a very practically viable path but in the longer term you don't want that risk at all you have another question please

uh just when you're like what can give an example of what your bug injection system looks like like you you provide like you know the elevator um yeah just high level example that yeah I think I didn't mention it but yeah mutation testing first of all is a good approach um the problem with mutation testing is not necessarily every mutation should be caught I mean some mutations are okay they are not bugs and we do actually a manual bug injection we have someone that understand the system insert bugs that we want to make sure those are caught so like is that like modifying just variables in the states um yeah modifying variable changing the change

[Music] bugs that we that we get right so like uh confusing in the message sender and the user and confusing about um computation a bitwise operation and yeah logic operation all the things that we actually see as bugs those are the ones that we will insert thanks hey everyone my name is Lee I am a David Euler so if anybody wants to hear more about our [ __ ] coin pools or thoughts on oracles that I'm happy to chat my question is for muted uh what do you view as the solutions to the problems that arise with t-wop oracles I guess

both with and without the additional problems that arise with the merge for sure so there are different components you can fix for example instead of using average slash mean you can use median so that takes away a couple of problems uh the lake you can additionally add backups to the price so for example you can say by default you use TiVo but you also cross check it with some other source and insurance it hasn't changed more than x percent uh from that Source or you can even just time it that um there shouldn't be like more than x percent change between two values between two blocks so you can remove

these uh like anomalies or manipulated values like if you are uh even with median if you are taking multiple values and averaging them uh you just average let's say the 95 percentile rather than all of the values so that would remove the manipulated stuff and that way you can build a secure t-wop system but in practice it is very cash complex and it's a very complex system to build uh we might have something like that in the future I know Euler is working on something but right now it doesn't exist um sorry just repeat that from the the

technical aspects do you view this is being involved in sort of new version of dexes or something built on top of existing exchanges or what do you see as sort of the mechanism to it yeah so on that like if you use the existing stuff you can still build a median based uh Oracle but it will be cash prohibitive it it won't be practical like querying all of the values one by one and stuff uh we might have a future uh primitive in the text or amms themselves that allow medians to be calculated more easily or they might have a native uh system which like does the mean or median only on 95 percentile or whatever you define in the pool so

something like that in a new amm or text can definitely be built uh would be interesting to see if someone builds that I I guess I had one thing which is uh one thing I add is uh in concentrated liquidity pools you could actually rebalance around certain events to cause the cost of manipulation to go up so when there are certain types of Trades greater than a certain size you sort of make the Oracle act like a batch auction and freeze or you rebalance if let's say it's mainly protocol on liquidity the protocol Upon a observing a trade could actually rebalance security so let's say Ave was using just as a hypothetical example say Euler Ave was using a

uniswap t-wop Oracle but the protocol was actually providing 50 liquidity to the unit swap pools upon seeing a price update the protocol could compute how it should move its own liquidity within that Oracle uh to such that it has some property that the lower bound of manipulation cost is always greater than some amount so there's definitely a lot of things like that that can be done if the protocol itself actually owns some of the liquidity in the Oracle which I think will start seeing more of uh in the future the slightly different answer that is interesting I was curious what about using a v web so Vivo are even more easily exploitable

because uh then like time is something you can't manipulate on chain you have to wait for the next block to mine 13 seconds later but volume is something you can easily manipulate you just uh keep you take the price to a manipulated value and just you keep going back and forth uh in the same transaction so they are more easily exploitable I don't remember the protocol that got hacked with vivops but there is one protocol that got had like four months ago they were using an off-chain vivop and got wrecked this way thank you yeah a question for torrent so do you think the Insurance Underwriters can use the uh the formulas in your presentation

to price the insurance for covering some different Landing pool I wouldn't do it right now what's the reason why you don't do it right now uh I mean a couple things uh one is I said do you have to have these sufficient conditions for these certain types of like bounds to exist I think we only understand them for a small set of protocols right uh and as people are adding in new more complicated [ __ ] coin pool TMS I would certainly not want any of the Cross margin risk from that to bleed into my underwriting calculation to be honest and it's very easy for that to happen so I think like this is the direction towards that but I

don't think we've reached the Pinnacle of Actuarial Sciences in this space we're very far from that hey tarun my name is Usman I have a question about the way you constructed the or evaluated the probability of the Ave attack succeeding so if I understand correctly you created um essentially an inequality that represented whether the attack is profitable and then tried to evaluate the create a probability space there around that inequality and then sample from it to see whether the attack had you know X profit probability of succeeding is that is it yeah so so the

way we actually did that was we did model all the different borrowers in the system and the different lenders and we ran simulations as a way of where the stationary distribution of these simulations gave us sort of the probabilities of Q star q m c and then from that we looked at whether the bounds were satisfied and like what's the probability of the bounds being satisfied under different volatility conditions and then different liquidity conditions so look at say the top K pools assume that like a certain set of LPS were actually one LP and they all pulled at the same time how much does that lower C or increase C so there was a lot of that and then we sorted like a hyper parameter search of that to see what the max profit was okay got it yeah that was exactly my question I assume do

some sort of like mcmc yeah to sample and I was wondering where you or how you constructed the data that you sampled from most of it's on-chain data for historical data for those borrowers and then for the Byzantine case of like top X removing those were sort of hand tuned strategies so those are not like reinforcement learned or anything like that okay so the last part of my question is do you think that like applying the strategy in the future where are like the foot guns here for example I imagine if you try and Sample over a space of attacker balances it's easy to accidentally Model A Flash loan size balance as a Six Sigma event or something yeah even though a flashlight

I mean you actually sweep the bounds that are possible on chain right because like you know how much liquidity is in Ave yeah at right now and so you actually just sweep through like what the upper bound is so you're asking more from the prospective case of like I'm making a new protocol how do I design it I'm when you're debugging a live attack you actually know what the current state is so you actually have very strong bounds on that does that make sense yeah that makes sense sure thanks do we have any other questions any Curiosities for the panelists no no okay I have a one question for the three

of you so I know the three of you are all doing you know Cutting Edge stuff in different ways and uh you know a lot of it's like magic to someone who's not expert in these Specialties so taking the the totally the flip side and and creating a little bit of trouble for our peers here I was curious what do you guys think is the most ineffective thing that people are using today right commonly very commonly they you know multiple people in the crowd should be using it what are people doing like obviously all of your Specialties but what are they doing that they shouldn't be that's just a waste of time that's a very interesting question so within solid ER there are a bunch of things people keep doing that are not

effective at all uh or have gotchas like safe transfer it's not safe at all it has its feature but it's definitely not safe uh some other things like even safe math I still see people using safe math and solidity 0.8 0.8 already has safe map built in you don't need to add anything more uh hearing that two things well I want to say um too many optimizations but I understand the other side of it of like gas optimization so can we make the gas

down and leave the programs nice and clean wow yeah that's my I guess three things the first is um writing in amm and not taking a numerical analysis class and not understanding how rounding works I mean that like you can 18 year olds understand how that works so I don't understand how you like you want to put a billion dollars into something that rounds incorrectly no I wouldn't do it but yeah I'm happy that I'm hoping more people actually like learn some basic you know how do I do the remez algorithm or how do I do things like that like should be like lingua Franca if you're going to put real money in something

uh the second thing is a lot of zero knowledge proof um systems I think you know there was this amazing set of bugs that like 50 of the implementations had uh where the fiatrimir heuristic was like not implemented correctly and we didn't it wasn't checked uh I think sometimes in a lot of uh core cryptographic things people kind of like Implement exactly the algorithm that's written in the paper but the paper doesn't add in certain verification steps and some of the state views gets reused and you know there's a lot of zero days so very much checking how you implement a paper directly uh especially in like ZK land I feel like is

uh even even in some of the e3k contracts like uh the the zero knowledge airdrop there were just some really bad basic mistakes that I feel like suggested someone like just read the paper or like wrote The Loop exactly and like wrote the branches exactly as the paper said which doesn't work in your current state machine um and then the third thing I think some of the auditor said this yesterday about like people who kind of do very ad hoc you know probabilistic simulations uh and then think that they're gonna make a algorithmic stable coin that lasts forever um I'm like first of all

you [ __ ] up 0.1 I made which is you didn't do the rounding correctly because you wrote in Python and like you're [ __ ] rounding in the evm are you like did you like even look at what you're doing did you look at the numbers matched but then of course there's the Litany of all the other basic errors you see in doesn't yeah leads people to think that they just found a way to print have a perpetual motion machine I'd like to remind you one point Allard is purely governance tokens uh you still see projects just launching governance tokens which make no sense uh decentralized governance in general is very mature and those tokens basically shouldn't really be valued at like billions of dollars for having right to own another billion

dollar of tokens to create a proposal that just doesn't make sense to me I see that you uh you you don't like the ve model not too much I'm gonna be careful because we're we're starting to expand we can find so many things wrong with what people are doing if we start going past security but that's time so thank you everybody for your contributions we learned things we should do and things not to do 20-minute break back at 2 25 with Richard from one confirmation thank you