Security Panel

[Music] [Applause] [Music] with that we are ready for our next panel which is something i'm super excited about we're going to be just talking about smart contract security um and for this panel we have same suzy sun nikesh rajiv and morellian um on on stage and um ryan will be facilitating uh this discussion so i'll let him ask all the panelists to use themselves instead of me doing the whole thing and making more fun so i'll hand this off to him and welcome everybody on stage hi everyone uh yeah thanks kartik uh i'm morellian and uh let's do some intros so nikesh why don't you start us off and then uh then sam and rajiv perfect yeah thanks it's great to be here um yeah so my background is in uh i actually do physics and computer science at some point uh before in the before the times was joining the blockchain space i was watering around in a bit of cryptography a little bit of reverse engineering just general i.t security type things uh but for the last two and a half years i've been working at opensupplement as a security researcher so basically we do audits and research and trying to improve the security of the space protect the open economy as you say i guess that's my broader broad outline thank you sam cool hey guys uh i'm sam i'm a research partner at paradigm and uh i do security so you know finding bugs mostly just finding bugs that's about it that's basically all i do uh hey everyone i'm rajiv i'm the founder of securium which is a recent initiative to further improve the state of security of ethereum applications and securium is currently running a bootcamp on smart contract security auditing that's funded by an ethereum foundation grant and sponsor partnerships from consensus diligence uh sigma prime and trailer pits so here i am thanks great okay so uh and and by way of introduction um i was one of the uh original members of consensus diligence and am now uh working at optimism uh focusing on protocol development and security issues and so i'm really excited to be uh doing this panel i think that so so given that youth global uh that that this conference is really focused on tooling which i think is really exciting topic and this group is is really security focused i think it'd be great to kind of we'll move this this conversation along kind of like uh you know balanced on the nice edge between tooling and security of which there's a good amount of overlap um so having done that i think like a good place to start would be just you know we can each provide a little bit of context about you know our the way we approach tooling where it fits in our day-to-day roles uh what we're looking for when we're when we're uh choosing what tools to include in our tool boxes if you will um and and if anything maybe tools that that you might have built in the past as well nikesh fair enough um yeah so actually as mentioned just before we started this that um my day-to-day work is um i'm pretty it's pretty sparse with tools so a lot of what i'm doing is just reading code and then trying to understand it deeply i think we have a bit of a bias that way that um i think a lot of the value we provide is just a security engineer taking the time to deeply understand code and then trying to match um match the knowledge to the to the particular task at hand but i do i was saying i do think a lot of the tools that i find useful are just things that that avoid distractions so um so like i have really good note-taking tools for instance to help me keep track of what i'm doing as i'm as i'm reviewing we can talk a bit some of those if you're interested or the fact that i have like um in the past if i needed to understand like a line of solidity i would like launch remix and then try and write it in there which was a huge waste of time but now i've got like the solidity rebel which just connects to like a local ganache cli in in itself like the whole point of that tool is just so that i can stop thinking about it so i can i have a thought in my head like what does this line of solidity do i quickly go and do that and then get back to what i was attempting to do before which was just understanding the system but i think a lot of it really depends on what you're attempting to do maybe just being a security auditor um there's a particular style in that that we follow which is just trying to understand contracts deeply but um but of course they're different approaches to security all over the space and i'm imagining there'll be several tools that will be useful in other places um i might leave it there for now um yeah i mean i can jump in here uh i think i mostly agree like when i when i'm doing audits for reviews i tend to actually stay away from a lot of the automated scanners i find that uh you know i'm gonna i'm gonna end up going through and reviewing the contracts anyways and so for me at least there isn't really much benefit that those scanners bring however that being said i do find value in tools elsewhere like um for example when i'm reviewing some contract on mainnet sometimes i need to figure out uh what you know what's in a particular storage slot or what happens if some function is called uh in the past i would you know pull up devtools and you know web30.edu you know get storage at uh and it worked it was very ugly but it worked uh nowadays i actually just used seth for that from the daptools package so uh here we go we're we're three minutes in and already someone to show devtools uh we'll see how let's see where else this goes yeah this is funny like i i i kind of got off twitter for a lot of the summer and then i came back and i was like talking about dap tools which has been around forever where did that come from what is it like what what flipped there that everybody wants to talk about daptools all of a sudden i actually think it might just be uh trends like you learn about a bunch of these things because they're happening on twitter and then everybody else learns about them because they're happening onto it and i think a lot of the security community is relatively small and uh a lot of the value is just like knowing what other people in the community are doing you hear that like i get to read a blog that samsung's written and then i learn something new because of that fact and i think it's just like access to the community you'll end up doing whatever else they're doing that's that's my instinct but i don't know i can't speak for why other people do what they do i mean it's really cool like martin and the team at devtools have been working so hard for so long it's it's nice to see them getting some traction like that but but please go ahead and achieve no i um i mean i i might be the odd man out i haven't used that tool so yeah please excuse me for that uh i might actually try to do that over the weekend but uh but yeah i mean from a tooling perspective i think the points made are valid the way i see it i do see tooling in the space of ethereum security as maybe focused on developers and maybe you know a separate set of tools that are focused on auditors and today i think there is a good overlap so a lot of the auditors like sam was saying you just are in the space you're looking at contracts and predominantly there's a lot of manual analysis so the roi that you would get from any of the automated tools is maybe not that much on a day-to-day basis maybe there are some special use cases for that but for developers i think there is there is a lot a lot of value right be it any of the static analysis tools uh like slither or the mythics or any of those there's a lot of value to that so i do see that sort of uh dichotomy maybe that that gets blurred sometimes but as for me um you know when i review contracts i do fall back on magnet analysis um so the tool that i use there is is is usually the serenity visual developer plug-in which really helps me navigate the code uh very cool or that stuff um for via ide via vsphere yeah by my old friends at diligence yep attended web so that's that's fantastic and i do tend to use slither now and then to just get you know get me some good starting points to just get some sanity checks growing and in the past i've actually uh contributed uh several detectors to the development of slither so that's that's my general perception on tooling specs yeah so my the way that like the pattern i'm i'm i'm sensing here i think is is um you know as auditors the it's very different from developers like as a developer you just like you live in one code base and you are there all the time and you started you know you joined this company your like project and you had they gave you a couple weeks to ramp up you know like the amount of time that is kind of like the training period for someone at a new company is kind of like how long you have for an audit i think so what you what what security researchers are doing is just like really trying to understand the code as quickly as possible and so i think that there's um seems like a uh the pattern is that you're sort of like a bit more less of like a just point and shoot scanner approach and more of a marriage of say human and automation to to get deeper understanding and i think that's where you see the visualization tools the graphing uh those kinds of things becoming very very popular for auditors um but so i mean you guys also see a lot of different code bases i i imagine um do you do you see patterns uh of tools uh and so you have opinions about teams and code bases and which ones are good and and which ones you love less and we don't have to talk about names but do you see patterns of tools that that the teams you think you know are on the right track are using in their their development process so i i guess my advice is whenever i see teams using um so like the team that i have in mind at the moment that they do all of their pull requests out in the open and then they answer their questions and they have security questions quite often i'll be reviewing code and then i'll go look at the pull requests that they made or some of the commits and i get to see all their comments and their thought process behind it all of that stuff is really useful um i don't know like it seems to be correlated with a lot of the continuous integration tools that they use like so as because i'm not a developer i can't say exactly how related these things are but i think there's probably some level of professionalism when you've reached the point where you where you take uh just development seriously and then you make sure that there are two people reviewing every uh like all your there's always someone who reviews all your code and then you're going through the process correctly that does seem to be at least correlated in my mind with people who take security seriously as well and just maybe riffing a little bit on what rajiv was saying i think a lot of our clients will actually use some of these tools before they reach an audit and it's like a good way to to find your own like bugs first in your own code um before you actually take the time and effort to go and get it audited so i guess that's my initial instinct i i'm not recommending a particular tool other than just noting the level of professionalism does seem to correlate somewhat with the level of security analysis maybe so so say you might say so github or git and and the code collaboration tools that in general that just enable people to ask each other hard questions about what they're trying to merge right so i guess like everybody is using github but then some of them are just like pushing to master directly and some people are making pull requests with reviews and that's that's the sort of way that i that's a that's that's like like reviewing pull requests is is a like a high bar or like an indicator or something i i mean maybe it i think it depends on the detail i'm thinking i'm speaking like sorry my point is that it's crazy that anybody's not doing that i think it's just what i'm getting at but okay yeah i think my my instinct is really more about like how much effort they put into reviewing pull requests there's obviously different um different degrees of how seriously you take that sort of thing certainly yeah okay um so so i think like maybe even if if uh it's not the focus for anyone here i'm i'm curious what if any uh impressions you have about the potential there is among the the the more advanced tooling um so static analysis i think like i think like running slither is a really good just like you know it points out a lot of stuff a lot of code smells um that's a static analysis tool then i think you know fuzzing there's a variety of good fuzzers out there that are maybe the next step to look at or else symbolic execution tools um do you have a sense do you have a feeling about like where we are at with those uh have you seen sort of like output from them and and found that useful or is it just usually just a list of findings that don't really give you joy um i mean i can jump in event but i'm sure i feel like might be monopolizing this a little bit so i'm anxious about that certainly feel free to interrupt me well i mean i'll just i'll just like sam and sam and well you told us in chat but sam just like tell us what you said about everything not in contracts i mean i guess maybe i'm not connecting the dots here i in chat i just said i'll pass on the question because i when i'm when i'm reviewing code i basically or a project i basically ignore everything that's not in contracts and i guess to even be more specific i ignore everything that's uh that's uh inside test as well because i personally i don't you know unless the code is like so confusing as to i'm not sure what the correct behavior is um there's really no point in me checking the test i think it's just a waste of time uh but actually on the topic of uh fuzzing i once again will start at georgia's georges has been like one of the major drivers behind the daptos shilling i think and now it's rubbed off on me so i would now i will now show dab tools again because you did this presentation internally at paradigm uh where you showed up the fuzzing and property testing that you can do with depth and it's actually kind of like you know you you obviously you have like a kid in a in metacore and i think myth x does fuzzing too right am i misremembering yeah yeah and you have and you can you can do you know fuzzy and property testing with them you want you can go uh more advanced i'm sure but it's always felt sort of inaccessible i feel like um it's it's always seemed like this this hurdle to overcome to figure out how to use these tools um and the interesting thing with daptools is they've taken a very similar approach to uh how go does it which is you basically have you just you just write a function in solidity like you know maybe right beside it right beside your actual code itself and you just put in as parameters to the function uh the things you want the fuzzer to explore and that's all you need to do and the rest is just handle for you just run the command so i think that's actually really awesome and hopefully as more and more people find out about this through the non-stop shilling that happens everywhere uh you know maybe we'll see more and more using uh usage of fuzzing and property testing so so to clarify what i i think i understand is like it looks a lot like a typical test suite but instead of saying um transfer one token to sam i'd say transfer x tokens to somebody and that's that's all i do i leave that open and the fuzzer takes it from there yeah pretty much you could have like you know if you had a function that uh you know did some complex math to figure out the returns for some exchange right uh you know you could treat it as a black box it's it it takes some um 256's input and returns some un-256 as output and you can just tell the fuzzer you know i want you to just like i just care about this um 256 input and then assert on the next line like the output is same right and the fuzzer takes care of the rest it's just that magical yeah so so for anyone not really aware of what what fuzz testing is it's i mean it's basically that it's it's uh instead of writing one test at a time it's uh tools that generate ideally millions of of test cases um and sometimes can be quite sophisticated about like like speaking from from diligence what for some reason the fuzzer there is called harvey and like that's not really like a product name it's just the internal name but harvey um it's it's quite like it's like it tracks where it's been in the byte code uh and when it like bounces off a require statement or an if branch multiple times it it does um like solving to try and say okay like i almost got this this if else branch to flip so that i could i could get into that um and it tries to figure out the the math so that actually can trigger that which this is not an easy problem um and i think that that is i actually was just looking it was about a month ago that they i think they've really shifted the focus from myth x over to just like like fuzzing and and doing um more fuzzing as a service and there's also like i'm really interested in what we were working on there which is this tool called scribble which allows you to write uh basically nat spec format formatted comments which will then you recompile the solidity and it adds all these assert statements that um allow you to describe specifically the the failure cases um still it was still coming along as far as sort of like usability but i think i'm due to check it out again go ahead yeah i think two critical points that that were made right one of them is as maybe security researchers who are deeply into the space we focus a lot on the effectiveness of tools you know understandably so how accurate it is false positives all that make a big difference we also focus a lot on the efficiency of tools and the second part actually leads to the usability aspect of the tool itself that i believe oftentimes is not you know because if if you're deep in the weeds then you know if we are developing and if it's all open source then you're using it so we really don't appreciate how uh you know deep we are and if that same tool is actually expected to be used by the developers of protocols and like you said you know we have like a week or two to actually look at this tool then that barrier i think becomes a huge deal right in terms of well i you know let's take slither for example right take it uh install it and you run it and it should just work right in the box right but for some of these other deeper tools like you said right being fuzzing great symbolic checkers there's just so much heavy lifting that needs to be done uh even before you can start using it right i mean you need to understand how that tool works the intricacies the documentation of the tool itself and then we need to write the rules fuzzing or uh let's say property-based testing right so there's just so much work that is involved there uh which i think you know hopefully over time will get will get much simpler so that the product or protocol teams themselves can actually start using these tools to uh to a good extent so i think that i think is something that maybe as a community we don't pay enough attention to i agree my cash no i was gonna say so i haven't actually used uh fuzzing since i've joined this space but like i used to do some fuzzing stuff back in like a vpn traffic and you just throw it a bunch of packets and see what breaks at least at the time a lot of what we were looking for was crashes basically looking for places where the whole thing crashes and then seeing if you could instrument the system later and find find where it broke i was a little surprised to to hear that logic applied to the smart contract space just partly because you're not trying to like crash the evm in any sense you're you're really um you you'll maybe it's more it's a closer to like smt or like property based testing rather than what we call fuzzing maybe i'm misunderstanding the term um or i've got some bias that's forcing me to think in a particular way certainly your idea at the end of like being able to have nat spec a particular property friends i i've mentioned this example uh in the past sometimes i'm looking at code and then i know that this value is meant to be a um a percentage so it has to be less than one for instance but it's not immediately obvious just looking at the code that it always is to the extent that it's possible to like not spec that and say this is supposed to be less than one please make sure that that's true throughout the whole code base um i think all that that would be useful but personally i haven't actually seen that that happened it sounds like you're telling me uh i just have to wait a couple of weeks and then maybe maybe that'll be out well i mean in fairness i think that that's how all of the fuzz swing related tools that we've talked about work is you basically have to reason like you got to know your system and you got to know what's wrong and if something is announced that only goes up then like the fuzzer can tell you if it goes down but you have to write somewhere uh that it should only go up and it should never go down so like there's various places you can write that um but yeah it's not it's not just like a general crash kind of situation it's you you have to be able to define your failure modes can i clarify is it doing this probabilistically or is it actually exhaustively checking the possible inputs i mean obviously exhaustively is a weird term when you're like enumerate through the whole space but you could do it symbolically as well to check yeah uh it's i mean like i know that uh like the myth x suite they would measure like how much of the code they'd visited it still doesn't mean like you could hit 100 of the code and not not necessarily have all meet like all the edge cases or explore all the the kind of like execution modes um but that is the objective is to traverse the entire system i will mention that daptos does do symbolic execution as well but also it's a good point it's a good point that you know it right now like all these tools do require you to define it like the the weak part about unit tests is that you can only unit test what you can think of right and so often you know in hindsight you'll look at something and go damn like that would have been a really nice unit test but like the hard part wasn't writing the test it was thinking of the test in the first place and with you know fuzzing and symbolic execution or property testing it's you know you've alleviated some of the challenges with like you know maybe defining exactly how to test but you still do have to think of the thing to test for um and in fact that even you know we can take that one level higher with formal verification we see that uh as one example that comes to mind um uh the the miso bug that i found in the uh a couple months weeks months ago i don't know how time works anymore uh that was formally verified it was just that there was no case defined for uh both minting or sorry both uh buying into the auction and using the batch uh contract and so once you know once the team went and like added that case the form of verifier was like yeah there's a bug here but you know you got to think of that first and so it might be interesting i don't i don't even know if this would be possible or not but if there's some way to just like you know similar to how traditional fuzzers just look for crashes uh if there's weight is just look for ways to send ether out or ways to transfer tokens out that might be way too computationally expensive i'm not really sure maybe someone else here can comment on that no no like i think that that that's slither does that rajiv yeah yeah i mean uh to a certain extent right yeah whatever you can determine uh syntactically and semantically like love ether and so on but yeah please continue um oh okay yeah so i was gonna say like i'm pretty sure mythx did did that does that uh the thing is if you care enough about the security of your contracts like it's like it's usually kind of well no this is not true obviously the experience bears that out but i think it's hard to detect the weird things um and i think that the messages that you end up showing are like well there's like a kind of like you call out here to unknown we're not sure what you're gonna do um but like fuzz testing so as soon as you call out to an unknown contract what are you gonna do like generate all the possible contracts um or or symbolic execution as well like it that just doesn't really make any sense um but but i was hoping and so so formal verification i'm just like uh overrated or underrated let's just let's phrase it that way we'll go around and rajiv you've got to go first because that's right absolutely so yeah i think i think like with many things in uh well in the space and maybe in life right formal verification is probably overrated in the near term in the space and probably underrated in the longer term uh so there's just i mean i get the impression maybe it's sort of the uh meme of the season or whatever right but it's just like hey you know let's let's go to formal verification right i mean i i do i do believe that uh property-based testing such as scribble or serdo spruver or kvm or verrex from chain security all these do have uh you know will play a significant role maybe just you know where we are in the maturity cycle of the tools i mean there are so many things that are moving right solidity is changing every month ethereum itself is changing uh protocols uh everything so in that scheme of things i think uh just just sort of moderating our expectations from these tools especially formal verification that it's not a magic wand and like sam said um well you know great we do use a formal very uh verifier but how do we know that you know the formal verification tool itself i mean you know somebody built it how do we know that that doesn't have bugs how do we know the properties that were written uh you know do not have omissions right so those things and this sort of goes back uh i mean none of this actually is new in the web 3 space if you look back all the way to [Music] who was it ken thompson's turing award lecture on reflections on trusting trust right so he talked about well all these layers that we seem to rely upon as something very canonical something you know perfect but that's not the case and that applies even to formal verification tools so no wonder right i mean if you have a checkbox saying well this protocol was formally verified it's not a magic wand but that is not a problem with the tool or the approach it's just a problem with our mismatched expectations if you will so what you're saying is you should write a gd spec you should write a what sorry this is a spec a spec i'm uh so that you can like identify those things i guess right i mean that that would be again a mismatched expectation at this point having looked at several code bases i would be happy you know for a typical project for uh something more than uh one screen readme file right something you know we can start with that we can go to better documentation i mean if we have a list of all the contracts and the interactions a spec would be fantastic absolutely yeah spec is a powerful tool um english language underrated uh nikesh uh overrated or underrated formal verification i think it's probably useful but as rajeev's pointing out there's probably a mismatch between what it can do and what people think it can do even the spec i don't think helps as much as you might um might expect at least my instinct from that is based on the fact that uh people have been talking about like formally verifying vpns forever and there is a spec like it's there's an hour i've seen it's existed for a long time and uh and it seems theoretically that you should be able to just implement that spec in uh in a formal verification tool and then but still open ssl has the market and it's like spaghetti code completely and partly that's just because they got there first and also like if you want to open a new you want to add this new uh protocol you want to use diffie-hellman instead or you do something slightly different then that's like spins out a whole six month eighth month project to specify that part of the test i think the like particularly in the blockchain space it's moving so quickly that by the time we have like a spec of erc20 people already doing flash loans and stuff so then you'll you'll lose the uh the ability to to at least keep up to date with what people are doing i suppose i i do think it probably would be useful to have uh formal like formally verify some repeatable components like if you get i mean i might just throw open second contracts in here like if you if you can formally verify something that's been used like in lots of different projects and is relatively well defined um i think that might be useful but uh but i at the moment i think it's just going to be lagging behind for a long time yeah so so i think i like sam anything to add i think rajiv's uh you know short-term long-term answer is just so he's like effortlessly wise that it's hard to add a whole lot but i mean anecdotally i will say that usually when i see that sartoria has formally verified a repo i'm like okay that's probably safe um like you know again but i think that speaks of equal volumes to both the technique itself and also their team's ability to actually reason out what your code is supposed to do for you because that is what they do is they sell you the service and they sell you well they tell you the technology and they tell you the service to use that technology so yeah so so one thing i think is interesting there is like um one of my favorite auditing techniques was like making diagrams and i think that's something like that's a form of spec like i i and and so a lot of tools do this too they in that they informal verification as well like in that they force you to reason through uh they just put you through an exercise in which you sit down and you're like what does it do what does it actually do and you know converting solidity to a picture or or words i think is an effective way of or like or properties and maybe properties is a higher value output because you can reuse them um but i think for a lot of tools that is my sense is that that is a lot of the value is that it forces you to interact with the system more deeply yeah i think i totally understand oh i was just going to do the same absolutely agree with uh you know with what was said uh i think to sort of go back to one of the first questions uh that was posed if there were two tools that i would love love to see right from again separating out the auditing from a developer perspective from a development perspective if there were two tools i think those would be at two ends of the spectrum uh one of them would be something like slither something that's very fast static analysis that catches all the code smells um that catches all the basic pitfalls shows you what the best practices are so that i think would give the best bang for the buck for the development team right away and the other one would be the other extreme which would be the property based test because that would force the dev team to think about you know well one do i have a spec right and you might call it spec documentation whatever but it forces you to think of well what is the requirement what is the expected behavior right and it makes you document that formally in the context of this tool right so those i think would be the two sort of uh uh top on my wish list so i have an instinct it's not very well formalized so i'm i'm kind of shooting from the hip here but i i think um marilyn's point was excellent about the fact that it forces you through this process in itself is useful even if the output of what the the tool says um might not be that readable um but i have a sense that we might be mixing layers because at least in my in my experience the the real value of a lot of these things is being able to transfer the knowledge in the developer's head into someone else's head so into an audit for instance or just into another developer so they have some threat model in mind and they know that they wrote the code in this particular way because they're trying to avoid some particular style of attack and then an auditor comes in and thinks well have you thought of this style of an attack and maybe they have maybe they haven't but then there's a huge ramping up period and then it's also quite unfortunate you get to the end of an audit and now you're an expert in the system and then that wanes until the next audit shows up so um like i think that a lot of processes are potentially in place to maybe shorten that time period uh so that um so that we're not doing it in batches so like obviously it'll be useful to try and maintain more of a continuous sort of relationship that way but um but i think we then make a mistake potentially when you then try and specify it in the code because at the high level i haven't said anything about this particular contracts or if statements or anything i'm thinking really just about have you thought about replay attacks have you thought about access control issues and that sort of thing and um i guess a lot of times your threat model goes out of date after a while like you you have you wrote your code is assuming some sort of threat model and then it turns out the ecosystem changes uh flash loans become a thing or for instance now you can do reentrancy because the gas limit has changed or something like that has gone wrong and you don't go back and revisit the code because because you thought the code was self-sufficient whereas um what we really need is just a way to transfer knowledge i think a lot of the value comes from just the existence of the security community that has seen all of these things before you can go through previous audit reports and stuff we have repositories of where these things exist so like you could say i'm building a tool like i'm building a voting tool let me look at all the places these are the checks that i need to worry about these are the things that are broken um i think a lot of that is useful well before you actually get to the code level um and to the extent that we can have tools that just like spread security knowledge around the space i think that's uh that's going to be uh at least it seems like an underserved market that's my my own instinct but it isn't particularly formally uh sorry formalized yet so we're kind of just shooting a little from here fair enough i think like a good example of that like the threat model changing i think is maybe like developing a dex uh oh this will use a bunch of erc20 tokens and then somebody's like oh but i have a token that will do callbacks to whoever you want when you transfer it um and you just don't think about that right you're like it's just an erc20 token it does nothing fancy um so uh maybe just to to keep moving along and [Music] i don't know this this is probably a little bit of everybody's wheelhouse but like do you have thoughts about like what you should be doing when the code is running on chain like it's out there uh is there is there a magical way to detect and prevent uh attacks in real time um and i think nikesh this is like kind of softballing for you so go ahead i think this i sort of have to mention at this point so uh we suddenly open zeppelin we have this tool defender it's got our order tasks you can suddenly write up your uh your your security properties or things that you want to check you can say like if this balance changes or some property or holds on the blockchain uh then please run this task or at least give me an alert we're also developing a new uh a new tool called forde which is um like a web3 native cybersecurity thing which is it's quite it's basically like an alert monitoring system there'll be details to come soon um but uh the the important thing the thing that's particularly interesting about this is it's it's web3 native so uh so it's not like an external tool that you're running and then you try and pipe it into the blockchain it's actually running directly on the chain so you'll be able to hook it into all of your apps it's like develop sorry it's decentralized and and directly integratable in the same way and composable in the same way the rest of uh the blockchain so that's my uh my pitch does it is it gonna save you or is it just gonna make sure that you know right away that your system is totally owned uh true that that's a good point so it is it is um it's like agent detection so you're it's detecting things that have changed it's not um necessarily preventing it but it did suddenly we do have things like order tasks that say like if this happens then run this command so you could like pause the contract at the moment that something changes so you can you can take sort of automated actions that way if you get like i mean if the if the attacker doesn't bother to use flashbots i guess right like and right yeah so of course yeah it it's too that it it'll shorten the time period it takes to react maybe that's a good way um are there other things out there or sam or rajiv do you have a thought about not even tooling but just like running these systems safely that was an okay answer too just okay no um i mean i've seen quite a few attempts to building these sort of things now where you know you try to alert on transactions in the mempo of course as nikesh said now that flashbots is more and more thing that that becomes kind of hard the the only time i've really seen i don't know what i don't really know where i was going with this i was the the point i was trying to get to is like i tried building one of these at one point um and it was meant to like alert on past pastors actions so like things that were already mined and just just to see like if anything interesting was going on tried to like automatically detect if a transaction was like a novelist uh it was like somewhat okay it was very noisy though so i sort of just gave up on it but that would be i don't know if anyone's built that or made a public version of that but that would be cool to see just a like a live automated threading top feed almost yeah i have uh i don't have much to add in this space but maybe i have a more questions in this space right so if you and i have discussed this with some of you in the past is if you look at the web 2 world right you have a long list of security products in the last 30 40 years you know all the way from avs firewalls intuition detection systems and all the you know different names of that intuition prevention systems all these things right so there's no reason you know except uh taking into account some some of the big changes in the web 3 space uh maybe culturally as well as technologically that these systems could not theoretically be implementable in the venturi space right so if you're able to see a transaction in space as it is flowing through the mempools or whatever layers you're in theoretically one should be able to uh simulate that you know for you know your main net with whatever tooling be able to simulate this transaction and be able uh well you obviously need better and faster resources than the other attackers themselves but you should be able to do that and then you know put in a transaction that actually takes over or goes ahead of the taxes transaction and somehow fixes the code or makes the taxes transaction invalid right so theoretically i think it should be possible i don't know i mean uh maybe encase and others uh have more practical experience in this place with defender and other tools but that that was i mean that was just a thought and i hopefully you will see some research or maybe even products or techniques in respects just make sure i understand uh that claim so the the idea is you see something in the mempool and then you're you're essentially trying to replace that transaction so obviously front running as a concept is existing and people are doing it for unlike non-security related reasons like just for arbitrage generally and there's that's been developed uh quite extensively to the point where your people are like running gas sections and things uh whenever something new happens and of course flashbacks now is alleviating some of that um i understand you're perhaps approaching it from the security angle but maybe i haven't seen why it's a different concept it still seems similar to seeing something that you don't want to happen or something that you want to prevent first and then getting your transaction first unless the contract itself is designed in such a way that it has a delay um sorry i'm just i'm thinking out loud at this point and i might be uh misleading him no yeah why don't you jump in here i think you've been quiet for a little bit um i mean put me on the spot i guess i don't know i think i guess i didn't really have much dad uh um you you you were unmuted i took that as a signal oh yeah sorry yeah that's red too much okay um i mean all right well i yeah i i kind of think you're right nikesh like in the uh you know if you can well basically i guess you're gonna get into this is like outside the our our our all right wheelhouse but like you're gonna get into reorgs right like because you got you got flashbots you got private transactions i'm a brilliant black hat hacker i know how to you know um i've got i found an exploit i submit it through flashbots nobody can see that um and that's it's gonna execute i'm gonna own your contract the only way to to get back to like to to restore that is to reorg the chain and like outbid and i kind of lost track of that conversation that was happening over the summer but um that that's that's where that goes to me is as far as i can tell it still sounds like it might be in the same bucket in the sense that i said and now i'm definitely speaking outside i don't know anything about how how useful it is to re-or how plausible it is to do that hopefully people are thinking about that to make make that difficult but um but i would still guess that if that tool is available if that technique is available it'll be used first to to win um like trade union swap trades or something to arbitrage some as long as there's like direct money on the line that'll be the the use use case originally um and people will be doing arbitrage with that tool before like the security level catches up that's my my instinct so yeah i guess we got i guess we've got like a minute and a half left so sorry well a question i kind of like i just remembered i really wanted to ask is like what tools needs to exist or like be way better than it currently is that you would like to see in your life so let's like 15 seconds what does it do nikesh you're already go ahead um i have this this grand plan of like making a threat modeling tool that i think uh that works it's same same kind of saying working at the higher level of understanding threats rather than understanding code that's my 15 second pitch cool rajiv so i have a slightly different wish right i think all tools have their place but my wish is they get used sooner than waiting for the auditors to run them so i'm thinking and i'm getting really big on the shift left that has been such a big thing in the web 2 space i think web 3 space needs a lot of that i have like a really big insane idea and like a smaller duo by idea the big one is like i want like this integrated all-in-one platform where i can like view contracts decompile them analyze transactions inspect storage slots uh look up four byte hashes like the works right like everything i need to do ever is like a tab away like convert from hex task or whatever right all that stuff that is like a lot of work oh so i suck at ui design so i'm not doing it myself uh the more doable one is like some tool in my id that lets me annotate specific variables or blocks or whatever with things that i don't have to remember like this variable is always going to be even or this variable is always going to be less than 100 or something like that and then that way when i click through three functions and i look at the variable again you know i don't even remember that i just hover over and it's like hey by the way you said this is going to be less than 100. so you know just for reference yeah okay that's great um i think we're at time yeah um that was an awesome discussion we'll we'll do two uh quick things um and anybody can pick them up to do everybody but the first kind of question is uh for people who are trying to enter the space as auditors uh do you have any tips or advice for them and what you kind of recommend they do if they want to be on the auditing side join the security bootcamp sorry no that's that's you you should chill first yeah yeah maybe maybe just to give more context to people what is the boot camp and uh how can they find out more yeah i mentioned this in the beginning but uh securing bootcamp is a three-month bootcamp that has just started in october it's funded by an ef grant and the sponsor partners that's not the top auditing firms in this space the idea is to be extremely open to people from different contexts so there's a two-month learn phase where people are gonna learn about ethereum 101 solidity 101 201 all the techniques audit findings all the rich content that we already have curated in this space and the final month is going to be where the rubber really hits the road they're going to be taking a look at some real world projects where they actually evaluate them for audit readiness and uh hopefully you know have a good chance of becoming auditors awesome uh man i'll kind of blend this on the other side of that i feel like i i might want to answer that question just because uh first of all i certainly agree with rajiv that the securing bootcamp seems excellent but of course uh i feel like i have to point out if you're gonna ask me that question uh open zeppelin has a bunch of uh um videos that we put out like tincho one of our security researchers puts these things out we have like the ethernaught and uh all sorts of these sorts of techniques are useful and we're always hiring so if if you actually resonate with that question then come hit us up all right one quick one um and others can kind of mix and match the last one too i just for people who are trying to now reply apps to production or contracts to producers i mean that um any tips for how do they how should they think about auditing or insurance or anything else around that and what are some things to keep in mind for newcomers very open-ended anything qualifies i think maybe the same instinct like try and get plugged into the security ecosystem you'll like there's lots of people who will guide you through the process but uh it's hard to answer that in one second but try and get plugged into the ecosystem is my my main suggestion look your audits early the lead times are long perfect well we'll end that there thank you so much samurai vacation orient uh that's an awesome discussion and uh for any other questions we'll relay them to you over email so well with that we are ready for our next talk so [Music] [Applause]