DeFi Security Summit 2023: Day 1, 15 July

Transcript

[Music] [Music] foreign [Music]

foreign [Music] [Music] [Music] thank you

[Music] [Music]

thank you [Music] thank you [Music]

hello everyone I should start in about 15 minutes so thank you [Music] thank you [Music]

[Music] thank you foreign [Music] [Music]

[Music] [Music] [Music] foreign [Music] [Music]

[Music] [Music] foreign [Music] [Music] home

[Music] better [Music] foreign [Music]

foreign [Music] [Music] [Music]

foreign [Music] [Music] [Music] foreign

[Music] [Music] [Music] [Music] thank you

[Music] foreign [Music] [Music]

[Music] foreign [Music] [Music]

[Music] foreign [Music] [Music]

thank you [Music] [Music] foreign thank you [Music]

[Music] it would be fun thank you

morning good morning good morning everybody good morning how are you doing uh it's a scary moment for me uh actually we John Mitchell who is who couldn't come here with me we started this event uh actually we thought about this event about three years ago the covet came uh initially John asked me because I come from a field of uh could be a science called formal method which is that not a lot of people in this thing so he told me how many people we expect I say about 50.

so last year we arranged this in Stanford I think we basically we basically couldn't accept all the people that wanted I think there were 400 people there and I think there were four thousand attending remotely today I think we have 800 registered thank you all and I don't know how many of you are attending remotely uh so I'm gonna do a little introduction but of course you're going to hear everything during the during the presentation uh also maybe I want to acknowledge bio and Gibson he's not here but together

with John and me we establish a non a profit Foundation because the idea is that we want to actually use this community to secure the fight and this is a non-profit which is actually running this event so uh the this event is being made it's a we are charging a little money but it's actually the car we are covering it with with sponsorship we're always looking for more sponsorship I think we had both last year and this year uh generous sponsorship from different uh companies and we'd like to acknowledge so 12 of bits this is a for those of you I'm sure many people know this is a

leading security company in this in this field they have actually contributed for last year they contributed for this year they also help us in organizing 101. how many of you were in 101 yesterday seems quite a few that's great I think 101 is a very nice event because it's eventful maybe basically people entering the space we are looking for more things we're also going to do it next year the idea is we want to actually bring more people into the space and do Workshop that was catch the flag so uh 12 bit they play a key role in 101 and they also actually help us during this event there's electrical Capital this is a U.S based VC film which is specialized in

developers tools they are also here they also help us last year too we have Sigma Prime this is a leading security film uh basically securing smart contracts specifically also about consensus about generating unit tests I think they're also here and also play a key role in 101 Lido we're going to hear from them everybody know this is a leading is taking protocol in the ethereum they're also contribute to the security of this and polygon is a layer two this also a leading company in Layer Two and of

course which is the company that we are running we also have the second level of sponsorship so we have immunified immunify is a uh everybody knows it's a back Bounty program they were actually uh they were they were also uh they were also sponsoring last year we have jump Capital it's a VC film remix skip which is a Visa film which is also contributed this year and last year let me escape for those of you who don't know they also did the Stanford blockchain which is actually started this event we have sequel which is new so second one is actually helping us Rajiv

actually basically from the beginning basically sort of deciding what topic to include deciding on the program and this year they're also sponsoring and we we can see many volunteers from from the circle well and we have open Zeppelin open Zeppelin is a leading security film they also was there last year they are contributing libraries and they're also quality Beauty Audits and they also have this product called photo and there's other sponsors who are coming and we are always looking for more so this will we have called Arena and we will hear about them basically a bounty program for for community-based called review we have ddub with a leading security firm we have ethereum

Foundation of course that needs no introduction and also ethereum France everard mofo nethermite uh shield and spear bit so these are in spear bit is also a leading security firm uh that actually is here we also have a lot of uh support from the uh uh people who are helping us in shaping the program and the way we do it we're basically assembled a small steering committee which is actually now growing and the steering committee here I have the name so I'm not going to say

but these are people who are helping us in in basically deciding what topics to include deciding about venue and many many other things uh you see the steering committee is going which is okay uh we have the core team so these are people who actually help us it's part of them on the on the staying committee but these are the people who really help us reviewing the article this wheel we have 170 articles submitted and we made a big effort to try to accept as many papers as fast as possible and we try to see which papers are original so we have here Rajiv we have mudit we have UV Kirsten it was actually helped

us last year actually also assembled the program we have Nathan uh from the Italian France we have Kathy Spencer we have David Stanwyck you're a chairman and Jessica silver Brown from from sotoa and we have the Fantastic volunteers maybe they can stand they are here they are a bit anonymous some of them I mean these people actually help us all the way actually even from last year running the catch the flag so these people help us all the way I think it's great it's grateful this is something

which is very nice about this community that people help each other they come and help us and please if you have questions help them and ask them sorry or help them too but ask them uh we have the speakers I'm not going to be able to to say all of them but I think we we have really really nice list of speakers from Academia from industry from and actually experts newcomers people who spoke last year but people are also we try to have as many as possible new people uh they are more and more actually uh this is fantastic list and you will hear about them and we love for you to accomplish just make sure that you give

your talk and finish on time we have session share but these are this is a very these are very very good list of people who can educate us about this space uh there are more here uh this is it uh maybe this is obvious but I want to say why are we here so we're here to enjoy Paris but the we are here to actually make this space more secure okay and what we want to do we want to develop techniques and we want to actually build metals that make this space more secure we call the non-profit D5 first the idea is we start with D5 but we want to make

code not secure and we want to develop techniques that normal developers in solidity or in other blockchain they can use to secure their code and I think we are taking some method from web 2 but we're also innovating in web3 and we are developing some things which are not do not exist in web 2 and you can hear during the talk in this these two days you also can see if you some of you attended 101 and one thing which was very very good about D5 security Summit elastic that some of the talks that were there this was the first time the talk was presented so for example last year change security they presented The View we enters in the for

the first time in defy security Summit and this is great this is what we want to do we want to have people who tell us something new and this is what if people say that what they want to do to have here we want to find more new things here and we wanted people here to innovate so this is what we are trying to do and you can ask a reasonable question how good are we doing okay so we started this last year how many bugs have we prevented so honestly I do not know it seems like despite defy security Summit bugs still happen okay even we we tried very very hard but I think and we should try but back still

happened I don't know if I listed all of them I thanks to you are here but these are some of the more known one and there are more but these bugs happen despite device security submit the first device security Summit and I imagine that after the second device security still be some box okay but we are trying to prevent them this is our hope with all the things that we are doing and of course we are trying to do the best job that we can what are we going to do different next year because everybody is asking us so I think uh one thing that we did last year we did in Stanford this way we did it in we are doing it in Paris next year

we are not sure yet we have many venues who are proposing we want to rotate I think it's a great idea and I really apologize for those of you who are attending remotely couldn't get Visa the same problem happened in the US it's happening here we are doing our utmost but I don't know if there is a place that we can choose where Visa will not be an issue but we are trying to make this space as accessible as possible uh and as affordable as possible and we'll see next year where we hold this event another thing that I think people are complaining in their right that the schedule is too packed and we are trying to improve we will improve next next year we also apologize for these people for the people for the speakers that

didn't get enough time to to speak it's very very difficult because we are trying to get more more and more people to speak uh and and what we will do next year we'll have to find a much larger venue and we're going to have a basically a parallel session so the idea is that we'll be two sessions so we can accept more talks and this is what we're going to do we we will look for a place which is Affordable and allow us to do a parallel session also the review is getting very very complicated for us so we are doing things which academic usually do some kind of a two-phase review the idea is that we are getting the the work we are trying to we're getting the submissions

we are trying to see if they are if the if the topic is interesting and then we invest more time in reviewing the originality of the talk and all of this so we are we are doing things which are not new in the beginning we sort of did it in a ad hoc way now we are getting more organized next year we'll be more organized another thing that people ask us all the time why is once a year so to be honest this is so much work so we couldn't do it every month but we decided to do something more modest every month which is actually in addition to that so every month we're going to have a virtual conference that we basically confer it will be just three hours and it will be virtual and

will cover a single topic say monitoring say and we actually have many topics and the community is suggesting money topics so it would be a single topic with with people who are expert in this topic and some discussion after that and this will be starting soon we are working on it and we love to get more feedback on it uh I think I'm just in time or even two minutes ahead of time and I think everybody should do so have fun if you have questions which I can answer or maybe please ask me there's no question so thank you very much enjoy [Applause]

[Music] hi everyone I'm Merlin co-founder of Marvel I hope you enjoyed the the fireworks yesterday night but here we are not going to blow up everything we are here to make the the space super safe and we will start with a gene as the first Speaker Gene is from Lido you can come and um it will it will speak about the the V2 upgrade and from a security perspective so the V2 upgrade

happened like one month ago something like that in the middle of May we two months sorry and again I guess we'll have a retrospective on that event no oh we need extra minute to set up sorry maybe for the next ones I will try to uh the person will be able to uh go here

in advance just to set everything up okay okay is there a Anton here yeah can you go there please just so that we can like uh have sort of relay

awesome thank you just sit there or cool let's go okay here we go uh hello good morning uh maybe I'm going to use this microphone uh good morning everyone um so uh my name is Eugene I'm from lied on ethereum protocol and today I'm going to talk about uh V2 upgrade and from security perspective and I'm mostly doing Engineering Management so like one controversial

take in the beginning of my presentation I wouldn't talk too much about code security about like how to write secure code how to avoid putting vulnerabilities in your code and something like that um it's actually because of two reasons for us because today I think that it would be a lot of very good security talk about code um and the second one that I want to share my personal Lessons Learned From V2 upgrade and my role is mostly about Engineering Management code review organizing process and I would try to talk about things that beyond the course

security and um if you're just asking me for example give me just one resource or article or whatever to to help to get better in a cost security I would share with you only one uh I guess that a lot of you of you know this website it's actually the digest of biggest defy hacks and we need to work hard to not get featured there and uh so here is agenda for my talk I'm starting with a small introduction into

lighter V2 after that I would share some cases or stories around security but not code security I picked these stories because I think that it's I want to share some maybe unique parts of our processes because really uh one like our goal was to um to match which upgrade as secure as possible but it's it was like a lot of things that might go wrong and our goal was to mitigate This and like all these cases so it's really based on how like experience here and challenges that we made during this virtual upgrade and

in the end of my talk I would share you uh my way of thinking about protocol security uh as a layered cake so yeah I'll show you uh so let's start with the stats um so uh Lida is a largest liquid sticking protocol in space and as you can see from the stats it's a biggest possibility for the team uh like the second row it's about code size so even from this from these numbers you can understand that it's a lot of complexity in development and like all upgrades took seven months of

development we have in like in lighter Dev team something like 25 contributors so um and uh here is how upgrades online look like um two things to note for example uh things like spec smart contract development test net and security audits normally should go sequentially right and on this timeline it's really uh more like parallel that's happened because our goal was to try to deploy this upgrade uh close uh after Chapala card

Fork because enables enabled withdrawals and our goal as a liquid taking protocol was to follow this upgrade to enable withdrawals as soon as we can for our users so our goal was try to follow uh ethereum network card for timeline and the second one it's you can see upgrade preparation stage the tooks a little bit more than one month so like from the beginning of April to middle of May when which was upgraded I will talk about this like later in my talk [Music]

um from future perspective V2 had free uh like epic features um and this require us to completely rewrite a protocol from ve1 um the first one with drawers is the most important feature because uh yeah it's actually if you if you stick in a like liquid stacking protocol you you expect that you can unstake and withdrawals and before Chapala had Fork it wasn't possible but uh once hard Fork was enabled and we just implement this in code and the stake enclosure and scale it oracles it's a feature related to scaling and

decentralizing validation set which is very important direction for us because we're striving to because right now we have only created set and we're striving to decentralize it um yeah here is like uh to have like perspective of what the difference between V1 and V2 to understand like complexity of this upgrades let's deep into V1 context so it's a pretty straightforward actually like it's a free smart contracts Lido staff Oracle another operators registry and it's written using um Aragon framework on top of Oregon framework uh and Aragon framework was written on solidity 0.4

and this requires us also to use solidity 0.4 uh which is not great uh uh so and here is a V2 contract landscape uh it's uh like three times bigger in code size in a smart contract amount yeah all blue contract there is a newly introduced to newly um like created uh contract and um all new contract is written on a modern solidity uh 0.8 and um basically every every single contract

that you see on this slide has been upgraded except one so it's like big scope and okay how to upgrade Lido yeah uh we didn't have an option to deploy V2 uh as a separate protocol instance and for example migrate liquidity after that uh the only option was upgrade on a flight uh it was one transaction because yeah you need to like do it like you need to keep continuation of operation right and uh since the protocol is controlled by by the Dao by leider Dao uh the only Aragon voting uh has permissions to do

that to upgrade it so in order to upgrade smart contracts uh one needs to initiate to initiate transaction to the proxy and change implementation from old one to new one plus like some configuration cable management and so on um and like to to do anything or go on voting has to have evam scripts it's an array of triplets uh like who who to call which function to call and what params to use and you can take a look on a picture so it's basically like a list of actions it needs to be done and if the dial votes

for this proposal the array can be executed on behalf of Aragon voting contract um so V2 vote it's like actually even script plus a special template contract which we put like a lot of cable management to make upgrade more verifiable and interesting fact that executing the upgrade took about 8 million of gas and it was front ranked by withdrawal and the tea Hunter so you can take a look on if interesting you can go to the link and read his blog post um

so leader which operate is a complex process and what did we do to reduce the risk um first I want to share like our perspective how to write good spec good spec from my perspective should be first of all resilient against economical attacks taking an account sophisticated actors and [Music] um number three it's very important not try to set price on assets but use Market Force to do that um also covers all edge cases even if it takes a lot of resources and a good spec should be derived from frost principles starting with problem and constraints and after that go to like solution

um and yeah so Prospect and like this story about YouTube the first stack of this spec we put together for uh one week that actually described happy parts uh but we quickly realized it's the most problematic Edge case that might happen during mass slation when sophisticated actors can um can be in in better positions of regular Staker which is not good yeah so and next month months we uh just try to mitigate in this case so we're introducing two protocol modes Turbo Modes is a duffel one and bunker mode for uh mustache and Convention which is Delight withdrawals until penalties are

would be socialized um okay um so um another story it's about testing yeah so how how okay we just did good spec we did write code and how to make sure that you like I mean like the coaches in development environment right and uh production environment it's always like a little bit different from deaf environment so how to make sure that cotton production performs at as intended yeah to achieve this we create a test suit uh acceptance statute and

and we cover all scenarios in each case is there and next we take the actual script that was used to upgrade the protocol and run everything in a on a local manage heart local my network of the chain to make sure that things uh like things go in the right way so in this environment we run real script uh simulate the voting process by impersonated accounting and voting from like our like big audio holders and after that simulator upgrade and after that run test suit um

acceptance test is test ensures that the protocol function as expected but snapshot test can check that some scenarios be here behave the same before and after upgrade yeah so for example stake in one F in Lido before V2 and after V2 should get in your hands exactly the same amount of staff exactly the same amount of token and this can be checked with snapshot tests um okay so you tested your protocol in a proper way and you always need some

external external security you need like some like another pair of eyes uh to check that everything is correct um so it's obvious uh like everyone doing like security audits but if we wanted to if we wanted to be sure that upgrade is correct so we naturally want it more than one audit yeah and like due to the timing we run like this audience in parallel and this required us to have like special coordination process we have like dedicated dedicated person and it was a mess I mean like

it's just do it sequentially and just have some gaps in between of audits yeah because to handle all findings uh you will need this time um but this helps a lot to get the two upgrade on time and finding sets by different Auditors was different so it was definitely worth it and a little bit about search or approach certora also did for us a security audit but uh with formal verification and on top of all these

bonuses that formal verification gives you from Engineering Management perspective for me it was surprising that our developers started to think uh like in variant based in invariant basic way so it's uh like yeah it's like it was surprised for me uh yeah I see five minutes um um okay so you did audit after that you you need to make sure that you deploy it properly right and we have like special Department in our Dev team called the Ops that basically ensures two things um ensuring that any upgrade is

externally verifiable so like all params and configuration published and ensuring compliance with all security practices and um especially for me to upgrade we had like these like four things on top of this the most interesting that we introduced bug bounty to not yet to be deployed code we also had like additional audits that actually checked that pre-deployed contracts and templates are matched to um that version that was audited by another Auditors and yeah we created some fun tool called diviscon um

and yeah and the last stories it's about uh emergency stops so two sometimes you need you need to address unexpected issue right so for example um we cannot anticipate every scenario yeah and it's essential to have safety levels and usually what people do is create kind of multi-seek that have permissions to do emergency stop of your protocol right but um this introduced additional risk so um to address this we developed like gate seal that that has three advantages over like regular multi-seek it's limited it's

limited anytime so you can stop only for six days uh to allow Dow to react and it's like one one time um so I guess I guess I need one extra minute to wrap it up yeah so um uh protocol security from my perspective is a layered code and yeah you you should always start with the code because you need to ensure that God is secure but like you want to make sure that Angela and spec is also safe yeah and also you need to test it um

like on top of all this like snapshot tests and testing I definitely recommend to go in a test net public one um you also like need to think about external security things if you have all this underline you need to make sure that you deploy it in Secure way and you always need to expect unexpected things because things might go wrong in production and you need to address these challenges right and like all the stuff it's based on people because it's actually people driving all this thing yeah and you need to ensure that your team is good enough so you

need to hire right people you need to educate them you need to build culture and this is very important of and very uh underrated aspect of security and I think this is my main message uh uh to you that security starting with the people with people and you need to think about it um yeah and there's a lot it's the last slide so we are like looking for master of security to light a team so um if you're interested or you just know like right person just send me jam on Twitter and please subscribe on my Crypt videos that I recently started so thank you awesome uh if there's one question we

have almost like 30 seconds me huh so you said it's better to do sequential reviews than to have them all come in in parallel uh and and I can see there's a trade-off there like when you when you have two parallel reviews you might get different answers when you have sequential reviews as as you said there's a lot of benefit in being able to answer that getting your new work checked as well as the old

work uh would would you do both if you had the time and money um if I have time uh I would go with a less stressed uh option to have it sequentially because you can properly address all findings to like uh fix the protocol get some posts to thinking about it and after that go to the next auditor and if you do it in in parallel you need to really like apply patch send to everyone that is working on uh on your coach right now communicate it and it's really and sometimes uh like like another auditor also found this bug and also reports you

these findings like with another suggestion and it's becoming a little bit mess you know like it's it's just but yeah we was forced to do it because uh uh like our idea to was to deploy a sub after Chapel hard Fork so I think it's it's not about a choice it's uh yeah it's uh it's a trade-off cool thank you thank you Eugene I think we we need to stop now um yes thank you I will put I will be here for a whole day you can uh catch me yeah there thank you cool now welcome Anton from a security

engineer as at chin security he will speak about like re-entrancy and Beyond Basics I think I guess uh maybe we'll talk about like uh view real entrancy not okay we'll see let's just start okay uh hello everyone my name is Anton and I'm like engineer from chain security this is already installed uh who you are we are like in security of securing the smart contracts in 2017 it's a list of our awesome clients I'm gonna like Rush a bit in the beginning just because if a lot of material to go through and yeah

here today we want to give you like kind of our view on a smart contracts and that helps us to reason about really complex systems and to start like going beyond the basics let's go first into most basic career entrance example I mean this is something you will find if you look on the internet for re-entrancy right and people most I hope already know that's here for example withdrawal function is vulnerable but it's vulnerable because if you have like a high level specifications that we want our balances some of our balances to be balanced uh either balance of the smart contract by calling visual function

inside this code message sender like message sender can be potentially a contract via the fallback function right you can potentially violate this specification right and like by looking at kind of patterns in this code we can see that like we're reading some variables we are having external call right this is a call to untrusted parties so to say like this is address that can be controlled by not the developers of the smart contract but it's a sort of controlled by message sender in this case right and afterwards we have right and the quite standard

method how people are dealing with with fixing this problem is this check effect interaction pattern right this is already fixed code you see the last thing here withdrawal function does its call so it's a basically performs the same thing but it behaves correctly with respect to like this external calls that might occur right so it's like pattern wise regarding like read write operations we basically have call as a last item on our execution list and as a result any anything message sender will do in their fallback function it shouldn't affect our code right so this is where Basics

but uh like what we would hear I'll try to uh kind of introduce you is mindset how you can think about contracts as a concurrent objects right uh concurrency is like quite well established field right nobody has like a single processor on their PC now right everybody has multiple and there is uh like greater for done on like crypto uh on sorry concurrency scientific field to make sure that operations are like behaving correctly when they need to right and the good way to think about this as this is still broken example you see call in

the middle it's a good way to think about code in this case is that the there is some execution thread right there is some threads that needs to do a work in this case call withdraw function and the external call call to uh somebody who didn't write the code not the non-developer controlled code is basically like a huge operation right and regular concurrency systems like usually any operation can be yielded to some other thread right and you need to be sure that you are like establishing motexes which is like exclusive execution uh contexts where only one thread can

operate at the time technically it's super uh the same thing is like you have re-entrant cigars right and you basically forbid any other contract any other execution thread entering your contract again right by using these modifiers right and like to find uh [Music] box using this concurrent smart controversy concurrence object mindset we need to think about what can be done during our yield operation right if we yield there is a potential uh thread one let's go message sender control thread

that can ex can be executing anything in our smart contract right and as you see like I here have a kind of read write patterns for not only uh like this draw function but for any other function in our smart contract right so there is a deposit function by the way I'm here dropping some values there's only basically storage values if I have time I will go take a look at the Special Value that is balance of account because this is a really special variable and but for now like let's assume we only care about the state of our balances mapping and as you see like deposit

withdrawal balances all these three functions they are kind of actually reading or writing uh our uh writing to the same balances mapping as our trade zero right and uh like why what we can kind of uh get from this concurrency field it's going to be next slide back to this kind of my I guess interpretation of this theoretical uh Works done before I'm going to have a kind of list of references in the variant of my presentation but so in most cases we can from our experience

as Auditors we looked a lot of at a lot of clients code we can say that [Music] um worst case scenarios for re-entrances happening when developers are not assuming that their code can be executed in parallels of the same when if their code can be executed with re-entrancy because in most cases developers are thinking about so to say sequential way of things they're not thinking about [Music] like a call that can re-enter and this is this usually leads to the worst kind of bugs of course there are some like protocols it had a look at and

developers who plan their smart contract around the range we see right for example if you have a router unit swap router that like it should render or like flash flash loan smart contracts right there is a built-in function that calls the kind of hook to send fonts for this flash loan and this basically contract is intended to be re-entered right it expects to yield execution to third party but there is like post execution threads a post execution checks that prevent uh basically This Thread one from doing something that you don't want to happen on your to your

protocol right okay so the next point is that if we want like to detect that our smart contract is um oh yeah sorry uh it's it will be certain point but the second point is that uh if our concurrent object which is smart contract is linearizable this is the special concurrency property of this smart of this objects is that the concurrent execution is equivalent to a legal sequential execution with respect to some sequential specification right so what does it mean it means like if developers are syncing only in a sequential way they only have like sequential specification right this if there are contracts comply with this

linearization uh property then most likely they are called is executions like re-entrance is safe right and thus to avoid unexpected bugs we need to have our smart contracts like linearizable of course assuming developers writing their code assuming only sequential specification right and the there is a really nice check from the kind of concurrency domain that if it's not really analyzable then you need to find two operations belonging to different threads so to say that I performed on the uh shared variables concurrently and at least one of the separations is right

what means let's get back to our example I kind of summarized if you see on top of this conflicting operations what it really means right so there is two operations that can be conflicting if they belong to different threads they operate on the same data item and at least one of those operations is the right operation right so by looking at this picture we have three youth operations right and technically previewed operations already happened they we cannot affect them in most cases uh trade one cannot affect them we'll see later like examples where it's actually important to also consider previewed but in most cases what we need to be sure is that positive is Operation

the threads you're going to perform not going to collide with anything trade one can perform and if you like follow these rules you can see that our post-used operations are basically conflicting with deposits with withdrawal and balances and yeah worst case scenario we know is like you're calling visual again right and it's this basically means that there is inconsistent conflicting right operations of this drone but let's like think for a moment also I don't know if people did this mental uh effort before just to think about what what re-entrants you can actually mean for even such functions it's like getter balances right so if you sit here the

balance is the public mapping right and you are reading potentially a field that's going to be immediately overridden before uh overridden after the execution right so you technically thread one will be already sort of a reading scale data right while still because in positive execution of thread zero uh it's going to be is going to be overridden right so and and the same for actually like a deposit in deposit it's attack kind of doesn't make economic reason for massive sensor but if you decode deposit in during the trade one execution uh you basically donating one into the smart contract but

nevertheless you will break this invariant we have in the very bottom the the sum of balances should equal to this balance assuming there is no of course this uh forced uh either into your smart contract right in this basically means that uh all this conflicts that our like uh heuristics from concurrency [Music] concurrency this heuristic helped us to basically find all kind of things that potentially can break our balances right our environment sorry so I want to know

really pay attention to that we had the properties this uh the sum of balances equals balance of the smart contracts that we wrote our contract with this with respect to this property which wrote a smart contract and it got broken right but developers can potentially uh like write a smart contract that completely has completely different kind of specification right so in this case uh for example I wrote a smart contract and it's kind of just snapshots the message sender right you see like in the beginning we are like reading old one we're just calling him to notify for some reason and in the very end we are

writing we are writing the message stand there right and developer can have uh like uh invariant in mind that's basically last caller should be message sender right uh after my execution of right and if you see how this function works it actually has a correct execution uh it no matter what the old caller will be doing in his callback he cannot affect the kind of assignment of the last cover right and if you look on the right side this is basically the broken example of the uh is Vault right this is

big classical entrancy and has the same exact order of operations and it's just the fact that we had we had different invariant helped us to sort of uh say that the contract on the left is safe and controversial right is broken right so like going back to this really really packed with data points uh first of all there should be a sequential specification specification without re-entracy and only then by using this method you can you can reason if you have something unexpected happening or not right because if developer had in mind uh specification like on the left side it's

actually reentracy safe so to say it's a very interesting can happen but it won't be breaking in violating the invariance of the smart contract right uh yeah I also have an example uh similar uh where basically on the right side you have already fixed code right this is checked effects interactions pattern right and on the left side this is the last color but we're doing call as the last execution back and as a result you can violate this invariant depending how you define the end of function call right assuming this function call ends with the end of the call frame so to say

is the old color can call again the right function and snapshot himself again right and not the new color right so it's again reentrancy is really hard problem just because there is check effect interaction pattern like you see here it won't even be helping you because if you have a specification in mind that doesn't comply with it it's not going to work so summary the range consumerability cannot be detected accurately without knowledge for a smart contract specification uh yep read only react and see why is uh yeah we had suicide but uh heuristic there is that you can basically check

what you are accessing in pre-post uh pre-healed and positive of your execution and if there exists any way to combine your pre-post data that you have modified then there is potential way to basically have a return I think certori are going to present like a way nicer method for for this is their method they're going to have like I think kind of symbolic execution building a model but I think it's quite good yeah I guess I have I'm out of time so I'm out of time right cool

thank you thank you I'm done we have one minute for the question if you want if there's a question here an equation okay so we can you can go for welcome Peter so uh Peter is a Blog blockchain flat researcher At Con base and uh we'll talk about that what's the state of T5 Security in 2023 uh which is quite large we hope it will fit in 20 minutes enjoy expect I'm installed now right now

all right welcome to the state of defy security in case we have not met my name is Peter and my full-time job is I'm a blockchain threat researcher at coinbase and I'm also an editor of a Weekly Newsletter called blockchain thread intelligence where every week I look at all the major compromises who gets hacked what is the root cause what is the research latest research that we could learn from the tools that we can make our practices safer so we have a lot to cover today so we have we're going to talk about the economics of traditional security versus blockchain security we have the threat model exercise that we're going to go

through and we will talk through code security as well as the incident response practices that we currently use in the industry okay let's let's first talk about the economics of traditional security versus D5 security why is it that the Bad actors are so interested in our field that more and more of them are coming to attack us well if you look at the traditional security and what are the bad guys are really trying to do is for the most part they're trying to steal data they're stealing data so there were about thousand incidents last year and the most they could steal was around 400 like half a billion dollars with about two million dollars per incidence that they could profit and the reason like

those profits are really coming from ransomware attacks because when you steal all those emails and Social Security you still have to monetize them you have to go on secondary markets and try to sell it that is not the case with the blockchain security where we have about 300 incidents last year but almost four billion dollars of actual assets were stolen so that's six times as much profitability for attackers relative to traditional security fields so that means nation states uh Financial actors they understand this mathematics and they understand that if they want to make profit cryptocurrency ecosystem is the way to go that is why more and more of them are targeting us

um raise of hands how many of you are doing threat model exercises when you're building a protocol or evaluating protocol there are a few few hands all of you should be doing this like you should really before you build a protocol you should create this diagram and I'll show you what it is in a second thinking about like all the different ways that someone can Target you so do a very basic exercise like what a generic D5 threat model looks like and then we'll see how the bad guys actually exploiting it so we have to start with users so basically you and I we're interacting with protocols for the most part we are talking to dapps so these are traditional web 2 applications so your thread model there is we're dealing with

web 2 infrastructure with routing protocols which are attacked Every Which Way and then we have wallet software once again we've been we have Atomic wallet 100 million stolen so you have to think about those threads as well and then we have of course the underlying blockchain technology and the focus of the stock will be on Smart contracts that are running on top of blockchains and administrators that are managing them so here's how attackers are actually targeting this so the last so so far this year so this is up to this week the majority of compromises involved smart contracts so we have 400 million dollars that were stolen in the smart contracts space and then another 140

million based on just administrative issues so basically someone's stealing private keys what we are seeing though and unfortunately we don't have time to talk about our older issues on the user side so we have 100 million dollars stolen from users and this is all involving like crazy drainer attacks and phishing and transaction zero transfer issues and the wallet software leaking your mnemonic phrases so for some reason this is becoming more and more of an issue we can't really dive into this for now but uh this is becoming a concern but let's talk more about the right side of this threat model so the way you should think about security is prevention so code security is

prevention followed by detection and then when all else fails responding to it so let's start with preventing things let's look at the code security so this I would take a picture of this this is a list of attack vectors that I've observed so far this year prioritized by risk so these are the methods used to break things risk is a function of not only the value that was stolen but also the chance the likelihood the occurrence of those issues so the concerning part here is that the price Oracle manipulation and reward manipulation consistently stay in the top left corner year after year quarter

after quarter we're seeing those are the main ways that attackers compromise us examples of price Oracle manipulation how many of you are familiar with that okay so everyone is on top of it so someone you're relying on a price data if your protocol has that you have to be extremely careful about how you extract that data and see if it's not manipulated reward manipulation is more tricky so think of Euler compromise where someone was able to trick the protocol to give up a larger liquidation reward than was expected stolen private Keys is more of a process issue so I think developers think a lot about code security they go through multiple Audits and they feel safe at that point but you still have to think

about operational security so where do you still store your private keys while large is your multi-sex so we we've just seen from the from recent hacks three out of four multi-sig is not sufficient and you know keeping your keys in a metamask on your computer which can be targeted by malware is also not sufficient so you have to think about not only what code you write but how you will manage that code as well other things like insufficient function access control is an embarrassing issue to have in your protocol that means your Auditors or even you did not go through that threat modeling exercise you do not know how exactly your protocol can be targeted and what exactly needs to be protected so you have to be just really mindful of at least the top five here the place

where I really want to see all of these issues going is the bottom right corner where re-entracy attacks are they still happen this is still a concerned issue that should be mindful of but luckily at least so far this year they were I guess total nine issues combined between those two and that's where we want to see versus 40 something in price Oracle it seems like every single week when I observe a hack price Oracle manipulation it's a it's a it's not something we want to be so what is the issue so is are we do we not have enough Auditors our Auditors not experienced to find those issues there are quite a few companies out there if we talked about a year ago

there were maybe a dozen folks out there that you know you cannot book an appointment with them they were booked a year ahead now it feels like they're more and more entities which are coming online they make their services available and then even more available as single Auditors who are performing those Services as well we have plenty of bug Bounty programs we have competitive Bounty programs like code for arena tool sectora and Foundry it feels like the industry is getting more and more mature trading is interesting because I think this is more of an indicator of what's what's what is breaking here is that the

trading is very much focused on offense so we we got really good at teaching our Auditors how to break things but what about teaching developers on how to write really secure resistant code and I think there are a few exceptions I think if you looked at Patrick Collins YouTube channel like he's very focused on writing unit tests like how to write defensible code but for the most part we're overly focused on offense so just some takeaways for the uh for code security one I feel that developers are they do not have tools they don't have sufficiently mature secure development process and tooling available to them

we have to provide standards provide guidance on how to build code securely um defensive training is lacking I think if you're if you're thinking of a class and you want to build something let's let's focus Less on Auditors and more on developers so they start building code from this get-go uh operational security let's let's teach our developers on how to be safe how to not use multi-sig which is too small or it is stored in securely and at last when we grow the next generation of Auditors that list that I gave you we really should be updating it the list of primary attack vectors let's let's make

sure that they're aware of it let's make sure that they understand what are the ways that protocols get attacked and not just simply run automated tools with that as Eugene mentioned it's not enough just to do safe code audits we also have to think of what what happens when everything goes wrong and that's where incident response process goes so first how many are you familiar with the kill chain concept okay so not as many folks so this is as a as an incident responder the same way that you're building a threat model for what can go wrong with your protocol this is the model that you use to build what attackers can do and what stages to

Target your protocol so this is an example um kill chain for majority of D5 protocols out there the way that it starts it is with the reconnaissance stage so this is usually when attackers deploy test transactions so we see with Nomad compromise they were like messing with on live on chain that's rare but it happens public discussion of vulnerability so mango mango markets attacker like he was actively talking about it in one of the Discord chats resource development that's usually when the initial funding of the attack is happening when you may be getting some flash loans just to set up the infrastructure for your attack preparation usually involves helper

contracts where they either deploy it they configure them to Target your protocol and of course the active exploitation stage things don't end there there's also the laundering part that that's what happens after the protocol is attacked the way that this is useful is that if you can disrupt the attacker at any one of those stages you win even if you cannot stop the attacker at the very beginning in the preparation or resource development stages but you catch them in the middle of the exploitation you get at least minimize how much money was stolen from your protocol let's see a sample attack that happened and how it applies to this threat model

so Euler attacker there's a lot happening to this and more and more revealed it feels like every week on the reconnaissance stage we don't know what they did it sounds like they probably set up Foundry and they were doing everything offline so there's no way you can catch them if they were emulating the attack locally on their machines on resource development we saw the funding so as usual it seems from tornado cash full by exploit deployment so that's your preparation stage and then the attack itself the attack itself lasted for what is it 15 minutes and then at last they were starting to swap assets from usdc to other things and the reason the reason why they do that is because

assets like usdc and tether they can be frozen so most most attackers they tend to quickly swap them so they're not frozen on them at any of those stages Euler could have come in and stopped the attack and notice those stages lasted for minutes so you really had to be fast like if you want to learn more about like what to do Post exploitation invite you to actually look at the talk by my colleague Heidi Wilder tomorrow called Rec build but we will focus on just the beginning stages so let's let's look at the timing here so we we can start with the compromise stage this is when the attack actually occurred detection that's when someone

usually someone else notices that there is an attack in progress finally the end of the triage process that's when the uh the protocol usually determines okay this is an incident we need to respond to it and the way that I determine the triage time point is when they usually publish something so they say okay we have we have an issue okay so on Euler's side it took about nine minutes for an external party nine minutes for Peck Shield to put a tweet out there that we have we have a problem and then another two hours for them to respond to say okay we are investigating this this is a concern other protocols like multi-chain took an hour for someone else to find it in

another four hours for them to respond Bonk similar seven minutes to hour and a half year notice it's negative 17 minutes someone was actually able to catch that there's a an exploit contract that was deployed before it was used in the attack that's that's where we want to be but it still took him another hour and a half to respond so the money was lost and the abysmal response by poly Network six hours to detection and then five hours to respond notice in every single one of those cases these are the top five largest hacks so far this year in every single case someone else had to go and knock on their door and say Hey you have an issue not a single point that the protocol itself had sufficient monitoring to say like we have a problem

and we're going to respond what is an issue do we not have enough Monitoring Solutions it feels like more and more companies are spinning up out there the issue is that we're dealing with a lot of noise the signal to noise ratio is not good we can go back and find like yes we know there's an exploit and yes our protocol did catch it but can you tell that to me 17 minutes before the exploit actually happened that's what we need to push for forensics teams are too focused on traditional tracking of assets as opposed to doing the full analysis that were used in traditional security reversing the smart contracts analyzing how the exploit works and then the incident response is once again we're relying on volunteers we

have people like Sam basically called in into war rooms who are you going to call to really help you with the protocol I feel like there's a gap there so takeaway here is incident response detection by Twitter is not going to work that's a problem lacking incident response process if you don't know exactly what you're going to do every single minute you're wasting that time and every minute wasted is the time that you lose Millions we need to move not only because of how quickly those attacks are happening we need to move from detection to automatic intrusion prevention you don't have time to review all those things you need to pull pull the plug early on automatically so at this point you might say I can't trust my smart contracts I can't

trust my wallets I can't trust anything definitely not myself not to lose everything let's go back to trading shells and to that I want to tell you don't worry this is the issue here is that we're trying to compress the time that it took decades for traditional security to build up the expertise and tools and we're trying to compress this time in just a few years and it's painful so the well to suggests is that really rely on the community we have an amazing Community every single one of you here is amazing at sharing knowledge we have captured the flat competitions where you can learn we have conferences such as the one we have here we did not have conferences for a couple years back there was nothing and of course we have newsletters Shameless plug subscribe to block thread wrecked and others to just

keep up on what are the latest events and when it gets hard I just want to make you just remind you why are we doing this why are we doing our jobs why are we waking up every morning we're trying to build trust in the ecosystem and that's a critical step to adoption a critical step to letting all these people to use our protocol safely freely without anyone telling them no you cannot use this so every single one of you in this room has the power to increase trust in the ecosystem and in that affect millions and billions of lives and with that any questions [Applause] there's been a lot of talk about account

abstraction and I'm just curious how heavily does a con subtraction feature more specifically in the role of stolen private Keys is it a continuous discussion it's a side discussion is it something that the security industry is really taking notice of or incorporating I think it's amazing I mean we're we're dealing like if you remember the threat model 200 million dollars lost can we use this new tech to make things better can we introduce additional checks and balances maybe some kind of recovery mechanisms I think there's an opportunity to to make things safer but it's too early to tell I feel like we're still at the standardization stage

and adoption stage we'll see how it plays out I I'm optimistic that it will be useful for many other reasons too uh one more question given that the state of malware has a bunch of techniques for say like self-entry or self-decrypting binaries to avoid AV detection like prevention seems somewhat infeasible until like cryptographic keys or cryptographic information is sent to the contract so to what extent do you think prevention is actually feasible versus like attackers will just Implement well-known countermeasures to bypass your prevention well it's lucky we're not at

that stage yet I feel like we're still the attackers did not it's like a you know the frog and the poison snake analogy where both need to constantly compete and get stronger and stronger it's so easy to exploit the smart contracts right now attackers don't really need to obfuscate their smart contracts just yet please don't listen to this talk they they don't need to evolve just yet we'll get there but for now we can still simulate transactions and we can catch like basic things like oh your your pool just got completely empty or your your your governance somehow is changing so we can we can do really basic things today that will catch an attack in progress and when we need to evolve we'll evolve but I wouldn't say like okay we have to just

give up I guess once once they evolve we'll need to do that as well but at least we need to catch the bare minimum today which we don't maybe your last question okay cool I think um so it's time for the break thank you Peter so there's a 15 minute break before the second session so I guess you can like talk out there and see you again get this coffee and pastries downstairs so we'll see you back in around 15 minutes we have the next session on D5

protocols after this [Music] foreign foreign

foreign [Music] [Music] thank you [Music] thank you

[Music] [Music] thank you

[Music] foreign [Music] foreign

[Music] [Music] [Music] foreign [Music]

[Music] [Music] [Music] foreign [Music] [Music] foreign

[Music] [Music] [Music] thank you [Music]

last time [Music] thank you [Music] you guys

[Music] all right [Music] thank you

[Music] thank you [Music] thank you [Music]

[Music] foreign [Music] [Music] I think

yes sure [Music] no it's like okay exactly mirror yeah amazing [Music]

[Music] I know yeah it's good hey everyone it will start again in three minutes thank you them [Music] schedule

foreign [Music] [Music]

thank you [Music] um [Music] okay yeah yeah okay okay um uh Hey guys and we start like next section section of our conference and the next speaker is Mikhail inventor and CTO of gearbox protocol and it would be a talk about like continuous delivery and monitoring so Mikhail welcome

[Applause] thank you thank you guys really nice to see all of you please grab your coffee and come in we will talk a little bit interesting think about how to manage protocol and uh just a few topics what I really want to tell with you today so my primary things is based only on real experience because I will launched gearbox protocol from the hackathon to 125 millions of tvl so it was really a lot of mistakes a lot of things we have

learned from practical experience and I will talk you to you how to launch manage and updates safely the five protocol with 125 Millions on board now it's quite less we have around 10K lines of code we use different tokens as collateral you can just imagine we have 70 at the moment and this quantity is growing we have at least seven major defy protocols connected so users use funds which was provided to the pools with external protocols and our protocol is Dow driven from the day Zero it was a

quite nice idea for to give people leverage we use credit accounts corrected accounts are isolated smart contracts so when even before launch the protocol they ask people to pay some ease to the places credit accounts these smart contracts and give them tokens and we had a really extremely high partition High quantity of participants it was 5 000 participants at the launch and their active contributors to the Dow and now we are delivering the third version of the protocol so we have different protocols we have a lot of system interconnections and everything is

changed on the file and could be hacked so what I'm willing to tell you today how to sleep well when everything could be is on the Fire and just to explain what gearbox is gearbox is a decentralized brokerage account and the idea here is that if you want to get leverage you open your credit account you provide your part of the funds and you can take a margin loan from the pool and then all these funds on account could be managed by you so you can build any strategy what you want you can swap tokens on uni swap you can provide them into Lido you can put them into convex position so it's a full

compatibility and at the same time only things that is forbidden you can't withdraw money into your pocket so all funds on this credit account which is isolate a smart contract I used as collateral and here just a short architecture part so as you can see there are two sides one side uh is called passive lenders these people who want to get high yields they just give Capital to the protocol and another part we call this needs as people who are Risk Takers they provide initial funds to the credit account and it's significant each credit account is isolated smart contract then

this credit account immediately takes a margin loan from the pool and then he just could send different transactions and these transactions the same like you send to normal protocols so you can swap on uni swap on Sushi swap you provide this money into cure for convex and so on and what we did at the end of this batch of transaction we make a collateral check to understand if this credit account healthy or not and of course we have some risk management but it's not what I'm willing to talk today because this uh gearbox like a lensing protocol has a lot of risk and today we built a pretty

complex system so on this slide you can see what under the hood we have protocol itself which could be a target for potential attacks of hackers and people who want to steal money we have our own smart contract system which is called router and we had to develop it we could not use one inch for example to find all ways between normal tokens NLP tokens for example we can find the best route from usdc into small complex convex position and build what we called multiple so it will be a list of transaction how to swap and deposit all tokens to get this position and it also

could have bugs which as a result could block some liquidations we have Liquidators and of course each time when these Liquidators are under attack it could be problem we have front and the axis Farms so a lot of moving parts and to control this from the small team we have maybe some conversation and we try to build the process to do that so we call this system is a gearbox risk framework and the goal of this system is to provide a full transparency for our community so each dial contributor could understand what's going on we are fully transparent we talk freely about risk and potential problems we want to be

safe and we want to deploy with confidence without any side effects and sometimes it's quite difficult to test that Liquidators could get stuck somewhere so there are three steps how we do that the first one we write the list of all potential risk and start building monitoring system for example as you can see for the protocol risk we monitor all changes in the pools we check that there is no unhandled liquidation or if they happened we get immediately some notification to the telegram and I will later check the website we have a pretty interesting idea we called it optimistic liquidations when we work with our credit account which holds a few

different assets on this example you can see on the right there is a Lido token and cvx3 CRV to swap it back to West we should do a lot of steps so here you can find we should swap convex position into Frac series and we should unwrap it into three series then we should unwrap 3 Series to die and replace and then convert them into less so it's a quite complex extincts and if one pool in the middle could have a lack of liquidity if you have back and rotor or Liquidator it could be a bad depth as a result so to really reduce the risk each three hours we have a special robot which run a fork

node the impersonate our configurator to change params and then we start to liquidate all accounts one by one and we have a logs that if this account should be liquidated our system could use it properly and there is no problem like lack of liquidity or any other stuff related to our software another good point which was already into consideration related to front end as you know it was a hug to the curve when someone was bribed and changed DNS for some provider and people use like a malicious front end and that's a big

problem here that the industry is growing so fast so it's quite difficult to check all libraries you use for front-end application and if someone make a malicious part of the code and you build your new decentralized application the some disaster like unexpected approvals who happens so what we did to eliminate such a risk we run a special robot each few hours it run a test framework and try as a user to run application and do different stuff like depositing money or building position from our website and we used our proxy provider which has

like an expected results how which transaction should be built and if we can find that our software builds the usual user routine but transaction which was generated by our application is different or malicious we should immediately send an alert and of course we can talk to people that something is going wrong at least on Twitter Discord we can block our application and so on but on this stage we check that nobody could add any address for approval and so on so it owes another part how to protect the whole supply chain from the protocol to end user and of course maybe

one of the nightmares for all of us is a market risk because as you know many hacks depends when people could manipulate some assets many hacks were happened when it was like a reader entrancy for some curve pools and so on we have some interesting ideas implemented on this smart contracts but to monitor more we have a lot of different and robots which run this simulation for example we work with risk Dao as you can see it checks the liquidity of the pools it's a quite crucial if there is no liquidity and we have a big exposure of the protocol of

some particular asset it means in the case of big price drop Liquidators would start to swap it back and back we will use whole liquidity and acquire bad depth so to prevent such things the continuously monitor all this stuff got notification to make a better decision and of course governance risk it's another huge topic now we have a Dao and which works for some multis for snapshot and then multi-six signs this transaction and of course as you know there were some cases when using social engineering people try to push some

incorrect or malicious transactions it could be some incorrect way which could be also to the hack so we built a lot of bots and connected them to the one website which is available for everyone so if you can compare with centralized exchanges which just provide a paper we have such uh things on our accounts it works totally different we are fully transparent as a protocol for people who are willing to use and we try to write this way in more simple way and we send this data to telegram notifications and to website then the next part is the simulation how

to do next step so when you get hacked we I have a personal experience when bug bouncy found some critical bug and at this point you can't think you really try to solve something as sub because you feel you are not okay and in this case we discuss all possible actions what we do so team could be under pressure response time is a king so be ready for that and here we're connecting the dots so we have a continuous moritong we have an analyzing all these possible cases together as a team and write all specification what to do and the last part is how it worked how to responds

for all this stuff and how to continuously deliver a new version not to break another part and here as you can see how we deliver all changes to our protocol as you can see the first part is Snapshot voting so people try to list new tokens people want to add new protocols people want to change something and each changes could break in changes it could break something and really could have a bad consequences so we use time lock of course it's a good practice for two days so if you are not willing to work continue to continue to work with these parameters you can withdraw your

money you can close your credit account or if you are a dow contributor you can tell us hey guys there is a mistake it's a problem could be here and so on and another part what we implemented for some emergency cases for example lack of liquidity some protocol got hacked chaining price Oracle providing correct data what really was when Luna price dropped down and we really acted immediately otherwise the protocol could be hard because deviation between chaining price Oracle and real price was in times so we have controller we have a lower staff lower time to act and we

also have lower we should not ask a community we also have a special roles who can manage and solve the problem and about the protocol updates when we really create some new transaction we make this system which everyone could go to gearbox rigs framework website and I'll show the demo and check what's going on from my point of view when we built a decentralized system it's a very very crucial you can find a bad example of this multi-chain when one person control everything he would carved by police and the protocol drops in gearbox through the centralization is a key

and another interesting part before showing sedema is cicd it's a practice which is commonly used on GitHub when you deliver your code in gearbox when the queue transaction for multi-seek is provided we immediately launch a special code on GitHub the impersonate multi-seek we apply all this transaction run all tasks optimistic liquidation I already mentioned to understand could this change break something existing or not and of course we have a system which compare some code from GitHub whichever Audi that we have I think seven or eight

audits at the moment to quote which were deployed to the user scan and now let's check how it works so it's a public website and here you can see what I already mentioned uh there are a few things what we are checking uh so for example for optimistic liquidation you can see the list of all accounts you can see the double we have a two different Liquidators to be able to liquidate at any case if one gets stuck another should work because they have a totally different code base you have a list of accounts you can find all these ways you can click on any account and get immediately the whole data

history about things so if we can find some problems for liquidation we can go deeper and understand everything another interesting part what I already told you related to protocol updates and here you can see this time lock we have two types of transaction one is Q which sets the things and we can immediately understand what's going on and another is execute and uh I think maybe this is interesting yes so here you can see we have at least things which based on usually it's a snapshot vaulting we have a simulation

what I already mentioned on GitHub we run a special cicd script to check that everything works as expected and with these changes we do not break anything and you can see this comparison too so basically these two get this the code from azer scan then it searched for all our GitHub try to find the same commit and GitHub repo and then all commits are related to some security audits so you can simply find the discrete configurator both audited by Chain security because this commit hash was related to this thing so you as external

part if you want to understand about the safety of this action you can find a related related Audi sometimes the system detects two of them or more and another part what I already want to show you and it's yeah and as as of course there is a lot of different data here uh yeah here as you can see it also shows us all differences previous values so if you are want to learn more you can click on actions and find the full explanation

and human language so basically it's what I really want to present thanks so much if you have any questions feel free to ask yeah guys we have one minute yeah thank you and we have one or two minutes for your questions so please raise your hand any questions yeah over there hi Michael very inspiration talk um I do have one question given that you said like every protocol UI protocol you will have a rigorous

audits or smart contract coding so how would you plan to scale gearbox as the prime brokerage oh thanks to the best strategy to do that uh it's a really great question thanks for that so we try on the first part we really take Blue Chips protocol to be enabled like curve and so on which is really uh proven by Battlefield now we have the third version we have a quarter so we able to limit exposure of any protocol so we can start with a small limit a few Millions check that everything is going wrong and

if the protocol works well if it's battle tested we can continuously increase this limit for exposure of any particular token to create more trust and of course it's not by our team it's more related to our community down members and risk team okay um thank you for the great talk and I'll just checked the site that you share that risk that gearbox the foundation then I just found that there are there is a minus 50 deviation on the Oracle prices for yeah yeah yeah it's pools yeah yeah it's what thanks for checking

it's what we uh listed today it's not in use and the problem is in spot price calculation so we double checked but for some complex token as you can see this is OHM fluxbp so itself to compute it correctly you should do a lot of steps so on the real Market I think it's more related to incorrect Sport price provided by one inch what we use at the moment not to the real time but these tokens are not in use and the biggest way why we build it and thanks for question that Community people like you could check with going on ask questions and we do all steps continuously to make

everything safe thanks so much yeah time is up yeah uh so we uh we don't have time for on the next question so I want to introduce next speaker uh thank you Mikhail uh uh welcome Quentin uh he's a protocol researcher uh from Marvel apps and talk would be about formally formal verification of Morpho protocols so let's welcome uh Quentin [Applause] all right

so hello everyone and thank you for watching introduction um so yeah I'll be I'll be talking about formal verification and about malfo and I think that uh former verification will become more and more important as time goes by in the device space and I'd say the same thing for Morpho so I thought it would be a great opportunity to to talk about both so I won't assume any knowledge about formal verification but my promise is this by the end of this talk you you will know what formal verification is or at least you will have a sense on the nutrition of what it is and you would have seen examples of formal verification being applied to defy and being applied to two more for all right so first what's Morpho

so Morpho is a PHP or layer over Landing pools so we call that morph optimizers and so you have one instance of a morph Optimizer for each Landing pool so one for compound V2 one for RV V2 one phone for r83 and what's more for Optimizer accomplishes is that you have the same wrist parameters as the underlying pull you have the same liquidity but you have improved rates so how can it do that well in a landing pool setting you have this full Supply apy and this pool bar API and the fact is that the pool supply API is lower than the the pullbo API and the reason

for that the main reason for that is that you have less borrowers than you have suppliers to hold the interest generated by the borrowers they are splits among these players and that's the main reason for the spread but in Morpho you have a particular layer which means that for the match amount you have the same amount on both sides and so you can decide the rates and you could and what morph optimizers do is that they put the rate in the middle which means that when it's a win for the borrowers because they they pay less interest and it's a win for these two players because they they earn more all right and then you need to have a fallback in case one of the party exits and you also need to have a fallback that is in uh in constant gas and that's not so easy to do so that's

the the Delta mechanism so we have plenty of documentation uh you have we have a yellow paper that is available also and more broadly if you're interested about any of the stuff that I'll describe in this talk uh you can find in total online everything is open source and there's one last thing I didn't talk about in uh for Marvel optimizers is that it's a layer on top but it means that you have additional contracts and so it necessarily means that you have additional risks the smart contract risks and this this is why you have an emphasis on security where there are many tests in variants we have monitoring of different kinds on

different platforms we have audits with carefully chosen Auditors an internal review process and also formal verification which is the the topic of this talk and I'll explain briefly what it is now so what's formal verification so it's a domain that is in between mathematics and computer science just for that I find it extremely cool but also you have a powerful idea underneath it which is that you you try to match the code with the specification and you want to do that in a formal and rigorous way a mathematical way to ensure great guarantees about your code and this can be done with giving and

getting a formal specification so that's not typically typically what you get so if you look at some documentation you get more informal specifications something like returns a valid value which may not be that useful because what's valid in that case or sometimes we don't even get specification so for example if you have a deposit function maybe the the documentation is okay this is the function to deposit the funds but it doesn't tell the whole story because the whole story is like what happened to the phones what's the yields how can you withdraw them what's the risk associated so a bunch of things that are not specified and what you want for formal specification is the kind of the opposite of that you want to specify

everything and you want to do that in a rigorous way so an example of a formula specification a simple that I wrote here is that for every input X if you apply F to X you get the value that is greater than 10. so that's formal that's great so once you have that what you can do is match the code with this formal specification and out of that you get what is called the verification condition so this is simply a formula that when you you verify it you know that the code matches your specification when that happens we say that the code is great so you cannot really say that code is great without a specification you always have a specification in mind when you said the code is correct all right so it's a bit abstract so I'll

try to take an example so let's take back uh the formula specification that we had on the on the bottom left and we have this snippet of code that looks like some solidity code I removed some keywords to make it fit on the screen and I'll do that for solidity code and we want to get a verification condition of that part of that so um so here uh just quickly you have an array of size 3 that is all the integers you have a function G that is unspecified and if you want the F the function f to respect the specification what you look at is that the return value G should be greater than than 10 right but this should only be needed

when X is greater than two this so this is the first line and also in the other cases you want V to be greater than 10 but since X is an unsigned integer it can only append for x equals zero x equal one and this is why you get this verification condition so it sounds pretty easy right but um actually for programs that get a little bit more complex it can be tricky and I leave you with a little brain teaser so let's say in the condition now instead of X we have X Plus or maybe plus plus X so maybe would be a little less confident about what the verification condition would be and in the general case it's actually can get

quite quite complex but um hope um what's what's good about that is that since both the codes and the formula verification are formal objects you can actually apply algorithm to them and you can do that automatically using a verification tool and so that's one part that is done for you so if we recap a little bit assuming that you have your code you have three steps to reformally verify a program so first you need to come up with a formal specification so that's the first step then you need to apply a formal verification tool so that's the step we've just seen right there and then the third step is to actually verify the condition

and verifying the condition even even if the second step is is done automatically for you verifying the condition is not always easily uh done like like this like automatically finding a proof is uh it's hard um and uh so I've seen verification conditions of 2000 lines of code it happens so it's not easy to do by hand um all right so it can get quite complex so why bother with formal verification I think if there are three reasons for that in the case of D5 first is that you have small programs so this is kind of uh embedded in the in the system you

have a limit on the contract size on ethereum and also related to that you have this open source culture with having readable code and also it helps for maintaining the code but it also helps to to reason about the code and this is typically what you do when you do some form of verification so that's the first point why why uh formula verification is a perfect hit for for defy and the second point is that you have a critical system where potentially you're managing a lot of funds and you really want to get it right the first time and that's why from reverification shines in this in this setting and finally uh maybe a bit less talked about but in the blockchain setting you

have this idea that you don't want to be able to rewrite history but at the same time it means that you the mistakes that you make uh they they are potentially permanent and so same thing you really want to get the rest the first time because this mistake won't disappear and so a formal verification gives you great grounds easier all right so this is the general overview of Marvel of formal verification and I'll give more concrete examples of how it is applied to the Marvel protocol using the three tools that we use at Morpho uh namely certain Almos on Wi-Fi and I'll start with the searcher so theater is a great tool for many use

cases and in the case of Marvel we use it in particular for data structures verifying data structures verifying optimization so let's say you have one function and then you have an optimized version of that function then then you want to verify that they do the same thing so you also used it for verifying the Morpho token and I won't get into the code but just know that in the more photo can you want to have an authorization um uh setting where you give users some roles and that's useful if you want to make the token transferable at the right time so you have these two functions the users are raw which is a view function and then just you have this set userable function

all right just so just know that and insert or what you do to be able to to specify is that your your contract is you write a rule and a rule is uh just basically a formal specification where if I add I dissect that row I have this first this Boolean this user have a role then I call any function f on uh on any argument and then let's draw this Boolean again and what I say at the end of the rule is that if the fact that the user has a role has changed well it means that the set user will function uh it's the search is a raw function that was called so in a sense what this rule means is that only the set user word function is able to change uh if a user has a role

and so this is not maybe not the first rule that you would have come up with so I wanted to show it that formula specification is not easy sometimes and this is actually a really useful rule so you can put that in your CI and when later you add a new function uh it will check for you with a perfect certainty that you did not add a new function that was modifying the rows all right so second tool I want to present to you is Y3 that we use our add more for labs and this tool is a general purpose verification tool which means that it's not designed for solidity directly so you need to add to this translation and it's a direct verification tool where you it does not

make any compromise in terms of samness and you can verify a contracts with arbitrary number of iterations in the loops for example so it works in a modular way and this modular way mimics very well the contracts when you call from the the outside you cannot change the the storage variables and so we use that to translate our code into Y3 code all right so this is kind of the architecture of the the program the verification and I want to show an example of how [Music] of theorem that we managed to prove using Y3 so I won't focus too much on

the syntax because it's another language but basically this term is really not so easy to to come up with and also to to prove on paper and when you want to formally verify to also get arithmetic and rounding errors that you need to deal with but basically what that says is that Morpho is a contract that Aggregates users and as such it has a position on the on the underlying pool and that means that you need to make sure that it's it's not being liquidated and this is what this Serum is about so if you take the supply and pool that the Morpho contract as you multiplied by the liquidation liquidation threshold this

gives you the borrowing power and you show that it's greater than the actual bar all right um so last example is about Almos and um yeah you can see that you have run really cool property of how most is that it's really tightly integrated with Forge and this looks really much like a forge phrasing test and actually it is so it works if you try to to run forge on it but when you run almost I need to get additional guarantees so pretty nice so this particular example is taken from the data structure that is used in Mafia V3 and this data structures works with buckets

with arranges where the bounds of the range are powers of two consecutive powers of two and the bucket is identified by a slower round all right so this data structure is improving Finance is very efficient and we want to also formally verify it and this is what we do here so we say Okay so the bound is indeed a power of two and any value that we get is in the bounds and this is automatically automatically verified which is very cool so let me finish with the contributions so I've shown formal verification that is done on Morpho protocol so for that we use direct verification of solidity codes

using tools like satura on the Almos and we also Define a methodology to translate solidity code into life record and to verify it and that's it I think that's all there is about the form of verification but if you have more questions I think we have a bit of time right yeah thank you Quentin and we have two minutes for questions and I already see one yeah thanks for the great presentation I am very interested that how long does it take to verify a protocol like Morpho so if we compare the in-house effort that you've done and say formal verification Services by somebody else who how does how does

decompass why why did you obtain for in-house verification basically that's my question yeah that's a great question so that's kind of my my core uh knowledge to a formal verifier at at heart so I didn't opt in for that but what I'm offered it is because you need to have deep knowledge about the the the protocol to be able to really understand and formally reason about it so it's not necessary the case for every protocols and sometimes it's a bit easier to verify with morph optimizers are really deepened internal complex protocol so you need to have deep knowledge of that and so for your question about uh how much time it takes it's also a tricky question because it depends on like how

much you know the protocol and like what tools do you have and also uh how deep you you are willing to go and if you want to really verify everything and take everything in so that can take years basically so it's really almost impossible I think to do but uh if you want to really verify the logic which is what we did using my free for example you can do that and you can do that rapidly so if you really focus on the The Importance that the car core protocol core logic uh hi I have some experience with formal verification and the way when it gets stuck that maybe you can help us how you

verify complex interactions for example Morpho interacts with our ah with a huge protocol morphe is a huge protocol if you start to mock a lot of stuff and dependencies it means that you formal verification relies more on your mocks than real code than not real code base I think you can understand the problem so what's your findings here how to make this complex formal verification for interconnected contracts and a huge code base that's a great question so indeed it's very complicated and different tools provide different ways of handling the handling it so Etc you can have a dispatcher for example you saw you say okay when I I'm

dealing with tokens I'm dealing with these sets of contracts and this is a way that you can like have your dependency so it's really neat way because you can like really specify what what you want but in the general case it can be yeah indeed quite complex and so one general idea that is um that I found really useful is to start small so you start with a small dependency version that so a mock contract of far away and try to come up with a formal verification about that and then so you have this behavior that you're you're mimicking and then once you have that you you you can separate it because now you only work on Avid to show that have actually does show this

Behavior so you kind of separate due to the dependency on with a particular specification and then you take the specification and try to verify that it works on Highway doesn't does that make sense yeah okay thank you Quentin and um yeah I want to introduce next speaker yeah thank you I want to introduce Daniel a security engineer from origin protocol and it will be talk about uh how to secure your great protocol welcome thank you I'm going to take just a minute to set

up here but it will pay off and that my speech will be actually be shorter and that's kind of what uh one of my topics is putting a little bit effort in ahead of time and saving yourself a lot of time afterwards how many times have you seen somebody give a presentation with two laptops before

all right I'm going to talk about the single most under recognized danger in crypto upgrading a running protocol uh the stakes are massive and mistakes can be mistakes are really easy and the consequences are just bad uh so Ave deployed a broken upgrade and locked up 120 million dollars for more than a week and Ave is the second largest D5 protocol out there uh last time I checked it had an 8 billion tlv compound did one billion dollars a few months earlier and uh three separate audits uh

and it was frozen for a week and some now I'm not picking on these two projects particularly they both care about security they both did a good job communicating afterwards but safely upgrading a protocol is hard and repeatedly we see even good projects do a bad job of this now Lido just did a great job of it they do everything right and so to some extent this is just focusing in on what you can do uh just three things you can do to make your life so much better and not be stupid uh so my name is Daniel Von fange uh you might know me from Twitter

um I'm the smarttron track security guy at origin protocol uh this is going to sound like Shilling here for a second so uh in two sentences I'll be done and there's an actual point to it but uh we just launched a new product oeath a few weeks ago and currently we're the number two uh yield aggregator on DFI llama for ethereum our previous D5 product uh which is a couple years old reached a 296 million tlv since I've been doing smart contracts uh upgrades and gatekeeping or security and upgrade gatekeeping we've done 50 plus upgrades to these two protocols with zero hacks losses of funds funds freezes or dramas so I spent a lot of time over the last

two years thinking about upgrades and I really care about this and it's so painful to see people repeatedly Doing It Wrong which is why I'm standing here today so what's different about new code versus upgrades when you write a new protocol there's just your code it floats alone suspended in space you can read your code and know everything about it and what it does Auditors can look at it and know everything about it but when you're upgrading your code there's your code and then there's all the stuff that's already there uh the state data the config data for your protocol um there's all the other internal contracts that already exist and then there's all the external contracts all

around it's this cloud of existing state and contracts that broke both the Ave and the compound upgrades in both cases the new code that was deployed was audited it was correct in one sense but it did not fit the environment that it was put into this is the biggest difference between fresh projects and upgrades correct code is enough for new code but for a safe upgrade the new code also has to work with everything in the existing world and one more thing when you write a new system from scratch you're often thinking about the entire system as a whole but when you write an upgrade you're thinking about list you're thinking

about as little of the current code as you can possibly get away with to write the upgrade but the reality is when you write an upgrade you actually need to think about more not less because of all the other things that are out there so I'm going to go over three important things you need to do to do good upgrades uh the first one is simple and that most people here probably know about this one raise your hands if you know about this one all right good I've got news for half of you um the number one rule for upgrades is don't accidentally reuse storage shots in proxied contracts the consequences can be so bad so fast that I'm going to be talking about this one first even though to some extent it's common knowledge and it's something that

Auditors are good these days about checking and a good auditor checking an upgrade will catch this one so I'm going to move over here and uh use props for just a second testing testing awesome all right so everything that your contract stores goes into numbered storage slots and the variable names in your contract have nothing to do what's actually going on under the hood in the evm so in the evm it's just slot zero slot one slot you know giant hexadecimal number and so when you write some code and we're going to call this one Foo here

uh the compiler just assigns Foo to slot uh slot zero here and then whenever you set food a three it puts those things in there hang on just a second uh and so now when your code pulls up Foo it reads three um same thing we'll put bar over here and we'll put one thing in bar so if you write a new contract and you change the order or somehow switch things around so that the compiler changes which variable names go to which storage slots uh when you read when you read Foo now you get the wrong

value not what you were expecting and let's say one of these was your admin address and the other one was your interest rate or something if you switch those two it's really bad you no longer have an admin and your interest rate is now a Bonkers number so that's the first thing you know you can't you've got to read the rules on this one it's way more complicated than I can actually talk about now but go read the solidity website uh hang on a second yeah so read the solidity website on uh how those rules work um

that was the demo there okay so that's the first step is knowing about it second step is check it automatically uh there's open Zeppelin has some good JavaScript tools that will compare your old contract storage to your new contract storage and see if you've changed the name of anything and so we have that built into our CI pipeline there's also a library called boundary storage check which I've not used but does try to do a similar thing for The Foundry side but it's important you know put it in so that every PR that goes into your continuous integration gets checked comparing the old contracts to new contracts and throw a big red mark if

you've changed your storage slots so here's a little bonus uh Secret in between the three things you want two contrary things when you're doing ongoing smart contract development you want safety and you want speed and these are opposed to each other safety means taking more time uh checking more things and that's the opposite of speed so kind of what separates Great contract development from good contract development is finding ways to cheat this paradox and one of the most powerful cheats I found is to have security critical code as small as possible if ten percent of your code ensures the correct behavior of the other 90 percent you can operate much faster when working

on the rest of the code and you can check the correct Behavior the Safety Code much easier because it's a much smaller set of code uniswap V2 is a great example of this the protocol split into a safety part tiny pool contracts that only move money and ensure that the amount of money in them just goes up and the rest of the complexity is pushed out into the router that makes the system easy to use but just because the safety checks are in a small place the router can't mess up the safety of the protocol um so this this split between critical and non-critical code is not only a design great design for building a protocol it's also a really good way to upgrade

one because a lot of the contract upgrades can take place in a much less critical manner um and it doesn't have to be in separate contracts it can just be parts of the same contractor you know code if you want all right so on to the second must have uh atomic programmatic deploys um sorry so many projects Builder deployment plans last after they've written their new code and for some project maybe there's a text file that says how to deploy it and eventually maybe something gets put into governance but let's step back and look at the bigger picture of an upgrade um

most projects have two phases for an upgrade first a deployer key creates new contracts possibly configures them and then hands ownership over to a a governance system of some kind like a multi-sig or a much fancier Community Driven governance system and so then that second governance system then actually switches the contracts over from the old system to the new system and may do governance config changes is a part of doing that so what you really need to do the right way to do this is to have all of your stuff about the switch defined in one file you want to uh do your deployer actions do your

framework or your governance actions and then if you're running in a local situation simulate that governance action taking place and happening um so this also has a a benefit that you're testing you're running to deploy your deploy process over and over and over again while even writing the code for your system and so when it happens for real it's not a surprise uh everything just works and you also want your thing to go into effect in a single Atomic transaction um everything happening at once uh otherwise the people get to play with uh an inconsistent state which is pretty terrible I'm going to stick skip that for time reasons and go on to uh

kind of the main reason for this uh Fork testing Fork testing is absolutely amazing uh it's the most underutilized tool in smart contract development and I mean imagine how powerful it would be if you could take a snapshot of the entire universe try something new with no consequences and then you know come back with what you learned so Forks allow you to have the effect of making a copy of the entire blockchain deploy contracts and then run transactions as if you were in a copy of the world so there's three valuable things you can do from a fork the first is you can just play with your new code in the Real Environment as if the upgrade it happened and you can run this you can run a your dap against your new code or play with it from brownie or something else that lets you just play

with stuff there's tremendous value in finding bugs or things you didn't think about you know the stupid bugs in that or just understanding the behavior of the system so you build a gut reaction feel for it uh secondly you can write tests uh that run against the fork environment just like your unit test you know you can make sure that somebody can deposit your protocol withdraw from your protocol that a sensible amount of Interest gets earned and it's testing that on your new code before your new code is ever even live and just put it in your CI like everything else and it finds out you know every time you put a push a commit up it's making sure that you didn't break your existing system and really they're not any you know they're like one or two percent harder

than a unit test to write it's it's really easy to do uh lastly and this is new uh technology these days you can actually fuzz against your fork test and so this is even powerful you can throw a million randomized tests against your fork environment and see if it works or not doesn't work and what's great about this we heard the question about formal verification well how do you test your interaction with all your dependencies this tests all your interaction with your dependencies and so if you're using Ave like we are or compound or stuff you get to find out if your code doesn't has some kind of mismatch with their system before it actually goes live uh it's it's kind of amazing

um and so Foundry you can then now have uh these built-in uh ability to fuzz onto a fork test um and let's see that's pretty much it this is the conclusion don't be stupid [Applause] uh I'm on Twitter at Daniel VF thank you okay it's time to questions for questions yeah I see one can you help us with the microphone uh thank you for the presentation um might sound as a dumb question not

sure but uh so fuzzing seems to uh only interacts with a smart contract on the local uh local environment how do you emulate the adverse adverse environment that exists on mainnet on your local environment is this something that is possible is this something that is lacking or is there a solution so uh let's take Foundry for example when it's buzzing it's got a local copy of the evm running and when you're Fork testing you have a local copy of the evm running and when it doesn't know something it goes off and fetches that information that it doesn't know from the blockchain loads

it in locally and then uses that from then on for time reasons I skipped dimmuing how Forks work but that's basically a part of how quarks work and so if your fuzzer needs to you know hits a code path that goes talks to Ave it'll go load in the Ave code and then if it hits a code path that uses a particular account it will go load that it users or you know that data from Ave for that account or something and so it basically just works it will make a lot of RPC curls um you know either I guess you know even fuzzing a small amount is still a pretty great idea you know even if you only run 10 000 transactions that's 10 000 times more than you know tests happened on compound for that upgrade

um but uh if you really want to honk it you know you'd run your own node to point to locally or nearby where you're fuzzing next question okay I saw another question here just to continue for this fuzzing on my net there are a few things maybe can you advise for the best practices the first one in unit test we can really add some predefined computations to check the function works correctly for example just hard code a few numbers compute them on the paper and so on when you use fuzzing you enforce copy paste so you

can go to the sum contract copy this part of the code put to the test so you mean that the function which some 2 a and b equals to the result of the same function so basically it do not make your system more reliable because you should implement the same algorithm for fasting testing if you want to compare the result which you compute independently with the things you have in the same time and for mainnet another part is very interesting because primarily we use fasting testing to find like uh problems with huge numbers if you have some overflows and so on when you start

on my net you have a pull limit on compound for example 10 Millions it's okay but it means that if you want to provide greater value for the Thousand test there is not enough liquidity and in this case could you suggest to really impersonate the compound for example root role to add more liquidity or what's the best practice to test fuzzing if the existing protocol has very small limits which do not cover the whole range of possible testing thank you yeah those are good questions um so you kind of hit on this at the beginning but often when you're writing a fuzz

test as opposed to a unit test you kind of want to use relative tests you know this account has one eth more than it used to have instead of saying this account has one ease so you're often dipping it uh secondly I'm a pragmatic dwarf and if I can make my life 90 better for a little bit of effort you know I would love to do that uh and so you don't necessarily you know you can do your fuzzing test where they don't have to be absolutely verified to the single thing uh what you're actually going to get as a result you know you if you catch the big things that's you know a lot of times you know there's Great Value you know if somebody uh ends up with a whole lot of money you

know that you know that's a problem or if it just breaks that's a problem um I forgot your last question in there so sorry about that catch me afterwards um I I want to announce the break 15 minutes break next session would start in uh um 11 40. but uh I think that we would have time for one or two extra questions but let's uh say thank you to Danielle and give some noise for him and and yeah if you want to go on a break go on a break and if you have some

questions you can stay and ask it [Music]

foreign [Music] [Music] [Music] [Music] [Music]

thank you [Music] [Music] foreign [Music] bro

Oke [Music] foreign [Music] thank you

[Music] [Music]

foreign [Music] [Music] [Music]

[Music] [Music] [Music] foreign [Music] [Music] [Music]

[Music] [Music] [Music] foreign [Music] I'm coming

back [Music] foreign [Music] [Music]

[Music] foreign [Music] foreign [Music]

[Music] foreign [Music] [Music] foreign

[Music] [Music] [Music] foreign [Music] [Music]

[Music] um [Music] [Music]

hahaha [Music] foreign [Music] [Music]

[Music] hey hey one one hey guys I think it's time to start our next session please take your seats if you are on the first floor or in a security garden please come to us maybe in one minute we will continue our great conversations about security and other stuff one minutes to find the best place assistant

foreign [Music] [Music] and I'm so glad to invite our sin to incredibly great experts in this area so please Applause to your face security fellow of ethereum foundation and Oren fine co-founder and CTO of

sphere X thank you hi everyone so so today we're going to talk about a masquerade encoding ethoscan or a hiding code hiding code and not showing what's really going to run and as everyone here probably knows uh when starting to interact with a new contract it's a common practice to look at to look at the verified coding ethoscan to understand what it's going to do and assess whether it's uh whether it can be trusted

and of course scammers know this too so the question is can they can they pull this rug from under us and it turns out that they they can and they often do so what we're going to show here is uh a couple of techniques a couple of techniques that are used to bait and switch to show to show you legitimate code that actually runs something else and then we're going to show an actual an actual vulnerability that was exploited on mainnet and it was missed by Auditors due to such techniques the most obvious case is um the most obvious way to do it is to hide a bug in

plain sight and it's made possible by the fact that you can verify any you can when you're verifying a contract on ethoscan you can upload any number of solidity files that you import even if these files have nothing to do with your uh with your bytecode so you can upload huge code most of it is not actually used but it can overwhelm the auditor and and then and then some vulnerability can be well hidden inside it's also in many cases there would be multiple implementations of some functions in different files and it can be quite difficult for an auditor even for an

experienced auditor to find out which one is actually going to be used in each situation so we demonstrated it here by deploying this decks which is uh more than 7000 lines of code most of this code of course is unused it was just uploaded as part of verification and inside it there's a there is one small bug well hidden let's look at it so this contract is ownable and it has a transfer ownership function there are multiple implementations that inherit from a inherit from owner from honorable and we see transfer ownership so the first two versions are fine the third

implementation is almost fine but it's missing them it's missing the only owner modifier which means that which means that basically anyone can take over this contract another form another form of attack is using a fake proxy so if your skin has this a nice feature where it recognizes standard proxies like EAP 1967 it recognizes transparent proxies and it shows you the implementation and it's common to rely on that now it's great for ux it's not so great for security because they have no way to detect to detect fake proxies so proxies

that seem to point to a legitimate implementation but actually in some situations or maybe always use a different implementation so it's going to show us the wrong implementation and here we see such a proxy it looks like a standard proxy but you can see that it you can see that it has the standard implementation slot but when you call the get implementation internally it's actually going to bring the implementation from a different slot and let's see what it looks like on on an etherscan so we deployed it and it is recognized as it's recognized as a standard proxy and we see the implementation address

oh actually so it's recognized as the it's recognized as a proxy we see the implementation address and Below you can see the code in this implementation address there's a function called check and it returns one but then if you look at the if you look above it you see that we call check and we actually got zero that's because the implementation that's being shown to us is not the implementation that's actually being used a more interesting version of this is what I call the non-proxy proxy it's um it's a contact that seems immutable and it seems immutable and you don't think of it as a proxy it can be some

elc20 token or something and it inherits from multiple contracts and each of these contracts can inherit from a couple more so you can have a very complex inheritance tree and somewhere deep inside this tree you can have a fallback function you can have a hidden fallback function that delegates to uh the delegates to some other address so effectively the entire contract becomes a proxy for unimplemented functions so anything that is outside the ABI will will try to delegate to that contract and at the time of deployment it can be well hidden because you because you can make it counterfactual so when you deploy it and when the code gets audited and evaluated

by users there is nothing in the delegated address which means that if you try to call something outside the ABI it's going to revert because that's what solidity does when you try to make a call to something with no code so it will revert but then later you can deploy the contract at any time you can anytime deploy it and add new functionality to the contract so what we're demonstrating here is an elc20 token and it has it it inherits from some contract and if you look at some contract you see that it has this small fallback function that delegates to a hardcoded address and there was nothing in this address at the time of deployment but later we

deploy something so if you look at the ABI on the left you see that there is no mint function because it's not a part of the API but if you decompile the if you decompile the new code you see that it has two new functions one of them being the mint function which allows us to Mint any number of tokens and that's what we did here so we demonstrated that we start from an address with no tokens and we call it manually because it can be done from the UI because it's not part of the API but you call Mint manually and now we have a lot of tokens which we can use to drain the to drain the liquidity pulling unit swap for that token

another interesting case is select all collisions so uh the way solidity encodes functions is by hashing them and using the front and using the first four bytes hashing the the function signature and using the first four bytes and four bytes is not a lot so it's easy to find a collision now when you have a collision between a proxy and an implementation the proxy will take precedence so it allows you to hide any function and I mean cover it with a different function and it doesn't have to be something that looks very suspicious it actually can look very harmless so we demonstrate it here by using uh but we have this simple Vault implementation it's a volt it has a it has a mapping of Vault managers and

functions for adding and removing managers which can only be called by the current managers so this contract is supposedly safe and here's a proxy to it and the proxy seems like a standard proxy except this smaller po function at the bottom called image URL so image URL is a pure function that returns two or it could return some string or whatever now an auditor might wonder uh why does this proxy have this pure function but most people wouldn't care about it too much because it's just you know pure function it doesn't touch the state it only returns to also how bad can it be well it turns out that it can be quite bad because it shows the first four bytes of the hash with default managers map a mapping getter which means that

now you're going to return to for any uh for anything you check in this mapping so here we have this we have a number of volt it's a volt that has a number that anyone can read but only managers should be able to change it and it's using this proxy vault and when we um and if we check it we see that any address is going to return to because of the image URL function so we were able to change the number from an address that is not supposed to be a manager so anyone can actually can actually act as a manager on this contact and another form of another form of such attacks is to have a hundred percent

legit code not mess with the code in any way but mess with the storage and a legitimate contract with the legitimate contact with bad storage with compromised storage is still a compromised storage so well so you can compromise the storage during initialization or if there is a delegate call somewhere in the code you can also do it later and when looking at the storage it's really hard to know Wilson it's really hard to know what this storage means because of the way mapping is uh is built in solidity so you see that there is something in some random slot you don't know what it is until it's actually used and I'm demonstrating it here using um using nosy safe so we haven't so we

deployed a safe and it's using the uh this safe is it's a agnosis safe proxy Factory so it uses the official Factory and we make a call to the official Factory and we use the official single tone the official implementation so all the code is uh is diagnosis safe code there is nothing efficient about the code itself and if we look at their UI we can see that it has one signer yeah so it has one signer and this signer is so this signer is supposed to be the only one that can transact in even scan we also we can also see that get own and get owners return only this address but below you can see a

different address and there are actually 20 20 more signers that are not visible but they return to when you call his owner that's because of the that's because the get owner uses a linked list but his owner actually uses a mapping so these users can actually transact and here we send a transaction from such uh from a such address and the transaction is successful if you look at ifscan you see that execution was successful even though it is signed by a different uh it's signed by a by a different address that should not be able to transact and our Owen is going to present an actual real life case okay so I'll dive right into it I have a

bit more than six minutes and I'll make it uh okay A bit of orientation uh chain swap was a cross-train bridge it was active in 2021 up to late 2021 and it was hacked twice in about a week and then we're talking today about the second hack first hack was 800k stolen and the second hack was 4.4 million dollars hacked and basically after the hack uh there were a few explainers that were published some talked about sloppy authentication checks some talks about some talked about uh something wrong in the increasing of the uh quota but basically they either got it wrong or didn't touch the the spot so let's find out why and we start with looking at the attackers transaction and

we see that the attacker's transaction in etherscan is basically interacting with uh chain swaps proxy which directs them to a verified contract now it doesn't show here but basically we find in we we managed to found an identical contract to this verified contract which was audited so it's not only verified but it's even audited and now we go to tenderly to see if uh if if the transaction behaves the same way and goes step by step but we see that eventually the hacker calls the receive function in the proxy uh in terms of proxy and but eventually it ends up in another uh contract right we see here a different address and the address when we go to etherscan we see

that this is an unverified contract and closed source so we see that something behaves differently from what etherscan shows us and basically what what happens there is that the hacker calls the proxy chainsaw proxy it calls another proxy which called which is called the factory contract he calls another contract which is called the factor implementation contract together with this string that we see here by the way this is the name of the verified contract so it's the same name but eventually it gets another address which is the address of the unverified contract and eventually the call is delegated to that contract so basically already here we see that there is incoherency between what etherscan

shows us and what actually happens on chain so let's dig it dig in a little bit deeper to understand the root cause so when we look at the verified code we see that receive function does a few authentication checks then called decreased auth quota which we've been naturally checks your quota and auth quota off is a mapping so naturally it defaults to zero and when you look at the code you see that only authenticated players can increase the quota so so far so good but again the transaction behaves differently and we saw it because you see a few different strings that do not appear in the in the source code so we looked for these strings and found them in another contract also used

by Chain swap and their auth quote of is no longer a mapping but now it's a function and we'll you could you look at the function you also see that see off quota Auto quota ratio and period which are those strings and all kinds of computations Divisions multiplications and so on but instead of of looking at at the code we just went Twitter scan and tried to query how much quota do we have how much does the attacker have and so on and basically you see here every address that you check has 10 in the power of 22 which is basically unlimited quota so everybody gets unlimited quota and this was the situation for for a week ever since the unverified contract was

deployed to the moment that it was hacked so to wrap this up uh basically what was supposed to happen was that the hacker calls the proxy contract which so which calls token mapped verified contract seems very legitimate but in practice this whole mess of calling the proxy which calls another proxy which calls the factory which Returns the address and eventually delegates to the closed Source contract uh so that's about it just to conclude so we presented a few techniques that confuses either Auditors or ether scan users about the code in etherscan and what really happens in in on chain and we've also seen a real-life vulnerability that was exploited and

ended up in 4.4 million dollars of loss and and eventually it's a cat and mouse game right there there will always be new techniques and new ways that hackers will be able to trick Auditors and and users so we must keep up that's it [Applause] thanks it's great great and interesting stuff I think a lot of questions guys please hands up foreign there I can see hello thank you for the talk can you

please iterate a bit more on how the grassy safe example worked with multiple signers yes so if you look at the code the the safe code uh the way it saves and it has a data structure that it uses for signers and for modules that is uh it seems to be like a linked list where it's actually stored in uh the addresses are are saved in a mapping but the map there is a link list pointing to this mapping so get signers get signers is going to get you whatever is linked in the linked list but of course when they actually check for a signer they don't need to go to Traverse a list they can do it in order of one they just check if

something is in the mapping so you can have things that are in the mapping but not but not in the linked list and even and by looking at the storage it's impossible to know what it means because the way solidity and the way solidity handles mapping is by uh doing a catch up hashing the base slot of the mapping and the and the key so if you look at a certain and Slot but it was written directly in assembly and it was not a Northwest mapping you are unable to to tell which mapping it is a part of what it actually means so you can describe a meaning to a meaning to this slot it's just some value that appears in some random slot so during initialization I created 20 such 20 search slots I could

also do it later by making some delegate caller from the safe and then you can have it you can add signals or modules and and it's impossible to know what they are until someone actually abuses it but this is a this will become irrelevant soon specifically for safe because they are working on removing all delegate call which is great all right thank you um hello and question I had two quick questions um one we explained that when there's some non-standard proxy then etherscan will go and ask like what this is the implementation and query that why

doesn't it just query The View function of this contract like I guess then then even if there's some non-student proxy you could get the actual result and the second question when you gave the Collision example it doesn't the on-chained source code would be different if then the code that was verified with the pure image URL function okay so for the first question uh it was um what was it again sorry sorry for interrupting we have a string schedule for today so Applause is for this various of the light side I think for this deaf Summit we are better protected

from this dark side people who find new methods do hack us one more time uplouses and guys let's meet our next speaker this is Alex manushkin product manager and blockchain researcher from starkware so he'll tell us about Unchained smart contract security great topic to discuss so look forward um display

your reply okay can you hear me great to be here thank you for the organizers a really really cool event didn't know that there would be so many fireworks for this so I'm Alex I'm a PM and researcher at Stockwell and today I'll be talking about building a secure starknet so when we are building a start nuts we are standing on the shoulders of giants it's not that we are so smart that we are thinking about it

ourselves the ecosystem has been up for a while there are many Lessons Learned uh in the in security and smart contract Security in particular but building a new system there is an opportunity to take some of the known Concepts and the resting them think about new approaches and that's that's exciting when you we are building a new system like this so today I'll be talking about the three pillars of starkness security as I see them validity proofs smart accounts and the Cairo the native language of starknet manual focus on Smart accounts and Cairo so just a brief overview overview

starting is a validity roll-up on top of ethereum that means that data is posted on L1 as status approve if submitted to the L1 verifier contract and once the verifier checks the proof then we know that everything is fine and the state is final and the execution was correct so that's the validity ropes and I will move to the next topics so a bit about user roles the users of our networks of of the blockchains that we are building so uh meet happy guy he's a new user to blockchain he just got into the space he watched some videos he wants to to make money and get

rich he opens a wallet gets some tokens and starts participating in defy and getting big bags with all with all the right meme coins one day he's been out on the in the lovely streets of Paris having fun drinking a bit and coming home and seeing this pop-up that tells him put your seat phrase here or your money is going to be lost which he digs out of the closet puts in there and the rest is that someone needs to come in save whatever is possible from his money and does anyone has any has this happened to you or do you know anyone who this

happened to raise your hand probably everybody okay so his bags got a little smaller but he's still he's still pretty happy and he's going to make it all back in one trade so he approves some years 20 on on uni swap maybe a while ago maybe he even forgot for forgets about it and then opens up a crypto Twitter with the cold sweat and starts remembering all the stuff that he needed to to approve and and now needs to revoke uh which probably also you know someone who this happened to so in enter native smart accounts so smart accounts or what is also known as

the account obstruction is the only way that you can interact with the starknet chain and there are many benefits to that non-subtraction fee abstraction but mainly here I'll talk about a signature abstractions and multicalls so signature abstractions is basically that we can write any code in Cairo in this case and verification of this code is the way in that to make a transaction and because it is a layer two it is much cheaper we can make some interesting use cases here we can make 2fa MFA that is built into the account we can make signatures with

a hardware signers also more ubiquitous Hardware wallets like iPhones which is also already live and and available on wallets that are operating on stagnet today like Argentine Bravos and of course you can change the private key key rotation and other stuff so definitely would have saved the happy guy from a lot of trouble if he would enable 2fa of course some additional signing besides his seed phrase another maybe an unpopular or maybe I don't know may not I don't see this discussed enough is the benefits of the multi-call so yeah this is how an interaction with usually looks like in D5 you approve

some erc20 to use your contract interact with the contract and if you are diligent enough you also remember to revoke it and of course this is bad ux this is a more expensive so users just will put an infinite approve probably forget about it and now even if you are diligent apparently there are scammers who are scamming the revokers so this is quite quite fun as well uh unlike the multi-call where everything is done in a single transaction of course it is cheaper it's better ux you only do one click but the real cool thing about it is because of the way that of the data availability on starting this is also

the cheaper way to interact with the network so in the state if data availability model you only post on L1 the changes to the state so if there's has been no change to the to the approve no change to to the state here because it was given used or revoked at the end of the transaction no state if so cheaper transaction is a safer transaction which is pretty cool um so why why are people still using your way it's not that smart contracts accounts were invented yesterday they've been around for a while on on ethereum on the and other avian chains as well uh probably the main reason

uh again there everything here that you you can't do with an eoa but what you can do is open on YouTube and see how do you interact with blockchain and see that you need to open metamask um so you say okay Alex you've been living under a rock 43 37 I think you have has been publishing is taking over the world and the problem with 4337 is not the default right it is an application layer specifically in ethereum you start using it you figure out that opening a new account is expensive you default to using the eoa and then

you use the same eoa across all the even the AVM chains that you're bridging to right the bridge knows this address you you know this address you know how to use it you just keep using the eoa um so uh 4337 is great and really hope that we as a community adopt it and start using it more [Music] just we need to think of a way to make it the only way to interact with the blockchain because that's how users will be forced to use it and rethink their their old patterns uh of course with with it being an applicative solution there are some interesting Concepts to think about um bundler nav who is building the bundles who is adding the bundles into

the block but that's a talk for another time bottom line native smart accounts makes darknet safer okay so we covered the users now let's talk about the developer woes so happy guy is finished his designing life he's now saying okay I'm gonna go heads down building the next D5 protocol and get reached by that and He is building a proxy also interesting a great talk before that on proxies um building a process so he can upgrade his account later and take some code maybe you can take a look and think what would happen to this code

later and this caused a 6 million a dollars lost in audios and the root cause is just because of how solidity Maps storage right there is based on slots and the first storage of the proxy is also the first storage slot of the implementation so if you are not thinking about it and not considering or leaving space or doing some some fancy stuff to to make sure there is no Collision there you might run into some issues like that another case which is also interesting so there is some some function here that either takes some East or take some

erc20 and uses it later in the code and this again was a hack in in open in this case and the root cause is this in in this example it was because there was some assumption about the message value that was used a few times while calling the function but I would say that another one another possible issue that that did not happen here is that there is a special treatment for eth and there is no um guarantee that this F if else is implemented everywhere in the code even if if did not require some special

treatment you would still make sure you need to make sure that there is a an if else for every special token that you are handling so a bit of an introduction to Cairo so Cairo is the the smart contract language of starknet if you have maybe seen Cairo before it has been a significantly revamped in the past few months and very much inspired by Cairo by rust both in syntax and the approaches to how it handles memory safety and type safety so Cairo is compiled to Sierras a safe intermediate representation there are

some great Talks by the guys who are developing it on YouTube that compiles to Cairo assembly and that's what actually runs on on starknet so there are some really great features in Cairo memory and type safety as I mentioned ownership of of storage and of data during the execution uh quite importantly a strict compiler right again very much in the in the spirit of rust when you are writing Cairo code now uh the the compiler will lead you through right it will pop up errors it's not going to be a smooth sailing which is what we want we want our compilers to to give guard rails as

much as possible to our developers who are Building Systems that should be handling money um a few examples from before just addressing I guess the the the cases shown in the example so it's a start net Cairo combination first in the in starknet the storage slots are a result of the hash of the name of the storage there can still be collisions but most likely if you define an admin variable you would still want it to be the admin variable after you do the upgrade right upgrades are still possible and bugs are still possible um but but it makes sense and in Cairo this is how storage definition looks

like it's very explicit there are explicit types that are followed by that are followed by the compiler in runtime and in compilation time and all the storage is defined in one place which is really nice for Auditors to to see there are no storage slots appearing and the second example here is is enums which is also a pretty cool tool um again starknet combination for this is that there is no special fee token the fee token is also a near C20 so no special treatment needed for for the message value and so it's all on your C20 again just

um not being Shackled to this has to work exactly like ethereum and the evm and the enums here are also really cool that even if you have several tokens that you need to handle once you add another variable here to the enum you will have to go over all of the code the compiler will shouted you that there is a case you are not handling in your in your switch case and you will have to address it everywhere in the code where there is a where the cinema is used so bottom line languages that we use for smart contracts and D5 should be safe which is what we're trying to do a short summary solidity is great it's really fun it's

really great to develop and it's also fun to learn all the all the quirks and features of solidity right and it's fun for the developer it's fun for the auditor that needs to find these bugs later and puts uh puts bread on the table and but uh Cairo in this case takes the opportunity to make a much safer language so this is different this is a new ecosystem it is growing we are of course bug will bugs will happen and it will be interesting to come here hopefully maybe next year and discuss edge cases and and cool bugs that were found in Cairo this is where

we need a community right this is a great opportunity to join and be the first to develop all these tools and all the good and best practices that are used to in solidity in the stocknet ecosystem as well so many Builders and tools are already there and great opportunity for you to join links to follow us and me and a link to the telegram security Community that's that I hope will kick-start from this session thank you [Applause] thanks for great speech and really

inspirable way to learn Cairo I am really interesting can check the documentation how to build on Cairo I think many of people as well and now it's time for a few questions I check timing so I can see hand here hi you're making an argument that account abstraction makes stocknet more safer for users and developers but AAA is pretty standard in these dating l2s as enshrined you know protocol level as well as L1 Solutions what what's the difference why does it make star net you

know more safer than anyone else okay yeah so the argument there is mostly that there is no fallback to the eoa right a lot of uh chains and l1s and twos that are trying to be compatible there are making a new UA an option because it's easier and easier to onboard more people that are already using it if there are chains that are already implementing it and making it the default and great if they are implementing a a hardware signing with iPhones great I mean this is the way to go one more question

okay if we have no question questions one two three okay thanks so much it was great great great explanation about Cairo thanks Alex and guys I'm so glad to announce our next speaker in this session please meet Harry mulakau co-founder of spear bit [Applause] thank you hello yeah so I want to start the talk right away but

um an infinite money collection ethereum so what if I told you uh there is a contract on ethereum that actually lets you deposit either in it and later on you can actually withdraw whatever you deposited sometimes you can withdraw more sometimes you can withdraw me less but at no point um and it's in its lifetime well the balance of this contract ever go down would you believe me um how many people think that this is impossible raise your hands seems like a lot of people think that um but turns out uh would you believe me more if I told

you there is 50 billion dollars in this contract right now um it has eight leading zeros and if you look at the um the contract on etherscan and see how it was deployed it was uh deployed using a tornado cash funded wallet and the person who wrote this contract is uh sitting here right now with us um anyone any guesses what is this contract yes it is the ethereum B contain contract so what is going on here so if you if I look at into the the either scan chart for um the balance and eat um of this contract it only ever goes up it never went down even though you can

actually withdraw from this um here's a different chart um this time from uh names and AI um you can see that the balance actually goes down at some point um uh around around April were the withdrawals was enabled um in the beacon chain so again what is going on here um so the withdrawals are actually processed on the the big contain rather than on the you know proof of work chain what sorry rather than on the execution chain from the contract and the big contain simply just like

gives you the Eid without really like changing the balance of this contract and this contract only stays as this like black hole which lets you like deposit it and run a validator um and you know nothing else really happens so here is like an infinite money glitch um you you deposit third to eat into this contract you run a validator for however long you want to and then you withdraw 32 eat and all of a sudden you just um increase the balance of the deposit control by 32 Eid without really like uh you know without out of nowhere I don't know how to profit from this but yeah there you go

so what why is this a big deal um it's interesting because calculating the total supply of heat is a very difficult problem in case of Bitcoin there's a very nice way to show that it can only be at most 21 million um but with ethereum it's not that easy there are contracts like there are accounts like 0x dead 0x0 which people use for burning eat would you actually consider the eat in these accounts to be part of the chain if you if you think about it from the protocol point of view you actually have to consider this to be part of you know part of Eid in the chain

um nothing is like truly burned if you just uh send something into like sortex dead um so if you try to compute the total amount of heat in in uh ethereum protocol so what you can do is uh at the beginning you can look at how much Eid was at the Genesis and then you can look at how much Eid was generated uh on minor Rewards um the eip1459 actually introduce the way to like properly burn eat for the first time in the protocol um this was e that you know unlike sending into like a valid uh like 0 x 0 or 0x dead you this is actually removed from the protocol uh this is either that

you spend on the base fee uh but then there was the big contain as well which introduced like more emissions um to the validators um and also like slashing tensile and and there was the merge which actually merged the proof of work chain and the the beacon chain um and this introduced this exception that the balance of the deposit contract only ever goes up you can never like make it go down so you can't really like look at every single account on ethereum and just like add up the balances because then you're double counting this uh uh the E that you withdraw from the beacon chain

um we can see so the moral of the story is tracking the supply of Eid is pretty hard you have to work around a lot of these exceptions um so yeah so what is this talk about um I want to talk about a lot of quirks in the evm I want to talk about some of the design mistakes I mean these are subjective things and some of the history behind it there is often a real reason where somebody thought some design was good at some point and then later figure out maybe it's not so good anymore I want to start with return data copy

it's a very important instruction in the evm this is what enables proper Dynamic data types in in solidity without this there's no Dynamic data types very very underrated instruction so let's think about what happens when there is an outer bonds access in an evm in general if you look at memory if you read from an offset that's beyond whatever is the current allocator memory which is you know M size you actually get zero um on an out of bounds axis in memory gives works as if you know there was nothing if you look at call data you know you

can do a call that uh copy of a region that's uh out of bounds for call data and it assumes as if there was nothing over there you would get values I mean you would get zeros the same would call that a lot if you read a call that a lot from something about call letter size you get zero however with redundant copy it's different if you actually try to read return data that's beyond your bounds you actually get a revert um how did we get here so turns out when the instruction was proposed in in the IP 211 the original proposal actually wanted to keep the semantics to be same as any other

instruction in evm that is if there is an auto bounce axis you treat it as if you were reading from zero however there was a suggestion by Nick Johnson from ens and he basically suggested oh this should never happen I mean a reading from out of bounds should be a reward anyway why don't we just reward and this was in turn implemented in the EIP um so the eif was implemented mainly because of the suggestion and and let's see what happened um because of this um turns out this was the cause of a bargain in the in the salty compiler

um I will try to explain what happened um so salty has an optimization step which allows you to remove unnecessary rights to memory so if you can figure out that there was a right to memory and you never read from this memory location you actually can't remove this right because uh you can save yes um but it's not that easy anymore with return to the copy you also have to check if the if there was an autobounce axis and any other instruction doesn't have to like you don't have to do this check for any other instructions and salty at some point did not do the stack and there was this optimizer bug where

you can remove the combiner can remove everything that a copy even though it might actually reward of course this um case is like very hard to happen in real life because in most cases the value of size here would be written at a size so where um a reward is actually impossible but I just wanted to give an one example of a bug caused by this exceptional Behavior and if you look at go ethereum as well curiously enough the return data copy and the return of the buffer is actually involved in a lot of evm bugs over there it's not really because of this exceptional case but still it's very

curious how this one instruction is the cause of a lot of bugs across the ecosystem the other thing I wanted to talk about is about transient storage so transient storage is an EIP that's you know currently in progress maybe Implement may actually happen in the next hard Fork but I just wanted to like talk about some Curious like edge cases here um so transient storage in short is it's like storage but only lasts across a transaction so before the transaction starts it's going to be also us and at the end of the transaction with the steroid any um we are gonna like zero it anyway like throw it off

um one common use case for this is re-entrancy logs um let's talk about let's talk about how re-entrancy logs are implemented today um so most of the time you just keep a variable in storage um you know let's say a Boolean called lock and at the beginning of a call you can just assign this lock to be true which means we actually lock it and at the end of the call you can uh just unlock it and before anything happens you can just say you can just check if it's already locked and if it's already locked you just reward and this actually prevents any any re-entrancy but this is actually not how it's implemented because of you know gas so instead of going from like zero to one

to zero you actually go from one to two to one and one one being like the the log sorry the unlock State and um when you when you initialize when you deploy the contract you start by initializing this variable to one this is because of like some um changes in like some issues with the glass refunds that make the second one uh more uh more optimal um in Practical cases but there is one um one foot gun here which is if you actually forget to unlock you have a contract that's now in deadlock you can you cannot use the contract anymore your contract is stuck

so how does a transient store help here so you can actually implement the same thing but with transient um using transient storage you can just set this log to True at the beginning to indicate a lock position and you can set it to false at the end of the call to unlock it um the same check as before everything is the same except that you work with transient storage however there is one peculiar case here which is if you actually forget to unlock there is actually no Deadlocks anymore so is this actually safer because you know there is no room for Deadlocks anymore let's think about it um which brings you to the question if

you don't even have to lock why do we have to waste Hunter gas to actually do the unlock right this brings us to like the question about safety versus chaos um there are a lot of uses uh probably sitting here right now who Skip payable in functions to save like 10 to 20 kiosks um these users may be tempted to actually like skip the unlock so what does this cause you can actually save 100 guys by you know saving download however this actually creates uh what could be called as a transitory deadlock where if you try to use the same the contract again

in the same transaction you you actually have a deadlock you know you can't use the same I mean you get a reward um and the strands in storage basically introduced this in a very intra transaction State and you know that probably like breaks some some sort of like mental models for you know both developers and you know everyone sitting here um so what is a better design for transient storage you know that can like fix this problem so one way to like fix this is you know instead of thinking about Trends in stories at a transactional level think about it at a call call uh level so at the beginning of a call you have a fresh set of transient storage and at the end

of the call everything gets cleared and in my opinion it's a better design because you you actually don't have to unlock by Design it's it's a very cleaner way to think about um this um and a lot of the invariants you think about can remain assays there is like no notion of intra transaction um you know Deadlocks um yeah that's it about uh transient storage and I want to do one last thing which is like a pet peeve of mine um if you do any like evm tooling this is like one thing that has probably like bit you uh at some point um it's about the it's about the order

of operations and shifts so almost every operations have a pretty common order which is you know if you look at division of X Y it's x divided by y however if you look into shifts um they actually have the opposite order if you do a shift of X Y you actually are doing you know y shifted by X why is that this is actually this was actually designed to save gas um how does that how does it actually save gas let's let's look into it so in solidity when you write an expression like you know F divided by G um most of the time what people expect is to evaluate it from left to right

um I'm talking about the side effects of the function not really like the operator precedence that's now of course would be um would be valid as in like any other other language but the the side effects you know fnz can have side effects most people expect it to have to happen before G however if you actually implement it this way it's actually less efficient because you need an extra swap instruction to put the arguments in the correct place in the stack for the division operation so shifts were actually designed to prevent this you know the well if we had to redesign evm all again you you probably can like you know like

swap though um order of every single instruction but you know shifts was particularly designed to prevent this you know one one issue this is like the only instruction with this you know opposite order um and if you have like built some kind of tooling this is something that you have encountered in the past now you have spent like hours trying to debug something only to realize that the order of operations were were the opposite says one other quirk [Music] um so what do you what do we like take away from all these things um designing the evm is very hard there are so many different users that you know there are people who build the compilers people who build tooling

people who build uh VMS like Criterium and you know other clients people who build uh tooling like Foundry uh people who write code people who want optimize code people who want like optimize for safety so having something designed for all of these people is very hard um yeah just think about it much more deeply before when you see a new proposal that's my only take away from this [Music] thank you thanks so much thanks so much I was deeply crying when you talk about this shift left I remember my hours of misunderstanding why thanks

so great great and inspirable talking about even we go into the roots of blockchain and I believe there are a lot of questions here to our great presenters so guys hands up foreign if you're doing that stack based system for the t-stores and stuff when it unwinds back up what if the lower level has set the same storage slot what happens I have to check the IP I don't know okay okay one more question here

just uh note if you sort of distract and send to yourself you can burn ethelium so maybe they should implement it yeah but it's still kind of is it really burn from the protocol is it I see yeah another another Edge case yeah nice any questions so uh I guess as we go further into the blockchain world right do you think uh evm will take Inspirations from something like introducing a heap and like uh like aslr or like you know more

security uh into like the VM design like how in the traditional World VMS have these so what are your thoughts yeah it's a good question I think one of the challenges the contract size so that really limits like the design a lot you can't you know you want to you still have to compile things down to like 24 kilobytes so you can't have too much uh too much on the evm it still has to be somewhat small maybe if we can restrict like some of the contract size issues um you could you know have complex constructs but yeah without that I think very complex constructs that require a lot of bytecode may not be like a good

idea yeah because then you have to think about the performance of the nodes you know there are some people expect every transaction to be executed in like a certain amount of like milliseconds and if you if you don't have this invariant then you know you either need like more you you either need to like increase the um you know compute requirements for a node which is very low right now for ethereum other other blockchains don't have this um so yeah that's one thing you know UVM was sort of designed so that anyone can run a node um so this invariant may be like may not actually hold true with more complex

things you know bigger by code sizes and all yeah perhaps one more question there yeah so about the out of other you know how to bond rate right I agree that it's bad to have inconsistent you know in that standard but what to do right uh you know if we suppose we are allowed to design another version do you think we should just maybe make it first make a consistent second should we just make it as exception I I don't feel like a rate Autobahn that gave you at zero it's it's a is a nice solution but you know really like two question what should we do and what will be the option

yeah I think consistency is very important um so if you're designing things from scratch like keeping inconsistent is very important like either either way um but I personally like the non-rewarding case um I think it's easier to analyze uh op codes if they don't have a lot of side effects and uh yeah that's what I think okay thank you guys thank you Harry Applause man to really great report about event as I can see now the two floors are full of people thank guys for your time it was really great session and before the

lunch we have a very significant announcement kindly ask you to keep two minutes on your seats and then we can go for a lunch thank you it was a great session thanks for organizers as well thank you just a quick quick announcement we wanted to do a special call out to where it is which is one of the bronze sponsors for DSS 2023 their name was accidentally left out in the keynote presentation this morning just happened to use a stale slide accidentally so yeah shout out to veritis verdis is uh blockchain security company building

tools and services in in this space using formal methods they do ZK Audits and we we have people from verities at DSS John Stevens who is not sure if he is here yet but he is up he's right there so feel free to reach out to him during lunch or after and he's also going to be on the formal verification panel tomorrow afternoon so yeah so that was the the quick quick announcement and yeah all of you have had a busy morning a lot of security stuff so now we are open for lunch lunch it's going to last for about an hour we'll hope to see you all back at 1 30 and we have a fantastic

you know series of uh sessions they're all panels in the afternoon so many many Fantastic speakers followed by Focus talks so please enjoy your lunch go get a big lunch and see you at 1 30. thank you [Applause] [Music] foreign [Music] [Music] [Music]

[Music] foreign [Music] [Music] foreign

[Music] [Music] thank you foreign [Music] [Music]

for those of you who are still here or maybe listening to this while you're having lunch so we have another announcement during lunch there are going to be interviews with the sponsors that is going to happen on this stage so you can either finish lunch and come back for some of the later ones or you can watch them on the screens that are downstairs so the first interview is going to get started right away thank you [Music] [Music]

okay but you can give thank you yeah they know

[Music] [Music] foreign [Music] [Music]

[Music] [Music] perfect perfect or when the next person is here all right well for anybody that is not hungry and not eating lunch and all the folks back home that are watching through the broadcast we're going to be conducting

some interviews of all the gold sponsors of defy security Summit so here first I'm going to be interviewing Justin my name is Isaiah Washington from coin fund and I'm blessed to be the uh the interviewer today so um Justin maybe you can you know start off by introducing yourself uh your firm what you guys do at Shell bits yeah sure thanks uh okay so my name is Justin Feist I'm the engineering director of the blockchain team at tread of Beats if you don't know us we are a security company where we specialize in high hand security technology we have expertise in blockchain cryptography abseconductive application and so on one thing that I think differs from like other companies is that we spend a lot of time trying to push the state of the art and the

research and we build a lot of tool as a wizard and auto to allow open source great awesome fantastic rundown of what you hope it's does thank you for that and um second question just to start off you know what um what is so special about D5 security Summit what made you guys you know decide to be a gold sponsor um and back the the steering committee putting together today's activities yeah that's a good question so we we believe that this is a good place to you know share and learn about like the update on the the five space on the security space uh there are not a lot of place where you can do that and this is one of the good ones so we are you know happy to to sponsor it and to help as much as we can awesome and were you guys also sponsors

last year uh to the the the inaugural uh I believe so awesome awesome great and um you know maybe we can just dig a little bit deeper into trail of bits um you know what tools the trail bits offer that increased code security you know how exactly does it work and you know where in the auditing process you know would one use um you know Trail bits as tools that's a good question um so I think our main kind of tools are slitter and Echidna so is a static analyzer it's going to look for common patreon in smart contract common vulnerability it has a track record of vulnerability found in a lot of protocols for example there was recently an independent academic Studios that

demonstrated as if people were using slitter they could have prevented something like 115 million of loss which is a lot and demonstrate that it's it's an effective tool the second primary tool that we are developing and using is called Echidna it's a smart contract further so we are using it to kind of check invariant on Smart contract and find logic bug it's a really powerful tool to you know go deeper and check my complex vulnerabilities very cool and is it is it protocol developers that are more so using your tools or is that Auditors that are using your tools you know on behalf of protocols that they're you know are smart contracts that they're auditing maybe you could tell me a little bit about that yeah it's actually both so thumbs up are something like Slither we have GitHub action for our developer where they can just connect uh

you know like the CI CD to to get to Slit your GitHub action and just laughing having it right on every pull request but we're also using it to engage it like on the first day we just want to Slit out you know check for common bags uh hopefully our client already won it before so you know there was nothing we have to catch with it but yeah it can happen for akina it's also both like we have some of some of our clients that are you know more mature in the space and have developed invariant and are using echina but we're also using it during our security overview anywhere so helping developer to develop their own variant and using in in the long term got it got it so here to hear everybody back home you know whether you're a protocol Dev or an auditor you

know looking to help protocols and projects building you can use the tools that trail of bits and and maybe you know with our last few minutes here you can talk just about the importance of you know tooling that tooling you know to our tools sorry and tooling that aids the uh the auditing process and it's the protocol development process you know when is it best to um to implement these strategies in uh the life cycle of developing a project true so for something like slitter you should just run it on every put request because it's going to you know answer and give you a result in like a few seconds so it's kind of low effort but something like Echidna it's really about you know kind of learning how to develop invariant and how to to do that

I do believe there is kind of a a need in the space to to shift like the Paradigm of development towards being more invariant focused and developing environment from the beginning this is really like a powerful mindset to have we have seen you know developer writing invariant even in plain English and then using akina to check them and the team that are doing that are always like in situations where they have a better security posture and better maturity just because they think about invariance so I do believe that in the future kind of getting into this invariant based development uh Paradigm of development is a powerful tool um I'm hoping like not to see more and more people adopting it absolutely no thank you so much and

kind of taking a step back here um you know to talk a little bit about you know your your view on the space what's important what do you think will be the most important D5 security developments adaptations over the next year yeah so the first thing is the one we kind of already a retention is to have like this environment-based you know development because you can test it with with tool but you can also add some of the inventions that you develop on Trend directly in your strategy smart contract to have you know additional uh you know Safeguard and capabilities there is also an overall maturity that needs to be developed in the space in a lot of different components you know how you develop your arithmetic how you develop your access control how you test how you do like your documentation and

something we actually released yesterday is our current maturity guideline that gives kind of some insight on to how to do that and those are guidelines that we have developed over the year based on you know all the discussion we have with the developer and all this kind of vulnerability we have seen and how to kind of fix them at their root cause and not to of them you know like in in the long term very interesting very interesting well thank you so much for your time really appreciate it I think we're going to transition to the next thing if anybody would like to talk to Justin I think he'll stick around yeah thank you thank you all right next I believe we have meddy from Sigma Prime joining me on the stage how's it going sir

good thanks how are you thanks for fantastic hey everyone all right so moving along maybe we can just start off with a couple words from you introduction on yourself your firm you know what you guys do what you do there happy too uh my name is midi co-founder and director of Sigma Prime we are a blockchain security firm who's been around for quite some time now about seven eight years we provide security assessments for our clients not security audits security assessments or Security reviews um I'll die on this hill any day um yeah we're very comfortable diving deeper into the stack so we obviously do a lot of smart contract security

assessments evm non-evm but we're able to dive deeper and help future l1's l2s you know cross-chain systems to hopefully ship better more secure software so we do a lot of code reviews on Rust go sometimes exotic languages as well and we're also quite well known for our fuzzy capability that's half of what we do that's the half that I look after and the other half is the development and maintenance of lighthouse lighthouse being the rust implementation of the ethereum consensus layer it's currently responsible for I believe just over 35 percent of the user market share

it's a big responsibility and yeah it's open source free and it will remain free and open source you have the commitment of the founding team we will not monetize lighthouse we rely on grants from the ethereum foundation but also a bunch of players in the space and uh yeah extremely proud of the great work that that team has been accomplishing over the past few years I would love to dig into a couple of things that you you um you know touched on there but first you made a point to express and emphasize not audits reviews can you dig a little bit deeper into that you know what is that sure sure so okay if you audit something you usually audit it

against a standard right so I think you know ISO 9001 quality management um ISO 2701 Information Security Management you have a set of Standards right a set of like a checklist effectively and you verify that whatever system you're trying to audit is complying against these guidelines we in this space in the web 3 security space we do not have those public standards yet there might be some initiatives running that will bring that to the table at some point but as of today I believe that calling them audits is yeah not really the right way to describe those assessments they are time

boxed assessments right the more time you give me the more time I'm likely to find bugs um so yeah I you know tend to I hope that everyone in my team refers to them in Security reviews security assessments but you know it's like back in the uh year 2000s when everyone started calling everything cyber security instead of information security um you know that battle has been lost and I think I've lost the battle with auditing now got it God that's super interesting and really interesting perspective um another thing you mentioned is that Lighthouse is going to remain open source what's the importance of open source security Tooling in the space so Lighthouse bingy a um a critical piece

of the ethereum ecosystem right now um it's extremely important to know that it'll remain free it'll remain open source despite the various attempts at potentially capturing the consensus layer and you know we've seen some of them over the past you know year or so and we expect to keep you know seeing seeing attempts at capturing the consensus layer and by capturing I mean you know corporations you know massive um organizations trying to have a say in how the consensus layer should work on ethereum we're a Grassroots team we've been involved with the ethereum foundation and the research space for over five years now and we do really have ethereum's best interest at heart

and um yeah whatever happens with Sigma Prime you know Lighthouse as a client will remain free and open source and I think it's extremely important to be able to give that sort of assurance to the community that's awesome good work thank you um so you know back to my my list of questions I went on a little tangent there sorry um what made you guys sponsor D5 security Summit great question I um attended last year's in Stanford and I remember being blown away by the quality of the talks and just the conversations that I was having with everyone it reminded me of what the ethereum security Community looked like in 2018 back in 2018 we all gathered

um in Berlin it was like 60 of us just kind of figuring things out or you like you know solidity smart contract security me too and back then it was like very few of us so it really had that same Vibe you know Grassroots Community we're here to learn we're here to teach and I remember after the last talk walking up to muli I mean like muli whatever you need next year will will be here so it was very natural for us to uh be uh be a sponsor of this great great initiative and I'm really hoping that we'll see a lot more of this in the coming years I'm excited about the virtual monthly I believe monthly virtual meetups which should be good um but yeah we need we need more of

these the device security space is you know crazy so being able to get together at least once a year and share our insights and knowledge is yeah incredibly valuable that's great yeah I thank you we all thank you on all of our our gold sponsors as well for for that sentiment um digging a little bit deeper into your thoughts about the space um you know perspective from Sigma Prime what is the perfect audit engage or assessment Engagement review engagement what does it look like so perfect for me or perfect for my clients because perfect for me is a report full of criticals and full of high severity bugs that's not

probably not you know let's say perfect from the clients well okay so you you want to conduct as much internal testing before you engage an external auditor and I don't think we we communicate this enough this is I think in my opinion very critical um so ideally a successful Security review from a client equals to a report that has you know very low severity bugs no criticals no high severity findings the auditing team has been you know able to navigate the code base very easily it's a lot of documentation a lot of comments in the code base you know diagram user flows

Etc all of this helps us understand your code better and as I said these exercises are time boxed so if you make us spend our time understanding your system you're effectively throwing some of your money out of the window right because you could just be explaining taking a day or two your developer is asking them to document the hell out of your code base and it'll make a huge difference so a successful sorry derailing a bit but a successful engagement for a client of ours is an engagement with there's no no surprises right there's been a lot of thorough internal due diligence applied already and our report doesn't really surface anything that they and anything critical that they weren't aware of um these don't don't necessarily happen

to often um unfortunately but hopefully more more of those in the future as the the space evolves and matures I think I think that's our time as URI is indicating to me over on the the side but thank you so much for joining thanks this has been great thank you cheers [Applause] all right I think we have another coming up I'm not sure exactly which it is but we'll get an introduction momentarily hello from lidoches from the shirt hey very excited to be here excited to

have you here with me on stage um we're talking to the folks that are not hungry and not eating lunch or have already eaten and all the folks back home uh looking into that camera in the back and the folks in the lunchroom I suppose um well maybe we can start off with just a quick introduction rundown of yourself in light out uh yeah Amazon I'm a core contributor at Lido well you may have heard of Leila we are in the LST Market we're like deleting a liquid sticking solution for ethereum we have about 15 billion in tvl um yeah we we are very excited to be here because security is Paramount to everything we do at title so yeah that's

great maybe we can explain it just a little bit to folks who may not be familiar with liquid staking derivatives are uh yeah liquid staking is like um uh it's a it's like a protocol layer over native ethereum uh staking so any anyone who has like um like not everyone can go into staking like you have to have 32 East right you have to maintain your own Hardware not everyone wants to do that so we offer like a like a small layer that we can like delegate your if whatever that may be like one is one half is to other node

operators so you don't have to manage your own Hardware yeah making it easier for all of us to be stakers yeah yeah making it easy yeah I'm a huge user of light on myself so yeah um well maybe we can jump into the the the the question I'm throwing at everybody um what made you guys decide to be sponsors for the device security system um yeah well lie Dome stands on the shoulders of ethereum and D5 so we thought this is going to be a great opportunity to give back to the community and um we like Lido understands the its role and the responsibility is like a is like a big player in the fight so elido wants to

share their best best practices share their knowledge um how we take we take security very seriously Atlanta so um I think it's a great opportunity to share our knowledge here yeah a great opportunity to dig into just like what that means right because um I think the perspective from Lido could be very different right from the perspective of trail of bits or Sigma Prime who have interviewed you know so far so what does it mean to really think about and focus on security from a protocol development standpoint you know day one or you know day and yeah yeah um I'm a technical guy so I can talk from that perspective so we have like a

whole process um starting from the like the design like the documents the spec the ADR what we call it like um the the the Lido Improvement proposal we we publish all these documents on our forums then we go through several rounds of reviews like internal reviews and also we we publish this on forums and gather feedback on the design and once that's settled we go into the implementation the actual code we write the code then we do another round of reviews like cross team reviews like not not all not even like not only developers participate in these reviews but

analytics too as well so yeah um then we submit our code to external audits um we gathered their feedback We Gather their findings findings and work on them and resubmit our code base for an re-audit so um once that's done we can we can deploy our contract yeah like the deploy process is also very strict We Gather like a deploy party what we call it it's like a three hour Zoom call we we gather as much people as we can we have like a first pilot the the person who was developing the contract and the second

pilot the person who's gonna be running all the like running the transaction yeah so um we again on this call we review the entire test suit the scripts the the smart contract code uh if if everything is okay we we run the transaction deploy the the code on mainnet and we verify that once again through like um different like internal tooling uh like we did the smart contract code from etherscan to GitHub yeah we even verify the byte code as well yeah so once that's approved we submit our like

address the contract address to our Auditors so that they can put the that address into the PDF and we can publish the the audit um yeah in our like a audit report so it's publicly available yeah uh that's like the entire like a deploy process of a smart contract it's a long process yeah yeah so it's not just write smart contract get audited yeah deploy it's a lot of work outside the the code the actual code yeah absolutely absolutely no very interesting um and the last question I'll throw your way is what do you think will be the most important developments for um D5 security

that will happen or that will take place in the next year or so um I think um uh we will see that um we we already see that the the the space is is getting more mature like the users don't jump at every like a D5 opportunity like they don't jump at every like 10 20 API they have to they they they they make their due diligence they do their diligence and uh we will that's why we will see like more projects prioritizing security and um like um so we will see the the security space

more competitive um among like some of the trends I would say that formal verification was going to be like big and also we would like to see like the off-chain security get a little more a little more attention like front ends um off-chain tooling like Bots we would like to like I think there's some room for improvement in terms of uh like security of those off-chain things so we would um likely to see some um some advancements in that area very interesting I think we're going to talk a little bit about formal verification next yeah okay thank you so much for your time and for joining me on the

stage thank you thank you [Applause] and next I believe we have mudits from polygon joining us how you doing sir doing great I guess I just did a little bit of introduction but maybe we could um you know I could turn it over to you to start off with just you know telling the folks here in person but also the folks back home uh listening and and paying attention to the stream an instruction of yourself your organization and um yeah what you do oh sure so I modded I lead security and smart contracts at polygon polygon

is a layer 2 scaling solution which is working on scaling ethereum blockchain we are building a lay to roll ups using the zero knowledge technology and proof of stake slash validium thank you so much could probably dig way more into that but explaining everything about polygon would be a big task and won't fit into a seven minute interview so I'll jump right into how did you get involved with D5 security Summit what pushed you and you know the organization to be a gold sponsor yeah for sure so I was there in the last year uh last year's conference at Stanford and it was just such nice like it was the signal to

noise ratio here is so great it's just like all technical folks uh very few of those uh like marketing folks I mean nothing against anyone but yeah like as long as it's like constructive talks it's fine but if you people people just keep selling their things then it gets boring and if you look at the uh like agenda here for the day for the conference you won't find a single talk which is like selling a product they're all technical detailed talks and that's why like we wanted to support this and from like I pushed for it polygon saw the opportunity here and we decided to sponsor well thank you for that and couldn't agree more and one of my favorite signal to noise ratio

conferences that I've been to over the last couple years last year and this year so far um and you know it's interesting to get your perspective because you're the only um layer oh scalability protocol that we have you know on this interview session right and that is a gold sponsor so you know from a large protocol's perspective you know what are the most important security considerations to you I'll ask about the large protocol perspective but then also just a large organization perspective yeah for sure so both for large protocol and large organization perspective that are like two broad areas for security one is like the

organized organizational bit which is basically your I.T security like phishing awareness training for everyone Key Management training and things like that so that's a very big chunk and the other chunk is actual uh like technology security so appsec security making sure the product you are building is technologically sound and secure and that we do by like um audit internal audits bug bounties and things like that what what what type of intersection is there between what some would you know traditionally call you know web 2 cyber security and web 3 cyber security as it exists you know in your organization yeah for sure

so web3 cyber security is actually just a superset of web2 so what you have to do in web 2 everything you have to do in web3 still and more some protocols forget this um and like they forget the basics they forget to do their key management practices and things like that and then get tricked but web3 actually you you can't forget the web 2 parts you have to do them and web3 security these specific bits also translate very nicely like in web 2 you know you have to keep your password secure for example from a user's perspective in web3 the same knowledge translates into keeping your mnemonic safe so instead of like trying to teach

everyone a mnemonic keep it safe like we could just tell them hey mnemonic equals to password then it automatically hits like yeah they have to keep it safe very interesting very interesting and what is a skill how many folks are on the security team at polygon is it yeah we are about 15 people got it got it and what does that organization look like because I I imagine and well I know very few organizations on web3 have a security team that big or that scaled so you know what does that look like yeah for sure like polygon at polygon security is a main focus and you can see by uh like it's very visible we are the only ones uh like sponsoring at events

like this uh we have uh by far the biggest security team in terms of protocols half of our team is focused towards organizational security so making sure like our users are educated uh key management practices are Discord telegram Twitter or secure all of those things I.T security and things like that and the other half is working on just regular web 3 appsec security so they make sure like the software we are writing is following the best practices and is secure so this marriage of web 2 and web3 security just you know keeps running through it which I think is you know one of the most important things you know personally right in in kind of like maturing the web3 style you know

all together is consideration all around really interesting thank you for the the insights and what do you think is the most important security consideration or will be the most important security consideration for the next year okay that's a very interesting question in the next year I honestly feel like uh we need to focus a little more on the web to side of security uh because uh that's something which is being attacked quite heavily by uh big actors like big state-sponsored actors the thing is like they are expert like if we talk about dprk and like actors like these they are expert in exploiting

web to vulnerabilities but they are still very very very new in web3 so the web3 exploits are obviously like you you need to be secure From web3 perspective as well but there are more people attacking web 2 than web 3 right now so you've got a focus on that um accordingly absolutely super interesting I think uh that's that's time with it thank you so much for joining me on on stage and great to meet you thanks for having me [Applause] all right we have our next interviewee coming up to the stage right now I'll stay standing hello sir Curtis great to meet you

all right well maybe we could uh just start off with a introduction to so I I've been saying this we're not only talking to the folks that you know four went their their lunch to listen to these interviews but also the folks in the food room downstairs that are look are looking at the live stream and also all the folks at home that weren't able to make it to uh security cement so maybe you could start off just by introducing yourself telling us a little bit about who you are what you do the firm that you're representing today yeah um I'm Curtis Spencer I'm the co-founder of electric capital I think we're the the fund on the sponsors list um we're a crypto Focus Venture firm been operating since 2018. we're a little bit different from a traditional

Venture firm we're more engineer-led so we write a lot of code do a lot of Open Source projects um you know I think it's interesting when you look at people coming into the crypto space a fund that has an engineering team is kind of an interesting gateway drug like lets people come into the space from a different vantage point from joining a protocol directly and then get to see like how a lot of different Protocols are built uh we also do a lot of data driven reports so maybe some of you have seen things like the developer report we index you know all of GitHub looking for developer Trends Etc Levering the developer apart oh thanks by the way um great well thank you for that that introduction overview of electric super interesting and how did you and electric

get involved with D5 security Summit why did you choose to be a sponsor of D5 security Summit yeah it's a good question so we've been investing across the security landscape a decent amount so sartora munify um and I remember discussing with muli um back you know before the DSs existed hey this would be great if we had a purpose-built conference where it was really just talking about security because when you look at the rest of the conference circuit landscape like we think nfts get a lot of coverage cryptography has decent coverage Mev consensus layers like all this stuff had had a venue but security did not have a purpose-built conference and we thought that needed to change it's sort of like

the last Bastion it's it's like probably the hardest thing and it was kind of weird that there wasn't like a dedicated conference for it so we did it along Stanford blockchain last time and you know the feedback was great and so just want to extend end it you know take it worldwide so cool I mean so I came from investing in web 2 security and there's RSA there's a million security conferences but they're you know when I joined coin fund nothing you know specific to security you know two years ago but now we have DSS we have you know securitum or trust Stacks securiums conference which is really cool and I think a few more so thank you for for you know making that happen of course with muli um so these are a couple questions I came

up on my own but um what do you see as you know because you're the only investor we have uh on on the this Circuit of a group of interviewers or interviewees what do you see as the largest opportunities in in security uh investing today you know the largest unsolved problems in web 3 security yeah I mean first off I agree with mudit that web 2 security is still a huge problem and like the intersection of web 2 and web 3 sort of like front ends getting hacked like we think there's a lot of opportunity there so like building special purpose firewalls or special purpose security to like you know secure defy at the edges I think that's a very interesting opportunity

set um you know I think one thing is just like defy education in general like no no offense to anyone in this room but I think defy security folks tend to be kind of wizards like it's like a dark art that they like are protecting and I think we need to flip that to be more like hey this is a normal thing every engineer in the world should learn this stuff kind of like writing a react app like that's pretty easy to do now so I think we need to like increase the tooling support so yeah I think things like formal verification demystifying that is a huge opportunity set fuzz testing like all these things that um you know traditional Engineers sort of have gotten there with unit testing I think we need to make it really easy to

use for all defy Engineers really interesting and this might be an extension or a follow-on to that question but you know if that's what's needed what gets you most excited what gets your gears turning in the security space I mean tooling just improving across the board like you compare writing a smart contract in 2017 to now it's just so much easier right so that's exciting just seeing that trend line like more and more people writing code that's always great to see um I think the education set like we're seeing like pretty great YouTube series now like on how to write smart contracts I think we just need to amplify that by 10x sort of like you see with like traditional JavaScript right like there's thousands of tutorials out there and I think we just need to increase it

and then I think the last thing is just standardization like there's no real like place to see hey this contract has these audits at this time stamp um it's still kind of a lost skill to like go and figure out like which audit applied to which version and so I think it scares both like institutional investors and consumers away because they're like well like how secure is this contract have no way of knowing yeah what do you think about you know kind of like um defensive security which I like to call kind of like the monitoring side of things uh everything I like doesn't I guess it's post deployment post deployment security yeah I think this is going to get very exciting especially

with AI because you can like scale the monitoring up and you know AI is not going to be perfect but if you have eyes on something all the time I'm excited about the AI panel later just to go into this more because you know leading that right I am yeah fantastic so you know I think monitoring in general the challenge with it is if it has too many like false positives people start to ignore it and that's the risk with any of these monitoring systems and so just you have to be really good such that everyone if they get a notification from the monitoring system it's really like important to look into because if people ignore that push notification because they get too many of them then it's like kind of a useless tool yeah totally well thank you so much I think we're we're just about at time

um Chris I really appreciate your time and being able to share your insights with uh the rest of the group here thank you for the good questions absolutely [Applause] all right I think we're down to our last interviewee here and I'm super excited to interview Sophia from sertora but I'll let her introduce herself as well how's it going doing well thank you for joining me um one of them hello great well I think you've heard the Spiel but we're not only talking to the folks here in the room but um also through that camera so the folks in the

food room and all the people that are Tuning In from from home so again thank you for joining me on stage Sophia inviting me maybe we can just start off with an introduction of yourself what you do sartora which you guys do and we'll take it from there so I'm Sophie I'm bidi I'm doing video at sartora joined last year previously I've been working for open sepuly another auditing company so I've been in the security smart contract security space for quite some time now um sir Torres leading security provider so yeah securing the protocols protocols code fantastic

um and I think so Torah you guys were the initial sponsor of DSs right yes yes fantastic so you guys you know are kind of the uh the the creators yes Curtis and Electric Capital right yeah but we are all together in this so absolutely thank you for all the other sponsors that helped these happen cool and and what um what brought DSS to be you know what I guess is a little bit different than the why you a sponsor question but yeah um I mean as I was saying we are a security company we were with top D5 protocols so it makes a lot of sense for us to be doing this organizing this um this is a great opportunity to talk to the protocols that they care about

security understand their pain points their concerns and uh of course like trying to figure out like how to help them and also you have all these amazing auditing firms security firms that um some of them they um use our technology so this is a great time and space to share our knowledge but also get feedback learn from each other and yeah and last but not least uh also to engage with security researchers that are freelancing out there that are also amazing um we give them the tool that we develop when they participate in this audit

contest platforms so we want them to get rewarded for that so also it's a great opportunity to talk to them totally and touched on it but maybe we could just dig deeper on it just to you know make it clear who exactly uses sartora's tools from you know you mentioned researchers but what's the the whole Gambit who do you sell to so we developed this technology for the ones that don't know like to apply formal verification to Smart contracts so I would say everyone can use it from like auditing firms that they want to provide these Services the security researchers that are freelancing as I was saying and the

protocols like this the prover like can be used from the like different from a noted it doesn't come at the end you can start writing your rules from the beginning when you start writing your code so definitely something that uh it's interesting for the protocols got it got it I think our sponsor from li-fi or not Wi-Fi sorry Lido also mentioned um formal verification and the you know his excitement towards or um you know informal verification maybe you can talk a little bit more about why formification is different why it's important you know why it needs to be used and considered when securing smart contracts so

um as everyone knows nothing is bulletproof so you have to do like as much as you can or you can afford like in terms of money but also time to make your code secure um formal verification is or at least like the tool we develop it's as I was saying it's really good because you can start from the beginning and also you can integrate it with your CI so every code change you make it runs automatically so we've seen like so many hacks after like small changes so you can see it as a fast automated audit definitely you should do more stuff but um but yeah

that's that's good about formal verification and also not only it's really important for bot to find bugs but also like proving these properties that's part of like formal verification that's got it got it and why is formal verification so important in web 3 you know where we're securing these assets as opposed to maybe you know some of the security practices used um in in web 2 software development so formal verification is pretty complex um I think it makes total sense for like blockchain because it's not um that along the code but it holds a lot of money so definitely you want to to prove mathematically that these

properties hold and these like uh their coding behaves as intended so got it got it very insightful and last question um what are you most excited about what do you think is going to be the the most impactful D5 security development in the next year that's that's a good question um I would say like with the device Mark contracts getting more and more complex I think the security efforts will have to become more holistic so I don't think is there's going to be like a new thing that is going to deprecate all the other stuff or tools I think

um the next like D5 successful protocol we have to to um manual reviews testing fussing formal verification um yeah totally I think we have a theme economic risk assessment as well 100 it's layered approach holistic security merger of web 2 web 3 you've heard it all today with all the uh the interviews well that's our time Sophie thank you so much really appreciate you joining me on stage oh thanks for inviting me and thank you for being a sponsor of D5 security Summit good to be here and everyone I think that concludes our interviews of all of our gold sponsors for defense security Summit so thank you

for having me Isaiah investor and researcher at coinfund and hope to meet you all and see you all throughout the conference [Applause] no yeah

foreign foreign

foreign foreign

[Music] foreign [Music] [Music]

thank you [Music] [Music] thank you [Music] [Music]

[Music] and everything startups foreign [Music] thank you

[Music] foreign [Music]

foreign [Music]

foreign [Music]

[Music] testing testing all right let's get this started hopefully lunch was delicious and people are well fed and ready for an intense AI panel here um so first off uh it'd be great if everyone could give a quick intro of who they are what they're working on and maybe a brief summary of how they're using AI today in their product I'll start with Chris

test hey okay thank you my name is Chris Hart I'm the CEO at Civic Technologies Civic we've been actually in the crypto space since about 2015 working on blockchain-based identity structures and so when I say that we do everything in the identity space from identity verification we'll do document verification we'll do things like IP screens we also then do things that I think are particularly relevant to this discussion today around AI so we do a proof of liveness that can be used for things like civil protection bot protection Etc we also do things like

uniqueness so uniqueness I think is particularly relevant for this AI talk on the one hand identifying who is human I.E proof of personhood and at the same time identifying who is not human you know what kind of output is generated from bot so we work in a multi-chain wallet agnostic way we adhere to things like the w3c standards for decentralized identity we're a very uh I think broad-based play in terms of we're on multiple blockchains and we're really interested I think in the emergence of AI how identity can play a role I think identity is now sort of embedded into

the crypto ecosystem but it needs to get embedded into the AI ecosystem as well so that's me amazing thank you so I am Lucas Martin Calderon founder and CEO of fantastify and I'm also building the co-founder of web freesect.news I blocked in security newsletter probably you've heard of it um and what we do at pentacify is we focus on post-deployment security so we automatically detect smart contract vulnerabilities uh directly from the byte code once it's deployed we came however as a company as a firm we were an ethical hacking company at first we automated that process using AI so we were able to ethically pen test

clients create their report have that develop that AI intuition to know which tools to use and that is exactly what for the past couple of years to three years we've been researching at the firm and getting that software done which you will hopefully enjoy using great uh I'm Joe Van Loon CEO of auditware so we're building audit wizard which is an all-in-one smart contract auditing platform it's basically like an IDE with everything that an auditor auditor could want and things you don't even know that you do want so uh the way we use AI is uh you know we

have a whole lot of tools that you can use to analyze code to manage your workflow to do threat modeling we integrate AI into all of that to help you kind of write your reports to reason about the code to do threat modeling to help you write proof of Concepts so we're really focused on the aspects of AI that are not just you know trying to use AI to find vulnerabilities or to do audit work for you but how they can sort of Empower you as an auditor focusing on the things that AI is actually good at and then using other tools for things that it's not so good at hello my name is Lee from d23e decentralized

intelligence I'm a co-founder there so our goal is to build the next generation of intrusion detection and prevention systems we are interested in how AI can enhance these tools so two of two of our most recent research papers and one is on how effective auditing is and the other one is using large language model to detect malicious transactions great thanks for the background guys um so I think everyone kind of experienced like the chat gbt moment this year where you know I think underneath the surface a lot of people have been working on AI tools for years but this kind of brought it to the

Forefront did this change like anything about your guys processes like when chat gbt came out where you're like oh we have to go back to the drawing board or was it you know business as usual uh I'll say for us that uh we kind of when chat gbt came out uh it wasn't originally kind of a focus for us necessarily and it's something we kind of tried out of uh what if we kind of put this in our platform see what it can do uh and what is good at and and where it can kind of streamline things and we saw that there was um there's actually a lot of things that it that it is good at there's definitely some things it's not good at like if you just give it a contract and say audit

this for me it's easy to kind of discount it and say like oh that's not really all that that useful but when you like break down to the the core components of you know when you're doing your own audit work what what can it be useful for and I think uh looking at kind of developers and how they're leveraging it too um you know using it to as they code just write boilerplate we were thinking of well what's the boilerplate for for Auditors and where can we sort of streamline things and have that same empowerment for Auditors just like you know how developers are using it foreign was actually quite important as well to

see uh kind of what the focal point of the llms were so every single AI of course has a huge bias and sometimes actually quite difficult to predict uh what that focal point is because it convinces you that that answer is the right one instead of giving other Alternatives in other sense detecting the tunnel vision of the of the models that make up tatibility was actually fundamental to not only verify and reinforce the models that we were already using to make sure that nothing was overlapping and if it was overlapping of course to to check the quality and how much Assurance how much

clashing there was but the speaking of the focal point and tunnel vision of the AI it actually gives you Clues to where the security flaws where the security vulnerability are going to be in the future because uh definitely there might be Auditors in the space that use that tool to either check it or or enhance their work and once you Fable you've been able to identify what that tunnel vision is it is extremely easy to modify the parameters of the AI models that you currently use to specifically look for vulnerabilities in this space because something that you might have taken for

granted using gbt or what the code that he normally produces in fact it is easily vulnerable if again if you find that focal point that it was trained on yeah I think from uh our perspective it was kind of a watershed moment in a couple of ways um I think it's not unusual for technology to come on as AI has slowly slowly and then seemingly very quickly even if for many years the technology has been under development but what it did do was I think demonstrate a real shift in the Zeitgeist of how people are thinking about the possibilities of AI and in particular AI agent so there was

a period of time where you know Chachi PT was clocking something like a 50 IQ now it's up at like 150 we started to see things emerge like the Tom Cruise deep fake and started to understand that there was going to be tooling that would be able to spoof an identity and then suddenly there came this llm model and people were fascinated and I think started to dive in as I did and I'm sure everybody did to test it and it was you eerily good and I think that created questions in people's minds pretty quickly at first it was fascinating and amazing and then you reach this moment you're like wait a minute if faces can be spoofed if voices can be spoofed if

llm models can get access to real-time data on the internet and you put all of that stuff together what is going to happen in terms of online information and online disinformation so from an identity perspective this has been a really interesting time to live through I think we're just at the beginning of it there is going to be a need I think to regulate and put guard rails around some of this stuff it's very exciting I think people are in equal parts excited and terrified and probably you know some of that is is Justified on both sides I agree 100 on that did you did you have anything to add to yep so um for us I mean the first thing that changed for my

for myself is I changed my bio from security researcher to prompt engineer um but as a company right I feel um um this thing has definitely a great potential for the future but there's also a lot of problems I find we do not thoroughly understand how effective and what's the cost um I think mainly because we are lacking like a very thorough Benchmark no matter is for auditing or it's for like um finding abnormal behaviors in real time using natural models so I feel like we are still quite far away from thoroughly evaluating all the LMS and

also understanding the cost and the limitations well given this to the technical audience can I have a show of hands of who's actually played with cha gbt all right that's great that's awesome what about uh like open source llms all right wow still still a lot of people I'm curious if you guys have like any tactical advice kind of like in the weeds of like what does your AI stack look like like you're using chat gbt are you building your own open source llms like just as you know some tool tools for the trade for people in the audience you know uh for to to the extent that I can that I can serve for sure it's uh the the most important thing with llms

is if they use the Transformer network is actually where their attention is what is that model tailored to look for attention uh generally it starts with the embeddings so an embedding uh it is simply a vectorized form of a token a word it really depends on how the AI model is is designed and from that you actually start the probabilistic and statistical process of what comes next uh the the main problem with chat TBT which is not a problem in itself is simply what has it been tailored to it is to predict uh what has worked actually in the past

according to academic papers books and so on so by taking open source llms whether it's metas llms or whether it's you get it from hugging phase that they have been crushing it lately you have from the very beginning to tailor it to be to get the attention for vulnerabilities um so that's kind of the first thing uh the the other thing that all the as opposed to static analyzers Dynamic and so on which treat data most of the time are sequential data or function locally function based you're able to think this time in terms of graphs which means that

it is not only locally to the function it doesn't only apply locally to the function via tension so to say but you're also going to Traverse through the graph through functions and actually that's when you're auditing manually auditing a smart contract you also have to think in terms of all right how does that function play spatially into the whole smart contract which from which can I take it from behind and get into that function you know a way that hasn't been thought before by treating data sequentially one of the main issues that you tend to get is is that special Vision within the uh within the uh across all the functions or even across smart contracts by themselves so uh if

if the attention again from these embeddings were were successful the graphs are going to be that whole graph is going to be and focus uh much better on the vulnerability at hand even vulnerabilities that have not been found beforehand and then beyond that stack of course we we tend to think that it stops there but there is a whole Research into into our drls which is uh deep reinforcement model agents right and well I could talk more about that later with pleasure but it's uh that would be kind of the right open source way to uh to to compete against tools that do an amazing job but introduce

that new category right without clashing or without adding anything new so I would say that is kind of the the the best way to play from from this from the scrunch uh with uh with llms oh thanks great answer um so for us we are using primarily chat GPT the 32k API and also the clouding API so what we found in our research is the token lens really matters a lot when you are finding vulnerabilities so a lot of the open source models they do not offer very big token Nets yet so that's one of the I would say deciding factor

on on picking which model to use for for either vulnerability detection or detecting abnormal transactions and I agree with what Luca said especially for like transaction choices it's following a tree structure right so the current large natural models they they take a sequence of tokens as an input so so that's also something we still need to work on in the future have you experimented with token compression or do you is the 32k limit good enough for what you're doing um so I haven't tried token compression but what we do understand at the moment is based on our evaluation a longer

token can lead to Greater hit rate and also lower false positive rights in finding vulnerabilities I I think it's hard to do token compression when you're thinking about security because you you necessarily lose some information when you compress it um and it's already hard enough to get the AI to focus on exactly everything that's there so you you'll lose some context and if you if you compress something that that's kind of where the vulnerability was but you trim that out then you know you kind of you kind of lose what you're what you're getting after um so for for us uh we also use chat GPT and I I think the great thing about

AI as a builder is how quickly you can produce a product uh literally you just need to design a prompt and there's I don't know 30 lines of code you need to write and you have a functioning product but it's definitely one of those things where you can build it quickly and then iterate on it forever so I I really like the the aspect of AI where you know you can start with something basic like an llm but you know as these guys have said that only has like a superficial context so really the challenge then is okay I have my product that I've shipped quickly how can I how can I make it better how can I make it more precise and let it go deeper so you start looking at uh how can I like

vectorize my my data and provide it like what functions can I can I plug in to kind of add some of the things that the AI model is missing and then you know train your your model on a graph rather than the uh just the the language itself so you can get deeper results like you can go further and further um you know refining it as you go so I think starting at the the basics of just using llm figure out how to use that most effectively and then pivot from there to something more complex I think is the way I would go about it so do you envision like a hybrid system where you like you start with chat GPT and then if you need to specialize you pull something off the shelf from the open source world and then extended that

or is there a way to just keep iterating with chat gbt yeah pretty much I I mean you can fine tune it but at the end of the day the way Chad GPT works is an llm right and you do need to look at the control flow you need to you need to give the larger context of how the code itself is working not just the text of the code which an llm is never going to be able to fully comprehend so you do have to do something custom with some open source tools um you know to to access the the control control flow graph and everything got it Chris what about you guys yeah um so we're coming at it I think much more from a framework of how do we help

attribute identity to either humans to prove that you're not an AI bot or an AI agent or on the flip side um to try and generate callbacks that basically can be read on chain where there's an identity token associated with a wallet that can be read by a smart contract that then enables AI agents as they're accessing smart contracts to be identified in real time so where could this be useful for example if you take a social net social network like Twitter we've seen a lot of problems with Bots posting and in particular I don't know if you guys

followed it there was a pretty big uproar over the course of the last month where there was a bot who was posing as a very political polarizing figure on Twitter she was posting a lot of inflammatory rhetoric on The Social Network this created a news cycle it inflamed tension to inflamed passions and so I think when we're talking about objective driven AI llm models where it's very easy as these guys have pointed out to go pick up you know the Chachi PT interface to create a graph to create your prompt with minimal coding expertise you can very very quickly

stand up something that's incredibly impactful and robust and as long as those things are being used for good all good but unfortunately I think we all know you know you guys are from the crypto ecosystem how many mints have you participated in where a bot came in and swept the mint how many Dows have you had interactions with where a civil attack was attempted to try and drain you know Dow funds so we really are thinking more about less about how to integrate the llm models and work directly with those models and rather how can we attribute identity to those things and if you take that social media

example that I gave it would not be very hard to solve for this right so you could have a two path entry in into something like a blue sky or a threat or whatever to try and do verification you could say look we're going to allow a certain amount of vetted known AI agents to come in and participate in the ecosystem and you drag and drop that construct into defy you know lending real world assets any of these things and then second we're going to make sure everything else coming in is a real person and so I think you know at Civic what we're thinking about a lot is that proof of personhood and then also that proof of AI for for lack of a better

term right now yeah you touched on something really interesting where I think we're in this world now where it's like Bots are usually bad and humans are usually good and there's probably a world where that flips where like Bots are people too and do you think that requires us to like design protocols in a different way we're just like if the bot's doing good work on the platform maybe you just encourage it and they do get to participate in airdrops well I'll say quickly um I think provenance is is really important and being able to attribute ownership back to these things is essential because I think you're dead right um at some point in time and and I think people will be shocked how fast this happens you're going to have an AI agent

operating on your behalf and you know it's it's Jarvis from the Marvel movies however you want to think about it it's going to be out there doing things for you you know booking tickets making sure bills get paid making sure that you know whatever news delivery service you have is coming through like whatever the things are and there'll be a whole host of things that these agents are doing they're going to need to interact in the real world on your behalf and you want that you should want that that is a future that I think we all know is coming and it's actually not that far away maybe not months but certainly years and so I think it does change the way that the interaction with the protocol level is going to actually need

to materialize and this is you know I know we're we're going to talk a little bit about the marriage of AI and crypto but to me this is where it gets really interesting because distrib distributed Ledger technology by its very nature is good at some things it's terrible for other things okay I think we know that but DLT I think and generally blockchain identity attestations have a few advantages it's distributed there is no sort of one Arbiter or owner of the identities on chain if I've gone through and proved I am who I say I am with a passport and there's an on-chain attestation that's privacy preserving and then I want to delegate that attestation to my AI agent so that it

can operate on my behalf then I should be able to do that and smart contracts that are gaining access to these things should be able to read that so I think it is foundational um it's actually very fortuitous in my mind that DLT and crypto has made as much progress as it has at this time when we have a really good use case with AI and in particular identity and AI I think is going to be crucial to get right yeah 100 um yeah we have a saying internally that like AI is like offensive technology and crypto is defensive and sort of like you need the marriage of those two um and this touches on what you're hinting at earlier is like regulation and so we have like government

regulation but then also potential crypto regulation like how how can we use crypto to regulate defy agents so there's a an EIP like 7265 around circuit breakers how do you all think like circuit breakers will manifest with AI like once you get an AI agent going like how do how do we shut it down if it if it goes Road you know I think uh the the EIP the the newest one they recently proposed um that already happened I think a good framework to know how can these things work out at the end is looking at has what has worked in web 2 because at the end of the day it's just gonna be a similar wave in terms of movements in terms of how things

settle down and and so on so with uh I do agree that but whether it is something that we want or not uh there is something extremely important called attribution being able to Watermark um what comes from from an AI and what doesn't being able to to hold hostage one AI which in return it's able to hold hostage the users in some very limited scenarios in banks for example that already happened where AI can have the last call those are AIS that have been audited every single line but it wouldn't be a New Concept that an AI can actually take last minute decisions and

with with this new proposal actually they're very the objective of that proposal is for people at the end of the day to trust D5 more so that means you're not able to get a rock pool and lose all your funds but rather when there is a bridge that whole breach happens way slower that what would happen in in around a couple of hours and you would be able to either take notice fix the problem in the meantime but of course you don't have the right to choose and to to choose to get your funds which is something that I do understand people are against however it Still Remains the fact that everything will be readable online and

you will know exactly what that AI or circuit breaker or whatever implementation they decide to pull you will know what the consequences of that are again it is still open and the uh the objective of it is once there is trust enough trust to bootstrap that defy application or that bank um to slowly take that circuit breaker off um that's already worked extremely well in finance it happened once in a line time in the NASDAQ that that Circle bracket was activated and actually saved uh a lot of companies billions of dollars so I do think even though it takes Freedom out of the user maybe that user would have less Freedom with

um without the Voting Rights the tokens or whatever is right at that time so uh so I see that generally as a good implementation to begin the trust as long as it is of course readable everyone can know exactly and predict how it's going to work and there is and there is a very a very clear decentralization in the way of how it works instead of Simply being a small multisig that we all know how that ends up true so like just pairing it back a bit so you're you think AI being the final Arbiter of the circuit breaker is probably how things will play out as opposed to to humans I do think in very particular cases that would be the case

highly audited AI uh where the result is not as because the problem with AIO the fears with AI is how stochastic could it be how uh and there is there is such AI that has deterministic outputs as well again it all depends on the model there are thousands of different infrastructures models uh sensory inputs and sensory outputs so so I do believe the the right deterministic one would be uh could be an option for the future and would end up happening yeah interesting I guess that's not that different from what happens now you know Quant systems and algorithmic trading at the end of the day is deterministic

right I mean it's making a call based on criteria we're just now saying this AI agent provided there's appropriate audit and guard rails around it should have an equal set of opportunity to be that last decision maker in that tree is that the way you think about it yeah to to be honest I do think it is not foolish to expect similar things that happen in web 2 and that have worked very well in web 2 to repeat themselves in web 3 especially taking advantage of what the blockchain is made for to decentralize the settlements so I do think we will end up seeing some sort of high frequency trading uh in in defy even

though at this current moment because of the speeds on the gas he doesn't seem very feasible but I would yeah I would definitely see that repeating in web 3 and in web 4 if it works very well in web 3. um I I do want to add a few like quantitative data from our previous research so we had a paper where we collected like roughly 160 D5 incidents and we evaluated um the emergency pause mechanisms in these D5 protocols and we surprisingly found out that only one of the protocols who supports the emerging supports has actually triggered the post within one

hour and roughly 42 I think of the of the protocols paused within six hours so so there are certain challenges with this circuit breaker designs if we do not use like automated tools right because D5 there's no Market um like ports right it's a 24 7 Market it's quite expensive for D5 projects to have a dedicated team to monitor transactions 24 7 on chain so I feel there must be some automated way to detect malicious transactions and Trigger the pause but the problem with heuristics of traditional tools is the only like someone used to design the patterns

right and the attackers were properly figured out a way to bypass the patterns to create an Innovative way to kind of steal the money and what's good with AI is they can find out abnormal patterns by comparing transactions with the historical transactions so no matter if the heuristics captures it or not it's very likely AI can capture in future all these abnormal behaviors that's something I want to add on top yeah interesting go ahead Joe I I just wanted to add that it can be a double-edged sword I mean I think it's definitely necessary like in the web 2

world when you think about security you always have all this time to respond to something and all these like indicators that someone's you know breaking into your stuff but in the web 3 world things happen quite quickly you know as these guys have said you it's really hard to have that be a manual effort where you're kind of monitoring your contracts and then you respond to something that's happening because an attacker may be able to finish their attack completely by the time you even notice right so you definitely need something automated and I think AI could be a good fit for that but when you when you think about it you're adding a circuit breaker you're you're also adding another Avenue for attack like if

um you're an attacker can somehow trigger that circuit breaker they can you know dose your your product right they can shut it down for a bit so you want to have that responsiveness to stop an attack but you also want to not introduce avenues for um an attacker to essentially mock a pattern that's going to trick the AI into triggering the circuit breaker so I I think it's something you have to approach really carefully because uh it could it could end up hurting you in the long run yeah it's like the classic who watches the Watchman problem maybe we have five minutes left but I'm curious like if we look forward to like the future world where we have like a perfect researcher AGI that's just like monitoring all the contracts monitoring

all transactions like if you had to estimate today when do you think something like that would exist is it a year away two years five years never um curious where people land there well I'm probably gonna get a bit of heat on but um the the good news with this is that I do not think it would be an AGI at the end of the day um true intelligence comes from when when you're not specialized at anything and yet you can abstract certain things that are specific to a certain topic or matter and you're able to implement that elsewhere or you're able to use the skills that you already have the general

skills that you have to create that or to look into something that might create that better than you do therefore I I do not think the AGI in this case would be the answer but rather an AGI to which uh many specific protocols and again that would be us um we would create specific AIS that are attentive to very specific things I do believe in the composability of it all so that let's say for example our brain can understand very well how to type but we don't have the mobility intelligence to to type just with our brain we needed

our arm right so the the arms our extensions in this case would be highly specialized uh artificial intelligence protocols that use different sensitive uh and sensory inputs such as for example we talk a lot about agents and agents in AI means several things could come from an llm agent that is able to select the right tool for the task or it could simply come from an agent that receives the feedback from the critic in the case of reinforcement learning right so having those very specific AIS that pay attention to one single thing there was even a paper on Google and attentionally sold you need

for for all of you that would like to read that that was the basics the origin of chat TPT and I do not think there would be uh it goes against the concept of being General to being specified in one thing so um to unfortunately for uh Sam Altman uh the artificial the general artificial intelligence wouldn't be able to control it all because uh it would be General by Nature it would be us who in the field have developed a specific and specialized tool that is able to precisely look into one very uh core thing so I do think that's going to be the Dynamics from the future more than simply having an idea that that replaces us all

just maybe one thing to add and a question on top of that on the one hand the monitoring I think you're right is going to be this very specialized focused attentive model on the other hand um it seems like the the Bad actors or or even just the trading firms are going to be incentivized to do something much more General they're going to be scraping sentiment analysis from Twitter from Facebook from LinkedIn they're going to be looking at trading patterns they're going to be trying to compile all that into some deterministic action and so on the one hand we can have very controlled models but if they're a very Dynamic aggressive and smart models on the other side I think it's a bit of an arms race and maybe uh we're bringing

the wrong weapon I yeah I don't think we can help uh not bringing the wrong weapon uh but if for example the open source protocols out there were developed with Watermark identification uh if it's not recognized in uh within the watermark database for example it would be an AI that might be Rogue so being able to um especially especially with ZK which is something we didn't touch upon but if you're able to verify what you're using on chain and you know exactly that the AI is doing exactly what you said he would do that that way you would be able to have that verification on chain sure you could trust certain AIS that haven't

been verified and are are not wrongly intentioned but I do think ZK will be here to help out in that verification on chain for all those things heavy computations of chain the Year Joe any final comment on the specialized versus AGI yeah um I'm not sure that an AGI is absolutely necessary to um you know extract maximum value uh out of the crypto space like the way I see the future is kind of like how we have uh MAV Bots now like Mev right so um there's this arms race to extract a maximum value out of every transaction and I think we're going to start seeing

that in terms of security as well right so ai's kind of kind of Empower those to be more abstract more generalized so that even a strategy someone hasn't thought of once it kind of the opportunity exists on chain uh an AI can a specialized AI can kind of come up with a way to extract that value and I think we'll see security kind of bundled in there as well I think within the the next decade we're going to start seeing this problem pop up where um security is almost like an instant finality on chain right like you deploy your project people start using it and immediately if it's vulnerable it's going to be hacked by some uh AI it's just monitoring the chain awesome

I wear time but um we could probably talk for another hour on this easy so if you have questions for these guys um please go find them um walking the hallways thanks everybody for showing up thank you great panel

thank you so the next panel is uh going to be on economic risks and we have the panelists joining us we're going to have Alex from git coin Dao Mario from solitary Network primoz from block analytica and yaron from B protocol please join us on stage please give them a warm welcome and we we're going to have the moderator tarun joining us shortly in a minute or so his

his flight got delayed and his uh making his way right up now so until that please uh just take a break and we'll get started as soon as uh tarun joins us here thanks maybe if we have a minute and pressure to entertain ment

thank you so everyone learned the tap dance we're good we're going yeah should we answered the question yeah let's ask each other most of you got in yesterday oh wow so you two rushing ahead I came last night which I'm really glad I didn't cut it close because I had a two hour delay in Seattle Washington how about you I came from uni and [Music] [Music]

[Music] thank you foreign [Music] [Music]

[Music] well hello everyone sorry for the delay I just got off the flight so I think it was a bit of a bit of a last-minute rush but excited to be here and to talk a little bit about economic risks with a bunch of different people who have different views on it so maybe first to get started with our panelists maybe we'll go one by one and have you introduce yourself with sort of what you what your name is what you're working on and what your sort of

favorite incident was that was a big Learning lesson for you and your the way you think about economic risks in defy I can start yeah my name is Alex and I work with get coin and with Dows generally for web3 Native risk so kind of a big topic for all the web 3 native things that can go wrong these days but previously I was an analyst at coinbase and my favorite exploit of the moment the thing that's on my mind a lot and I I may talk about this a little later because it's been a bit of an obsession point is governance attacks is where we see sort of new avenues of dows that are doing self-governance and doing interesting things with their funding

mechanisms actually being attacked and folks coming in either through social engineering of the Dow or through like an outright token manipulation and those have been top of mind for me um hello everyone my name is Mary radman I'm the co-founder of salty Network we are building a risk infrastructure for the centralized Finance more or less indexing the D5 ecosystem and in real time assessing the risks including econometrical economic side of the risk I will say like my favorite economic risk would we tell Luna because this was actually actually the time when we were in a funding phase it happened at the right time that we managed to close around

um but um one I really liked um was a unique one it was the binance chain stop or halt by CZ I really liked what happened then when all these liquidation events started to happen on those smaller elegators and so on Landing protocols it was quite funny to see what can happen in D5 when a chain gets stuck yeah thank you I I'm Iran I'm the sorry founder of B protocol historically it was a lot about on-chain risk mitigation Solutions mostly for landing markets recently we also started

to work about on-chain economic risk optimism optimization and Landing Market parameters I'm also contributor to the risk Dao who is also kind of giving it as a service and yeah my favorite incident maybe other than the classical Luna in other ones so we focused mostly about a landing market and stable coin risks so there was a bit of a niche attack but overall resulted with over 200 million dollars of loss it was back in the maybe end of the defect Summit days there was a platform called Larry Capital it had the lending Market

uh that was actually governed by Ichi there was this thing called Ichi the short story there is that probably intentionally but maybe just negligence set up very long to Value ratio for their own native token which is as expected sort of served as an exit liquidity for token holders token obviously pumped you know like 100x or so it stopped bumping and you know people lost their tens of millions in actual money usdc die Etc and he demonstrated very well you know like both the need for risk management

but also kind of all the pitfalls of all the compound folks but you know Landing markets in general and how to recover from an attacks how to how to actually act sorry how to actually act when attack happens Etc so yeah a lot of kind of lesson learned from there uh hey everyone my name is primo I'm founder of block analytica we do risk proposals for make a dial but we also build Rizzo dashboards customized series dashboards and recently we also launched one-site project where we tried to score borrowers in defy my best example of economic risks probably because I'm more on the

Financial Risk side is the um attack of um no yeah it actually happened on Solana so the mango markets attack later known by attacker known Avi why it was interesting for me because the the code worked as intended like he just manipulated the price with Perpetual features pumped the price 30X use collateral to borrow I think 100 million or 100 million of other assets and yeah it clearly shows the protocol was misconfigured um I'm not even sure because it's on Solana but I'm pretty sure this did probably didn't have any borrow caps Supply caps or any of those and uh yeah it just

clearly shows that active management even if the protocol the protocol needs to have parameter configuration for this kind of stuff and in this case did even if it had it like it was prob improperly misconfigured configured cool so uh you know we we covered I guess a breadth of different types of attacks whether it's governance attacks Oracle attacks like the mango case or sort of bad mechanism like Rari in the sense that there was no sort of adjustment that could be made but I think maybe broadly speaking I think the the term economic risk is probably highly overloaded and has

continued to become more overloaded over time as people try to bucket particular technical risks into economic risks so that Auditors can say that's not their job or vice versa people people in the economical side say you know hey this is a Auditors problem or so I think a good kind of coming to consensus on vocabulary uh you know would it would be good to kind of hear from each of you about how you would Define economic risks and what you view as sort of the boundaries of things that count as economic risk versus not now obviously it's a fuzzy line and that line changes over time but

um just like what is your sort of best unbiased estimate of the definition of economic risk yeah first first appreciate the question uh to kind of push us in our definitions as a community but uh I wouldn't necessarily want to Define defy economic risk as distinctive of what we think about with CFI economic risk but I think there's sort of a difference in scale because you are operating you know as for the first time in a financial system where each person is assuming complete culpability and autonomy in their environment so I think you have kind of like a movement from the micro risk that can then be understood at a macro scale and whereas when we study economic risk in more

centrally arbitrated areas you're going to see sort of macro influences moving to the micro scale of what an individual person or an individual company might experience so I guess I would add that little distinguisher of just sort of starting with first principles when we think about D5 specific risk and offer that as perhaps a addendum to the traditional definition and I do appreciate also teasing apart like a technical you know contract is it broken is it malicious is there a back door for this like chain those types of pieces I think can fit into the wider economic risk to understand the sector without having to be completely conflated right

sort of take it as as the The Wider Trends and the fact that complete self-custody and these new mechanisms we have for exchange that perfect autonomy is is what's creating the the risk surface area in general I believe it's a it's working right I believe it's a very interesting question I mean when you look at the technical risks you can always see these are the trigger points often in the economic sphere of risk what happened afterwards I distinguish usually like at solity in two parts you have the first one is more

of the protocol design level where you basically want to optimize your protocol that it behaves in a stable manner and the second one is more of a liquidity provision where the whole liquidity is actually interconnected and there are consequences when some kind of triggering mechanism happening and now the question is like okay we are now in this great Zone because there are many trigger elements and how far are you going there and that's basically where we say okay let's take in the Econo economic risk sphere everything which is there which is not from the traditional Finance space there like all these stuff what they are doing like sharp issues and so on cut it there let's not go in the

hardcore security audit site and everything in between is actually economic risk because D5 is is a composite and you have to deal with it chronologically yeah so my view is that economic risk is basically what will happen to you kind of on a bad day what will happen to your platform on a bad day we're kind of more classical cyber security is you know what will happen kind of in the presence of a malicious actor or an attacker and of course it's not mutually excluded you could have sold so-called Financial attacks but then also I think you know there is sort of a clear border where eventually

economic risk is something you could take as opposed to a lot of classical security risks which is you know like a clear sort of you know no go uh in particular you know even if you take you know like the tech loan as an example in my opinion you know even listing Luna or USD in some you know in your favor with Landing market so it is a risk you know but economic risk economics are reward you know no matter what the parameter is it could be under certain scenarios a reasonable decision uh to do you know one thing or another as opposed to the more classical risk which is you know sort of done only and

you know you should never go there so yeah uh yeah for me economic risk yeah it's a subset of I mean technical risk impacts economic risk but the economic risk can also rise from governance risk or Oracle risk or any kind of risks really um what I most um closely associated with is basically misconfiguration of parameters at a particular Landing platform or even the design of the landing platform not being properly configured designed basically the best case is probably other V2 where it doesn't have borrow caps right and we saw how this can go wrong in some ways

um if it asks these parameters to limit depth ceilings on certain assets being borrowable or limit Supply caps on as it used as collateral then it's always about configuring it properly related to the Token liquidity token volatility what we also do in our risk models is we look at the borrowers how they behave for instance if we if we see the power words are managing their walls actively they react when there's a market crash we know the loan book is safer right so it's all these attributes that kind of affect the the risk premium calculate for any Landing platform yeah I think it's interesting that the

first two answers were very sort of like broad definitions in the latter two answers are sort of extremely In The Weeds on particular one particular subset which in and of itself gives you this question of like uh are there actually really good ways of formally describing economic risk I would sort of have a different definition than probably everyone uh here in that my definition would be something I can do you have some notion of the utilities or payoffs of individual users and user types you have the notion of the joint payoff of the entire system and you want to look at where the maximum deviation between the max joint payoff and the sort of expected

individual micro payoffs uh differs because that sort of controls at some level the highest risk in your system and this is something that's sort of becoming more generic as these risks are to expand and scope and one of the places where we've seen risks especially economic risks expand a lot in scope is in cross-chain assets so um you know of course Bridges have historically been the main source of cross-chain assets leading to security vulnerabilities um of course as we all learned over the last week multi-party computation can really mean single party computation uh As multi-chain proved

um so fast forwarding you know if we look if we take a forward-looking view on this where do you see economic risks diffusing over time especially in the cross chain world where these risks are less Atomic and some of the guarantees you have even from things like debt caps may not actually be taking into account some of the remote chain behaviors and you know what do you think mitigations for those are yeah coming from a data background like to get a little bit in the Weeds on this one but I think I think it's really important to realize that sometimes we're mapping

traditional Finance modeling and I mean we the data Community is guilty of mapping traditional Finance mechanisms onto our D5 mechanisms as if that's going to be like a one-to-one and so we're using a lot of traditional methods to both project over time to do our risk models if you have automated systems that are doing any kind of risk detection or anomaly detection a lot of these things are not necessarily utilizing web 3 subject matter expertise to the extent that they should in my experience so I think really it becomes to say like where it's going to diffuse over time and sort of guess at where this is going to go I think the subject matter expertise and being close to

closer to understanding sort of even at a community level what the different chains represent what they're used for how those communities May behave distinctively and present different risk surface area we could you know do a a quick projection model and just use Maine just take everything into eat before the data gets ingested and oftentimes that is what analysts are going to do but you could also represent each chain as a signal and we understand that layer two is also as a signal is someone utilizing layer twos which layer twos are they going between sometimes that could be a anonymity preserving mechanism as we start to sort of dig into these models you can add Nuance to it when you understand and respect the

difference in the way that these Financial systems function and we're not just sort of slamming them through the the models that work really well for centralized Finance so I sort of see a a continued blossoming and Nuance with multi-chains more layer twos on the horizon more use cases and interesting communities popping up there around these different things and I see that being the onus then on data scientists and analysts to take those signals seriously and understand that any of those could help be not necessarily a fully independent signal but one that's in close relationship with your more traditional risk signals I mean I agree with you like Pro read

the only way to deal with those kind of risks especially in the future is going to be like big data approaches because D5 is at 24 7 business and only way to automatically be able to assess what's happening is a real-time assessment through Big Data approaches now the question is like how far are you going there because the main problem like when you go in this direction and virtuality are going in this direction you realize like there are so many of those trigger points so many so much deepness you can reach and the complexity gets so high the question is like what is the meaningfulness out of it and

I guess there is no way around besides this preventive security related Solutions which are there when they're when they see something's happening dedic is this at the stop um I believe the best way or the safest way is going to be once we reach a point where we indexed or whatever the whole ecosystem we have most of the liquidity captured and we understand the interconnectedness there that we can kind of build risk models what could happen like because the problem is now D5 small constantly new Protocols are arriving they are getting from zero to like almost billions in liquidity very fast it's kind of hard to

integrate those protocols make it like get holistically what's happening but with time D5 will get more stable molecuity will be there I guess most of the liquidity will be like with top 50 top 100 protocols and then all these big data will make approaches will make a lot of sense you will be able to capture the equilibrium of stability I would say like in the space yeah yeah so other than potential Bridge hacks and you know getting wrecked which is really like a hard problem and you know also very hard to analyze and also to predict we also see you know

some other phenomenas and there there are actually things to do it used to be very common you know like for a new L1 to come and just for compounding other and then list like completely standard assets such as is Bitcoin some kind of stablecoin and then comes you know come and say okay we have exactly the same assets as compound and other on mainnet so let's set you know the same risk parameters Etc so I think even at that level and this is you know something that you know projects can actually operate there so understanding that even in the financial setup you know the liquidity

is very different on all chains liquidations especially big liquidations might might take a much longer time to execute because the liquidity is fragmented and you know it's passed around and mostly on mainnet and these are things that can be modeled and you know and we do model but it's also important to have some awareness there also it's mostly best practice you know kind of on a technical level if you set up a new Landing Market on a different chain so more often than you know so okay you kind of make changing a lot and eventually they do deploy some blog some

Oracle there but very often the oracles actually quote not what you think they quote they quote the price on mainnet not the price on your chain uh and then okay you know so people maybe enjoy kind of mocking you know this Landing markets after the attack but there's no really a way around it you know typically they are forced to do it uh but there could be you know some monitoring steps there that could you know act in some near real-time manner at least to mitigate this so it's a you know like Oracle Integrity decks liquidity these are the things that maybe you could handle as a question protocol and then for Bridges

you know mostly pray that the bridge won't be attacked yeah at the maker we have this incredible hard task right now to actually quantify to calculate risk premium of of certain exposure to to different l2s through certain Bridges and if you think about it like that's incredibly hard like these are low probability high impact events right it's like I don't know insuring a house against earthquake um but you have like three years of data and um yeah it's going to be really hard luckily we have L2 beats supporting us who are probably the best in space with the risk framework um so there is a benchmarking approach to it where we could actually identify

um and the the risk scale of certain Bridges and l2s but again yeah coming up with a with a final number we actually need for this new reformed maker system where allocator Towers will be charged to deploy Capital um it's it's not going to be easy for sure yeah I think I think Iran's point about um you know oracle Integrity across chains is probably one of the biggest things that we've seen as the source of loss on on some of the the third sort of like lower liquidity chains um but I think it's not even necessarily just strictly the bridge risk as much as there's also a people starting to do slightly new mechanisms that you know

interact with consensus more or like take advantage of particular sequence or guarantees which don't Exist Elsewhere and then they don't realize they redeployed the you know a forked contract that makes particular assumptions about the ordering behavior on mainnet versus the ordering behavior on a particular L2 um and those types of things have started to really been sort of blossoming over time I think we saw the first ever real consensus instability causing huge defy loss attack in April of this year when um you know malicious eth2 proposer uh was able to get the contents of a block before sandwich everyone and then kind of cause some kind of long scale attacks

now this is probably the most sophisticated attack we've ever seen uh so far in terms of the amount of sophistication of someone having to run a validator having to probabilistically know roughly what time they would would be chosen as a proposer than based on being chosen as a proposer injecting a bunch of fake transactions and fake fake blocks at the right time to cause a fork to to lead to Big laws so you know as these types of things start to become much more plausible and doable in a fragmented L2 world how do you how do you think about these interactions between D5 and Mev and you know how that's going to change protocol

design over the next cycle yeah so Mev is actually a really great example of when because there was this economic incentive the community really hurried up and built some products that are extremely sophisticated they operate in real time the the amount of scanning that they're doing with available chains is super impressive and the development of that over the last two years is pretty incredible so I think we need to do something like that for anomaly detection as a community and this does get a little bit more gray because this turns more into the realm of sort of the whole Community taking Mutual responsibility and also those best practices being shared in an

accelerated Rapid Way so I think I really like that uh Mario brought up like the need for indexing and index versus data products like almost as a public good making this like clean data available making contracts transparent commenting things out in reasonable ways that sort of allow that increased level of transparency these kinds of like layer zero level practices and sort of like layer zero level cultural tenets that the D5 Community can continue to cultivate or maybe begin to cultivate in many cases it will create the more secure systems that we need because then you do have data scientists and and individual auditing groups all the way to the level of the protocol being able to develop

sophisticated near real time if not real time monitoring for anomaly detection and at that point when you've described what your expected behavior is in your system then you can imagine that even being moved to the contract level if we understand the expected behavior when the expected behavior is is triggering some kind of um you know alarm Bells we could over time begin to move that even to the way that the chain itself is deployed or other mechanisms not yet really experimented with so I think it again sort of data nerd answer but I see a lot of this coming down to how are we going to think about the

community's responsibility and expectations to sort of front run the exploits that are continuing to manifest and even the breakage that's not necessarily coming from a malicious place but the breakage that can potentially happen when we're in such a highly experimental Realm yeah I personally believe it's a really tricky topic the problem is like when we're talking about Mev it's a very short-term event to see it like in this way and what the problem is like I talked with many of those Mev strategies who are running around and I learned from them they are

now building MAV strategies for Mev strategies so basically then try trying to trick Mev guys who are doing mmv strategies and then the question is okay if everything is happening like instantly like you are fighting on the maple side how fast how are you able to react immediately on that side I mean it's we are not anymore talking here or not that you have few blocks that you can react or something like you you have to be able to immediately detect and do something around that and the question is like are you able to detect and then what to do like how we're able to do that instantly first question um I believe like probably from the protocol design I mean there are

solutions who are trying to make the mempool private and so on who are going to change a bit a little bit protocol could be the way forward but I'm not sure this is going to be mainstream so I have a kind of pessimistic view on that side yeah so I personally think that mbv you know might just become another tax on blockchain but but I think definitely I don't know maybe again layer and risk taking solution maybe could impose a so-called of you know some sort of consensus attack driven by you know external incentives a a second General the problem of having

something which is incentive compatible and relying only on economic incentives is pretty you know then long-standing open questions in my view even Bitcoin is not necessarily immune you know from this stuff Bitcoin is only sort of proven to you know act correctly when you have honest majority not when you have potentially like a rational or incentive driven majority and okay this is kind of debatable but you know at least one approach on a technical level I know maybe some ZK magic console that if you know you will be able to somehow successfully

separate the execution layer from the uh the way you build blocks and Rich consensus but yeah I don't know much about it yeah I'm certainly not an mvv expert and uh you know these things are going to happen um the most boring cancer would be that it makes the space more robust um I know the fix was deployed in this case but uh I also think you know mailbox get a lesson you know it's okay in some parts sometimes but I'm more Curious what's your take turn because I know this is your is your area of expertise um I think it's actually interesting

because these types of attacks have been people been talking about them for almost five or six years like the first feather forking paper I think was like Andrew Miller wrote in 2014 the first sort of like Time Bandit kind of analysis of like this was probably 2017 or 2018. so people had talked about this but there was never any real incentive for the validators to ever do it because it's quite technically risky like you you're slashing you could get slash for more than what you're trying to earn uh you also have to do a lot of timing attacks of like ensuring that your position in the network is sufficient that when you're competing with another proposed block that yours is able to reach the network efficiently

uh but I do think the interesting thing about layer twos is that having single sequencers makes this a lot easier to do these types of attacks so from my perspective the fact that someone was able to execute man now of course there's a fix and you can argue that oh like the relays should not have been able to send invalid blocks and to the whole network but that's sort of more a problem of like the the design was sort of had some centralization feature uh and that feature was exploited and now it was sort of made harder to exploit it but it's actually not still impossible to do the same attack right now so that's sort of there's sort of this this interesting surface area and I think in l2s this is

going to be a much bigger deal because there's really only one sequencer in a lot of places and you know of course right now the sequencer is your wink wink nudge nudge best friend like good guy won't do anything wrong right but uh obviously that's not gonna last and I'm sure there's going to be a malicious L2 sequencer that I think the l2s are going to have way more of these issues than than we give them credit for so that maybe not that was my my bullied Pulpit on that but another kind of thing that's kind of become really interesting in this vein is that some of these technical risks of how contract execution works and

um how people have implemented particular mechanisms uh affect economic risk now the Oracle case is the simplest one right of like where you inject Oracle data how you use Oracle data what Oracle how scaled Oracle data is ETC or how synchronized it is to your environment but we've also started to see a lot of other technical um changes to markets impact their efficiency versus risk trade-off and I think for instance examples of this are people working on on Oracle free style lending protocols or risk protocols so I was curious from from your perspective which kind of technical

changes have people been making that have in your mind been better for both risk management and risk control and or have been worse it could it could be you know it go both ways and of course the simplest example is of course the oracles but I think people can start pretty much because I know you've spent some time on the oracle-free part of the world um yeah I mean I could start with maker there are two maybe three features um so one thing that's kind of interesting to me and maybe only maker has I'm not sure is this concept of rate limiter on the depth ceiling part right so even though the dab ceiling is really high you allow just a certain increase in time right

um of course this imposes two new parameters some governance overhead it could also curtail growth right because it happened during bull market when the institutions were meeting like crazy and you know the dev silic was kept for 12 hours and they couldn't mint more even though you know we would allow higher exposure but there's this rate limiter for a reason because if there would be an exploit it actually protects you right another one are circuit breakers for auctions right um you could make a circuit breaker and there is one at maker where again you need to specify parameter when you say at certain price drop for certain collateral um you know let's say Define it at 70 percent you say for certain token you say yeah it's more likely the oracles

are manipulated then the Market's actually falling and to stop auctions in such case right so there's this parameter that's that's also there um but yeah regarding corticals again maker is quite specific because it has this one hour delay um because of this delay oracles are safer I mean technical risks are lower because oracles can be actually Frozen during that hour um but then you start affecting you start making trade-offs right because Oracle is is delayed um auctions need to be different so there are Dutch auctions the Dutch auctions are slower because the auctions are slower there's a bigger Market risk because there's bigger bigger Market

risk we needed to compensate it with slightly higher liquidation ratios right so if you look at maker versus other compound it has slightly higher liquidation ratio for for that particular reason um and yeah you could even say this again curtail is your competitiveness right so you always keep making this these trade-offs uh last thing I mentioned I'll mention regarding co-workers um yeah there are now new designs oracles or a class Landing markets such as ajna that was launched I think yesterday um and yeah I looked into the design it's uh you know because there's no oracles it gets really complex on the on the auction side right

um there's a whole new complex mechanism of how you kick auction how system penalizes somebody who kicks auctions but it shouldn't because the market prices is still okay I mean the Ultima ratio is still fine so we start imposing you start making trade-offs basically that's that's the TL there yeah so I I think out of historically a lot of the lending best practices sort of started From compound you know back in the early uh 2090 or 2020 and you know most of other first features were also following compound and I think yeah like one nice trend is that we kind of see even compound itself you know kind of evolving uh and kind of

self-learning and trying to change parameters there so obviously you know even compounds started without any ball caps and Supply cups and now it's becoming you know sort of best practice and it's much easier to run risk management such way compound V3 is also going to the direction of mostly segregated markets where you have one debt asset and maybe one collateral or multiple collateral but still segregated I seen liquidy sort of solved the problem and there was a huge you know kind of Gap or even bug about not socializing bad depth so I think

liquidity will the first one to do it and maybe I will end with you know maybe a more concerning Trends I think there's sort of a trend now trying to improve the liquidation mechanism towards you know sort of auction or variable fees in order to save Mev I think for example this is also downsides okay so the evolution is not only mixing easier but also sometimes have downsides I know we uh we just got our one minute so I want to give everyone one last concluding thought so what what thing are you most excited about in that related to economic risk that's either going online or just came out in the last you know for the next year like

what are you looking forward to over the coming year I believe what's going to be interesting is to see like these Risk Solutions that are coming like more and more into space more competition is there and that will lead also to more stability in the space and hopefully also when we look at the middleware Innovation site we will end up in a situation to have something like a data driven smart contracts they are going to be smarter more adaptive and this is like exciting to see like it's a huge risk of course although it's a double-sided sword but it could also help on many topics we have at the moment yeah um to keep it succinct I'm most

excited by web3 sort of being able to make good use of some recent gains in distributed computing and this is everything from like consensus layer attack strengthening like perhaps we get used to seeing what the minimum viable right number of noses and what the mathematic principle is that describes the strength of a chain before we even like inform adoption or inform that rollout I don't personally think I don't want to speak here but I don't think any of the layer twos are even close to meeting those needs right now just from a technical specifications point so I'm excited for for web3 to kind of be in mutual dialogue at a few different levels like synthetic data AI guided has been really prominent in web 2 progressively more and we could

do that with you know synthetic on-chain data to sort of begin to test principles stress test them and see them in practice in a more pragmatic and grounded way then let's ship it and hope for the best yeah so I'm most excited about the naturally I walk a lot about is trying to sort of replace a lot of the risk mitigation logic and replace Risk Managers and out Decisions by smart contacts and I'm also giving a talk about it in the evening session so yeah come hear it out um mostly probably excited about this permissionless pulls for landing such as the decision case um not necessarily quarter class style

but just like uni swap style blending right where I think fuse was close to it right where anybody can deploy pools so and different LTV ratios right so we have full flexibility and uh you know the most Capital efficient markets actually would come from this kind of New Primitives cool well thanks everyone for for your thoughts and uh give a round of applause for our panel [Applause] thanks Saran and the panelists for the Fantastic panel so we now have a short

break of 10 minutes note this is not a coffee break it's just a break the next coffee break is at 4 10 um so yeah so please go out Network and come back for the next panel in 10 minutes and that is going to be a panel on tools so see you in 10 minutes thank you just

foreign [Music] [Music]

[Music] [Music] [Music] thank you [Music] thank you

[Music] thank you [Music] foreign [Music] foreign

[Music] thank you [Music] foreign [Music]

[Music] [Music] thank you [Music] [Music] thank you

foreign [Music] [Music] [Music] foreign [Music]

foreign foreign [Music] [Music] [Music] foreign

[Music] foreign

[Music] foreign [Music] hello [Music]

hello [Music] thank you [Music] foreign

[Music] hello

can you hear me yay okay fantastic um welcome to the tools panel we love tools thank you thank you so um let's start things off with a quick round Adventures [Music] hello okay let's start things off with a quick round of intros um so who are you uh what do you do and also what kinds of security tools do you either build or use on a daily basis hey everyone I am Nat I'm a security

engineer at trailer bits um and on a day-to-day basis we're generally using tools like static analysis and fuzzing on a day-to-day thank you so I'm Patrick the CEO of fuzzing labs and as the name suggests we are doing a lot of fuzzing so we are basically building security tools and dedicated further for either a client side or smart contracts uh hey everyone I'm Gary I'm a software engineer at Electric Capital and I work on security tools that kind of focus on like post deployment so work on like a code search tool

and surfacing information that comes out after contracts are live and deployed hi I am Ori I work at sartora as a developer and in developer relations we're developing several security tools one of them is the software approver which is a formal verification tool for smart contracts and the other is Gambit which is an open source solidity mutation testing tool hi I'm bhargo I'm part of the research and specifications team at the web3 foundation I like to call myself a full stack verification engineer so I'm interested in the whole Spectrum right from like analyzing

consensus protocols all the way to uh verification at uh at the code level and mostly right now I'm focusing on verification tools for the polka dot ecosystem hi I'm Janice I'm co-founder of ddub we have a public blockchain Explorer that's geared towards security so we have probably the best decompiler for evm byte code out there so we offer free tooling for all sorts of security investigations but our proprietary tooling has to do with static analysis as well as Dynamic analysis of transactions so we do both Bots for monitoring and we have a language for

specifying those and we write a lot of static analysis for code awesome um and I'm Fraser your moderator okay so can someone or a few of you give your sort of pithy couple sentence analysis of the state of Tooling in web3 generally it's good so I mean we can concentrate on the negatives but uh if I were to give a two sentence description uh considering that this is a young domain we have very very good tooling uh security tooling

compared to much more mature software engineering domains we have probably the most advanced versions of tooling from the formal verification side the search or approver Etc from the static analysis side I mean I've been in the static analysis Community for over 15 years but the best tools we have ever put out are in this domain and it's all because there's so much money at stake so we can complain there are definitely problems but it's good to see where we are in the whole universe and we have some pretty awesome tooling that's an uh actually kind of answers my second question so I'm just going to

throw that out there too and you can answer both um so how would you say the tooling landscape is different in web3 compared with web2 yeah so there is one clear difference between web3 and web 2 right that you can't use uh security through obscurity in in web3 because like most of the code is open source like attackers can spend months analyzing it before they they launch the attack so one of the the key differences I would say is that since everything is

open source uh the the analysis has to be much stronger and uh obscurity cannot be cannot be used for security I think one of the main differences between web 2 and web free tooling from the point of view of the user is that the user base of tools in web3 is much smaller so if you need to look online for answers for your questions or look for video tutorials about how to do something with a certain tool you're probably not going to be able to find it or at least you're not nearly the same ease or quality yeah I think to expand on bargov's point

um one of the main differences I see is like because it's open source all the code is out there you know you can there's a millions of dollars of value behind it you get this really quick flywheel where you know there's Auditors and security researchers and they can go audit the code use all these tools give a bunch of feedback and so you get this really nice virtuous cycle and so I think it kind of leads to the tooling being really good and also evolving at a really quick rate um answers on the panel the only thing I would add is that I think web 2 Tools in some ways are also more advanced than

web 3 in terms of the usage in different code bases and usage across applications and so I think there's also in addition to that there's also kind of the adoption and kind of more having developers actually integrate with like existing static analysis tools and fuzzing is definitely something that like should be applied to all code bases and I think is definitely like something that is much more apparent and needed in the book um so I I disagree a bit actually compared to what you were saying um if you are speaking about web 3 in

general I think there is a huge gap between the different blockchain I think if we're speaking about ethereum the majority of the toolings are really good and we have a bit over everything and so on but if you compare two other chain in general um there is definitely a lack of static analyzer for the no formal verification on some chain especially if you also take a look at all the new l2zk stuff there is a lot of news um other smart contract language circuit ZK circuit and so on and in this area basically everything needs to be built so if we are only taking a look at

ethereum and evm here we are pretty much sure if we take a look at the rest it's nothing compared to to what we have I mean definitely would agree with that one big difference that I'd like to point out is that this is a perfect playground for security tooling uh it's it's the only opportunity one ever gets to have all the code open all the test cases pretty much all the past executions permanently recorded you can do pretty amazing security Tooling in this space in the web 3 space and the other thing that helps tremendously is that its small size of code bases like a

little over five years ago I was doing similar things I was doing static analysis at Facebook the Facebook Android app which is like the little app that you install on your phone that's a hundred thousand Java classes that's the deployed byte code Java byte code that goes in your phone like a hundred thousand Java classes imagine what tooling can analyze that versus the tooling that can analyze you know uh 50 Smart contracts that are typically what constitutes the the average D5 protocol that manages so much money so we have a perfect playground and we have gotten a lot a lot of advanced doing which is great but certainly it's true it's only

limited to evm and and especially even in evm mostly ethereum great um so that's somewhat related to this next question which is about how you hope to see the state of tooling change moving forward I guess we got some of that at the end we would like to see some more One-Stop shops currently you get different tools to do different functions so you get deployment or you get compiling or you get analysis and fuzzing so some tools

have already started to move in this direction to great success I think we're going to see more of that and obviously that relates also to the issue of multi-chain which is in general a bit of a lacking area of vulnerabilities for many of the tools yeah to give you an example in in all cases we are building security tool open source Finance by grants from foundation and typically in my opinion that's the way it should be I definitely enjoyed the different tools that most of the the guy are building and I'm playing with with them at all with all of them but the fact is for me when you have a

blockchain and it's creating his own smart contract language his own consensus and so on that should be the one that is financing and developing security tool to basically give that to the to the developer it should be at least them that is doing the first step and then defense security companies and teams that basically built on top of that and provide Audits and and everything but it for me it shouldn't be the the other ways I think there um are a lot of existing tools like um like for example for static analysis

with slither for example that do provide like a lot of results that developers and like security researchers have the opt the opportunity to triage um I do think there's probably room for improvement in terms of reducing false positives just to make sure that it it gives you like developers and users just a better idea of what is more likely to be wrong and kind of in ease of an ease of experience in terms of understanding like what code might be affected and on the flip side I think false negatives from the fuzzing side as well to make sure that fuzzing tools can be extended easily and nicely just to

make sure that bugs that should have been caught through fuzzing are actually cut and so I think there's a lot of room movement in kind of the existing tool space currently yeah maybe I can give some insights uh from like the polka dot ecosystem so the whole ecosystem stack Tech stack is based and rushed and it would be great to see some tooling for rust which even before like security or a verification the first thing is like program comprehension so it would be great to see tooling which uh improves like program comprehension

because it's only when the developer really understands what he's doing that he can come up with invariants and so on so that's like the the first layer uh that I would love to uh see being being developed and of course like after that comes uh static analyzers and surprisingly there isn't that much options uh which are robust enough to be used on like production grade code I think my feeling has been that at least for like Rush tools most of these tools are like academic in nature and in Academia you tend to prioritize novelty over

robustness and so that I feel that's a huge potential here where there are great ideas but these ideas have to translate to like robust tools that can be uh applied on production code yeah so I would definitely agree but there's uh there's a standard added here which is there's no money in tooling so and especially in comprehension tooling like their their well-known studies like even Google has put something out that says uh nobody cares about offering tools uh to help the programmer understand that's that's considered low value so you need to go directly to something that has value which is like

security analysis so I agree that there's a lot of need there but it's not going to be filled by the market so well foundations may need to step in to give better tools at that level because the market will not step in there and imagine this Market with at best a few tens of thousands of developers at best uh compared to the overall the web 2 Market with millions and millions of developers I mean there we start now to see some security tooling that's uh and comprehension tooling that that has General applicability but it's an order of magnitude larger our Market but certainly I will agree with everyone that there isn't there is a lot of room for improvement there are things we can

focus on both on follow the false positive false negative side but there's also a big potential for disruptive innovation here uh and where do I want to see disruptive innovation well first of all we just saw llms we saw AI come in and we've seen completely trivial uses like you just you find like a text generator that hallucinates and you treat you feed it your program and see what we'll say about it that's not very interesting what I'd like to do is move the frontier of what is considered automation have a neural net come up with specifications for the certor approver for instance

have something like that have deep automation something that will really push what can be automated versus what's now delegated to humans and that can get us to the next level with much much greater automation some good security insights encoded in our tools but at the same time the automation will come from llms or something similar so there is there's definitely a very a wide open Horizon for things that are going to happen in the next two three five years lots of potential for innovation thank you um taking this from a little more of a Visionary perspective back down to

really really minute we touched a lot on false positives just now I'm curious if anyone else has any opinions feelings thoughts about false positives they don't matter oh interesting no I'm I'm being a little provocative but they obviously matter but they they start to matter a lot at above the 90 rate that's the surprising thing you know give me a true vulnerability uh one out of ten times I'm still happy if it's a true vulnerability that's that's tremendously high value in this domain so I don't care if you give me a few false positives it's not like I'm trying

to get the attention of a board programmer programming iOS applications and now I need to give them like extremely low false positive rates I mean that's not the game here the game here is give me high value vulnerabilities even if nine out of ten times they turn out to be false now if it's 99 over 100 yeah that's way too much but you we can suffer a lot higher in terms of the false positive rate so that's why I don't consider this to be a huge problem that's my controversial opinion I I had warned beforehand and do you think that Tools in this space all seem to share that opinion or do you think different tools and different

segments of the space have different reactions to false positives and this is kind of for everyone including you I have to qualify first of all sorry and that's the last thing I'll say it depends on the severity of the vulnerability if the tool is ambitious enough to go for severe vulnerabilities and end to end that's when the false positive rate does not matter so I think most people will agree to that but so false positives can actually help in program comprehension our tool for example is iterative in nature so you will eventually be able to eliminate most of the false positives

but uh in that process you are focusing on the parts of your program that are the riskiest at least in the eyes of the tool and that in itself can help make your audits more focused your testing more focused and reduce errors in an indirect way I do think in terms of something like results from like a static analysis tool going into like if you're just kind of running it on code and seeing results um it's possible that like a lot of those are false positives and maybe one of them is a true positive but still even then triaging those results and going through

them and actually really understanding in depth what the system is supposed to do and how it's supposed to work is a practice that kind of needs to be done because that tool can essentially help you determine those vulnerabilities and those risks beforehand um I think there was a recent study that was just a release that was a few runs based on previous code bases where Slither was run it could have saved like 150 million in funds I think that goes to show that developers really need to take results from static analysis tools carefully and really

understand what are the true impacts of even if it doesn't affect your code base right now how will it affect your code base in the future once you do a code upgrade once you do a migration and actually understanding like end to end what that impact has on your system because there's a lot of things that can fall through the gaps and so it takes a lot of time and effort to really go through those and triage them I think on like the ergonomics and effects side of things false positives can be bad because you know if you keep running tools and they give you these false positives that are low severity

you kind of get desensitized to it and almost like annoyed sometimes you know like if you ever run npm install you'll see it tells you there's like five warnings and things you should fix but like how many of you guys have actually looked into that and so you know that's possible that for some of these tools that can also happen where you might just be like I don't want to run this anymore it's like too much noise so I think that's definitely one concern that we should have when it comes to false positives just that one oh sorry so one of the other uh ways of like getting rid of false

positives is to use maybe some kind of symbolic execution so that after the tool gives you this uh possible issue here you would want to have a concrete input or like a concrete test you know which exposes that vulnerability so maybe there are ways where you can combine static analysis with some symbolic execution to improve the the false positive rate so so I totally uh agree on that um the fact is most a certain point most advanced security analysis will actually directly include symbolic execution Android inside

because if you want to be able to find some complex vulnerability you will be able to maybe suppose or at least get a range of a possible value at a certain point in time so what I think is definitely valuable is symbolic execution to actually get a closer look of what is really happening and I think something really important to have and it's the beginning the first time I saw that was in slitter is the confidence of the vulnerability and I think it's basically what potentially matter the most if if you have a critical and confidence on that is very high it's not the same then are critical with a low confidence so

maybe a first step for the developer to do is actually to take a look at all the vulnerability with a high confidence score and then go to the to the rest yeah I definitely agree that static analysis should be used in combination with other tools I would also say like if you do actually find a true positive with slither or any other tooling that should be a sign that you should be fixing that vulnerability that you should be fixing that patch and probably writing like a unit test or some kind of fuzzing test even just to make sure that that's no longer exploitable so that in the future when you're updating your code you've checked to make sure that that

like it doesn't repeat itself and just making sure that you're like you're always running those tools like as you change your code and not necessarily just like write all your code first and then do the Slither and like run static analysis or formal verification or fuzzing just because once you get to that very end most likely those static analysis results are going to be never-ending fuzzing is going to be very difficult to get up because it's such a large code base that you may not have considered like what are your invariants beforehand and so ideally if you are running these tools like as you're creating your code by the end you shouldn't really have like a long list per se of like findings

that you should be like keeping in mind within your code base it should be relatively succinct because it's something that you've thought about as you're building your code and do you find that's how developers tend to use these tools or what workflows are you actually seeing in real life we definitely like them to make sure that they're doing this throughout this security work process um I think it's it very much depends on the project and especially if a project is set up with thinking about their invariance beforehand thinking about like what their code is supposed to do it's noticeably much easier to get

fuzzing set up and it's much easier to triage results because there are not that many results so it's you can very you can there's a very noticeable difference between those projects and um from that it becomes from the Project's perspective much easier for them to analyze potential vulnerabilities or like Risk with like external protocols and so from their side they have kind of a more they have a safer posture which can help them essentially future proof their code but also just make sure that their current versions are safe yeah a lot of developers have that misconception that you should use tools

as the last thing in the development life cycle right before even right after Audits and actually the biggest value you can get from tools is from using them from very early in the process it just gives you more economic value because the mistakes that you have especially in your design are going to be a lot more expensive if you find them later in the process rather than early if you're going to do it anyway please do it earlier I would also also add that actually for um going like after you've written your code going into like audits or bug bounties or

um any kind of um other eyes on your code at any third-party opinions having run Slither and having the fuzzing set up means that other people looking at your code can then focus on very complex bugs that integrate with protocols or different contracts and so the quality of those bugs are likely much higher those of like results from static analysis because these two these tools will help you find kind of the low hanging fruit and maybe complex interactions but it means if you've already run those tools when you get to kind of having that third party look at

your code that it's much easier to actually understand what's going on but also identify potential books okay I'll go back and push back a little on the idea that a static analysis tool especially can give you good uh estimates of its own confidence I mean confidence is a great thing but we need to be really careful when inspecting results at a certain level of confidence and I'll explain what we are noticing and kind of why this is happening there's this old anecdote in business settings you have professor and the professor is teaching her students everything about stock picking and hear

all the criteria for seeing whether a company is doing well and you have your PE ratio and you have what the executive team has sold recently and you have whatever criteria you want so the entire class is learning about all of those and professors like okay so give me an algorithm for finding the best stocks the students come up with something and they State their criteria and they run the algorithm it's like there are no stocks like that and of course there are going to be no stocks like that in everything that has money behind it if you only focus at what you can be certain about if you only focus at the highest confidence you're not going to find anything and it's the same with with analysis warnings if you only look at high

confidence basically that's clueless code most of the time so it's not going to hold any money if you do high confidence and holds a lot of money that's an extremely rare occurrence to find anything so oftentimes one needs to inspect a lot more than the high confidence warnings why because the analysis itself the automated analysis it knows of one thread and it knows of a guarding pattern against that threat and it thinks it sees that guarding pattern but it's not really there and you have a real vulnerability and a human needs to come in and find that even though I see a low confidence warning this is really

something that looks a little suspicious so yes definitely we want analysis to tell us how confident they are yes we want to focus on the high confidence but only if we have limited time for inspection if if this is really a project that we care about you need to inspect nearly everything that the analysis tells you about because this is a lot of money and the analysis is just doing its best and it's just a machine I want to refer to a few things that yanis have said before about confidence in terms of formal verification so you said before that maybe in the future AI

will produce specifications so um there is a running joke that formal verification makes sure that your code in your specification have the same bugs and that's a true risk that you can have with generated specs it might not be what you mean them to be and that ties into the confidence problem that we faced and we try to solve it using a different way with mutation testing the basic idea is that you take your code to Lady code and include a random fault in it and we call that a mutant and the idea is that it resembles a code with a bug in it so it should fail

somewhere along your testing suit maybe static analysis will find this mistake or fuzzing or your unit tests even and that gives you some estimate of confidence seeing how many mutants were caught we say it was killed and how many were not and it's pluggable with all kinds of different tools is there a chance that maybe a generated specs at least will be more different than specs written by the people who wrote the code like it it seems like it could be an interesting moment of diff although maybe the generated specs are like so

kind of average in what they generate that they also incorporate sort of the most likely kind of bug but I don't know any more thoughts on like generating specs so um yeah I guess that will depend on the exact AI technology but will be used to produce these specs I think that there are two main problems one they're going to see only specs that humans wrote and uh well most of the specs are are not catching bugs right and the other is that we see that the more uh tailored the spec is to your program logic um the more kind of unique bugs you can find if it's a generic bug there are

other technologies that are very good at catching bugs like static analysis and you're going to to miss out of some of the edge of that technology if you cannot really um find something that's very different from the other programs that have been used to train the AI okay great um thanks for coming with me on the small AI tangent um okay so I'm curious if there have been any developer responses to results from either your tools or tools you've seen that have been really surprising to you or taught you something about your tool or the state of tooling more

generally yeah there is always some funny responses from developer to be honest like you find the bug they fix it and they say it's not the bug but why did you fix it if it's not a bag but whatever so this kind of stuff happened all the time what what happened as well is that the tool is too specific or not specific enough and again that's the main issue with again if you want to have a high confidence on I don't know around Transit we're gonna really be specific on which type of from Francie have a high confidence because

based on the CFG the evm bytecode and so on we can affirm that there is a run from seberg but if it's like another variant of front and C if you if you have been there for like five or six years there was only one kind of frontruncie back then and not multiple of them so definitely the tool at the time was unable to find the let's say the Dao roundtransi but was not able to find the new read-only run from C or whatever that we have right now so there is definitely um updates to do on the tours and um and the fact are the developer some of them think the tool is Magic and

that we will do the all the job for you and that's my conversion and my controversial opinion about formal verification because everyone want to have formal verification but for sure if I'm formally verified that one equal one it doesn't mean I'm formally verified so for me the there is also a notion of let's say a timeline applied to tools static analysis tools should be kind of one of the beginner finding all the longing Foods then you are doing fuzzing and then you are maybe doing symbolic execution and then you are doing formal verification but it shouldn't video the

way you want it shouldn't be like a mixed up in different order it's really a process and basically that's what is I think missing in most developer mine I think one um common question that we get around when we do like fuzzing workshops and sharing um essentially how to fuzz is that if the fuzzer passes um then it means there are no bugs which it's it only means that there are no bugs within that iteration and that those attempts that it in those tries that it attempted um I think the other thing is that um the the invariance in general any

tooling that you use to test your invariants they're only as good as your invariants are and if you're invariants are wrong then your tooling isn't necessarily actually going to tell you much about your code which is why it's so important to actually start with like what your code is supposed to do and figure out what those invariants are I mean ideally before you even start building it but um that gives you a better idea of what you're aiming for and what your what your code is supposed to do and only then Contours actually be useful and helpful in determining whether those actually hold um sometimes users on code saw will use it to search for dependencies which

wasn't really something we like anticipated but uh it lets people dig into like the supply chain of the dependencies which you know we don't at least in ethereum there's no like widely adopted package manager and so kind of highlights like the need for some of this basic infrastructure for developers that you know it's very common in web 2 programming languages so we're kind of missing a lot of that key infrastructure because I think a lot of the focus is on you know the logic and the contracts themselves when it comes to tooling at least which is you know of course very important as well um but yeah it shows us there's still some more work to be done on the infrastructure side

so one of the reactions usually when uh yeah I try to show like a formal verification tool is uh that okay this is great so I need to write a lot fewer tests but that's kind of not the the best way to go forward because in some sense tests are specifications right with us if you have a code with a lot of corner cases well crafted tests really tell you what what the spec is so uh yeah even with all these uh verification tools and static analyzers tests are still like the the first thing that you would need to to write so it's like these tools are not like

Panacea so they don't get rid of the need for writing good tests I I don't have exactly good stories of user feedback but uh mostly comments on things that were said earlier and and also controversial statements uh so first of all I'd like to point out that the tools are Continuum right I mean there is perhaps formal verification against specs on one end but everything else is is very much a Continuum it's not just a static analysis static analysis and symbolic execution and fuzzing could all be part of the same tool like in our case they typically are

deep symbolic understanding of the program could very much go inside the static analysis tool it could be trying to derive specifications we're trying to do that uh one thing that I think might be a controversial opinion is that the the protocols that I want to use formal verification on are some of the worst written because I cannot understand the code fully in full confidence as a human and there I definitely want some formal verification tool where I can just write in terms that I understand the specification and have the tool tell me yeah it's true after a deposit of zero the shares remain the same oh great

because I couldn't tell that myself as a human that indicates really badly written code so that's kind of a controversial or negative opinion but we have to see that what we're doing in this space is whereas pushing the limit of tooling and their contribution to programming we are having very very Advanced tools and this is very good to see we are seeing formal verification fully used in practice for protocols that manage lots of funds now where what are the limits there we're discovering them in this community we don't exactly know it's not like other communities have done this other software development domains have done this we are at the Forefront there we will see

what can be the impact of all sorts of tooling on automating security of software since we've had a few controversial opinions already I'm just going to open the floor for more of them so bring your bring your best and most controversial opinions now I have a controversial opinion for developers probably not to my peers but if you've tried a tool and didn't like it or couldn't manage to use it well and it was actively developed for over a year you should give her another chance most tools have had some amazing

development in the last year or so and they could bear very little resemblance to the experience you've had before it's very easy to write things off oh I've tried it like a year and a half ago it was too complex couldn't run on my code you should try to do that again you are missing out um yeah completely and they actually should put that in the CI CD because the fact that the tool will evolve a lot will also put on Charlie feinbergs in the future I'm thinking typically of your the studio you mentioned that about the fact that slitter actually find bugs like on

some contract and if developer was using Slither as I will they will have find the bug the bugs sorry the question I will ask is do the bugs that was detected in this Duty was actually bug that was already on the tool at the time the contract was available or is it like new detectors on slitter that actually find the bugs actually did a close analysis of different The Depths between those contracts um so it's against the if I'm not mistaken the current version let's go there okay any more controversy

we should have competitive teams I I can yeah I mean we are all against formal verification so that's uh that's uh too bad what no I'm so my controversial opinion is yeah formal verification is there is way too much noise about that for not that much uh privilege in my opinion so it's a really really controversial opinion but from yeah I mean it's something that is proven to be efficient and so on I also disagree of what um you were saying previously regarding like we are completely new in this area like we are like on top of the game and so on I mean I think most of you in the

room have take a plane to come here and I think typically the Aerospace plane security is kind of a top of what exists in terms of assurance make sure that if you're playing get any problem you will get multiple backup and so on who are not even close to that in in my opinion on Smart contract so there is definitely some room to Improvement and I definitely think we have still a lot of tools and stuff to to do and yeah we are not on top of the game on that clearly not in my opinion I do agree that there's a lot of tools that exist for developers to use to make

sure that their code is safe but then that puts the onus on developers to actually integrate them use them use them properly and use them in the way that they're intended and I think that's one area that um it's it's a very it's it can be difficult to do because people just want to keep writing code and keep building new features or keep building new things but just taking some time aside into thinking about security and thinking about how to write safe code while you're developing code goes a long way yeah so if if I can defend a little the earlier statement and then we can we can

get back clearly there are domains that have had formal verification in the past I mean uh in processors in Hardware uh subroutines have been verified routinely since the uh Intel bugs like the AMD square root routine has been verified uh control systems in trains in airplanes have been verified general purpose software development completely open that can do any calculations whatsoever it's not a closed control system has not been verified as aggressively as software in this domain so we are in in to a great extent we are at the Forefront and I do believe in formal verification but I do think that the

extent of its applicability and its overall impact in the industry is still to be determined we don't know whether how much it will capture of the security the Assurance of the overall space I mean I think everyone will agree to that but it's uh this the this community is making great strides towards popularizing uh formal verification with various uh companies uh here well represented but uh yeah I think the truth is somewhere in the middle uh there uh but when I said before we should have competing teams I meant perhaps the people who will be convinced of the value of the tool will should not

be the people who are developing the code in the first place just like we have coders and Auditors uh to some extent it should be for some kinds of tools not for all of them it should be coders and quality assurance Engineers something and I know that's kind of an old idea it's tired we we kind of don't like the sound of it but you do need some sort of competitiveness there you don't want to always be trying to convince the person who developed the code alone you want to convince an adversary so to speak that's what I meant earlier yeah so another reaction to the formal verification hype and maybe tying into

the question about uh surprising customer reactions uh we've found out that for different people it could be a lot easier or a lot harder to come up with invariance or specifications and it seems to be somewhat of an independent skill uh towards a good code writing so people can be really good at writing uh complex or efficient smart contracts and struggle with writing specifications and vice versa and uh yeah I don't know if there is a good predictor for that trait okay I just want to leave like two more

seconds in case any last minute controversial thoughts came to the surface but it seems like not so much um Okay so we've talked a lot about smart contract security that's just been ambiently around but there are also many other layers to like the D5 stack right we have the protocols we have maybe some bridges we have wallets we have all sorts of stuff so what parts of the stack do you think could be better served by existing tools and how would you like to see that you know change moving forward I I think this the rest of the stack is

definitely under threat but it is very much a web 2 security issue not so much a web 3 security or device security issue so in a sense we all recognize that there is a need there but I don't consider myself at the Forefront of how this can be addressed what can be the next huge step in the web 2 security space in in anything that's outside the smart contract space anything that's outside the core crypto space let's say um so I can mainly speak um but basically for the in clients and auditing clients which is what we are

doing basically on a day-to-day basis so typically there is clearly like a tool on that both at the language level like um rest go and so on there is some toolings but nothing like no extra stuff for blockchain uh there is definitely a lack of tools for blockchain framework I'm thinking of substrate Cosmos and so on um so there is a lot of documentation and so on but in my opinion there is definitely a lack of tool of okay I'm building a substrate blockchain can you find out if I'm not like preventing any API publicly that shouldn't can you

verify a bunch of stuff and so on so clearly something is missing in the ecosystem and even in time of fuzzing I've been doing fizzing on layer one and chain for quite some time and different shell phasing as well and typically this kind of stuff is something that is only financed by the foundation and the fact the foundation need to do the work and um and and put money on the table because of course a differential further uh like uh the one I built with Sigma Prime become first is only applicable as well if you are doing burgundy and want

to find works or either if you are the foundation and you want to find bugs on on your channel otherwise it doesn't make sense to to to build the tool as a product because it will be only usable from one specific scope so typically in such cases those tools need to be built by some people's financed by foundation in in the same way that Foundation Finance for example multiple clients to get diversity of clients so in the semis I need to finance these tools but it could it's not possible to make it a product on itself so it's more like a pure research and development and and

securing the the chain itself and it should be the same for all of them I think they're generally many areas of growth that like automated tooling can extend into like for example for Bridges um yeah you can definitely test like the smart contract on both sides using like the existing tools but I think there's also a lot more room for additional automated tooling and like the Locking of funds on one chain the minting or minting and on the other or vice versa and so that kind of ties a little bit into differential fuzzing in terms of like if there's a reintegration of like

different functions on both chains but generally just more kind of end-to-end tests and and kind of being able to test more there there's a lot more potential that it's going to be very protocol specific and very dependent on what you're trying to build what invariance you want to actually hold and what you're trying to test is that it's not necessarily like a one size fit all just because of how unique and how different all of the existing contracts and Protocols are outside of just the realm of smart contracts yeah I think one area that uh could use some more attention is

it's kind of like fuzzy area of like behavioral security so this kind of extends to like wallets um you know having standardized ux's so you're not just like signing a bunch of gibberish like zeros and ones and letters um even to like standardizing you know Audits and package managers so that um users and devs and security researchers have confidence about what they're looking at and they can actually point to like what what things are being imported and what versions of code are being used um and so all of these kind of contribute Downstream to security and so you know like web2 they have like this like audit uh standard called like sock 2 and so you know maybe at some point like D5 or crypto has its own version of sock 2

where it's like oh this thing is like had Slither run against it or Torah or whatever and so on and gives a lot of users more confidence and actually helps us like push the industry to better adoption because each user that has a very poor like experience getting rugged or you know just making some mistake like they're probably not going to come back so we kind of need to like dedicate some more attention to the ux of crypto and the security implications there I would like to extend Gary's answer that so I think it's very important to also look at uh security from the user's point of view as well so I think web3 in

general has brought in a lot more ideas and Notions about like access control with Notions of proxy accounts account abstractions and so on and it would be interesting to have tools which exhaustively uh check if there are any uh ways of accessing your account without having the the credentials you know so these kind of basically tooling which helps you to uh yeah to verify that the access control system works as intended great so it looks like we have about

five minutes left so I'm going to ask one more question if I'm a D5 developer I'm starting a new project first of all how should I evaluate you know there's so many tools how should I evaluate what to use and how can I think about setting up sort of a long-term tooling pipeline I would say start with specifications start with identifying what your code is really supposed to do before you even start writing code that way you have an idea of where your target is where you're aiming towards and like what you're even trying to build

and then really just integrate security tools like Slither and Echidna into your um CI pipeline just to make sure that every time you're updating code you're adding you've decided oh my code is going to support a new feature run Slither on it write a small fuzz test on it um making sure that you're essentially up updating and making sure that that those that the static analysis results are triaged and the fuzzing is up to date according to what you're trying to build and kind of keeping your specs up to date I think that's the perfect way to start because if you start with that then you you're essentially growing a list of your specs and like your unit

tests and and your fuzzing tests can essentially help with identifying what your invariants are and it becomes much easier to actually create like a mental model of your code base and identify like what and where things could potentially go wrong either in the future when you update it and like add a new feature or just like make changes to your code code it gives you a much better idea of how you set up how you have set up your code and where like potential problems are are likely to be I would say first of all there's lots of tools to get started with a new project right now or for developers that are

just getting into the space or they're they're launching a new project so obviously they'll start from the free ones they'll they will run Slither but first of all you need to write lots of test cases and then you need to write parametric unit test cases like good things that do environment invariant based fuzzing and we have Foundry has an amazing facility for that best that you can get in almost any software development domain so you start from those you start by writing your invariants and having a fuzzer that knows about invariance generate tests you go and you run a static analysis tool and then you you are there and you've done the basics and you're thinking do I need to write specifications do I want to write specifications am I skilled to do that

we're already we've already eliminated 98 of the developers right there because at least in most projects there's not even sufficient test coverage let alone all the advanced things that we're talking about but if we're going to something more sophisticated uh yes you you then think of of all the a little more advanced maybe proprietary tools uh maybe writing specifications maybe using the Satora approver in a pay-as-you-go way or commissioning if it is going to be a project that has the budget for that but that's kind of the gradation but at the at the beginning level there's amazing tooling already

um I mean like I was saying before I've been uh very pleasantly surprised even by the I don't remember the exact terminology in the docs but the parametric unit testing in in Foundry just write in variance and I'll generate good tests for you within those yeah so uh I would say like the first thing is to start with the clear threat model and then also clarify the basic trust assumptions that you have when you're building uh the system or the protocol and there's actually a in in the tooling landscape there's a inherent trade-off between uh

Automation and expressivity of the kind of bugs that the tool can detect and it's you can't have usually both of them right so you either go for the particular use case that you have you either go towards like automation where you you get uh security guarantees but only for a particular class of bugs or if you want to verify like the consensus mechanism of the protocol itself then uh you would have to invest a lot more time and effort and it it's always yeah worthwhile to think if it justifies the the time and effort that you invest in

that yeah I agree with my peers you should definitely start early if possible try to use uh yeah the the more generic less specific tools um first and one important thing that I want to add is that you need to evaluate your testing as you go if you find lots of vagina specific error fever code obviously you'll want to focus more there and maybe controversially if you don't find any bugs that's even worse for you because then you don't know you have more more unknowns for you like I would be even more paranoid if I can't find many bugs in my code but definitely do some revaluations as your code

matures and uh remember to do this once in a while instead of saying hey I have no new bugs that's it I'm good to go not at all and I think also something to um for the for the beginner developer it's also reuse existing Library I mean we don't have anyone from open ziplin but I think they are a good example of basically some kind of best best practices that you should do there is multiple templates of contracts so there is a use huge chance that you can basically start from that and using what is already provided to you as a basis and then just ramp up on top of that so

I think it's also really important to actually take a look at what exists and is already secure by by default I would also just add uh not like in addition to not Reinventing the wheel just start small in terms of like what you're actually trying to build and don't just create one piece of code base that has like 15 different features and then um treat that as your proof of concept just because it's going to be really hard to understand how how is that code supposed to work and what are the potential impacts of a code base of that size so if you start small instead and start with like a minimal viable product of what your code

base is intended to do in the future and then by some version you'll have essentially what your code is end to end and you do that piecemeal it's much easier to actually understand what the impacts of adding new features and new code is great okay I think that's all we have time for so thanks to all the panelists thank you all for coming and listening we really appreciate it [Applause] thanks Fraser and the panelists for the great panel so we now take a short break it's a coffee break and we meet here

again at 4 30 and the session is going to be a panel on monitoring so yeah please take a break and we'll see you back in 10 minutes thanks thank you [Music] [Music]

thank you [Music] [Music] foreign

[Music] [Music] [Music] [Music]

foreign [Music] [Music]

[Music] [Music] thank you [Music] [Music] foreign [Music]

[Music] [Music] foreign [Music] [Music] thank you

[Music] foreign [Music] foreign

[Music] [Music] [Music] foreign

[Music] [Music] [Music] [Music] [Music]

[Music] foreign [Music] [Music] [Music] [Music]

[Music] [Music] foreign [Music] foreign

[Music] [Music] foreign [Music] [Music]

[Music] thank you [Music] foreign [Music]

[Music] [Music] thank you [Music] [Music] foreign [Music] [Music]

[Music] thank you all right welcome back hope you had a good coffee break so we're going to get started with the next session it's a panel on monitoring the panelists are Alexander from pessimistic security uh Carlos from foda Foundation the mantas from lossless gal from hypernative Mir from cyber's Assaf from

iron blocks Andy from bloxic and yanev from hexagate and it's going to be moderated by Ernesto from BTD Labs thank you please give them a warm welcome [Applause] yeah so hello everybody as represented like I'm I'm Ernesto from beginning Labs we are working on ABI protocol previously I was like yeah the CTO team that created the protocol and but yeah today we have quite a lot of people here like and the idea is that the there

is a lot of talks of security procedures and security tools during this DSS and some of them like is quite a lot of them are more focused on pre-production but we we want to talk a bit about what happens when smart Contours get deployed when you have production systems and all the tools that all these people here what they can help for for these kind of systems so yeah maybe the elephant in the room first that there is a lot of hacks there is a lot of capital getting exploited like a

weekly basis sadly on on defy on blockchain systems so looking at that can we prevent that is the big question is it realistic to to prevent them and maybe if you can give your your thoughts about that and at the same time maybe you can present yourself like if you want a bit more if you can start in order so Andy yeah thanks my name is Andy and I'm the CEO of black sack um he's a security company I'm focusing on build um interesting scenes for the um divide and for the production area so we um we have a couple of tools and to

monitor the ongoing threats and ongoing attacks and we have some internal systems to you know to trying to block such threats and we also provide some plugins and funnel analysis tools to the whole Community to and fully understand how they um to fully understand how the funnel goes without their attack um yeah so uh this is basically an introduction of me and um the company so in terms of your question um so can we detect the uh the attacks and can we preventing them I think the answer is both yes and no and uh from one perspective um we I think every guys here are the

experts in the device code area and we are every day we are developing some methodology strategies to uh trying to detect the D5 hacks and if one person asks me that anything can you detect all the happening attacks my simple question is yes but that doesn't matter because if I Mark all the transactions as malicious transaction as attack transactions then suddenly I can detect all the hacks but the problem is that we need to maintain a balance between the false positive and the first negative right so if we develop a product for our customers and we have a monitoring annotating system for our customers to be if our system can report like a 50 or 100 alerts or even 200

every day then no one will look at your system again because most of them are false positives so we need to maintain a very good balance between false positive for snacks that's what we are trying to do inside Block Set we have some um a good strategy you know we're trying to detect that attacks but we're trying to maintain the false positives I think uh so um from this direction I think in the future we uh by the efforts of the community by all these guys working in the security Community I think we can detect most of the attacks not even none of them but we can detect most of them yeah certainly yeah yeah let's let's keep it a bit short

like an introduction because I think we have plenty of topics to to discuss all right I will make it short so my name is meredolev co-founder and Cito with cybers Cy versus AI power threat detection and response platform and proactively securing different protocols and other crypto businesses so about your question so it's yes we can detect them but we cannot prevent everything right and so we can detect attacks on D5 and we saw it recently we detected the poly Network's attack and the multi-chain attack that it was more about private key leakage servers detected them in real time also shared the alerts with the community community

via our Twitter Channel but as Andy said it's not only about detection right you can alert on every transaction but the false positive will be very high so it's about effective detection and actionable insights and actionable insights are very important for detecting an early to give an early warning and for potential trades automate response but meanwhile maintaining a low false positive rate in order to prevent pose of protocols and contracts right so this is a trade-off always between recall and precision and wheel servers we have almost 100 years of experience in AI detection and AI application so this is what we are doing in Daily Miner

yeah so uh I'm dominant as politis I'm co-founder and CEO at lossless uh basically we started lossless with idea of building on chain uh hack prevention and mitigation system uh which is basically which allows you to freeze and retrieve assets from from like many different exploits and we already managed to to freeze and retrieve for hundreds of thousands of dollars so I guess that answers the question that yes it's possible to like spot and and like manage retrieval of these assets but very early while building uh lossless on-chain mitigation platform realize that you also kind of need to have a

good detection system in order to spot these incidents early so we started building lossless Ages which is our current focus and it is a threat detection system which which yeah is kind of open for everyone to use and and is powered by a lot of heuristic-based rules that kind of I guess a lot of other guys here use but also the we use different AI modules to to help us to to spot these incidents so yeah yeah that's lossless hi asafeli CTO of iron blocks prevention and detection of malicious activity on the blockchain I believe that we can

prevent most of the attacks that happen today the ones that will be much more difficult their the unknowns of the futures but most of the attacks today are possible to prevent yeah hey so great being here and thank you sir Torah and the rest of the sponsors of Hosting this event my name is Yaniv CEO at texagate exagate is a web 3 security provider we build a real-time web 3 threat intelligence system that basically provides early detection on

all types of web free threats ranging from cyber exploit to financial exploit to phishing fraud and scams regarding your question so so first you know I think two years ago defy summer if you would start try to build this kind of panel you wouldn't find anyone so I think with everyone that are sitting here in the panel and I'm seeing Andy there from forta so uh you have enough people in the space that are working on this problem each and every day and we see this from the tweeters of everyone here that everyone can detect exploits I'm sure not like 100 of the exploits

are detectable but with time we will have more and more coverage when we started the company we wasn't we weren't sure that we will be able to have like such an accurate uh detection models but luckily because the nature of blockchain because the data is there and you start to see these patterns and you build the right models exploits and other threats are detectable and then you need to optimize and we put a lot of effort there and I know that the rest of the the pack here is doing the same thing on early detection right now of course not everything can be already detected like Atomic exploits right luckily today with exploiters so running an exploit

operation takes a lot of experience and they live this like traces so so many types of hacks are detectable but I think that detection and again we share with everyone here and and I think like the next step is for collaboration in the space where like detection models and companies will collaborate and send the alert to like a security orchestration platform where you will have the right incest response uh procedures and you'll have a better coverage because it's not like one company because each and every one for example uh although everyone are saying Ai and machine learning or security

heuristics you take a different approach you have different Personnel you have different ideas right um so I think that we'll see in the upcoming year more of this kind of collaboration and orchestration that will improve the security in the ecosystem for sure I would say that most of the hacks are detectable even Atomic ones um it's just a matter of also from the protocol side of things how they should build their procedures and we'll talk about it of course in the in the panel I think how you need to orchestrate everything in order to protect the system okay

hello everyone I am gal from a hypernative hypernative builds a platform to detect and prevent all sorts of risk from on-chain from security to financial governance and community-based risk uh I I think in addition to what was said here I think that in the end when we look at security and any other domain or industry security is always a layered approach like it's not it's not a zero zero sum game there isn't one solution that can fits all we need to use a combination of solution a combination of techniques and combination of preventive mechanism to really protect in the end the user funds

and the community which I think invest and put their money their identity and Trust in the protocols so I think everyone here are trying to increase that awareness and create tools and I think we all obviously believe that what we are building can help and prevent more hex and exploit and I believe it's it's an ever-evolving process of adjusting right adjusting the Security Solutions adjusting the attack techniques and trying to find more and more of these risks and mitigate them hi I'm Carlos Corolla data scientist at Florida at Florida we do

real-time network monitoring to find threads and scans and so on and going back a little bit to the question of can these threats scans be a tactic the answer is absolutely just wait two hours and someone will see that like the funds have been gone right or you're always going to find it but if you find it two hours afterwards absolutely pointless so it's a little bit what what everyone has been commenting on can we be early enough so that you actually can take action and can defend the funds or can help defend and not just find that something has disappeared because you're always going to find that something has disappeared a posteriori anyway so hi my name is Alex I'm CEO of

pessimistic security Carlos stole my point about that about of course we can detect hack but I would also add on this that even knowing about the hack that is all that also has already happened is USB can be useful for the protocol because the faster they know about it uh so we all remember the case with the running protocol when they didn't know about the hack like seven days after it happened so uh even even two hours after the hack happened it can be still useful uh in the knowledge about it can be still useful so and I would also add on the

point about false positive rate uh that the earlier you can throw the alert the earlier you can launch the defensive action the the more you are ready to you know to to deal with the higher slightly higher false positive rates I mean that uh if you if if you react within five seconds and have for example false positive rate of 10 it's better than if you have false positive rate of zero and you react within five minutes this is my point so and I think everyone here agrees yeah and I forgot to uh introduce myself so

uh yeah we're at pessimistic security we have been working in webpage security for six years and we performed hundreds of security audits we developed several tools for developers mainly focused on security also on static code analysis and last year we started developing spotter the product that is aimed at alert at detecting and preventing the hacks as early at this as it is theoretically possible yeah let's follow up in in that topic is a pretty interesting one of a false positives so a well as as we know like the big majority of device is quite open in a lot of

cases controlled by even smart contacts like governance in the case of Fabian let's say a and false positives it feels like that if you act and you do something on false possibly you can create like some problems so what is your take maybe we can yeah we can have like two or three people commenting on that like Assaf starting what are the problems that you see if a protocol that if I protocol reacts and it is actually a false positive a higher Force positive and react fast I don't think that it's a good solution because damaging the user experience that much

it's not something that bring a lot of adoption to the market and a lot of protocols and confidence to this ecosystem we have the ability to minimize the first positive to a very low number and I think that some of us reach that small very small number and this is something that we can accomplish and we don't need to to just uh let it be a number okay yeah maybe yeah Alex that you were

already talking so like what do you think about false positives like do you think they can be a big barrier even for the adoption of web 3 monitoring tools because you know from the perspective of the protocol like even my personal experience is that yeah if everything is really good and it seems that it will prevent but if we if a big protocol like takes like the decision of freezing like uh let's say a pool this could be quite damaging if uh like the alert was not correct yeah it's it absolutely is it can be quite quite damaging sure and this is why we should deal with this problem of increasing the you know the both uh the Precision and

recall um however I think that uh false positives are inevitable if you want to act early so we still need to deal with the risk of false positive alert and I think that uh so yeah it's inevitable yeah and now we uh all we have to do is to uh is to design the protection system for which some degree of false positive rates would be not critical for example if we if we discuss the architecture that you personally uh that you personally created for the monitoring

detection of Avia I think that it's pretty reasonable because it's uh it's a decent it's decentralized in a way and it involves several types of reactions not just you know just pulling the trigger and posing the whole protocol you know then nothing can happen and all the product all the Integrations are damaged in immediately etc etc no um we can just perform some minor actions for example limiting the funds withdrawals or limiting transfer size inside protocols and these could normal users won't even notice such such minor actions but they still will be

very [Music] um how to say so they still will be able to prevent the hack from happening so I won't take more time I think I can go from forever yeah but yeah and and related with a similar topic is it feels that there is like some big difference in instructors like of those and like even the teams themselves and their approach to Security on web3 versus uh well traditional software and security related with traditional software so do you really think that there is something really fundamentally different or it's just a matter of that we are too early

like and this will just improve over time maybe mayor you can comment uh yeah so it also connects to your previous questions about false positive right in the end organization need to build an incident response plan right so if you want to protect yourself from specific attack vectors maybe in this attack Vector there is less what's positive and then you can be much more reactive versus for example private key leakage that you we will face more false positives and then you need to bring a different response so you need to come with a response plan and this real-time monitoring and response incident response plan are well established in the traditional Finance right you can

see them in every organization and basically this enables the organizations to come with a structured way to deal with incidental response because during an attack there is a chaos you need to Define who will be what the communication the responsibilities the decision makers so all of these plans should be defined before the incidence response plan right and together with the real-time Monitoring Solutions it can bring a lot of benefits to the device space so we don't see such planes and such Monitoring Solutions mature yet in the device space but I think that's a manner of evolution right it will take some time but we will be there yeah maybe the Mantis you you have

anything uh yeah so I I have a few points about this first of all like we talked with one of the projects that mentioned that David better stop their protocols like three four times per month then lose a dollar so like it seems that some projects are kind of okay with you know false positives and reacting on those uh but second I think we are still quite early in our like Monitoring Solutions so they should be threaded like carefully and like you I think like you can rely on them and they are pretty reliable but uh as as my colleague mentioned like you really need to have a good incident response you know and and have a good plan okay I got this trigger

this is for smart contract a what do we do next how do we trash this who is the person responsible for triaging this game maybe in the middle of the night who is responsible at night so the problem is that a lot of current projects don't have that set up yet and and yeah that's that's a huge problem um so yeah yeah following a bit on that like because it's I mean it feels quite natural you know that the like web 3 should learn from from traditional security so which is the role that you think that the tools themselves because how it works usually in web 3 is that somebody puts example uh or and even not on the product side but more on the

tooling side puts example of how they should be used and and well then there is some adoption so for example like what do you think which is the role of like basically the teams building the tools on educating like uh there were three developers like and and trying to build Frameworks uh procedures yeah that's uh that's a great question um and I must say that we want to and we are starting to building that and um like inviting everyone here in the panel and in the group to to collaborate on that to build this open framework for best practices of how a protocol should be protected and I think that companies

should work on that together with the ecosystem so we'll have similar thing to what we are seeing uh in traditional world where you have Security in depth in layers it is starting from you know security by Design because if you design your protocol the right way you can prevent many hacks it continues to um to auditing to forward verification to appsec to monitoring to security orchestration interest response red teaming which is let's play and let someone hack us and see how we react on that because when there is a hack and we've been in

like dozens of War rooms it's chaotic like everyone is asking who is connected to binance who is connected to Circle who can help us trace the funds right and it's of course it makes sense today because the ecosystem is still not mature but there are so many things that we can learn from traditional Finance where you have like procedures in place you have playbooks in place and I totally agree with what domantas and mayor just mentioned um like this question is just a segue to just what what they answered right um I think with that like companies like everyone here in the panel should offer the ecosystem like this

Frameworks again in an open and Joint initiative but also I think protocols and this comes like to you uh Ernesto and like we're seeing that with other Forest protocols should also like raise this awareness because I think that when you'll have these Blue Chips protocols that will start to raise the awareness um everybody else will follow so it's kind of a like a joint work both from the security companies and the Bluetooth protocols maybe your thoughts on on the topic of procedures and so yeah sure uh I think

when I look at the traditional security like where where is the focus so there is a very big assumption uh that you will get hacked like um a lot of the budgets and a lot of the tools that are used today in traditional security are around finding finding hacks finding malicious activity in your web application or in your network and then limiting the Blessed radius or limiting the exposure of the tech and I think and I by the way talk about this later today but I think that we we haven't come with that mindset uh in in crypto and and when we look at layer tools and more infrastructure optimized infrastructure

that is being built more code will be more complex like there will be more complex application and I I think hex and exploit will not stop they will just increase so I I think we need to get to this mindset of really thinking uh I think as Yaniv said as well fit doing the right processes building the right design inside the smart contract that address this like how do I limit something bad from happening when it does happen how do I have the right processes in place even in a decentralized manner to stop this from hurting and I think there are there are

solutions like we are building these Solutions and we it's a lot of Education because a lot of the teams that are building applications today don't have a security function in the team so there is a lack of talent in in the area and I think a lot of what I think everyone here is trying to do is also to wear this to increase this awareness and and to be this function to all of these applications yeah and following following a bit on on the topic maybe Carlos you can comment on that live but is there because when you explain like and what we are just talking it seems pretty obvious right

like that if you can protect the protocol like and if the tools kind of work like even being an early stage or not they are just net positive why not why the movement is still starting or almost starting nowadays and not one year ago or two years ago and is there any fundamental difference between like the the web 2 and web 3 teams like it's just what God just mentioned that is lack of awareness lack of security procedures or what do you think is I would definitely lack of awareness is there but it's also difficult because it's so flexible when you're working the web3

space like if you are working in in web tube it's much more limited things that you can do whereas you can have like almost whatever going on in a contract and that's already like a starting point and on top of that everything happens so fast all the time with a lot of limitations like for example if you try to use machine learning models and you are trying to run real time it's since you want to be decentralized and you don't want to have everything together you are going to face at some point problems of okay where do I have my history of data like you cannot keep collecting things in each one of your decentralized nodes because you're going to explore them so how do you want how can you do machine learning where you

need like six months of historical an address if you cannot keep that um that information in memory and there is no real way where you can keep querying all the addresses that are doing any type of um anything in a network right so there is like on top of it being very new and it's something that it's actually difficult to do like it's just wide and they're a part of a part of it it's also being learning on how to do things and like putting things in the right direction and like starting creating Frameworks and everything that we have in commenting but that also is going to take time and it's it's moving it's definitely moving in the in the last couple of years and it's going to keep moving and it's going

to keep better in better and we are going to be learning how to do the things and we are going to be improving all the and all the systems and being more safe but it's not something that we are going to learn overnight because it's actually a difficult problem what do you think Andy like on the on the top here thanks for questioning I I think there are a couple properties in the website compared to web 2 that makes the web stream more vulnerable and more attackable so I think I can sing a couple of scenes one of that is openness in the web screen it's everything is open the smart contracts open the source code is open right so everyone can look at your source code to located vulnerabilities but in web 2 uh even you

want to know cut the availability inside some bank system you cannot do that because you do not have the source code right even you can reverse engineer and to do that but it's it's highly reached about so I think openness makes the web stream more vulnerable than sorry not even one of which makes the web3 more open but I'm open to everyone or even to the attackers so this is one of the point and the second is that some mechanisms inside the production makes the attacker much easier like the flash known since right so in traditional Finance system we do not have National like if you want to attack a protocol you need to have one million US Dollars then this may make most of the attackers they cannot do that because it do not

have one blockchain you can have that right you can use a flashlight on two borrow like 10 millions and dollars to announce your attack so this also make the scenes worse and the researching is that we do not have enough tools inside the webstery um to no credit the vulnerabilities because um I'm a professor in um in universities and um I I can see many students they are working on a traditional web to a security area they can developer tools to locate some sophisticated availability inside some traditional software but for web 3 smart contracts their next very useful tools we can locate some vulnerabilities that have

the business logical oriented because the business logic or anything is a logical bug if you want to um detect logic back like if we want to develop a filing system to The Logical back how to mutate the inputs how to uh how to detect dependency between the different intact inputs and how to um how to provide a very good Oracle these are challenges we have not solved in the website so we Knack of Tours so all these things make the web series a very um on good place for attackers but unfortunately a very bad place for protocols yeah I think that's my points yeah some idea that was commented before

is that well it's possible to to detect that is clear like is is possible to prevent a at least at up to certain point uh but then about the levers like that needs to be exercised like on on the particular protocols that it could be an option that uh partially like stop the deposits of certain amounts like and and be focused on a subset of users versus the others uh for me that at least to think like that monitoring is not something that it should be just thought once the protocol is deployed but something that should be taken into account like while you are actively developing like the system so maybe for example Alex like uh when do

you think is like a good moment to start like already thinking on okay I want to apply this kind of tool and it will be important to have this mechanism of my protocol in order to protect it's a great question I would say that as for now we are so early and we have so little actual battle experience with the threat prevention with the active I mean active threat prevention when we actually when we really prevented some hack from happening and we didn't see a lot of unsuccessful hack preventions and they will also take place somewhere in the future

so the best practices are still to be developed somewhere maybe a year from now maybe further further so I think that as for now we are in the place when we should just experiment with things I think that at some point we will have something like open Zeppelin library for threat prevention and you could just just integrate it into your project and and just just be sure that it works that okay I can set up any kind of monitoring now and it will just work but for now I think it we should set up you know a big

discussion with the protocols with customers like with the liquidity providers in order to find a solution that could feed everyone in the place not only I mean not only defy protocol owners I mean Dow participants because liquidity providers are also very important players and the retails retail customers are also important people in this in this ecosystem so I think with all with with all being said I don't know probably that is like the most responsible answer like the I don't know but yeah something that you mentioned like you mentioned the different

participants right like on like it's not only about the the protocols developing I mean the the teams developing the protocol but liquidity providers and so on and of course like then there is like multiple different systems like so one question that maybe on this like I want the opinion of multiple one of you is that if you can put an example like more than an example like which is the system at the moment or systems one each that you think makes these monitoring techniques to shine so let's say defy versus breaches versus like security of funds like on on wallets like yeah if you can maybe go

yeah I I think that um and I'm referring a bit to the topic that we talked about previously I think that we need to at least at least my personal thinking is that we need to to change the like change the mindset right like we talked about all the challenges that right that web3 and the centralized system brings uh to security but the way that I see it is actually it's an opportunity because quite frankly and I've I've builted systems before in web true building a hypernative on web 2 would have taken us years to get the data and the and the vulnerabilities and to look like the

fact that you can see all the code the fact that you can see all the interactions with the code the cross all the chains and see it historically I think is a huge uh of course it's a huge Advantage for attackers but it's also a huge Advantage for the protect actors and the people that are building the security so I think that that if we'll look at the characteristics of web tree system and actually leverage them we can build Solutions together that that will be even better than than solutions that are built on web too so to me it's like D5 of course D5 is is a target for a text because right like the the gain is

very clear for for a hacker in the end hackers have um like a very you know they go where the money is and where they can get the most gain in the in the simplest manner right like hackers don't like to work hard if possible and this is what I think what we are trying to do here right like make their life harder yeah maybe mirror your opinion like system that is particularly good for yeah as gal said so I think it's eventually an evolution right we will learn from every incident and every attack and we'll build a better system and a better monitoring and response systems but eventually I I believe that

AI can bring here the advantage because in the end also it will be a cat and mouse game right the attackers will be more sophisticated and they're the protectors and so on and so on and then we'll need to come with novel ways to detect and in the end you know with D5 protocols I would say it has a huge surface attack right it's not only an on-chain it has also UI right it also has a wallet it has a contract so you need to protect it as a system So eventually I believe that we will come with the holistic system that will be able to protect different protocols yeah so I think we should use uh 2080 per simple principle here because

basically the biggest tvl is in D5 protocols and of course naturally the hackers are targeting those so of course we should also focus our monitoring uh on that but then going deeper I think what's particularly interesting to monitor is the the forks because previously we we noticed that like a lot of hacks that happened where on projects that decided for a well-established protocol but then did some changes maybe in the tokenomics or like some other adjustments and in the end developers maybe didn't know what exactly they're doing they may be added or removed some code and that led to some like bathmath bath calculations and and basically with

those protocols you have pretty clear understanding what they are supposed to do and they how they are supposed to work but then if you know that this program you kind of can apply the same monitoring rules to all of them and then see what's the the Delta there how they are like different and and then if the Delta is big enough you can kind of understand that maybe there's something wrong with that protocol so I think yeah that's that's where I would put my eggs basically okay yeah maybe you yeah so as for the protocols out there right now I think the most obvious one that can use the monitoring are of course the bridges uh there are most of the logic is option and uh

it's uh logical that they use it first of course the D5 protocols as most of the money in it so it's obviously the best approach to go to these customers first but we will see it first of all it Bridges then we will see a standard for security at D5 protocols in 2016 audit wasn't uh wasn't the standard for security yet 2017 it became a standard for protocols now monitoring becoming standard for protocols and we will see I believe a prevention that's going to be a standout

also for the protocol some of it will be on chain some of it will be maybe in the other layers of the ecosystem yeah yeah maybe following on another item that was mentioned that a well everything is quite open on defy but that includes also like giving the teams that are contributing to a protocol so one potential problem that can be can be ambitioned is that the malicious attackers like will understand so deeply like the technology of monitoring that they will try to like uh well avoid it and still do the attack so how do you think that the this because in

traditional software and security the systems are of course way more clues you can have privilege higher privilege that are enforced but when let's say an example like of a dial on where you have like three different teams and you need to provide them or provide to the dial like certain monitoring tools like so how to do it in a way that the attackers don't know uh how are the the techniques so maybe Yaniv you can yeah that's a great question um so I think first having like the fact that we're decentralized is very challenging it's like among other things like I think it's like it's top three

um challenges in the space but I will enter it like and also combine and answer to the uh to the previous questions I think the way to deal with that and to deal with like system that will shine from like using Monitoring Solutions is basically combining security by Design procedures and tools it's like when you want to build the Fortress you won't build it like in the bottom of a valley but rather on top of the mountain right and then Things become much easier so even if you're building um like a protocol and you know that everything starts centralized and then along the years it become decentralized

you need to think ahead of time of okay let's build it and do security by design for the moment when we will be fully decentralized and now everybody everybody else are aware that hex will happen and like I'll mentioned it before there is a challenge that people in the space don't think that can they can be hacked when you will have this notion where you understand that dowels are the next phase in each and every protocol then you will build like the right procedures then you will build maybe like time locks maybe you will um you will organize the Dao in a specific way that will be able to to react and act upon uh incidents

um time will like time will tell I think we are still not there yet um but with the evolution that we see with the monitoring and the awareness in the system and the ecosystem I hope that next year we'll have like uh like more like we'll have white papers that we'll talk about it um and this notion of combining security by Design with how Dao should react and the the providers will just consolidate and will have the right security procedures yeah maybe your take Carlos on that completed

yeah so uh like the same as the teams like know like the the that there is monitoring tools and work certain way how you avoid the attackers to be aware of how the monitoring tool to then like circumvent the monitoring tool by new methodology honestly at some point like as it keeps evolving and getting better if you are good enough does it really matter that they actually know that they are going to be detected like at the end of the point what you want to do is to put there a deferent for them to actually not do things if it's just so much more difficult because they know that no matter what they are trying to do they have exactly the code that is going to be run and they are running it locally then doing simulations and

you're always finding it and they are spending time and time again until they actually can do something that might not trigger everything then that's that's actually still successful right like because you're just making it so much more difficult and putting it in the end you're giving security by okay I'm going to find you almost whatever you do unless you find something super Niche and then once that happens we are going to be on top of that and building on top of that and it's ugly because that shouldn't happen but it's a way of learning like it's a little bit of um of a cat and mouse game like okay we get better they get better we get better they get better and so on but that's the thing at some point I feel that as we grow and we learn more and we build better defense mechanisms

even if they even if they know the mechanisms and they can reproduce it it's still going to find a lot of the things that they are doing it's like when you have a lock on a bicycle like if you really try to break a lock you break it right but it's therefore deferring you and making it very difficult and wasting more time and giving more traces so that you can be found it's a little bit of the same yeah I think following on that is actually quite interesting but a the same as like maybe looking for Perfection is not the not the approach because like it will work without the Perfection like how how you see like in terms of speed and the Practical speed nowadays because my way of thinking I

think like a lot of people like in the web 3 development side is that we are used like to Kind of Perfect Solutions like and we we think that okay monitoring there should not be any case like on where it can be skipped like so maybe your your take Alex on like in practice like on the last month's year like is that Perfection from the part of the attackers there or is more like there could be always ways like of or almost always so uh I would say that in the tree we are not really accustomed to security for security to be perfect so security is always imperfect in the tree at least

um I would say yes that we we will still be imperfect uh but I think that uh for the same that the same reason uh you know just uh let me rephrase so as far as I remember in the middle of 20th century uh bank robberies in England suddenly stopped it's just because the risk was too high to take it so we can just uh just increase uh the risk for the hacker you know increase the difficulty the

complexity of the task Etc et cetera et cetera so at some point it will be just pointless it will be easier to just uh I I don't know Farms some coins to get some easy money than to Drain Liquid people and I also had another point on this Martin could you please repeat the question sorry no I was more focused like on the on the Practical speed like so uh when you look like a potential solution it will be okay like I want to protect an Mev case that you will get executed atomically like and it will drain the whole protocol so I was more asking of from what you see like last month last year

like is that the case at the moment are so sophisticated the actors or it's just more of overthinking from part of the engineers that right I think I think that uh when we really start stopping the actual attacks they will need to do to do something about this and I think that within a year we will see more sophisticated sophisticated hackers and they will try to obfuscate the attack they will try to hide the attack completely with the prior going to private pools and for any of these ways of uh you know hiding attack or obfuscating it or bypassing monitoring in any other way there are

solutions and I'm afraid that I will go over time if if I you know describe all of them but Solutions exist and but they will but I think that we will start thinking about them in practical way only maybe the next year because earlier it's to me just doesn't make sense because hackers are not that complicated they are so lazy they deploy attacking smart contract and then and then broadcast actual attack transaction you know may sometimes uh within several hours and so it's it's insanely slow they must not do this but they do this because

they are lazy so I think that we must teach them to be less lazy yeah and and a bit related with that like uh maybe for maybe for you and like how do you see the implementation of new privacy Solutions like on on blockchain Smart content how you you see the relation with this monitoring because like on one side it will benefit the attackers even more like on the other side it could actually be a place maybe to plug monitoring in some optional way so oh yeah uh this is a really very good question because we have an audio debase Insight in inside the boxer so um for

the pricey um um transaction so it's like the flashbot right so we can see many attackers and abusing these services to launch attack so um one of my one of my colleaguers uh um he proposed the solutions that we should you know investor some transaction inside the flat spot to a preventative response from being abused but I do not think this solution this solution Works in practice but you know I think this solution can be accessible by the community because you are in the transactions on a decentralized world right this cannot be accepted by the community so I think but but still um how to uh how to uh but still from the um privacy

service providers perspective how to prevent their service from from abuse by the attacker still an open question I think at least we can do a a couple of scenes first we can um if if the is attacker has been confirmed at least we can you know work with authority you know to solve some um to to share some information with sort of to check the attackers by such uh service providers I think exactly what one thing what we can do I think another thing is that uh maybe uh in the future we can add some community-based Eventing systems inside the transactions it's not just a centralized community-based we can invest some transaction if it's a

malicious then we can like we can delay sending a transaction if we do not block station you can um I think they can they can not solve the issue but they can mitigate the issues currently we have yeah thanks okay yeah maybe like uh last one that also was mentioned during all your takes like is worth the console like the forks like so that there is like a lot of people like a lot of developers that just work other protocols like and there is quite repeated pattern of detecting hacks into Forks like so what two actually questions together one is why you think is so it's just like the the team that doesn't put too much effort and the other will be how they

like big protocols that maybe don't give so much importance to that the how they can incorporate that in the procedure so basically looking like uh all the hacks happening in Forks as a way of understanding of of your own product maybe mayor can comment on that yeah so I think that this might be addressed and during the development right maybe tools like sartora or other tools can address this problem and to see what kind of libraries are using maybe this libraries in Blacklist and so on and so on so I think that this problem might can be easily addressed you know it doesn't just needs attention

education and to be more uh more precise when you're developing but I don't think that this is a huge problem that we cannot solve today okay yeah so we are kind of almost at the end so thanks everybody maybe we can leave like some we have four minutes so maybe if there is any question from the audience for anybody here include hi um I'm I'm just like here that Andy

talked about some traditional web 2 uh software that your students and probably like PhD student or undergrads were using for detecting like traditional traditional security flaws so is there any recommendations that we can take a look at oh yeah um see excuse me right you're asking me right you're asking me right yeah okay yeah so um I think for for some recommendations I think I'm looking at the the the the defy hack Maps is a very good start you know two from uh transforming from the web to security to episode screen because it has some so many uh so many past hack transaction you can analyze to an understanding why

the hack happens what's the one ability is there and how to trigger attacks and after after um getting all these insights then you can have more um understanding of the Webster hacks and then you can write some tools you know to analyze your attacks to detect these attacks you can have the static Dynamic analysis to us um you can you can develop by yourself you can improve all the existence towards and and you can have more knowledge on this area hey thank you everyone for the panel interesting so I have a couple of questions but I will just start with one is given that we have today on the panel I know eight nine companies doing monitoring

I was wondering how are you guys collaborating on sharing data uh it feels like um you could all benefit from sharing thread data monitoring data put into the standard for alerts in a machine real way my question is where you are starting to win that and if you're not away all of the of all of the startups over here I believe it's their it's the starting point they're finding the the market and how to reach the market the

better way but you're absolutely right and we already discussed before a few of us to collaborate and and showing the data because it's bringing more security for the ecosystem and security for the ecosystem is the first thing that we should take care of and yes we are starting to move this also as a share vision uh yes I have a question could you explain the process of front running the malicious transaction for example like uh what would be the infrastructure setup somebody wants to tackle

maybe somebody different yeah I can talk something about it because we have some some experience of you know from Iranian attack transactions so basically you need to have infrastructure to listen into the memory Port transactions and then you need to have a automatic way to synthesize your uh your from the running transaction like you need to copy all the attack behaviors from the attack country inside yours owns my contract they need to replace all some critical variables like you need to replace other attack address to your own black hat addresses then you have some infrastructure to quickly as soon as your transaction on blockchain so that's basically uh how the system basically

works run your own node or do you collaborate with other flash ball Builder I cannot say public here but I think have your own load is a very good a very good start yeah okay so yeah thanks everybody we were a lot of people here but I think it was like a good result so uh hopefully yeah it was interesting for the for everybody there thanks [Applause] thanks Ernesto and the panelists for the

panel so we now have a short break uh just regular break no coffee for the next 15 minutes and we meet here again at 5 46 for the final panel of the day on wallets and here is an important announcement so the break after that is going to be is going to have snacks and drinks so please stay back so there's going to be snacks and drinks not in this break but the break after this one at uh I think 6 45-ish and following that break will be a series of focused talks by I think 20 plus people so yeah so

please try to stay back thanks foreign [Music] foreign [Music]

foreign [Music] [Music] [Music] [Music] foreign [Music]

[Music] [Music] thank you [Music] [Music]

[Music] [Music] thank you

[Music] foreign [Music] foreign [Music] foreign

[Music] thank you [Music] foreign [Music]

foreign [Music] [Music] thank you [Music]

[Music] [Music] foreign [Music]

[Music] [Music] [Music] foreign

[Music] [Music] [Music]

[Music] thank you [Music] thank you

[Music] [Music] thank you foreign [Music] [Music]

[Music] foreign [Music] [Music] foreign [Music] [Music]

[Music] [Music] thank you

[Music] [Music] oh I see welcome back

so we now have a panel on wallet the panelists are Clement from safe Dima from 45 Riyadh from Cubist Shahar from fireblocks Tariq from volume finance and you are from the ethereum foundation and this panel is going to be moderated from Francesco from metamask consensus so please give a warm welcome to the panel and let's get started awesome cool thank you so much for the intro are you guys excited about D5 security Summit I know you started at night what 9 30 you will go another like three four hours but are you guys still excited

oh cool awesome awesome I see some energy cool so yeah I'm Francisco let's start a quick round of like intros and uh yeah I'm super excited it's only one hour no I'm joking it's a lot but we will cover a lot so let's start with a quick round of intro and uh yeah yo please kick it yeah so uh I'm your advice I'm a with the ethereum foundation working on security and I'm also a co-author of erc457 so I'm working on a count of suction which is quite related to water security hey everyone I'm Shahar um with fireblocks I lead the security products you need to basically I'm

responsible for all the security Parts at the Firebox platform coming from about a decade in cyber security before that hi everyone I'm Dima I'm a co-founder and CTO in fortify and we're an Institutional NPC wallet uh purpose built for D5 hello I'm Riyad I'm co-founder and CEO at Cubist and I'm also a faculty at Carnegie Mellon I'm we're working on infrastructural Key Management Solutions and separately I like them what's the word at night I pretend to be an applicator photographer hi everyone my name is Clem I work for safe previously known as gnosis safe I worked

there as a product lead for safe core so I'm specifically looking at developer tooling SDK API and also helping on some other initiatives my name is Tariq and I'm Serrano here by some excellent security Specialists I will say that I've been in a crypto space for quite a bit wearing different hats currently working at volume we're working on Cosmos SDK L1 chain called Paloma which incends to be a first response chain uh to very much a lot of the security issues we hear about coming to wallets so great to be here with a lot of the awesome folks there we go nice that sounds good and uh let's also remind everybody this is really like an

interactive session so if you guys want to shoot your spicy questions like feel free to just raise your hand and uh and ask your questions but let's start with some like uh context you know what's what's the role of wallets into D5 today what do you guys think about it I have an opinion um there are so many panelists today well so what is the role of of wallet in D5 today is it specific to divide in the question I guess while it are the primary entry points for any user that wants to execute or interact or perform some action on chain

um as of now we currently have two primary ways to execute and execute transactions and make calls and interact with contracts one is through EOS which you know stands for externally owned accounts these accounts um only constitute a public in a private public and private scheme uh key pair that allow you to sign uh transactions and messages and the other one are contract accounts which is what safe is offering and you know contract accounts are pieces of code that themselves live on the blockchain and which allow to hold any logic to do

anything good or bad and uh yeah so they're very important wallets are not just like wallets actually I I don't quite like the term of a wallet because they Define so much more than um the you know what we think as people when we think of a wallet but they also um yeah they hold they're critical um yeah in the for the development of the ecosystem Beyond just I think uh the idea that we only use them for transacting because they can hold so much more so yeah let's me all right so uh my answer is a high level it's a however what is the wallet for defy the

wallet is the user agent this is what represents the user and therefore from security perspective it's the user's last line of defenses probably only line of defense because uh once you go on chain we know it's the wild west and the protocols can do whatever they can do whatever they like they don't represent the user the water presents the user and that's what a security that's what the user the user security should lie whether it's an Unchained wallet with a count of suction or off-chain wallet this is a technical detail but it has to protect the user um maybe if I'm if I may say I think like fundamentally I view I really relate to what you have said I think I

will I I viewed a wallet as the system that essentially allows the user to authorize only those transactions that they want to do and make sure that like you know any transaction gets the proper authorization and if you vote from this perspective then obviously a wallet needs to do Key Management because if keys are compromised authorization is completely broken because whoever possesses the key can do anything they want but even if the keys you know remain safe part of the authorization system is to present the user with the correct UI to be able uh for the user to make the right decision about any transactions they want to make and really encode the user intent uh into the transaction that allows um and kind of another angle of it is once you're dealing moving to say institutional wallet thinks it's on no

longer already the say the authorization or the intent of a single user but rather an organization that can have a policy multiple users needs to express their consent and so on yeah just like to edit it I think like if you go on like semi philosophical level connecting like security and everything so the wallet is what actually enables ownership right and the governorship is the key is is the core value that we bring to blockchain to crypto to web 3 to D5 is the ownership through ownership um by the user of their assets and this is what the wallet enables and from there you take the connectivity from there you take

um the key management and the intent and the policy and everything together that comes from and enables this kind of true ownership of your assets and this is what the like this one makes it like the last time defense this is what makes it um actual the true ownership of the user that's super interesting we will touch on actually an Institutional wallets differences but now that we're speaking about tenancy security like what developer or wallet developers can actually do for enhancing this uh this this security wallets today and not just on the technical side but also like uh on on a more like uh yeah High Level side on structuring their team because that's super interesting I think like

different wallets different strategies so um oh sorry so when you build a volatile because this is the the ownership because this is the last line of defense uh for the user you got to have uh everything everyone on the team with security at the top of their mind right um and we're seeing this at Firebox all the time when there is like 10 different 10 different ways to do something to take shortcuts right that would be less secure design that would allow someone to potentially Bridge the system or to

bypass any kind of protection that we add and I think when you when you build a secure wallet right if it's not security there's no point of it so you need to make sure to not abuse this trust that the user gives to you um so like you gotta have people you gotta have uh people on your team that know what you're doing in terms of both cryptography and security it always goes like hand in hand but the security part is usually about uh the right way to engineer something the right processes uh to enforce within the organization within the developing process and the cryptography that comes hand to hand is about you know the right cryptography

how do you leverage um how do you connect to the blockchain the right way how do you enforce uh all the promises they give your user as uh um some prefers the tight as possible in the last I don't know 10 15 20 years in cryptography sort of maybe narrowly construed there's been this move towards building Primitives that are misuse resistant so you know people say for example uh you know older elliptic curves uh it's so easy to get things wrong if you do something like ed25509 maybe it's harder to get things wrong part of that is marketing part of it is reality so I think taking that notion of building things that are hard to misuse

and easy to use correctly I think that's a really important thing and it's not just a matter of the technical part of it it's also of course the matter of providing Clarity to the user what will this do is this the right thing to do if they're I mean we've already heard if there are seven ways to do something now I'm confused which is the right one if I do the you know one of them here should I do the same thing should I be consistent is there a reason to use some other option so simplifying I think isn't a very important one and the second one is like we're really understanding like if I give you an interface that interface really should be robust to even what we can think of as maybe not a malicious user but a user that's do you know going out of their

way to you know get to the get to the other side get to the end goal with without necessarily thinking so much about oh my God what's going to go wrong right so even that user should be safe um I'm going to jump in I think for us at volume we have a little bit of a um I think a different Outlook one of the things we're asking for what we like with what metamask is doing is giving the user information about what accounts are behaving badly and whatever constantly behaving well um and I think for us you know observing state of you know important accounts uh or important contracts is something that developers today don't have like hey tell me which are all the bad contracts coin gecko does a good job of it when you know in gecko terminal they try to tell you here some of the contract sort

of states that you might want to be aware of you know things are meantable things are unsafe I mean we at volume view wallets as outputs and the question is how do we maintain the safety and the Integrity of the output in a world in which you know everybody's trying to get those outputs or devalue those outputs um so for us the way we're looking at it is hey you know let's look at the metamask way like what about these other accounts can put our wallet our outputs at risk and then how do we pass that information along to the user and the dev and I think that's where we're looking at in terms of you know we think we talk about cross stream liquidations uh cross chain stop losses you know we're always saying hey can we go a step further to make wallets even smarter

about the Dark Forest in which they operate yeah I think also like the the the transparency that we're trying to push in terms of like hey you're building like kametama snaps today us developer you see exactly how the the snap is interacting with your extension and every transaction it's kind of like you are aware of what's Happening uh yeah and uh I think like in Utah like Simplicity I think like all the standardization is extremely important uh without that I think it's uh and we will touch on that I just want to go back super quickly on the institutional side like what are the challenges today that uh you know like institutional wallets has like compared uh you know like I think like and end user wallets or is there any specific things that we

we need to know I don't know how many of you guys are doing like institutional security or versus like specific but but it's definitely a good topic to touch um I think one interesting challenge we're kind of seeing especially when it comes to D5 for D5 transactions times is often of the essence right if you're doing a swap maybe you know the conditions may change slippage and so on uh but on the other hand you know institutions obviously don't want to have they want to have like multiple layers of security including say institutional some kind of approval process where the manager of the person initiating the transactions might need to approve that and so you find this balance between uh operational efficiency and security of course the more secure the most secure thing would be to have every transaction have like

you know four pair of eyes look at it but in you know and maybe if you're just doing like a you know uh rare transactions once in a while it's not it it's worth it right but if you're doing like uh D5 transactions things that are much more time sensitive it's really how to find this balance between operational efficiency and security and I think like the the the right tools for it is for example to give uh institutions they're able to encode different kind of rules and heuristics into an automated engine that would say well depending on certain parameters of a transaction this looks low risk maybe the person can do in and and kind of sign the transaction on their own whereas this looks maybe a bit more risky the amounts are higher the protocol is less secure let's kind of

run run this through a more detailed approval process you know I would add that if you compare and you say what's unique for institutional so I would say two things one is governance and the second is connectivity so governance again like you when you provide a wallet to an organization to an institution so you you realize that the wallet is part of a way bigger system that they that they operate so like they come with their organizational structure they come with their constraints they come with their policies that something existed before they went into crypto some things existed before they went into defy and they need to keep complying to these and the quality you provide

um needs to combine these as well so this is the main challenge sometimes organizations have when they go over and the second one um is the the connectivity so again because this is like the wallet is going to be part of something bigger so you need basically API for everything and they're gonna connect the water to like many other systems for visibility you to control the actions to verify them to approve them um and it's always like part of a bigger system that's that's lived before usually before crypto even and in the world it has to to properly connect to that yeah so I think the institutional use case is one of the primary reasons to

move away from the eoa model that is traditionally been used for crypto because uh with eoa you have like a one-size-fits-all it's the accounts the account works the same way for everybody whether whether you're in the individual user or a large corporation so um so as it was already explained here it's um you need them you need a way to encode the corporate the corporate structure the the way decisions are made with the authorizations you need a way to incorporate them into the account so some accounts may be very simple like once for individual user but one but some may have very complex policies based on who you are paying how much you

are paying whether you are interacting with someone on a regular basis whether it's payroll or whether it's something extreme maybe you want to have time delays and maybe you have to have time delays because you have a controller that is supposed to inspect the transactions and say and be able to veto them so all of the things should be encodable in an account and we don't want them in all accounts we want them only we only want the account to be as complex as it needs to be so that's a reason to move away from eoa and to have logic in the account I agree with that um so especially in the case of an Institutional um entity this is presumably an entity that has some structures assigned precisely

to the the task of keeping the wallets secure Etc these are the folks that have the best ability to handle this on their own and at the same time they have a greater need to hide that information from the rest of the world I don't want to encode my corporate policies in a public blockchain I don't want to reveal what decision-making procedures I'm using in in public I want all of that to be completely hidden and I don't want anyone to be able to tell is this account something with complex policies is this account something with uh with with simple policies I would much rather have everything appear to be exactly the same an eoa and handle all of this policy question completely off chain I think this is a much much more difficult thing for end users to do in the case of

an end user wallet like okay that's putting too much stress too much on the the end user to be able to you know make all of these complex decisions for them it makes total sense that you give them a you know some more decision-making process on chain they sort of Outsource this to somebody else but but in the case of an institution I think this these are precisely the this is precisely the audience where there is the capability of making these decisions and setting up these policies ahead of time and in a way that doesn't involve using the public blockchain and I think that is just a better uh security posture for an institution so I think it's not uh I think it does not conflict the requirements do not conflict you can have privacy for like you don't have to put your actual corporate policies and

the old structure on chain you can have a representation of it as a Mercury or something and that's what the zero knowledge proofs or use are useful for so the transaction can actually prove that all the conditions are made that all the right people have signed assigned a transaction that it has the proper authorization for this amount for this token or whatever all of this stuff can be incorporated in the form of a pro of a proof and still have the on-chain security model with with respect um I I say this as somebody who has been doing research on zero knowledge proofs for the last 10 years if you have a problem and your solution is to use a zero knowledge proof now you have two problems um you've made the solution you've made the situation worse

um like you've you've actually like the the the difficulty of encoding your uh uh logic in the correct way of making sure that your proving is done correctly you're verifying the fact that you're spending a ton of money on gas to verify each thing like all of these things have actually made your problem worse you may as well have had a much simpler and easier to write piece of software namely the thing that's deciding whether or not to allow a transaction or not and just run that offline if you're able to prove it you already have the expression of the computation stored somewhere offline anyway The Proven needs it in order to generate the proof so now the question is like do I run the proof and then post the proof or do I just check the thing and decide whether or not to allow the

uh the group and the key Point here is who is I you just say I check the thing now I probably mean some server some offline server and so you have a single point of failure If This Server now if you implement the policy on a server the server is compromised you have no additional line of defense there is no there's no enforcement at the asset level at the the account level so it's uh so now you rely on on a single entity or I mean it could be more than one server but it's still a small number of servers where you encode it so it's a trade-off I agree in some cases this trade it's the right trade-off in others it's not I I it's not that I generally prefer to avoid the I generally prefer

to avoid the central like a central servers and single point of failure but of course it comes with some complexity for example in the zero knowledge case so either so either you lose privacy or you add complexity that's a trade-off absolutely agree I want to jump in here um so that was an excellent exchange I think for us we've had we had an even simpler problem uh we were starting a private credit wallet for a real world asset SMB uh payments and lending very simple uh and everybody was kyc to AML on both side uh and then one day they saw a dusting of some random erc20 and it said Tark what do we do and I'm like I don't know I mean anybody can interact with your public address and send funds

from tornado cash or elsewhere and I think one of the problems with our institutions is that like how do you protect us against that how do you make sure that the outputs that are in this account only the outputs that are important to us and have not been poisoned by other outputs and I think that's a that's the thing that we face and we don't have a good answer I don't know if you guys have thoughts about that so we yes please go ahead so I was going to say that uh for for us uh usually the solution is is you deliver the fact that you live off chain right and you allow the organization to have another layer of say abstraction or cleaning so to say on top of that and then not necessarily every transaction

everything that happens on chain is also like potentially confusing the user and they give them the possibility to to clean that or you know worst case go to customer support and say hey this is like something that I don't want to see I don't want like everyone to see and then you can like modify that right um I wanted to kind of touch on the point uh like the point of debate it was right I think there is a uh um a potential Middle Ground here I think that um for example I don't think that the entire organizational policy I agree with reality like that making the entire organizational policy like who's who's manager what's transaction needs to promote I don't think that it much makes it makes sense and it just adds

complexity to the launching component but I think that um it still doesn't I mean it's it could still we can still do use account obstruction not use EOS for example you could have the online component for example require just some kind of a quorum of uh Quorum of signatures and then one or because fundamentally from the organization's point of view there is like a central centralized policy one one source that you want to enforce and then it's only um and so this would this could encode for example like the entire organizational structure now of course you could say you don't want the single server in the organization to be a single point of failure to volume but then what you could do is you can have replicate that server and just require multiple signatures from from all of them without still requiring to to

actually you know encode the full organizational structure on chain so again this kind of and I think then the component that you end up on chain with is much is much simpler right it doesn't have to do zero knowledge proof for example revealing that you need to maybe have five you know uh you know five different signatures to approve a transaction that doesn't reveal much about your organizational policy and still it allows you to enforce a very complex organizational policy at each of five points which could be different five servers within the organization and I think then you you kind of avoid a lot of the complexity uh and you still you still maybe you know uh can end up with I think overall with a simpler design so yeah in other words what we're talking about is separating authentication

authorization which is again one of the weaknesses in eoa where authentication and authorization are the same thing and in a in the traditional security World these are all very very different things so the authentication can be in a server and you can have multiple server for different departments for different things so and these they do the authentication but the authorization the what you are allowed to do once you collected these signatures from this server and that server this can be enforced on chains so now at least you have some so at least you have some enforcement and then so yeah I think it's a what you describe is basically the separation of authorization authentication yeah I I think that actually like the the even

the authorization that could be enforced and change could be a like it I view it as the only thing that you might want to enforce there is just kind of to avoid avoiding any single policy server uh being a a single point of first you'll you can essentially you know it would only kind of collect a a bunch of signatures and that the authorization of you know end users could still be done off chain at each of those uh you know replicas let's say of the policy server yeah in the context of of safe um we're actually offering to do that on chain um with the use of modules and guards so you can leverage other contracts to verify that a particular policy has been followed

um in the context of uh what you described about having non-kyc AML tokens being sent to an address which I think is a very interesting example I actually really do think that by running a guard you can prevent incoming tokens that are not whitelisted in the contract to actually enter the the smart contract so you can do that and you can also work on granular Access Control policies to allow those roles to to live on chain however I think it's a very interesting uh discussion the two of you had I think it's all a big question of opportunity costs for those organizations to actually do the work of

setting up those policies and migrating these policies on chain and there has to be a clearer benefit I think than just having that moved on Chain versus managed by apis and in their own Enterprise setups so I think there's a lot of opportunities to look into how that that transition in those interfaces can best talk to each other and and I think yeah here like you have said the the distinction between authentication and identity in your wallet right like I think for me this um like the the contracts allows for um I guess defining a wider interface

for these two worlds to to talk to each other rather than than NPC then not EOS yeah yeah I agree and I think that you know eventually eventually I think like different organizations have different view of like what's important for them right some would say I have to have a one-to-one representation on chain and if my wallet on chain has these uh they already let's say say tokens some in a bad situation because this is what like my Auditors are looking at and some would say no I have like my own database off chain and this is what's important and this is what the Auditors are

checking and this is what I need to be airtight and like right on with compliance right so it's like different organization will require different solutions I think if you if you zoom in on the security perspective and you say like okay there's like authorization versus authentication so you could have this situation where you deploy like multiple policy servers so to speak at the end of the day you gotta make sure that they are secure right they can you cannot we always try to you know edit add more and more security mechanisms which is good um but if it's very hard to create a system that if all the components that hold

cryptographic secrets are getting compromised so the system is still intact right if someone owns all the five different policy servers so the wallet is owned right it's like and maybe it's not nice to say this way but like that's all the security that you have if they own everything so they own the wallet um and and there's like a limit to what you can have if you move everything on chain uh you might just add too much uh complexity and not uh to not add too much value so like you need to find again for the right organization the right deployment model that has like realistic and uh pragmatic security

approach two small notes Here one um I think in this case of moving things on chain there is what you're saying makes total sense of course if all my policy servers are on uh life is bad on the other hand um if I put all of my policies on chain I now okay the devil's a little bit in the details or forget about all my policies that's that's that's a red herring let's say I put some policies on chain and I'm enforcing them on chain and this is my last line of defense right all of my servers get owned and now there's this last line of defense saying no no no no life is okay um and now there's a little bit of a question do I will I live with those policies for the rest of my life or will I add some kind of governance procedure

that can change those policies which now it reintroduces this idea that now something right such as a time delay precisely so this is the this is the kind of thing where the devil is very very much in the details and I think that this ties to the other thing that I wanted to say which is it's very much dependent on the structure of the organization that's trying to do this and on the structure in general of like what kinds of transactions do I want to see and and what do I want to allow and not allow so to some extent a lot of these questions are very difficult to answer in general because for certain applications there will be really nice uh answers that look like mostly on chain for other applications or other organizations the answers will look most more like things should live off chain

so I I think maybe this is a cop-out but one answer is there's no one answer time lock is as close as possible to uh to having this answer because regardless I mean you can have often off-chain policies for deciding whether the change is authorized or not when someone changes their policy so if the policy is enforced on chain but you always have I know like one week of one week of delay where the organization can sign a sign a transaction to cancel the change then now you can you can Implement any you can Implement any logic you like in order to inspect it and to prevent it unauthorized changes so it's probably as close as it gets to having something

general but and the other point I wanted to make is that uh it's a slightly technical Point regarding regarding getting dusted with tokens that you not want such as tokens from a from tornado cash since we are talking about elc20 tokens rather than native if then technically technically I don't see a way you could prevent it because the changes are not in your account the changes are in some balance in some list of balances in somebody else's contract so if if I send you some if I send you some tokens some you'll see 20 token through a tornado cache you have no way to say I do not accept it you can get rid of it you can burn it even even that can be made quite hard but uh it's a but

you have no way to prevent the you know not to accept it and this is something that I wouldn't I wouldn't want to be the one who has to explain this to the corporate lawyers like why did you accept these tokens because I had no choice and of course given that you know regulatory now is looking at transaction analysis in order to determine whether or not people have complied with you know particular law at the transaction level um you know we as security have to explain well you know there is a possible you know I mean there's some exposure and that's that's for us a tough conversation yeah yeah I think this is it's like a never-ending race right like uh you could like as a corporate create like a garbage account which uh your smartphone wallet when when it sees uh those uh

tornado cash tokens or something like that it transfers automatically to like the trash can and then nothing moves out of there and like you know on the organizational level that's like this is okay and it's a cool fact token you can't touch that I mean otherwise you're yeah I mean but you gotta choose right to your point I agree yeah I mean that's like the only thing you can do yeah I mean once once outputs now become essentially Persona non-grata or they are limited by laws that say that you cannot interact with them um I mean they become weapons right and so we are concerned for our clients and and we just don't have easy answers today but but hopefully we will in the future but yeah it's a big deal for us

yeah I mean like you cannot but again like you gotta choose if you live like fully on chain or you're hybrid right if you're a hybrid it's not it's it's like a challenge but it's not like a an unsolvable issue because it can uh quote unquote just clean this on like the database at the auditory see and everyone agrees that this is how the system behaves if you're fully on chain then like eventually you got to choose which solution actually works for you right I think that like it kind of ties back to the question that was earlier about you know how what's the right principles to build a secure wallet and I think one of the key things you need to do is you need to learn to say no what I mean is that um things that are like I feel like the guiding principle

is that things that don't require touching the private key that don't require like controlling the authorizations those can be left kind of definitely outside of the core secure component of a wallet and maybe even like in a third-party system some kind of integration just to keep the you know keep yourself focused on security keep the system and the architecture clean so I think even uh kind of aspects such as you know what do you do with different types of tokens you really got to ask yourself does do those decisions require the decision on behalf of the wallet or is this some kind of you know maybe treasury management system or something like kind of like logic that can be held externally and I think this is important both like you know from a company building point of view to keep yourself focused but also from a security Point

of View kind of to a voting bloat uh in your system architecture uh bloating in you know in the in the architecture and that kind of uh keeping the attack surface as minimal as possible so following on this discussion what are the third party functionality that you think a wallet should leave to the community or third-party companies this is so spicy this panel that I just skipped all the questions I had before and just following the flow easy life for the moderator foreign things that fall in scope are definitely as I said things that are required touching the private key right that's you know you're never gonna give like uh free access to the private key to any

external system you're never never gonna do that things regarding to authorization um I think are also very important um and authorization has a lot to do with UI so you cannot just say I'm gonna build a wallet and like you know leave to UI to somewhere else because because building a secure your eye that reflects the the actual you know that can capture correctly the intent of each transaction each action is super important so building secure UI and you see it even like outside of crypto wallets right when you're doing a transaction with your Apple pay there's always going to be some kind of UI component but that the iPhone's gonna show you which allows you to review what you're approving so I think that's definitely Falls in scope um and there's also a question of you know of timing right things that are important for them to happen at the time

of transaction also in scope for the wallet if you view like auxiliary system you know for for instance I think that um even if we think about things like monitoring we've had this previous panel of monitoring I think there's definitely great synergies between the two but maybe I wouldn't view it as core to a wallet because you know you just need the public key you just need the address uh and you can have an integration for response for mitigation but I would still view it as like complementary systems that can work together but but are still separate so I want to away and go first off yeah so the short answer is it depends on the company I think but I had given this answer so um I agree it starts with like the core of uh security private Keys uh

transaction control right without this you have like nothing and then you build and I think like the the right mindset is always so like to enable the customers to like do whatever they uh they want and choose to do in a secure manner right with like API and then like when like on your on your own you you extend that for like more core functionality over time um I think that everything that has to uh Clarity which is like for me the essence of ownership right if you do not understand what you're actually doing so you do not necessarily own it right um if just like sitting at yours and you do not understand the request

um so it's not enough so it's expanding on that um there are things that you definitely should not be doing yourself right um if you talk about Disaster Recovery processes for backup and recovery of private keys so it's like by definition should never sit with or just with the wallet provider because otherwise it's not really a disaster recovery right you need to give your users and I think this is especially true with self-custody Solutions So You Gotta Give the users a way to continue operating even if the company ceases to exist from there just like sorry just like from the the advanced security side of

things talking about like monitoring talk about the advanced tools um it's really it really debentures on the segment of the market you work with right I think over time we'd see more of these capabilities shift into core wallet offerings right I think like simulation is like a good example for that but over time we'd see more and more of these shifting into wallet providers as like default functionality with like the more advanced coming from like third party vendors and and overtime adopted so I think there's kind of two this is I love this answer so there's kind of two P two ways to answer the question

generally I think one way is from a technical perspective what pieces live inside of the trust boundary and one what pieces live outside of the trust boundary of the wallet and I think what Dima said is absolutely correct like we can always ask ourselves does this need to touch the the private key is this something that's interacting with that's standing between the user and the private key right because if I can't have trusted input my life is bad if I can touch the secret key life is also bad okay um but then there's a separate question which is what do you present especially in the case of now forget institutional in the case of an end user wallet what do you present to the end user because anything that seems like an add-on anything that seems optional even if you think it's really important probably 80

of your users will say too complicated I don't want to worry about it right and so you this is another one of these examples of make sure that it's something that's hard to get wrong like so you the the the sort of the pressure from the other direction to integrate things is precisely that if you make something optional and if it's something that's really important and even if you say in your documentation in really big letters please don't leave this out somebody's definitely going to leave it out because it's just too much trouble and who cares um and so that's the kind of thing where you now you have to make a decision like okay this is important I don't want it touching the private key of course but I want to present a unified interface or a unified abstraction to the to the user such that

they're not going to reach in and you know grab the engine in the wrong spot right yeah I think this point is particularly interesting also in the context of account abstraction how to bring it um because as we strive for better user experience in the context of say for instance you know users typically set up multiple keys and currently there's a trend for people to you know deploy their accounts using NPC using a social login for instance that's already you know one trust party involved right that separates the the connection between the user and the actual contracts and so we just like you talked about optionality right we need to think about ways we can

make sure that they they they can connect to their accounts in in a setup that actually guarantees that they have full self-custody while minimizing trust but still trying to optimize for a user experience that competes with well authorization and authentication of web tool Based Services so here right now is a lot of efforts from different projects to look into this um and yeah I think it's a it's a challenge that's very familiar to me okay so I'll say that um all the companies here are amazing and um I I we take the position it's a

business decision we have to compete with fire blocks we are competing with kenosis uh we're competing with metamask and they're the best in class so we are always looking to say what other features that maybe we can provide that differentiates us from the other security offerings so we can say please take a second look give us a chance right so we see it as acutely competitive that for example currently we are monitoring other accounts that you interact with to look for you know nefarious Behavior we have you know we call cross chain liquidations these are things that we tell our customers hey you know you get something different from us and I think that's important and um maybe the only way we'll survive because if we say A you know we'll just leave it to the third you know third

party something that customers say they want that they're not getting from other providers then we may lose the business and the opportunity to grow so I think uh hey there there's just so much out there um to do on it and I feel that we shouldn't close it off if it's a good business decision and if your customers need it but um if the customers don't want it you know hey leave it to community so I think I thought I will take the community side here it's because every pretty much every example that came up here that came up in the discussion is something that is part of the TCB is part of the trust base I can I can show at least one example that I've seen in some project where they chose to edit as a model so and everyone is now talking

in a in the account obstruction space about modular accounts so uh now take a say for example so they so they support modules and they support models it's a multi-sig but with the model you can add functionality such as social recovery and social recovery you could say that it is it's as good as touching the key because it can it can add a signer so you can add a signer but it doesn't have to be implemented by safe the company it can be implemented by the community and then users get to pick you get to opt in so it doesn't affect you unless you opt in and you can audit it and decide yeah I want to add this functionality even though it touches the key so it's definitely it becomes part of the trust space and pretty much like any any example that we discussed here is

something that could be done that could be done with the module there are even external things that are done off chain for example the the issue of understanding of an informing the user what's going to happen during the transaction so it can be done by the wallet provider and some other providers do it on the other hand there are also some great companies doing that are focused on simulation and trying to understand it to prevent red pills and so there are vendors that do it as part of the wallet there are also vendors that do this as a separate service and maybe a wallet that doesn't have this will want to work with this as an external model so everything could be could be modular and the way I'm the way I'm looking at I'm looking at the

modular account is uh since I think the analogy of like iOS came in so it came I came up here so yeah I see it as I see it as an operating system the account is the user's operating system on chain and the account itself is essentially the kernel so you cannot mess with the kernel you cannot make changes there but it has system calls it has a and they enforce certain permissions now each of these modules is an app that is an app and this app requests certain permissions that you can choose to give it or not to give it or not to install this app at all once you install it and you give it permission let's say you install social recovery you say I'm I'm allowing this model to change the to to add an owner to device that's fine you

gave it a permission but maybe you're installing another thing that does spending limits the the spending limit and you are not going to give this permission the only permission you give it is is to prevent a transaction to see what it does and to prevent it so it's an operating system hold on a second are you saying that therefore it's a modular by mandate or you're using its modular by choice no it's modular I mean if you choose to install a modular account that are that is built this way for example there is a ELC 6900 that that developers are now working on so if you choose to use such modular account then it's modular by Design you have no way to use it other than by

installing modules and maybe the models come from the same entity from the same order developer but maybe some others come from elsewhere let's say you have a you want to play a game so when you're using session keys for the game so the browser will be able to transact without popping up anything on your on your device so but but this module is only authorized so this model is authorized to to send transactions from your wallet but only to one specific contract so you can install this as a model this doesn't have to be written it will not be written by the wallet developer because the water developer doesn't know about it so instead the game developer is going to build this model and it will not ask for permissions that it shouldn't so the only permission it asks for is to transact with that particular

contract you have I think I completely relate to the mother point just maybe a small observation I think in some of the examples maybe the social recovery like the analogy in the kernel and maybe some of the models will be like a kernel module rather than application and then you need to be careful I hope not I I don't think the the equivalent here would be delegate call and I think the op code this the delegate call opco just shouldn't be in your in your code base don't delegate it don't delegate your kernel okay I want to add one one more thing um back to directory point and I really appreciate like the honest answer but we gotta compete right eventually it's like it's it's a business um and it's a really hard question what

should be left out I think like one one thing that's like very clear to me is if you cannot fully trust that component if you cannot fully trust the com the technology or the input so it should not be part of the of the wallet because this trust between the user and their wallets is like the the highest level possible Right like you trust this technology you trust this vendor with your private keys with the core for your operations and if you mislead right if you put something that you as a vendor you do not fully trust that's like I think that's an issue yeah I think it's also like part of like the standardization side if we need to build like modularity system we need to

have like a fully standardization I mean I'm just looking at the snaps example you know all the vision about like you know adding and giving this power to the community building whatever feature they want to enhance in in the wallet like yes will be cool but think about in the future that snaps can be added to any wallets out there but without the standardization like people will build more and more wallets with the same functionalities and I think this is not where the end user Community want to see where the wallet ecosystem is right um I don't know we have like 10 minutes or any question around like you know wallet security or or anything related to what we discussed and great spicy debate here today please please your hands erase your

hands if you have any questions yeah only spicy questions exactly exactly no snarks question or NPC MPC questions oh yeah it's interesting okay cool yeah maybe just following up on the the module uh topic that you brought I think it's a very interesting question right the modularity of accounts because right now I guess also your point around standardization I guess as an industry what we're really trying to do is trying to figure out how we can reduce the security implications of this modularity because naturally uh currently you know adding modules completely overwrites um some of the rules that you specify in

your initial contracts at least in the context of save and so there's a lot of like interesting interesting initiatives and teams looking into how we can build Registries for modules that could come and meet certain security standards um and you know I'd say if we're also trying to think a lot about this and how to best operate that and work with you know Security Experts to try and see what can be a process that actually make a particular major trustworthy and yeah hence enabling modularity of accounts again this comes back to this question of like who's the audience right because in the all of us sitting up here are you know we're like we're kind of hackers

right it's like yeah I want to run Linux I want to install some some kernel modules and like uh fine even on my like mac I turn off the system Integrity protection I actually don't I promise um so like great but I'm pretty sure my mother never once in her life installed a kernel module and like if she were going to I'd be like maybe maybe not and and like this like that's a joke okay fine but like the the problem is like now we have let's say the next billion users uh on the Chain I don't know 90 of them are people who will also never have installed a kernel module and yet there will be scammers telling them please install this kernel module right so then now we end up in this interesting situation where I I there's there's a debate here for a reason right like iOS

pretty locked down I don't know if it's actually better security than Android it depends on who you ask but I mean if you look on the Android App Store there are a heck of a lot of scams right so this is the kind of thing that we will start to see in the future as soon as we have modular wallets we're going to have scam modules and we're going to have people like telling me to install a scam so that they can steal my stuff and so there is a great power here and so there's also unfortunately a great danger here and this is going to be just one of these continuing hard problems how much uh Power do I give the end user versus how much education do they need in order to actually use that power in a reasonable way and not just own

themselves yeah so uh that so I don't think I don't think anyone should install kernel models in this sense that's what I meant with the delegate call delegate call is essentially okay it's like like giving someone access to the entire memory space of your kernel you don't want to do that like ever there's no uh there's no legitimate reason for it anymore you could Implement anything as an external module and um and then since since it uses permission model that is essentially like Androids or iOS where each model declares which declares what it needs and you could even say that you want to approve it each time dynamically like append the append the permission to your call data so let's say let's say a

scam module tells you that it's going to interact with the game but actually it tries to add an owner to your account so in that case I would expect the account to check for it and to say okay so this is a this is going to add this is going to add another signer so I'm going to revert it with a message that says if the user really really intended to do it then append this string to the call data say I know this transaction is going to add an owner so you have ways to inform to inform the user the models are not the models are not kernel modules these are these are it's like apps with the with the very specific permissions and you can have no permissions by default and have the user approve each operation absolutely and and then the the sort of

the bad side of that is you know the what was it the windows uh whatever remember the Windows XP like do you want to go into system mode yes of course and everyone just clicks it without reading the the box from then on right so so then this is a UI problem right like now we have to make sure we're not exhausting the user's ability to make a decision because if you ask them seven times on the seventh time they don't care anymore they just push yes yes and there's no perfect answer I think I mean I've been following both the uh when I come from a mobile security in a before blockchain so with iOS and with Android we've seen different models and even inside each of them the model shifted like uh when I was talking to the Android team in the early days I

suggested having Dynamic permissions and let the user let the user decide when when you try to access the camera they said no way this is not this ux users will never accept it and now this is the default so like it took them nine years nine years to get to that point so I think we'll have to experiment and see what works best with the users and hopefully with as little disasters as possible this is also um this is also you know user education right like to your point the let this app access my camera so it makes sense in a world where way more people are aware of what can the camera access do right if you just start

it on a very early days that no that many people had smartphones and not that many people um took you know selfie every second um so it's not like the the concept of what access to a microphone or access to the camera is for the end user has shifted right I think like today many more people are aware that like letting an app track you means that like someone knows exactly where you live where we work with your friends Etc and if they you give access to your camera and maybe you look at the cat at the at the phone just after the shower so it can snap a picture right and that's undesirable right so it goes back to the wallets

position within the market and with the users and I'm going back to like your first point about what it's been the last line of defense for the users it's actually been also the first line that the user is interacting with the external world and this is an extreme and amazing opportunity for wallet providers to actually educate and let the users know hey these are the consequences this is what's going to happen and this is good and this is bad obviously we should not do the Vista UAC thing that's like are you sure you want to do this as an admin and yeah everything requires an admin permission so we and I think also Microsoft now on Windows 11 saw this right and they are

like way more comfortable with making people admin less so it takes a lot of time to change consumer Behavior but this is like all the wallets are situated in a in the right position to educate the users and move the market and let everyone make like more um like wiser and smarter decisions yeah and this is the so this is the role of the wallet like the off-change side of the account the wallet because there's no there's no one size fit all here for some users you want to allow installing certain apps okay installing certain models and maybe for others maybe when you install a wallet on your on your mother's phone you want to disable it completely and say no if you if you want

to install some app talk to me talk to me I want to have a look at it so in that case maybe you want to have a different settings you want to say that in that her wallet should not even offer her to install apps whereas maybe on your on your device you want it to just ask you but to describe very clear very clearly what the permissions May mean so it's a it's a ux problem but it's not it's not identical for everyone so what else we need to have different modes for different kinds of users yeah 100 I think we have two minutes but I want to say education is key and also having customized uh wallets for different Target Persona I think also is the next next wave cool so any any less

key takeaways we spoke about like barriers we spoke about like you know how wallets what's the role of the wallets that we need to solve this like what are other like misconception about this our spicy debate here that we didn't spoke about and how wallets can solve this literally like one phrase of barrier one phrase of like a solution I know would be difficult but let's uh let's let's do that for for finishing up this panel and don't be afraid to take the mic I can uh I can try and do it I think it's hard um taking you know from a different perspective comparing device security Summit the first one last year to this one last year was like 90 maybe 95 of the conversations were around auditing

security auditing for D5 protocols which is insanely important right this year we see way more conversations about products wallets monitoring tools all these things so amazing work guys and also this shows how the ecosystem has shifted right and we talk more about building more about servicing our customers and wallets again I believe maybe I'm biased that they see that the core of these things of the operations and we have an opportunity to drive more collaboration more standards more information sharing more security education for everyone I'll jump in and say that um you know a

week ago the multi-chain um you know sort of epoch was a time I think the wallets should have I wanted to see more vocalization from wallets once there was risk in the market wallets to say to people if you're using Phantom make a change do something don't just sit there and for us in our company we regret not being more vocal about it we just stared in like you know disbelief as we saw this thing unfold and I think there's more of a place for wallets to be a voice that part of that education which says we see things happening please be safe metamask does a great job when it comes to suspicious contracts and accounts I think we need to be louder there I think we'll probably start to see a

little bit of a culture shift um as as more folks who are kind of really wanting a web to experience move into web3 that will be fundamentally good for web3 in my opinion but it will also bring with it a bit of a change I think many of us have a contrarian streak have a very much like you know it's my wallet I want to do what I want and that's great for us but it will result in probably Badness happening to the vast majority of users that come on in the next 10 years so to some extent we really do have to be willing to make hard decisions and to as you said make statements like please don't do this please do this instead it you know there's a bit of that resistance to centralized control but at the same time like if we don't give people some amount

of guardrail if we don't give them a little bit of education and the opportunity to do the right thing and maybe make it hard to do the wrong thing I I think we will all be worse off for it cool awesome times it up and uh yeah I think uh we are we are literally between like the snacks and the drinks so yeah big round of applause for our panelists and thanks everybody thank you hi everybody thank you for staying so late so I have bad news and good news uh the bad news is that there are more talks to come many more but the good news is actually there's a lot of snacks and Cocktails and thanks to Nate and

sexier from Italian France there's a lot of food hopefully outside so please enjoy I want to just before you leave one more thing I want to take Rajiv from Sacramento from actually you saw running all the session organizing the session also I want to announce one thing for you interested in security there is a new event actually going to Aztecs which is actually held last year it will be held this year together with Dev connect in Istanbul if you are interested please approach Rajiv and enjoy but come back in 15 minutes [Applause] [Music] foreign

[Music] [Music] [Music] foreign

[Music] foreign [Music] [Music] [Music]

[Music] [Music] [Music] foreign [Music]

[Music] [Music] thank you

foreign [Music] foreign [Music] [Music]

thank you [Music] foreign [Music] [Music] [Music] thank you

[Music] [Music] foreign [Music]

foreign [Music] [Music] foreign [Music]

[Music] thank you [Music] [Music] hahaha [Music]

[Music] [Music] foreign [Music] [Music] foreign

[Music] foreign [Music] foreign

[Music] foreign [Music] [Music] [Music]

foreign [Music] [Music] foreign [Music] [Music]

foreign [Music] foreign [Music] [Music] [Music]

[Music] [Music] thank you [Music] foreign

[Music] [Music] [Music] thank you [Music]

foreign [Music] thank you [Music] [Music] [Music]

thank you [Music] [Music] foreign [Music]

[Music] [Music] foreign

[Music] foreign [Music]

[Music] foreign [Music]

thank you yeah of course okay hi everyone thank you for being back um we are going to have six talks for this session the first one is going to be uh about how to stop hackers and the importance of the first 60 minutes with our dialogue damn Cube good evening my name is Orr I'm the co-founder and CEO of iron blocks

in 2018 6 am I got a phone call from someone in my team my team in Bangkok and they say is that there is a someone over the telegram group over the support group that is complaining about the fact that he's trying to convert some tokens and get an error message over the website and the arrow says 99 of slippage so I took my laptop I started digging in I made some phone calls to my team members no one knew what's going on I look on the recent transactions and I start calculating after some time I discovered that 20

million dollars were liquidated out of the pools for 72 hours there were no trades over the app no one could use it I didn't eat I didn't sleep all of the team all of the community no one knew what's going on no one knew what would be the future of the company and the only thing that we knew is the fact that the ecosystem is not ready it's not ready to scale and is not ready to bring Mass adoption it was too early with those kinds of security measurements finally we succeed to return 10 million dollars out of the stolen amount it was like Israeli military operation

and we also understood that was like lucky was lucky because of the fact that my partner and I we succeed to save more than 300 million dollars that could be stolen out of the pools and the only reason that we succeed to do that is the fact that we responded immediately and this is why we build Tavern blocks and back then we also understood that if it happened to us it can happen to anyone and that something actually was missing that this is not the way to protect on

webtoon it can happen to anyone because of the fact that it's actually security to the center of surround code if we're talking about audits or formula verification or back Bounty all of that this is code but what about workers what about Market assumptions or private Keys compromise private keys this is not code until last year until 2022 no one did real-time Security in web twin and even someone some project want to protect them and observe like so malicious actions they had to create

their own system from sketch it means that the project had to write everything a full detection system by themselves it was highly complicated there were no tours it wasn't easy in the recent year during 2022 we saw that there are a lot of companies that provide detection Solutions some of them mobile size it brought a lot of confidence that was missing this ecosystem however to prevent an attack a good detection system must come together with a good prevention system and let me tell you a story about two weeks ago one of our employees she went to see a family in Colorado

and while she did that she tried to book a test she tried to book flights to this conference over in Paris and basically while she did it I got about 15 text message for MasterCard to verify my identity and what happened over there is that MasterCard they saw that there is unusual activity with our account and they basically they verified the transactions before they finalized to process them with this understanding a Tavern blocks we Implement a similar technique it means that we verify transactions

before they are getting executed in the base layer and if we are talking about decentralization or privacy or transparency which are the building blocks of this entire ecosystem it's our job to make sure that those building blocks are kept on behalf of the end users into the new era at iron blocks we build the most exciting solution today in web3 security we built a full security network that lay down in the base layer its verify transaction before something actually happened completely decentralized transparent and private

today is the most precise solution with the best user experience out of all the existing Solutions in the market and if you are talking about decentralization We Believe that it's a multiple entity game we shouldn't be the only player to take a decision whether a transaction is malicious or not if you are talking about privacy we believe that the transaction data also the user data should remain private that there is no need for that any Excel party would be able to take any advantage over the end users we also believe that protocols users communities should be able to understand what are the processes that their

transaction are going to go through and choose whether they want to proceed or not so if you build a detection system please contact us we want to make sure that this ecosystem remains safe if we build a project in web3 think about embedded security and if you already have a project up and running use detection use it use prevention this is all important thank you [Applause] foreign

where uh you want me to send to you yes please get to this email um for the next speaker can you be sure to go to the front row just to make sure we can have you on time and we are going to start in a few minutes foreign

okay thank you for waiting with us our next speaker is gal Sagi and is going to talk about attack and detecting an attacker and not have vulnerabilities and and this uh hi everyone I see the crowd has decreased a bit but thank you I appreciate staying staying late for me thank you thank you [Applause] um so I'm going to talk about how to detect hex and exploit by detecting the attacker as opposed to detecting vulnerability click on the Green

it's not working um foreign I think that the general assumption and again this is a room that has I guess many audit companies as well but uh I think that we've come to realize that audit is super important like it's the first important step when we are protecting a project but it's just not enough it's just not enough and there are reasons why audit is not enough

first in the last few weeks I've been talking with many many projects that are essentially delaying their Lounge date because they're waiting to get audit which is again in an industry that wants to maybe move a bit fast that's that's limiting I think there are some server use cases or attack vectors that Audi doesn't cover today like one of them is how can you verify that the byte code that's actually deployed on chain is actually the one that was audited there was one simple one very famous hack called saddle Finance where the team used an exploitable library and they exploited on another project it was a

Fork Library and they actually got notified about it they fixed the code but when they deploy it they forgot to change the proxy pointer so they're on chain so the audit was good right like they fixed the code but when they deployed they were still calling the exploitable code there are other like private key tests there are other dependencies that are not necessarily but audited by you so we need uh we need something more than just an audit and I talked a bit about it in in the panel uh today earlier security when you look at any other industry security is usually a layered approach you don't

just take one solution but you take a variety of solution and you need to think about it when you of course when you allocate budgets but you need to think about security as an holistic holistic thing that uses layers and different solutions it could be using more than one vendor it could be using a bug Bounty it could use real-time monitoring system and the focus if if I take for example Cloud security for for an instance is the assumption is that there is uh you are going to get detect you are going to get hacked and a lot of the focus and the budgets in Cloud security for example are around how do I eliminate

the blast radios and how do I detect the attack as soon as possible in order to mitigate the risk and what we what we try to do is how do I get like how do I what is the equivalent of that thinking in web tree and the thing that that we started thinking about was that if we take all the blockchains and all the bridges that are connecting them and we treat that as one big infrastructure and then all the the apps and the protocols that are deployed on top of this infrastructure can we find signals that will indicate to us that there is an attack going to

come before there is a big impact uh on the on the protocol and we try to we try to investigate and understand if this is a correct assumption and I think that the results that that we found are were very promising because we found there are tens of different signals that can essentially detect and attack before it happens and hopefully prevent it and one of these examples of these vectors and these vectors could be from on-chain data they could be from off-chain data but one of these example that is maybe less proprietary and more common today when you're talking with uh

with monitoring companies is basically detecting a lot of the attacks are happening when the attacker deploy a smart contract and that smart contract is actually the attack code and there is a gap today between the deployment of that contract and they actually trigger of the attack and there are reasons by the way why there is this Gap I'll not get into it but when you when you try to classify and find the text like that you're essentially we're essentially using the the benefit of blockchains that are transparent like all the code is

transparent all the interactions between the participants and the code is transparent but it's it's a very challenging uh thing to to do to find an attack because there is some contradiction about what we are essentially trying to do right when you think about it we are essentially trying to find an attack before we actually understand what is the vulnerability that that attack is going to to do and what we are trying to do is we are trying to be as wide as possible on our detection right like we are trying to detect as many different attacks with all sorts of types and attackers and methods of attacks but on the other hand we are trying to

be very narrow on the accuracy right like we want to decrease the false positive of saying there is an attack when there isn't one and one of the examples um they demonstrated for for uh the for the case that I just mentioned about smart contracts that are doing attacks is you could have thought about looking at the source of funding of a smart contract as an indication of how malicious that contract is and is this something that is going to deploy an attack and if you would have done that you would actually uh do something that is not optimal it's not optimal on two on

two areas first you would actually overfit and it doesn't matter if it's a model or it's a rule-based system you'd overfit and give too much weight to this parameter right like and what will happen is that you'll miss a lot of attacks that are not actually happening with this method because there are attacks the RX and XY just last week I think Arcadia Finance around half million dollars was stolen was a hack that wasn't funded by tornado cash so you're losing and you're not detecting as wide as you want and on the other hand you are essentially creating a lot of false positive to the system

because and this is debatable or not if uh contracts that are funded by tornado cash are legitimate or not but not all of them are or maybe a lot of them are not actually doing an attacks right so if you want to connect um these two automated processes you again there are a lot of cases that you don't really want to trigger that automated process so I think that's that's a demonstration of why why doing this finding as wide as possible and being as accurate as possible is not a very easy uh challenge and a typernative

um we wanted to really understand if this and again this is just one example of a signal but there are a lot of other types of signals that are essentially indicating about an attack and we wanted to to test and see if this assumption is correct by understanding if most of the attacks and exploits as it is today could be detected uh before before they trigger and I think the interesting thing that that we found and we ran historically like we ran all the transaction on ethereum since Genesis essentially through the system without actually knowing past information and we found out that around 98 of the hex and

exploit that happened uh historically could have been detected at least several minutes before the first tech transaction so very promising results and of course if there are the the right prevention methods we could have applied them in this case so I think I don't have enough time so thank you thank you [Applause] I don't need to worry about that one no

yeah okay our next speaker is Andy Bill and is going to talk about thread intelligence in web3 you mind if I use that mic okay well thanks for sticking around everybody I know it's been a long day um so I'm going to talk about threat intelligence in web 3. we're going to talk about what it is how you get it and how you can use it um I just want to kind of frame my comments uh by saying that I think it's a really exciting time for threat intelligence um I don't know if any of you attended the

real-time monitoring panel earlier this afternoon but there were I think nine different companies on stage during that panel all of them doing some form of detection which is uh the uh sort of the the necessary function that generates threat intelligence uh in this space so there were at least nine companies doing it I know of dozens of others which means there's a lot of teams out there generating threat intelligence a lot of it's being captured internally and used by those teams at Florida we're taking a slightly different approach and we're sort of opening it up and allowing a community

to develop detection tools on top of the network and then make their make their threat intelligence as public as possible so let's get into it so let's Define threat intelligence real quick so it is Data first of all that is collected and analyzed and I just mentioned there were nine teams earlier doing this there's many others that are collecting and analyzing uh data as well and the purpose of doing this is to one hopefully prevent attacks but you also want to learn about your attackers their their techniques their tactics their processes Behavior Etc and you can you can glean insight into all those

things by collecting and analyzing uh threat intelligence so what kind of data are we talking about um the security Community will bucket threat intelligence in different ways for purposes of today I'm sort of organizing it in three categories the first one is operational so this would be the identity timing and techniques of a particular attack and I'll get into some examples of this here in a second second category tactical threat intelligence sometimes this is referred to as TTP so tactics techniques and processes of a of a threat actor or a campaign third category strategic threat

intelligence so this is more higher level sort of uh threat landscape Trend type Intel that will often a form like an executive team or board's decision about what to do with the product or an investment or things like that okay so let's look at some examples so operational threat intelligence um for for purposes of the presentation let's think about it in the context of a phishing attack so some operational threat intelligence might be the scammer eoa that was responsible for the attack we know this attack happened on ethereum so the chain ID might be relevant the malicious URL that was used to trick

the the the user or users um scam technique was ice fishing so maybe there was uh token approval farming that was involved and then the timestamp so all of this um you know you can you can glean on chain and off chain um and this is something that that Florida is doing today second category tactical um so we're zooming out a little bit from the specific uh sort of instance of an attack and we're interested in the tactics and techniques that were that were used so for this phishing example um the attacker might have air dropped a

Spam token right so they needed to create a token first and then airdrop that spam token to hundreds or thousands of of uh potential victims um one example of this is called Sleep dropping if you're interested in this particular threat you can go read about it on the Florida blog another example of a tactic is using excessive funds to make a scam token seem legitimate so if you were to go to uniswap or some other amm and you saw you know a substantial amount of liquidity there you might think that that was a legitimate token but we're now seeing scammers that are you know seeding liquidity pools with millions of dollars of liquidity to just to make it seem like their their token is is in

fact uh legit and then a a third example of this is um utilizing verified proxy contracts to make it again to make it look like your your um your token is is legitimate and that the code's been verified okay and then strategic so a couple insights that we've that we've gleaned from looking at uh phishing attacks over the last year one of them is that on ethereum in particular the focus seems to be on stealing assets that are already held by users and this is because a lot of the most valuable assets particularly nfts

are on ethereum today another Insight is that on BNB chain for example the focus is on getting users to buy and invest in scam tokens and they can they can do this because or it's it's more profitable to do this because the transaction fees are are lower on BNB and some of these other chains so the setup cost the infrastructure cost of these scams is is a lot less okay so how do we collect threat intelligence I'm going to talk about it in the Florida context specifically so forta is a essentially a giant security camera an alarm system for web3 so from a tech stack standpoint we sit above layer ones and layer twos and the Florida network

is just looking down on all the on-chain activity and we're looking for exploits scams patterns that look like those activities and when we see it we're essentially raising our hand and saying we found something and emitting public alerts about that right so it's a giant public security camera and alarm system for for web3 there are about 1100 Bots or little security cameras running on the Florida Network today um some of those were built by the Florida Foundation some of them were built by some problem some teams or individuals that are probably in this room Ford is an open platform so any developer can can develop and install a

little camera on the network and watch whatever they want to watch so what are some techniques that are used by some of these Bots there's a lot of heuristics you might hear this referred to as rule-based detection an example of this is if I see a plus b that's a scam we're going to flag it right so it's a very kind of rigid way of defining what is what is bad another technique which we're seeing more of now machine learning based detection so an example of this would be I've seen 500 previous phishing attacks and this one looks similar so I'm going to label it as a as a as an attack as well

um some other things that uh some of the developers in our community do are they'll do essentially they'll apply sort of guilt by association so if we know that b is an attacker and it's an eoa and they deploy a new contract will automatically label that new contract as a scam because it's associated with something it's associated with an entity that we've already identified as a as a bad actor similarity is another approach so we will analyze [Music] thank you we'll analyze smart contracts and uh apply different engines to uh to identifying and labeling any new smart

contract that's subsequently published on chain that looks or resembles a scammer contract okay so how can you use web3 or how can you use threat intelligence in in web3 so there are a variety of uses I'm going to start at the bottom actually because for the last couple years um the entities that we're leveraging threat intelligence in crypto I'm not going to say web3 but in crypto more web 2 crypto we're law enforcement agencies exchanges and AML compliance platforms right so think about um uh

government agencies CIA FBI cyber crime teams things like that um and your large centralized exchanges right but over the last really year or two web three wallets dapps and protocol teams and also end users now have access to more threat Intel right if you're using a wallet today you might see a warning pop-up um that is telling you the you know the the contract or the transaction you're about to sign has a malicious entity involved right you may want to you may want to stop what you're doing so that's becoming more more common behind the

scenes there's a lot of threat intelligence that's informing those those warnings protocol teams like we've heard right can react to potential exploits if they have timely threat intelligence and end users can also do this right if you're you know perusing Twitter and Discord and other social channels right you want to be mindful of um threat intelligence tactics and things like that so you can you can prevent yourself from being victim to social engineering so I will pause there it looks like I'm out of time thank you if anyone wants to talk more about threat Intel I'll stick around for a few minutes [Applause] um next speaker yeah perfect

okay go ahead go ahead I'm Hermann younger meta Mass security team not working yeah no no we need to go back right okay so we're here to discuss Memphis project we want to deploy a public database of defy incidents but using standard call

sticks we will explain everything here first let's agree on the definition of incident there's a formal definition we get several impact but we can narrow it down to an event when a D5 agent loses an asset people need collections of incidents for several reasons we want to make studies for papers we want to hire what do I hire I hire an expert of a smart contract or are an expert on web3 wallet phishing I want to train my people what is the most complicated incident taxonomy what is the most complicated event

where's the money Lots Etc and risk management same reason sources we have lots lots of sources papers shout out to the centralized Finance attacks that's Joe 2022 it encompasses all the work done before we have all the kind of attacks we can find and Define the device space plus a taxonomy in five levels this is what we leverage to explain the ttps on each incident we have a sources security companies BSC insertation analysis slomis they do a lot of live

data they do a lot of frequent reports we have newsletters with lists going just great Molly white wrecked shout out as well blockchain threat intelligence by Peter cacharginski it's important you you need to subscribe if you can you will find a lot of hacks that happen scans you will have indicators of compromise and we have the individual research Samsung stack xvt whatever you are hi Sunset who has a repository that reproduces attacks by doing Forks in the same block is happening this is something that

we cannot just do that we have two we can do in web3 where we see exactly that I have it happen internal transaction Etc so we have the data we have the necessity so what's the problem the problem is we don't have a fixed a standard on how everybody publishes this information so for example if I want to make a recapilation for the Oracle compromise attacks I need to comp all the sources one by one need to do the job get the data do uh spreadsheet maybe a Json then do the processing and then get the total so if I get a report of 2022 see all the attacks I get a final amount but I don't get

the data set I don't get a unique data set we need to have that we need to have a standard so we built the standard and then mandatory joke we have 14 standards do we make a standard string Global no because we will have 15. so what how do we solve it we don't need to the standard that's the funny part sticks sticks is the standard we need for thread Interiors sticks is been around from 2012. More Than A decade is what the big boys use at web to to share information uh threat intelligence around big companies small companies Styx represents the data as a graph with

node and it just sticks can be represented in XML can be represented in Json so due to these properties is really easy to automate the process by pipelining or by automating the consumption the add-in of data Etc so sticks has what is called as domain objects which are types so I have types for attack pattern the ttps I have identities for researchers big teams attackers Etc indicators which are key in our case our addresses transactions intuition set which are the apts threat actors which is the actual hacker the

malicious actor malware which can be exploited in our case vulnerabilities you want to put CVS and we can relate all of this in a graph way so for example we have two campaigns by the same apt used in a specific redactor that has different kind of attack patterns ttps right we can associate the indicators to malware so we have a hatch we associate it to a malware and then if we have all this information together we just do a traversal over the data set we can as well put researchers when the researchers makes an observation to get

the credit or to get the reputation over the kind of data has been collected we can relate it which is very useful in our case if we want to valorate if we want to give a value over a tweet over a publication a blog or confidence information whatever this doesn't look very clear here but is the apt-1 the first apt defined by Mandy and mandian makes a PDF report about ads the stick representation how all the elements all the actors all the exploits all the techniques are together putting together inside this report

and most importantly sticks can be extended so we don't need to have a web 3 metaverse a D5 sticks we just use the same protocol and we add the elements we need in our proof of concept there are not more than seven here we name address transaction and import and estimated loss recall that for us an event is important if the actor loses an asset so the proposal was spoiled we really want to have this public that set available for everybody in a web interface and in an API publicly because we want to make the community contribute you know a proof of concept for example

we took the kyber swap incident last year you can see the threat actor all the addresses the full actor used the TTP which was leveraging Google tag manager the victim and the address of the victim now these are very simple objects but everybody every person who has done investigation can see that relationships appear as soon as you start to collecting enough data if you have a lot a number of objects the star randomly start to do the traversal you you may find a relationship between two types of attacks that were unrelated at first this is when motion last year as well lost 42 million dollars we can see the

addresses the kind of attack in this case is compromised on the private key and and the attacker if we don't have an attacker it doesn't matter we just Define that uh as a threat actor and then by virtue of looking at the relationship we just set the node we can add as many nodes if we want and and when we're rendering by doing some algorithm we get the objects we need to understand visualization let's not forget that this Json I just put some examples because in our first version we want to use is object on GitHub this is the most the centralized way to have it everybody can just contribute viable

requests there will be curated and added to the set then every actor who wants to do the analysis go into the repository gets all the data and and process it in their own graph database SQL database whatever flavor you want um notable examples the attack pattern the TTP is asset taxonomy this is that taxonomy we borrow from from the last article on defy attacks so this is in the layer auxilia it has thus cause a faulty web development so in this case for example we're missing the Google tech manager but as long as we start to recollect to compile more cases we can create

extended taxonomy which is one of our goals we have addresses as well as indicators and we Define thread actors so finally what are our goals why are we doing this it's all about intelligence collection analysis and dissemination collection really want us as meditama security team and the community to add data to this Repository so meant to become a well-reported definitive list of all hack transactions ever this has been asked in several form I want to have that I want to have all the transactions all the hacks in one single place

uh while this is centralized in a way if we use uh decentralized source is possible to manage one minute I will make it analysis uh of course if we got all the data the taxonomy build excellent will emerge so the actors will find a use for these database the actors that make decisions to take decisions and finally dissemination I got the seconds uh basically we look forward to mempo to become an essential infrastructure element essential fundamental it's vertex to the element on the device security community people will get into member will get

links and we'll identify incidents indicator for compromise we think that this is a product that is needed it's an application will be maintained by the community keeping the spirit of ethereum GitHub repository where we can discuss the rest of the features on on the issues thank you very much [Applause] look like quick quick announcement so the focus

talks we have very little buffer times in between the talks so we would like to request all the speakers of the next session session 10 if you're here in the auditorium or if you're listening to this downstairs please make yourself just come to the front row of the auditorium so that we don't lose time in tracking you and is Andres Monty from range oh great thank you perfect okay our next speaker easily and he's going to talk about defy Arc detection and prevention thank you so we are a bit late already I will go really fast

um so I'm a co-founder from d23e and we are working on different aspects of the security life cycle so typically there are three um three very important cycles for any attacks so there's the before launch we do kind of auditing and we also use automated tools to find the vulnerabilities for more verification fasting Etc we also have afternoon security so we have like vulnerability search intrusion detection prevention Etc and also after incident right we have a circuit breaker Etc

so the core members of d23 has worked in the entire cycle of D5 security and we have quite a lot of Publications here so I would like to share three Publications we have done this year with collaborated with other word leading researchers the first one is the blockchain imitation game um in essence we detect attack transactions in Memphis and we copy the anniversary contract to create our imitation contracts and we also generated imitation transaction and then we front around the attacker and steal the the profit if they were earned and then we will return the

profit to the D5 projects that's the first paper so for technical details you can check out the link on the top the second paper is blockchain large number model so in essence we build a large luxury model trained on previous transactions for D5 protocols to learn what's the normal behavior for transactions then once there's a abnormal transaction enters the system we will try to rank the transactions and if it passes a certain announce threshold we will issue an alarm and this will trigger potential defenses such as emergency posts just the second paper and the result is 49 out of the

124 attacks among the top three most available are among the top three most transactions for past attacks the third paper I want to share is this do you still need a manual smart contract audit the answer is yes for sure but what we actually did in the paper is we have this data set with 52 D5 attacks with the source code and the actual vulnerability and we also have a modern beta list from one of our previous papers um listing all the vulnerabilities we have in in D5 and then we do some prompt engineering ask large number models if there is an attack in the smart contract

a lot or not the answer is yes or no with some detailed specification of the vulnerability and then we compare the answer given by large launcher models with the actual vulnerability and we found out that both gpt4 and Cloud can correctly identify 40 of the vulnerabilities but the downside is it's having a very high false positive rate so that's it thank you [Applause] switch so it is just to switch the slides

this should be very like foreign it's coming in a few minutes yeah at the end of the day so even like

the technical stuff is tired just [Music]

okay um the slides are coming but I cannot really introduce the next speaker is Andres Monty and he's going to talk about question mitigative safety mechanism yeah so I mean I'm not gonna start with other slides because hey unfortunately I haven't memorized them but uh yeah I'm interest Monty there you go yeah thank you So today we're going to talk about mitigative measures for bridge exploits and yeah a bit about me I'm Andres Monte co-founder of range I've been working in crypto for about five years and specialized in security for the last three and it's particularly in the cosmos ecosystem so yeah today we are going to talk a bit about British exploits mitigative mechanisms with an emphasis in Cosmos

so white breeds get hacked I guess the first one is Bridges handle a lot of tvl so you know like they are like very good targets just for attackers that attackers mostly are rational economic actors so so yeah bridges are very targeted for that some designs are better than others images more on that later and bridges are very complex sometimes they have to integrate many different blockchains they have to be written in different languages so end up being even more complex than the blockchains that they are integrated with so like this is a really nice anatomy of bridges by types of design from from li-fi you can see in the blue like in

the very left uh the the most trusted designs like these are multi-6 and then as we go to the right we get to more like trashless designs in the middle we have like a POS validator insert systems and then in the in the very right we have what we call uh trust minimize or trustless designs one of that we are going to talk later is IBC with light clients and relays but then we have as well CK Bridges which there says non-exist but there are many other projects right now building them out so yeah like the reality is that all Bridge designs are not created equal I think as a community like we've made a lot of progress and moving more for like the the right side to the to the pink so

we are building more and using more uh trust minimize uh and trustless bridges but the reality is we are not there there as we've seen like in last week and many other events but we have to understand that most of the bridge exploits are not just because the designs are poor like if we see I mean there are some like for example the one the jello are uh multicid Bridges so Bridges where the key has been compromised like the big one of course is is running but the majority of bridges actually have been uh implementation flows right so it doesn't really matter uh the quality of your design How Sound your protocol is even

the most sound protocol Bridge protocols can be subject for for implementation flows this is the case for trustless Bridges but it's also the case for canonical Bridges between ethereum and Anil choose so we need to assume as an industry that we like it or not there will always be yet another software back and also like what we really realized is that as we move more to trans minimize and translate Bridges the the comp they're more complex like they are a very complex software projects like for example at the oblivinates of CK and and instead of the system so so there will always be bugs we need more proactive and

mitigative safety mechanisms how did some focus on code is not enough and also Bridge code bases are not immutable so our very large code bases that are really not immutable and also Bridges have a systemic risk to the whole critical system they are really the glue and they really pull systemic risks for all the applications that talk to so we need a different types of mechanisms and mitigative mechanisms some of them are here like for example rate limits that we are going to talk later like IBC rate limits and the recently proposed RC 728a1 we have also transaction delays as the one implemented by the war hunt deal with the Wormhole governor and their secret Breakers MMA

multi-message aggregators and also like hasi by the nurses team so now we are gonna step over the pond and go to the cosmos ecosystem how we are handling this right now so for those that don't know ibc's a transness protocol interability protocol that communicates arbitrary data between different state machines initially built for Cosmos but now these light clients have been important to other ecosystems like polkadot and ethereum and we have ibc3 limits I think is the first standard on the wild being used in production so these are governance configurable rate limits for fungible tokens over IBC this means as a native example that a specific token a cannot

be transferred more amount than 100 in in the last hour between in or out a certain chain and this is very important protection mechanism because it's not just protecting that there is implementation flaws at the bridge level but it's also protecting at the chain itself that the destination is not exploited so in Cosmos we talk a lot about sovereignty so what rate limits gives you is actually a sovereignty of how much you trust your counterparties when you're attained when you're a project and you are connected with another chain without rate limits you're actually just giving an open bar and and it says not the bridge that can be exploited but also

your counterparty so dread limits give us a kind of like parameters to reason about this trade of space we have two implementations the first one is by the osmosis team and this is implemented with Cosmo Watson smart Contours which is a framework written in Rust for for Cosmos and Compass to awesome and then we have a the native Cosmos SDK module written by the stripe and this is just the present this is in production this is life but what is the future looking at for us so we want to stand as a community Vision like fungible token transfers as we mentioned before ibc's arbitrary message passing so we can pretty much put rate limits in

any type of message that happens across chain uh we would like also to combine rate limits with transaction delaying as we discussed with Warhol I think there are many cool features that you can do here and then also just make them smarter so make them dynamically adjustable so you can you know based on online events you can adjust uh the the very limit of a certain token pair so you could even say Hey whenever upgrade happens make like the rate limit very small and then you can continually increase it as you get more confidence on your on your implementation and this is really like our Focus that we are putting in in range so we are building in Cosmos and we are kind of putting layers of security layers on top

of IBC integrating of chain monitoring systems and also this on chain mediative uh techniques that we've discussed before like on-sym mechanisms uh like rate limits circuit breakers and more uh we arranged my Twitter handle is AES Monty in Twitter and I'm just super excited as well to know uh how other you know Bridges other projects are thinking about this and on other unseen safety mechanisms so yeah just reach us over Twitter or here in the conference like super looking forward to discuss all these topics and yeah thank you very much for your attention thank you [Music]

um okay so we are taking a five minute breaks and we will be back if you have any question for the speaker don't hesitate you know to look for them and to contact them directly let's please thank Jocelyn from Trailer bits for uh chairing this session thank you fantastic set of talks [Applause] so the the cocktails and the snacks are still being served they'll be served till 10 pm I believe so please feel free to go and grab a snack or grab a drink and come back food is not allowed here

technically yeah so if you want to eat and watch we do have the other rooms on this floor outside to your right and for the next session speakers for the next session please please join us and meet us here if you haven't already so the next session is going to start in a few minutes and for that uh the chair is going to be tomorrow from sartura so please give a warm welcome thank you good

[Music] foreign foreign

[Music] foreign [Music] [Music]

thank you [Music] [Music] foreign [Music] [Music]

thank you [Music] [Music] foreign [Music] [Music]

[Music] from a founder of B protocol on a simple economic risk approximations good luck yeah thank you yeah okay thank you everyone for participating in this last session of the day so my talk is about simple economic risk approximation but also mostly about sort of finding a uni swap formula for landing market and along to Value ratios and so just some quick background on you

know what is risk management economic risk management and non-to-value ratios so basically there are you know like multiple parameters that one has to be set in the leading Market in this talk I will mostly focus on the loan to value ratio which means that basically if you put some collateral how much depth you can borrow against it uh well obviously in the permission setting the goal is to make sure that you always have some incentive to repair your loan because no one can you know there are no other means to come in you know kind of nicely ask you to okay please repay the only guarantee here is the

collateral without it we will end up in some bad debt or other bad incident event and the fact is that you know risk management not not only in if I in crypto in general but also in tradeify is notoriously known for being you know something which is both very political and very kind of human but even work we saw bankruptcy recently yeah okay maybe I was first should say that you know like the Inception of Bitcoin roughly came because of the 2008 crisis where credit uh score writing agencies you know kind of give a

very positive ranking for a subprime loans and then can crypto but of course also with crypto we saw with the three Aero bankruptcy Genesis trade bankruptcy they just say okay maybe let's not you know liquidate three error because you know if you liquidate them we will lose a lot if you want liquidate them we might profit and they bounce back and we all know how it happened you know how it ended likely with the bankruptcy of Genesis Trading with safety X you know it's more like a criminal activity and fraudulent uh intent but eventually the you know they just say okay let's not liquidate Alameda let them have whatever position they want and you know it also ended

badly but yeah but even in regulated markets you know this is kind of notoriously a bad thing and again the 2008 subprime crisis is like the prime example but we see such examples like on a yearly basis and yeah and then come defy with the promise of okay everything is transparent on chain but yeah but the reality is that most of the fine Landing markets right now are sort of mostly on chain Banks has to take the trading decision which which is even worse in a sense because