DeFi Security Summit 2023: Day 2, 16 July

Transcript

[Music] thank you [Music] [Music]

foreign [Music] foreign [Music] [Music]

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

foreign [Music] [Music] good morning everybody how are you doing

how tired are you okay good okay well today is a bit shorter uh but uh I think we have amazing talks we have a lot of things we have uh spicy Partners you see you have some uh I've watched the telegram this you're gonna have some fun so I would like to introduce you Shaya who is the first session chair all right let's get this show on the road happy to be uh starting the or kicking off the second day of DSs happy to be here

um and I'm not gonna always say in time have you guys listen to me so if you uh introduce Mark Toda he'll be speaking about modern secure or modern smart contract design and security without compromise hello good morning uh yeah I'm Mark Toda I'm a protocol engineer at uniswap Labs um I'm sure many of you saw that we released our unit swap V4 protocol a few weeks ago I'm going to be talking about it today I only have about 10 minutes I'm going to be giving you a brief overview of kind of the architecture of unisaw V4 specifically talking about our Singleton and Flash accounting pattern

and how it sort of affects the security of the system um okay so kind of a standard design principle for smart contracts and one that you know swap really cares about is this idea of sort of defining your invariance and enforcing them explicitly and tightly on your smart contracts um and sort of a famous example of this is the XY equals K curve from uniswap V1 and V2 you know there's like a single line of code where we're enforcing the invariant and it sort of ensures the security of the unit swap pools and sort of one important thing to note about the way that we like sort of traditionally have handled these invariants is sort of that they use the smart contract as like the base unit for invariant checking right like one pool

in unison V1 and V2 and V3 is one smart contract and the invariants sort of apply to one pool and so any operations over that pool you know the invariants are enforced and like each pool is sort of its own set of invariants and its own checks and this is a really nice abstraction for smart contracts because it makes them quite easy to audit right like every smart contract has these things that you can verify and things that you can test it makes them makes it quite a bit easier to reason about changes to the protocol as well and sort of the asset positions specifically for unit swap are segregated by pool which allows for some nice checks but it does have a few downsides which I'll try to explain here one is that there's sort of if

you're performing operations over the unisot protocol that affect multiple pools then there's some intermediate checks between the different pools that have to be done which can cause some gas inefficiency it's also hard to do more than one operation at a time and I'll give examples for both of these so here's an example where someone is doing a swap across two pools on uniswap this could be unusual V2 or V3 so for example here they're swapping weave to die but there's this usdc intermediate step and so the first thing a router will do was would be to you know swap width for usdc on the with the uscc pool and because the invariance and the logic is handled contract by contract pool by pool the with usdc pool you know checks

the curve and sees how much usdc the user should get for a certain amount of Wheat and sends that back to the router and then the router has to do the second stage separately where it goes and talks to the uscc dipole sends its uscc there and it swaps for the die secondary pool checks for its invariants sort of separately right and so the key thing to note here is that this usdc is kind of like a intermediate operation in terms of the protocol itself but because each pool is handled separately it has to be sort of fully settled in the middle right so this usdc is like transferred back from the protocol to the router and then back to the protocol so you can see how that's kind of a potentially inefficient like extra step another example here would be if we're

trying to like Swap and add liquidity to one single pool um like if we just had one side if we had just we think we wanted to add liquidity on wheat and usdc at the same time um it's one pool but it's two operations on one pool and the invariants are checked operation by operation as well and so the router would have to send the wheat in uh swap it for you know half of it for usdc and then send them both back to the pool to add and so again you see this intermediate step with the usdc that potentially like is uh is unnecessary and so as we were sort of thinking about designing a new protocol we were thinking how can we improve this trade-off while also you know making you know making it easier to interact with the pools easier to build Integrations

and also maintaining this sort of uh invariant checking system and so the first thing that we did which seems kind of like the the main way to do this is to make uh Unison a Singleton as opposed to like a multi-contract system and so in Minnesota V4 there's one single contract that holds all the pools we call that the Singleton or the pool manager and so all pools live on this contract instead of being separate contracts with separate asset balances all the asset balances are shared and the pools are handled by uh struct and the library construct that handles all of the curve math so each pool is still able to maintain its invariance and maintain the balances of its curve using that Library construct construct but we have the ability here as you can see to kind of

perform multiple operations in the same smart contract and the way that we actually do this is using an interaction pattern called flash accounting which is specifically enabled by a new EIP called EIP 1153 or transient storage which is not out yet but it should be out in the next hard Fork Cancun and so the basic pattern of flash accounting and again I'll go through an example of this is that the router can still make calls one by one operations swaps and add liquidities across different pools each pool still asserts its invariance on each operation but instead of settling them right then as the operation occurs they sort of store the the delta or they store like what needs to happen for these operations to be valid and as all these operations

happen those Deltas kind of aggregate and only at the very end when the router or the integration is done operating on the pool is everything fully settled so I'll explain an example here so here we have like a router and we have the V4 Singleton pool manager which has many pools so it's going to be the same thing where we're swapping wheat for die with usdc in the middle so the first thing the router will do is call a function called lock on the Singleton and lock is sort of the way that you start this context or you start this like multi-operation transaction and so calling lock does two things it sets up a lock accounting context on the Singleton which is a transient storage mapping basically of two sides like debits and credits where one is tokens

that the pool is owed for the operations to be valid and the other one is tokens that the pool owes to the user that they can take and then the Singleton calls a callback on the router which lets them perform operations under this context so first operation here might be let's swap one week for usdc and what happens in the Singleton when that operation is called is it talks to the pool construct which is just like it operates pretty similarly to a unisaw V3 pool and the construct will say okay if I get one week I can give the user 1800 usdc based on the curves and the liquidity and so on and then the Singleton will add that sort of Delta to the lock accounting so in this case it says I need one with because that's what the

user was swapping and I owe the user 1800 uscc and then if we do the second swap here where we're swapping 1800 usdc for die we'll talk to another Pool and again that pool operates independently using the library instruct construct and it says okay if I get 1800 usdc I can give the user 1800 die and importantly here those Deltas cancel out so when the 1800 usdc is sort of given to this usdc die pool it cancels out from the lock accounting because it was an intermediate step and now the lock accounting says okay I need one width and I can give 1800 die and now the router can call a function called take which literally just takes from this o side of the lock accounting

and it pulls the tokens into the router and then there's another operation called subtle which is basically like you send in funds and then it settles the Need side of the lock accounting so the writer might send in one weave and call subtle which would clear out the lock accounting and then once the full lock call is done the Singleton essentially needs to just check like is everything settled right are all of the are all of the Deltas zero and if so then we know that every pool was satisfied and the full swap the full operation was was done properly and so yeah again transient storage is really important here because as you can imagine all of these operations and all of this accounting is happening

um on every call like separate calls and so if we had to do this before transient storage it would be full s stores for every Delta um and so with transient storage because these are sort of only temporary State it's only needed for the context of this operation we can throw it away afterwards and transient storage is is much cheaper for that operation also this is quite flexible in terms of operations because or in terms of Integrations because you can you know call many operations on many pools in whatever order you want integrate with other external protocols as well makes it makes it quite easy also yeah the invariants are so managed tightly by the pool so we can like buzz test and formally verify those pool constructs which is which is a nice

security principle okay obviously it's very short um there's many more talks on universal V4 at ECC I put a few of them here um yeah go see them thank you oh thank you so much Mark so who has questions about univ4 oh there's a lot of questions regular mic hi thanks for the talk um

in terms of invariant check usually it's encouraged at end of the operations and it's great for the protocol itself but do you think it opens other attack vectors because encourage you know it basically ignore the middle steps in a largely sense for example you know read only reagency and what's your take on that and how should we deal with that yeah that that's a good question I think from my perspective kind of the uh if I'm not sure if you've like read the code but it's quite similar actually to the the code of universal V3 it's just like instead of being the whole smart contract it's a library inside of it and so basically the only change to the ways that the invariants are handled

is that instead of checking the required tokens in and tokens out after a swap they just get added to the Deltas and so like from the perspective of a pool as long as the Deltas are being satisfied properly throughout the entire transaction all of the invariants are satisfied if that if that makes sense I think the sort of re-entrancy and multi-operation flow is uh actually pretty unchanged in this case yeah hello hi so how do you handle uh tokens that do weird things in this new model of only one single pool yeah that is a good question

um again it's actually pretty much the same as unisot V3 like you can make a universal B3 pool with any random tokens you want and like maybe the sort of behavior of that pool is is undefined in that case and that's the case on unisaw V4 as well but but because these sort of logic and state and checks of every pool is segregated within the Singleton uh it still actually doesn't affect the solvency of the pool as a whole or up pool might have less tokens what do you mean by that if somebody uh you know if weird behaving coin actually remove your balance or increase your balance you know the pool's accounting you know the total accounting might be off

right oh right I see I see what you mean yeah um that definitely would be true but it would only affect other pools that also have this weird token which affects balances right okay cool any other or sorry is um Jeremiah here yeah awesome awesome well thank you so much Mark let's give it up for Mark again and now we'll have Jeremiah Smith from um open cover talking to us about the state of defy Insurance uh hey everyone I'm Jeremiah co-founder and CEO at opencover I'm also one of the

lucky 280 or so oh uh uh oh is it this what I'm supposed Okay so I'm also one of the 280 or so lucky people in the world that got wrecked by the Terra ustdpack but then got unwracked because I had purchased insurance or more precisely uh d-peg cover and it was interesting because I had professional experience working with D5 Insurance protocols on a personal basis I had been using the product since like 2021 but it was the first time I had a claim and it was also a kind of the first time that the the industry had a

major stress test more more money was paid out in connection with the UST Depot than any other event before it um so it was you know like it wasn't perfect um but it worked so people got their payouts and it was a kind of fascinating fascinating moment to to or fascinating kind of experience to um to have in fact it was so fascinating that uh we decided to build the First Data aggregator for the defy insurance industry really the idea was to shed light on the different players the different approaches how much underwriting Capital there was um and that's how we launched open cover long story short we've been collecting

data for 12 months now a couple of months ago we released what we believe to be the first comprehensive industry reports on defy insurance it's on opencover.com if you want to check it out and really this talk is sort of sharing the top 10 things we've learned in the process so I guess the first thing um what we typically call defy insurance is actually oftentimes defy cover it is the sort of Define native on chain equivalent to Insurance it serves the same purpose as insurance but it is unregulated which means that it does work a little bit differently so for example payouts are typically discretionary rather than contractual there's no onwards manner of course Etc we're seeing about uh or I should say at

least um 15 teams working in the like working as insurers doing underwriting so there on the bottom you've got the the regulated players so the the ones offering sort of bonafida insurance and on top you've got the the on-chain ones offering the the cover the cover products and really there the um the main sort of difference or what are the important differences anyway between the the on-chain providers is in the claim assessment so they're different approaches there's Community voting there's uh parametric approaches where effectively you can claim a payout automatically if a certain condition is satisfied on chain uh there is optimistic Oracle approaches or effectively new claims are considered

valid uh unless they're challenged within a certain period if they're challenged there's an arbitration process and then there's the expert claims assessment approach which is more similar to the to the traditional um to the traditional one in terms of um the kind of standard categories of products that you could find on the market today you've got protocol protection which will protect you against things like smart contract bugs Oracle manipulation governance attacks you've got deepeg protection which is typically like stable coin Deepak protection you've got a new one bridge bridge protection basically the idea there is that you pay a little bit more for your bridging transaction but you get a guarantee of the outcome within a

certain certain amount of time and then you have the sort of non-retail ones the slashing protection for validators to protect them against slashing penalties or and or missed rewards and audit cover which is effectively kind of like a guarantee on an audit if a bug filters through an audit and then causes some sort of financial loss the protocol can claim from the from the protection provider moving to sort of uh the core metrics of the industry so here we're really looking at the um the on-chain of providers mostly it's a bit harder to get data for off-chain providers so if we look at the top 10 on-chain providers and

um the the associate underwriting Capital what we've seen in the last year is a drop of about 15 in the amount of underwriting Capital so that's the capital really backing the policy the stuff that gets paid out that gets paid out if um there's a valid claim that drop is in line with the overall drop in D5 TV also no huge surprise there but worth noting that 80 of this Capital comes from one provider which is Nexus Mutual if you've heard of them uh more surprising is the drop in active cover so we're seeing an 80 drop in active cover in the last year so we're at about 45 000 ether which is something like 0.2 percent of d5's TBL at the moment

even more surprising is that at the same time we've seen an increase in the number of covers purchased so the number of wallets that purchased cover for the first time um if you see there's like a little Spike there around November the FTX collapse and then between what's that like Feb and may there are also some spikes we think the latter is is due to airdrop farming I think arbitrums airdrop was around there um but overall I think the the Insight is like the number of covers sold is in the low tens of thousands so all time uh the number of unique wallets that have purchased these types of products are in the low tens of thousands and I think there's more than six billion wallets now that have interacted with D5 so

we're looking at it like a really really low penetration it's still very very early um so I guess that's like 0.2 0.3 0.4 percent penetration if you look at the payouts um on the top 10 providers we've tracked 580 claims and that led to a bit over 40 million paid out as I said mostly around the UST I'd say around and after the the UST Depot and if we look at what that means in terms of Provider cover provider profitability um if you look at the loss ratio which is the ratio of the amount of like the funds paid out and the the funds collected as cover premiums or cover fees were above 100

for most of the providers that have had significant payouts so that means that they've kind of paid out more than they've collected so unfortunately although it's a very important part of the ecosystem it's not yet super profitable I guess to to be a cover provider but uh you know hopefully things will will change soon and talking about yeah the future so what's the future really of defy insurance and D5 cover I guess that's the same question is what's the future of defy and that's a Pandora's Box that we're not going to open right now but what we will say is that uh on the provider side we're expecting a continued shift to uh Marketplace

um to sort of marketplaces so um basically anyone can create a cover or Insurance product anyone can fund and the the the capacity for that product anybody can buy that so sort of more collaborative decentralized approach compared to to the traditional one so we've seen this with Nexus Mutual V2 that launched basically a couple of months ago it's pretty much a Marketplace other leading providers like insurers are working on marketing places and newer providers like Neptune Mutual cozy names are going to Market directly with a Marketplace product on the protocol side as we've been discussing for the last couple of days or I mean I guess if you were here at the workout we are expecting a focus on

security architecture so basically not just like preventing attacks but limiting their impact if they do happen so things like circuit breakers and overall we expect that will lead to lower premiums and in terms of end users we expect to see a lot more embedded protection so that's Protection cover or Insurance offered at the point of transaction so like in wallets in um in the portfolio trackers in dapps uh kind of like bridge cover where you're basically bridging there's a toggle you toggle it if you want to pay a little extra to to have your your the outcome of the transaction guarantee and I only have a minute left which is perfect because that's the last slide all right thank you

thank you nice thank you so much Jeremiah um maybe we have time for one question anybody have a question about do you find insurance all right well I think it's time for a break in that case thank you so much thanks [Applause] [Music] morning so we have a quick 10 minute break

and this is not a coffee break so um that's going to be a little later we're going to start at nine on session 12 on vulnerabilities and exploits it's going to be chaired by Spencer from spear bit so please uh make your way and if you're a speaker in this session please make your way to the first row do we have Andre from bgd thank you [Music]

foreign [Music] foreign

[Music] foreign [Music] [Music]

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

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

[Music] morning do we have Jin Von from uniswap Labs here ah great can you please make your way to the front all right good morning everyone I'm

Spencer from Spirit session share for session 12 vulnerabilities and exploits have a really diverse group of folks going to be talking over the next uh hour and a half or so so first I'm going to introduce Andre kozloff from bgd Labs he's going to talk about some security challenges on it good morning everyone it's not about most like our security challenges but yeah like more about our governance yeah my name is Andrei and I'm working last almost five years around our protocol originally I was the part of Iowa Genesis team and last year we created the bgd labs initiative and now engaged

directly by the Dao and we are trying to think mostly about the Dow itself and what will be the talk about I want to make a short like introduction which everybody aware of how our protocol was evolving but from a bit different perspective like initially a long time ago let's say around like four years we got rbv1 it was a minute it was controlled by multi-seek and but on the early stage everybody was accepting it and it was fine but then over time it was not an option and we developed our governance which allowed us to control the pool completely uh through the voting system sure and we

was in a quite good spot good position but over time it was quite high demand of expansion to go to the different networks like to polygon then to Avalanche to some other also we grew and mainnet with some other components with a safety model and so on and very interesting question appear but how to expand because okay we can go to optimism which happened a bit later but security of the bridge on optimism is the same as the security of optimism itself so we can go there and it will be fine another option we can go to polygon and there is official Bridge but it's not the same security as

polygon itself and then we can talk about Avalanche where there is no official breach there is just some Bridge which is just doing the mint in burning tokens and what to do because guardian or multisig is not an option because we are going back to the same centralization point which we had let's say one or two years ago on our everyone and the main pool on ethereum uh then yeah we can choose one of these Bridges if it's not relapse but then we end in the same centralization problem because we fully depending on one particular bridge and we don't know anything about this bridge like yes for sure we can check the code

base we can check what they tell about validators we can trust that all these validators are independent but then even one line of code can ruin everything completely it's quite fragile situation and also if you want to expand more like okay imagine we checked one Bridge it took for us let's say one month of the engineering work and now we want to go to another Network we need to spend another month and still we don't have full assurance that we will be living in peace we will be we'll have a good decentralization level and so on and so forth so what should we do and how to survive in this environment

because like it's more and more networks over time and that's actually what we were working in a bgd Labs last year we were thinking about this particular problem and now we are coming with the other delivery infrastructure the main idea is you know what why we should depend on one particular Bridge provider why not to do aggregation on top of them because if we have three providers all of them have different community and it's quite remote to imagine that two out of three or three out of four will disappear in the same moment or will be hacked or like we'll go down whatever so with this thing we can have quite good level of

security and also we don't need to dig so deep into the every bridge like now for us more important question how reliable is it I mean in terms of availability also the cost for sure security is also very important question but if we fail once we can survive and yeah the high level architecture is that we create our own transaction let's say on our aggregation level which is completely Unchained we send it through three or four or whatever different Bridges and we accept it as confirmed only when we receive it multiple times

let's say two out of three on the destination Network before we we think that it's route or like we don't know what is it apart from this we like a bit go in the deeper in the technical we have couple of levels of abstraction inside the system to guarantee the delivery because if we will lose the consensus maybe we will want to retry the message and maybe we will not be able to send a message to not Bridges from the beginning so yeah we have also some retry mechanisms for that because I would think that it's very important if you send a message once it should be delivered like for sure but imagine what what will happen if it will really happen and two Bridges out

of three let's say will be misfunctional maybe they will not be malicious like nobody knows what can happen and for that we have emergency mode because we still have a garden in our system but in normal mode the guardian operates more like spam attack protection if you need to retry some transaction or if we need to execute some action receiving to not spend our funds on the bridge we have a guardian but in case of emergency and to activate an emergency we need to create the vote in a main net activate the specific Oracle which is like independent delivery channel to this network

then a guardian takes more or less full control and can reconfigure the system so here like if you want to screw the system you need to have control over a social garden and you need to also have control over let's say Oracle of the like chain link level I mean which is also quite tricky so it's quite good but is it good enough already because it seems that we solved the problem of centralization on the crossing Communication in a very simple way which I really like is the application Level developer because you don't need to to dig so much into how the roll up work or how the the communication of this particular Bridge working but still we have some problems because

originally when our governance was designed in the good old times the gas was one gigaby there was no so much of a bull market so the voting was efficient we were able to vote with let's say one dollar per person and the participation was not the question at all it is still like debatable is it a problem or not so much but the the holders of let's say fifty dollars worth of have a token or one hundred dollars or even two thousand dollars to five maybe they will don't want to spend fifty dollars to to make a one particular vote ethereum is crazy and in the same time we don't want to go

again to the centralization point because we will be happy to move uh voting out from ethereum but what do we do we cannot just do it on the some centralized entity and that's why we are coming with our governance we won V3 sorry and our main idea is to move voting out from ethereum but now because we have quite trustable infrastructure which we control from the both sides and we understand how it works completely we can move move it out and how to do it very simple it's the storage proofs because the current version of Davao governance is based on the on-chain proofs so on every transfer the same is uniform compound

and all like mainstream governance on every token transfer you create a snapshot to understand how was the balance of the guy but it's good bad and it's not so gas efficient but the ethereum like native mechanism is the block hash because block hash kind of contains all information about the blockchain in the moment of time so all we need to do we just need to bridge this block hash on another Network which is cheap and to start vote from there and it's yeah it's very simple as simple as as this but yeah I I will give just a little picture so we've reached the storage proof and then

any user just go into the normal RPC of ethereum you don't need to bridge any funds you don't need to do anything you just take the the proof and you deliver it there and that's it and also because we are on the cheap Network we can improve the user experience because we can add relayer in the in between and say you know what governance we're going to pay because every vote will cost let's say 20 30 cents on the polygon or another lunch so whoever can participate even not having polygon and Avalanche and even don't have any in any funds at all just our tokens uh why uh our delivery infrastructure is also very efficient in

the case of the governance because governance is very slow system and when we send the message through like three or four different Bridge providers it can be slow it can be expensive but if you're working with a governance system and you want something now it means that you're in the big troubles and you're in the wrong place because our government like vote takes five days and then you have time logs and so on and so forth and for that like to have another half of our delay on the bridge one hour it doesn't matter at all so we have here multiple phases we create the proposal then there is like some time log to before activating the vote in uh to for people to prepare

their balances then when we deliver results we also have another time lock because still even if we trust to our cross chain infrastructure there can be some malicious action so also we try to design crocheting independently from the Dow itself so that we don't trust anyone even own crushing so the guardian can cancel if something and then yeah you deliver to the destination Network and there you have another time lock and you can execute it another key features of our governance apart from Storage groups now we can have multiple voting machines like also we not depend just on polygon

for example if we will put a voting machine there we can put our voting machine on Avalanche we can put it on optimistic roll up unfortunately we cannot put it on ZK at the moment because kitchen costs too much money and I think many people noticed it in the last year of development also we have a mainnet backup which guarantees us that even every even if all side chains will go down still we can vote for proposals and and make them work and another quite important thing which is sounds a bit smaller but we think this is very important because last year we were working a lot on improving the uh how is the name of on simulation of the governance

proposal because it's hard to predict what will happen if you'll just be checking code it's good if you can check all state transitions which will happen in the transaction you can understand what exactly happened so in the current governance system we Bridge the full payload and the byte codes let's say and the byte code through the bridge but it's not efficient because you don't know what you will receive on another side of the bridge yeah you expect that it will be this but maybe some extra IDs will appear maybe some other stuff so now we have payloads controllers like the place where we create our payloads on every particular Network and we bring just IDs so in terms of simulation for us it's very simple we just say Okay

id15 appear and all the code and all like information is already there we can say how it will be in the end quite in advance okay and what we learned during this development Pro process uh we was like heavily using properties and formal verification and for me at least I understand that it's the best debugging because when you're trying to define the properties on the system like cross chain communication or like or Dao it's very very important because many things you think that you thought but you actually didn't and then formal verification

explains you very very fast and another thing that the basic blockchain mechanisms are very underutilized on the application layer because for sure like when you hear something about Roll-Ups when you hear about like core mechanisms of chains or you know some circuits you hear a lot of them but when the when you when you go and check at least like how it was a year ago when we wanted to find at least simple example of with the good code base just to make a test with the stories proves that was nothing like it was some examples but they was not working and we think that it's still like quite undiscovered and interesting Direction

just the point like how to find good application of it and yeah that the communication protocols uh very very hard because when you dig into them then you see and when you see all the hacks around it's very tough story and this is digitalization is even harder so now we think that when we're in a good shape but it's hard to imagine it actually how to make it still perfect okay that's all I wanted to say thank you questions thank you [Applause]

any questions hi um you mentioned that you potentially will have different voting machines across different chains um would they be happening at the same time and aggregate it back to mainnet for the decision or do they exist only one at a time um of course they exist only one at a time as the backup mechanism because you can take decision based on the gas cost and everything like where to vote right now because when we start going this direction that we want to aggregate some

data across multiple chains it becomes very very complicated like originally we had also high demand people are saying oh guys but we want our tokens on polygon voting because there is also important Supply but when we go into the synchronization topic how to understand and which particular moment of time will lock both networks it's impossible so that's why the the same thing is also impossible to have voting on two machines you need to have exclusion I mean possible but useless what was your approach to testing did you attempt to automate it the testing

communication protocols especially cross chain are difficult to test just curious how did you approach that because in our case we accept some parts as the Black Box I mean the bridge in the middle itself we cannot test it uh so in our case testing is way way much simpler system because we have color chain like a sender and First Chain receiver and they are quite isolated between each other it's very simple system so we were using apart from formal verification the test but it was mostly like unit test because then like I send the message and I can be sure on another side that this message is from there

but why I can be sure because I received it from the multiple Bridge providers where they have like big Community behind and we we cannot consider that all of them will disappear in the same moment in the same hack if we consider it then it's different story thank you very much [Applause] all right everyone our next talk is

going to be Hassan Muhammad uh from halborn give it up for her Psalm everyone [Applause] hello everyone so we're going to talk today about breaking digital assets costly solution okay so yeah I'm more intro about me I'm

Center security architect Holborn my backgrounds were in realty research and offensive Security operation over like seven years uh mostly like iOS and windows in terms of vulnerability research and red team in terms of events of security right now doing R D Hall burn and yeah rounding around and stuff you can follow me on Twitter uh yeah so more about us Holborn we are like specifically as r d we have found like uh some zero days a lot of them a lot of vulnerabilities this is one of the most two famous One abilities we have this closed recently uhm is quality and the one I personally found is the dogeco environability which is effect

also 280 Network uh yeah that's what the brands we are working with yep so today's agenda we're going to talk about what's the digital asset security cost to these Solutions we're going to talk about NBC some cryptography stuff and we're gonna talk about uh real-born voltage and this original presentation has been like for one hour long presentation but it have been like squeezed to just for the timeline we have today uh so like who was the Axor digital accessory Solutions like Banks or centralized exchange they're not holding their assets differently like in minimize qualities or their own self-castell wallets they have like a

more complicated procedures to execute large transactions let's say to move like from Treasure to another one and they are using technically something called like casting Solutions uh this is just a market overview I believe that this slice is really out of date because right now the market value is really different than the one we are seeing here uh yeah so what's the difference between your Minima squad or your soft Castle wallet versus like a really Enterprise grade kind of digital asset capacity so your wallets like small amount we're

going to talk a small amount this could be like some few millions of dollars that's considered small amounts for the amounts operated through custom solution Enterprise great custom solutions for big financial institutions uh simple cryptography digital signatures it could involve like some multisex some simple multi wallets uh you're using it like normal users are using it like not financial institution that's a crypto exchanges and stuff like that but for digital custom Solutions what banks are using it like this is where banks are storing uh their digital assets to like Bitcoins or speeds or any kind of curved currencies and also like centralized exchange so like when they're holding their liquidity Zone

stuff like that uh the transactions is like more frequent large amounts it could be like a billion of dollars some cases in terms of the cryptography behind that custody Solutions is mostly like MC protocols uh sharehold signatures keys and other complex cartographic protocols we're going to talk about each one of them so yeah as simple as that like when you are in shape and transaction from yourself Castle Wallace is just like a few buttons maybe you're entering a password but for a casting solution like I have seen something close to that one like kind of casting Solutions where you have

some people like required to enter a specific room use like specific laptop or an iPad to sign a specific transaction and stuff like that there's also procedures like for that mostly for financial institutions so yes there's stuff like that for this should uh uh so why we should care about digital casting Securities actually like the digital casting solutions they are designed for Securities like to provide security forced digital assets so that like I would call them like uh a security product or a product have been built with a lot of security consideration would make it like really hard to break uh but let's assume like two following scenarios like in web to space and web series space and web2

space uh we are breaking into a financial institution we are getting access we're becoming like domain admin stuff like that we are compromising like the sun guard or this app start to craft like some soft messages yeah that would work like 10 years ago but right now it's like more complicated stuff like yeah when attackers like games that much access and they start to actually craft uh this kind of messages yeah there's a lot of precisions action responses like it will not work uh that much easy but on web3 like you can just like gain control over the infrastructure and this is definitely optional because you can do like some tags some smart contract attacks if smart contracts are part of system you can compromise like the key

materials or the private keys and like just sign your transaction send your transaction and all of your friends come it's not much easy in web3 that's why like three actors nowadays are focusing on more attacking like kind of work through institutions and virtual reality stuff other than regular financial institutions because it's really easy to make profit over them so yeah that's like a kind of uh compromised scenario of a normal let's say a centralized exchange they're not using any kind of gasoline Solutions so the attackers are still compromising the operation machines and the operation machines interacting with the backends

to handling the private key let's say and sign kind of some kind of transactions and they just send this transaction broadcasting it to bitcoin node but in a secure scenario or like oh where is that exchange using kind of casting Solutions so we will have something like this one's a function inside it's like the customer let's say or like the multi secure competition or whatever so when the attacker is trying okay I want to show you the request for transferring one million dollar there's like kind of a part of the cast solution it's like kind of a policy manager we'll talk about this a regular policy manager will like give

some alerts and shade some NPC and start to like paying people they have been transactions we've all just like kind of okay we're just satis action it's not us and yeah it's attack will fail or the attacker will be like not really able to take the money out uh so yeah the core functionality of casting solution is like MBC or TSS or more signatures are not all the same definitely so like the NPCs use like a multiple parses coming together to compute a value based on like uh private inputs a TSS is like a distributed K generation

and the small signatures like just like mod signatures we are using almost like everyday and our curves to life where we like have a group of people trying to authorize on a specific transaction so I will talk a lot more about NBC because NBC is like the core part of a castle solution but definitely there's a lot of other things related to custom Solutions like as communication channels but as a core saying is happening uh inside The cryptographic Primitives of rescue solution which is uh mostly based on NPC so NPC is not like an actual cryptographic broker but it's more like hashing like when I say hashing like there's all functions can

come to your mind to make the actual hashing it's the same for embassy you can you can employ like multiple cryptographic appearances to build like an embassy or multiple competition so it's early in 82 like some historical stuff and the embassies that when cryptographer actually starts to talk about NBC it wasn't really about cryptocurrencies and digital assets security or digital transactions because that time they didn't have a kind of the stuff so some research yeah definitely they're not like publicly classified informations but most of like the embassy research paper was related to some other activities that time when

they are like color launching missiles and stuff like that so nowadays we have like really common papers for the digital assets security like people who's building like custom Solutions this is the most top protocol I have seen when people are implementing their own classes or the cases that have been auditing so like GG okay bus General golf header that's the most common one I have seen and DMZ I don't know what's DMZ stand for but there's a lot of open source library is using a DMZ paper implementation so uh not about like when you start to the end like at the GG protocol or the

implementation you will see like there's a lot of a research have done like attacking these protocols actually and there is no one attacks but people like for example when you just like grab this Rebel or you're trying to implement your own protocol uh you're not gonna really like scroll down to all differences I know okay yeah definitely you will check the skirts because there's something security but you will not read each like kind of research paper that's really time consuming but there is a lot of current attacks on this YouTube protocol but still commonly used is it to find bugs let's say because for example when I'm getting an artist they're using like GG broker I'm not saying GGG protocol is not secure but uh yeah it's more common

to find implementation or other call uh so ways like to do like the embassies it can be done like through the secret Choice sharing schemes like customers like sharing Social Security and other cultural cryptographic Primitives you can't just pull together and create your own NPC like VR cryptographer I I don't recommend you to do that definitely so what do you need to break a decent uh additional asset security solution so you need to like have a breaker mindset read some codes some masses required I do believe

understanding like additional signatures definitely but yeah I mean the actual core of costly solution is more in terms of cryptography stuff but you can still break a custom solution like attacking their like web interface or the API interface or other stuff yeah this can work but you can also attack the cryptographic bars so uh trust no one every component inside the actual classy solution is the let's say is a vulnerable because like this red modeling of a constitution is like uh should be kind of completely different other than a normal software because for example you don't even trust your CPU or operating system and we're going to talk

about this in a moment uh yeah work however if you want we are hiring if you're interested in as stuff you can bring me after the talk uh so yeah we're gonna talk about a red flags when we are starting like kind of Engagement with all the things the show has to custody so the most common Red Flags uh is and by the way is this what like this flag that has like some real scenarios but I have just squeezed it because of the time so yeah we're coming we are running our own implementation of the cryptographic protocol or we are started our own emcee implementation or css implementation that's the right flag and we're going to talk about these

Industrials we don't have securing claim or trusted execution environment or uh okay we have securing Clays we have HSN hsms we have but we don't know like the context management and domain management CNC plus plus and or remember station oh unsafe memory languages so we have like first scenario we are running on our implementation we are running our own implementation could be like closed Source implementation or could be an open source as actual argue his retina it's not related to whatever it's open source or closed Source implementation uh it's just like it's their own implementation because most of the people they don't have access to like Rockstar cryptographers will be

where they will be able to implement the recall like error free or bugs free so that's definitely kind of a red flag and requires definitely more work from you in terms of all that in terms of securing this product because it's me you're gonna read and inspect a lot of code so how you break that or how you solve that so you need to understand the actual protocol like you just drop the client code and go understand the actual protocols they are trying to implement towards the actual paper yeah definitely reading research papers is not that much easy like definitely if you're on like a cryptographer but I I do believe like having the basics mass of computer science level math you will be able to

understand those uh the paper but yeah if there's some parts of like printer mapping for example like you don't understand that you just go ahead and Google it like your internet age you don't need to go to the librarian look at fat box yeah so review the implementation try to identify like the core points of the implementation like for example the key generation flows as actual protocol steps verification and signing and once you spot this theme entry points you will go and identify the same entry points in another implementation of this protocol or open source implementation of this protocol and I find them but right for example if they're using a for example there's

other implementation protocol for instance are using like a different entire different curve so you will start questioning why is these people and their implementation using a specific curve and you might start the client asking click on some questions and you might come up with the binding uh so the other one is like we don't have securing claim or to asset execution environment and this is like breaks the actual idea of custom solution because it's mean you're running your your processing your key materials or your private keys or your cryptographic operations on power machines I would say or for example if someone come from my zero machines they can just dump your private key so like there's kind of no security

so you don't need to break it because it's already broken so there's no casting solution or a kind of AMC running outside of trusted execution environment that's completely broken thing uh okay well we have like trust executor environment we have like securing Clays but we don't know how to manage the context or we fail to manage the context uh management between both of them for example we are doing like kind of uh we are extracting the key materials from the secure enclave and we are processing them into like how the web app also API and we keep them like we are not the realizing the values or whatever so the key can be extracted around time in case of

the compromise of the untrusted domain and the Andreas domain is say let's say like okay all of your cryptographic stuff are inside the search execution environment or secure Enclave but the attacker gained access to your like uh we want we run interface or the web app container or does it start like QR already dealing or you're executing some calls to your securing claims and you are keeping your private key stored in like in a variable or whatever so that's where you are failing to manage the context between the security execution environment and your untrusted domain which is like the interfaces or your apis oh so you're like CNC plus plus like

that's a like CNC plus plus using uh non like a memory safety issues is really common for example at the communication level because it will help you uh exploit the untrusted context let's say uh maybe that will lead to further attacks but definitely like most of the cryptographic Brokers are usually implemented in two languages that have privacy it's like scenes build Plus or a rust there's like some type of scripts but it's not really common but most of them like our CNC plus plus because people are just getting on shelf cryptographic Primitives from other libraries and they start to use it in their own implementation so also like

academic people are more comfortable writing in CNC plus plus code so it's more like you're starting through a kind of as a message processor or as well so I have seen like some issues related to that one where you don't need to attack the actual cryptographic broker but you're just attacking the memory safety of CNC as well as like all the communication broker causing like some hip overflows in the case I had uh so like how to break it just exploit some memory Corruptions because I I don't think there is any advantage or for the attackers to see inside the CC

plus inside casting solution other than memory corruption vulnerabilities because yeah it's definitely so like some cryptographic flows that's an entire different thing uh yep so that's all for today any questions so far complicated topic right okay thank you all right our next speaker is jinwon from unispot Give It Up

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

conference I'm assuming people know the importance of the uh on chain Oracle security then the second part will be analyzing the exact cost of manipulating a particular uh on chain Oracle given that you know everything about the pool and how the Oracle is designed which will serve as a foundation for the third part which is if you know the exact calculation you can then evaluate the security of any particular pool combined with a particular Oracle design this will be an incomplete framework but it serves as a starting point to asking

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

farther away uh from from your current uh current mid price it's kind of mechanically true that it becomes exponentially more expensive the further out you go and also there's a there's a fee component so uh it might be only a 30 basis point pool but if you're buying eth for like a billion dollars per each then it's really really expensive to push price marginally further um the second thing you can do to increase your liquidity is you can first start bootstrapping your protocol around pools that are well established right so for

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

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

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

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

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

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

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

uh maybe everyone give it up for Jen thank you very much [Applause] give a warm welcome to Matthias from chain security take it away [Applause] okay um I'm very happy to be here for the first time for DSS last year at DSS Anton one of our Engineers was there to then present what is now known as read-only re-entrancy and I'm using this

opportunity to present something new we have been working on also here for the first time to address more a practical problem and that is like to validate deployments so just very quickly about me I'm CTO at chain security um I've been in the space for some time right but the authors of what I'm presenting here especially Hubert has been in the space for a lot longer and um the only time you'll hear the quick chain security thing so we are Auditors right we we work with all the big projects and have been doing this for for quite some time so far so uh now to

the interesting part what challenges do we face with deployment validation what challenges do we face if deployments go wrong so simple things like you can incorrectly configure your deployment right you can have wrong code deployed something you didn't intend or perhaps like something you didn't have audited you can even think of malicious deployers pretending to deploy one thing but really deploying something else right and then on ether scan you upload a code which actually doesn't reflect the reality

we can have incomplete or broken deployments right deployments can go over multiple steps you need to make sure that in the end the system is consistent but you are deploying in a system like on ethereum which is public everyone can interfere in between um and in some cases you might do an upgrade right and in this case you did have previous state and now with the new code the previous state might interfere in ways which you didn't intend it now to those of you where you think wait okay that all sounds a little bit theoretical I don't know how many of those are but

there are many examples actually of how this really did go wrong now this is uh where the presentation doesn't go Slide by slide so you can't see all the tweets sorry for that um so I'll just have some cases here like the most like perhaps one of the famous ones tornado cash governance takeover right so it was a um a case where someone deployed an upgrade and wasn't perhaps checked carefully enough that there was a self-destruct inside of that coach and that allowed the person too like because it was declared to create two right to

redeploy other cases like of systems where actually the security and the code might be fine but it's secured by some multisig which is actually not a multi-sig at all right we had several very big hacks which happened to be like that we had the why I earn I don't know if I pronounce it correctly case like the previous the predecessor to yearn which had a wrong USD token configured right and got exploited this way and so on so I can go on and for all of these cases there have actual B in exploits the thing is like this is not covered by auditor so far right we as Auditors we do focus on

the code we do expand from there and this is a natural expansion so what if you could easily validate just for starters like which address contains audited code right you can go and etherscan but you don't know has this code been audited it's very hard to figure out actually uh you have a git repo right where is that code is that the code which is live am I looking at a newer code which has been updated push domain whatever right very hard to figure out um as an auditor you do have some implicit idea of like a trust model but is it still valid is the system still

behaving like that [Music] um how can I detect suspicious admin activity how can I warn for the tornado cache case of self-destruct and create two can I make all of that not like a lot easier to validate and in the end a nice bonus if you know a system is insecure and you want to prevent people from using it just to warn them like be careful here right can't you somehow do that so there are some solutions for that but that's a nice side effect of what I'm going to show here so welcome to deployment validation we propose something we call deployment

validation files so they are very simple files they describe a correct deployment they just State this is what it should be there's one file per contract you can have them composable you can upgrade them and it's a system which is meant to be like trustless independent it's not controlled it's not something from chain security right we present a new standard here which can be used to achieve that we give a reference implementation but all of that is open and free to use so I'll give you a quick motivations like for these kind of files from the different perspectives so you are a

project and you did write your code you got it audited or not but now it's time to deploy or it's time to upgrade right depending on your use case but did it go correct like did the deployment work as expected you can have transaction record reordering you can have reverts in there some people might some Bots right might have seen something try to front the on you front run your initialization are you now really the owner or not is are all the contracts you used which you set up the correct ones right and is it what you tested is that also what

happened on chain right you might do the thing which we always suggest people to do like do Fork mainnet tests but also they depend on some historic state right they seem to work now you deploy you want to make sure it's the same thing which I use to assume the cases from the auditor perspective why stop at just auditing the code right so you did order the code you do understand that system but deployment often is out of scope so now you can check it right you can say Constructor parameters are they what they should be but also are the follow-on config changes done in separate transactions are they what they

should be and um as an auditor something which I also struggled with when creating that presentation is like you do have an implicit or explicit trust model in your heart like assuming certain roles behave in a certain way but often that's not documented very few audit reports do say what the trust model is and then for users it's hard to say is it like safe to use right so all of this is from the auditor perspective now a simple perspective from the user like really you just want to use safe smart contracts right so how do you figure out has this code been audited how do you check if the

deployment is still secure um did they do some upgrades or not uh did configuration changes break the project right I mean all of that happened a very practical use case some of you might be delegates some of you might be in charge of having to sign off on an upgrade I myself am and that is too much work in that sense that you think it should be easy to check but it's not right it's really hard to figure out is is that upgrade what they really wanted to do did they set all the correct parameters very tedious work currently um so

who audited it and who checked those values independently why does everyone have to do the same work over and over again lastly integrators perspective this is another project like many people want to integrate with uni swap with are there with all the big projects right and then you always need to make sure are you integrating with the version you are expecting what trust assumptions did that version have is it is the code I'm looking at the code which is on chain it can be pretty annoying right some projects do a good work but many it's very tedious to figure this out and lastly some assumptions might change over time right so famously you might read that in many audits reports right fee on

transfer breaks your project but you say well I am not going to onboard any erc20 which has fion transfer but then again like usdt has it like you can act they can activate it right another thing which sometimes happens like for uni swap lpps so the fees which like uni swap would get directly through LPs they are disabled right a big discussion and what happens if they get activated like these assumptions for integrators they are very important so I'm going to introduce this like so we we want to have that new format which if you come from the devops side of

things think of it as terraform right it's a file which describes the state how it is supposed to be um it ensures that's the starting point what you have in your git repo is what's on chain pretty simple but it goes Way Beyond right so here like it documents the expected State the expected critical contract state um you for example proxies right the proxy should point to some implementation right and then if it changes you want to know but there are many other variables like it can detect if those things change and it can also make sure it didn't change

and change back right you can imagine this case someone upgrades to a malicious implementation does some State changes updates back to one which you think is fine and you will never notice right so it covers this by tracking the state divs over time and lastly it allows you to reference other deployments so you can say like I'm dependent on on that system and so on and that system has a certain assumption about the behavior and so on So You reference that in the files but I'll just quickly show you let's see how well this works what this would look like okay and just

very quickly general idea project deploys contract at some point runs a lot of configuration transactions someone who creates that file would then go ahead and later credit based on a snapshot after the configuration has done and then at any point in time later right usually much later user would validate is that file still valid is there deployment still what's expected to be okay so just to show you some some stuff how does it look like I picked kind of a random project we are not associated

with and um and in this case that's um eigenlayer right so all you need to do you need to say like this contract is at this address and then uh yeah version 1080 but that's very simple right that's all you need to do then you start you see the command line here right so you say like hey my code is that I'm layer contracts this is a proxy you saw before like I was saying like it's a transparent upgraded proxy right so we tell it where's implementation um in this case it's an implementation a strategy manager this is needed to resolve storage variables and then

you just reference that file in this case I'm also giving the initial block and this is because by default if you don't provide it it will take the block right after the contract has been created but in this case a lot of config settings were set in future blocks so that we see what happens there I have that so I might switch to my laptop because you did not see what was supposed to come here is that possible no okay um

okay that's that sound a little bit hard so you um is there someone who can support this like what just keep going okay so you'd see some output here which is not visible and it would tell you like the byte code has been verified and it would decode State variables um let's see so I assume this also doesn't work like this is a longer video on how how the thing works right so that's unfortunate um the presentation will be online so

you can check there and then all of that uh will be available so I'll just try to briefly explain uh some important parts in there um most importantly so it generates a Json file which describes the critical storage slots it decodes them in a way so it's clear for you what you are actually doing like it's it's balances and not some random hash and so on it tells you where these things are right and then you can edit that file it dumps the full state but for us it's important to define the critical state so basically your job as someone who creates those files is to delete a lot of stuff out of them where you say like look

that's not a critical State it's supposed to change it will dump all the events which happened and then you will delete everything which you say it's not important to stay the same but some critical events like upgraded and so on you would want to keep it so now the big thing is like how how does it all work right and most importantly because we are in blockchain who do you need to trust to make this thing work um so the idea is no one right so anyone can create that there is an on-train registry where you can say I am someone who creates these dvf files you can register there but in the end the user

is in power to say where they want to pull it from the dvf files can be signed right you can sign them as Ledger or with private keys or whatever and users will generally say look I trust certain perhaps Auditors certain providers to give me good information to to delegate trust to them to some degree but also you make it very easy to inspect what did they actually sign off on um so some hard things we faced while doing that obviously how do you make it pretty smooth to decode those values you can like a slot uh ethereum storage slot looks like that

right so that's a mapping in this case and you need to tell someone what it really is right in this case balance is the owner and the value is not 246 D hash whatever but it's 42 times 10 to the power of 18 a lot more easy to understand if someone put in state you didn't expect it will not be able to decode it it will warn you about it so you can say like hey what has been going on here we have versioning included so because contracts do upgrade over time right and so on so you can do all of these things what works already

is if you have a Foundry project and like a big shout out to Ether RS and the things all of that is built on top of of that system then you can run it already then we can validate them we can do upgrades create new files based on New State they can already be decentralized distributed and fetched and so on all of that is working you can sign them with and so far either you have a private key on your disk right or you do have a letter to sign off

so all of that is working as a quick summary take home message in this case like deployment validation enables like projects to show that their project has been deployed correctly both to them and to others Auditors can document what deployment states are safe users now have a very easy way to check if that code has been audited if it is still what they intend like Dow voters have it much easier to see like what I'm actually signing off on was the intended changes

and lastly integrators and then obviously we like build us this is very important they can really ensure that they are interacting with the right system make that much easier and also they get the trust assumptions around this then um they're very like you would have seen it before but they're very easy to generate right and then very understandable like much easier than anything which I have seen before where you had to go to multiple websites to do this kind of things and my message here of course you should start using them now using them is currently um something which we wanna enable the first people to do it like we we never

brought this out so we want to get feedback so uh please if you are interested to try this to use that go to GitHub chain security deployment validation and say you're interested we before we make it public like open source we want to get some initial feedback from everyone to fine-tune it to to incorporate that feedback and we have an idea of future features um like uh there should be an Erp which describes that file format that should be like perhaps hard hat support to support older projects and so on right or ones which use Hardware today many of these ideas very welcome for input from

your end what you would need for this kind of stuff and then obviously collaborate like this will be an open source project so okay the video nice I know I'm out of time with the speaking time here but yeah sure okay yeah I think that's it

um yeah so you see this file which was created like contract name right where it's at the code hash which has been deployed these are the important parts and now the list of the critical storage variables like it has been initialized initially I was very confused when they did it for the first time because it wasn't initialized you see the owner you will check is that the intended owner you have some other other variables like for example the status here you might say like okay status is not a critical one right you get rid of it you delete it um then we we check all the others implementation and so on generally very critical storage slots we go down and see that there are critical events like

the admin has been changed right what happened here you'll want to reason about what happened here um like Beacon upgraded it did never happen but you want a document that it never happened like because when it changed when it would change you would want to make that this file becomes invalid and here you do see that actually this contract has been upgraded twice right and and actually it first was upgraded to empty contract and later to the implementation contract so these kind of things you you can very easily see here we still work a little bit on like making it even easier to to decode and then in the end you can also say a little bit like who you are you

can sign off on this you can describe what you are seeing and the idea is this file will live in the project repo so people have it very easy to say like hey this is where things are deployed this is what it describes but it will also live inside Auditors like Auditors or other trust providers will give this out and then give their ID idea of what they think the system is safe and then you can compare right so yeah this is how the file currently looks like thanks for making this possible give it up for Matthias thank you very much and the last presenter of our session

Dimitri from abdk Virginia [Applause] thank you hello everyone how does this super cool thing work okay is there any back where's the back okay cool hello everyone I'm Dimitri coverage from abdk Consulting and in parallels from ethereum foundation so some of you may know me is no deter sum of Sam as a

cryptographer and today I'd like to talk a little bit about security of defy and internal applications in the world of zero knowledge and well the talk is pretty short but I would like to introduce you to some really nice bugs that you can see there so that you can get some understanding what are the real problems so when you code and cure application in their knowledge so um you might be familiar with the zero knowledge not only in the context of proofs but also in the context of four labs and you may know that the typical scenario in ethereum is of course you just submit the transaction then it's executed to null nodes and then the

storage is updated with the results of the transaction well if it's executed correctly and in the zq roll up scenario a little bit different so instead of the inside the transaction itself is fully executed on the nodes the transaction is crafted on the side of a so-called prover but then it's a proof of its execution is submitted to ethereum and the proof is verified on all nodes and then the storage is updated so the proof just convinces all the node that the storage updated has progressed correctly so the node themselves they don't know uh what are the all steps that led to the storage update they just check that

the update was done correctly so what's interesting about it is that of course uh the nice thing about it is that when a transaction is Big then it's of course better so that it's executed only on the prover side and the other just verify that it's correct so the verification is faster than a person the transaction itself the downside of course is that still the verification of physique proof is somewhat expensive so we may hope that in the future we can aggregate these proofs we can batch this proofs we can do various optimization with those but so far well as the correctly mentions

the career labs are still somewhat expensive another interesting downside well not the downside but rather a feature of uh ziki programming is that the it's the language that is used there it operates on a bit different domain so you may know that in usual programs well in ethereum virtual machine or in solidity you operate with the 256-bit numbers and to use the 56-bit arithmetic or on a regular x80x machine you use like 32 64-bit Wars bytes and so on so they are all aligned to powers of two but in the ziki code usually uses a

different domain it's called a prime field it's a set of numbers that are smaller than certain Prime p and as you get and they you can infer from the name this Prime is not the power of two because it doesn't factor into other numbers and because of that there can be all sorts of issues when you code in decay so we at abdk well I'm decay in abdk and the other a b is my my block 500 so we at abdk with my longtime colleague Mikhail has audited a lot really numerous projects that did ziki programming and we have found quite a

number of bugs While most of these bugs are pretty subtle so I will not go into details but I will try to cover the most kind of simple ones but still kind of informative enough for you to see what's the issue of Suzuki programming so when you talk about um it's like a programming we usually talk about so-called circuits so circuits are not exactly the programs so circuit uh the feature of circuits is that they they consist of so-called constraints and these constraints are relations between the variables or rather functions that are executed on those variables so in regular code you could just do instructions one after

another in the world of constraints you impose relations on the data and if you are familiar with for example database programming uh working with the relations is way more different and working with real code and with circuits we when we code in circuits we have to satisfy two basic properties which cryptographers call completeness and soundness so and they are like two sides of pretty much the same thing so the understanding is that the circuits should behave exactly as the code but what does it mean to behave exactly at the code so on one side the data uh by complete this would mean that every valid code

should satisfy the constraints but on the other hand if constraints are valid this means that the code must be valid and this is called soundness if you make a mistake in either side there will be problems so sometimes people say well completeness is not that big a problem because well in the worst case maybe you can just regenerate your code so the the key the problem with completeness is you have some execution that is valid you just cannot make a proof for it because of some back in the circuit but the thing is of course this may also lead to fund loss for example if

what they are going to do is to withdraw some money from a roll up for example and if this transaction doesn't work if it cannot be converted to a valid circuit because of a circuit bug then you're screwed so both mainly to funds loss of course and let's see some concrete examples well not about the fun loss but let's see concrete examples of bugs how what bugs are there so the interesting thing about uh problems in the code and in the circuit is that when you when there is bug in the code is usually when someone exploits this bug it's noticeable you

can usually so the traces of exploit are stored in particular when you submit when it's in the blockchain that everything is in the clear text so a person submits a transaction you see who calls which contract you see all the commands you can see the entire stack of code execution and everything is clear is clear and it's very noticeable after the exploit after the code was exploited the situation in a circuit is different the difference is that since only a proof is validated on the nodes the transaction itself is not validated and because of that

if there is a bug and an adverser is able to create a proof a valid proof for an invalid input this means that uh the proof will be seen as valid everyone sees that the proof is valid but the input is not known you just the proof just asserts there is some input that satisfies the circuit but if the circuit is wrong you just don't see this input itself well for data availability purpose we often require that the data is provided so that it's it can well the transaction is be reconstructed

but in general if the proof is valid you don't see what happens inside and because of that it's very it might be very difficult to trace if there is a subtle bug in cryptography or is back and code in circuit programming you may not see exactly how it was exploited you just do well well there is a valid proof and then all funds are lost so you must be very very careful when when programming circuits so let's say some small examples what I mean when I talk about constraints suppose that I execute a code where I compute a square root of x so Y is a square root of x assume that X is

perfect square so we don't have any uh uh any rationality here so suppose that Y is integer here and then in the circuit program that y y and x are linked by some relation What relation is that the relation is that Y is the square root of x it's the same as y square is X is it the same well it's almost the same because we want to exclude ambiguity here the ambiguity is that if you tolerate in negative numbers then you should make sure that for

example Y is bigger than zero uh well I already have six to begin the zero but if x is allowed to be zero then y can be zero as well and constrained here is that y square equals X and Y is bigger than zero so far so good so for for this sort of arithmetic operations writing constraints is not that difficult uh well ensuring that Y is non-negative somewhat difficult but we can we can omit that so assume that you can do this range check so this is a simple constraint but let's go into some more interesting examples here so before we go into

examples I um explain why it's a problem that you can work you work on a different domain so in CK programming and when you talk about things like zika snark we operate on so-called Prime Fields this means that all operations are done modular p this p is typically typically for snarks is close to 2 to the 256 but it's not at all to 256 because of that when you do operations uh where the result or intermediate variables go get close to this barrier to two to the 56 you may get problems and these problems are exactly here so

you see for example when you have like two variables X and Y and so that there are multiple overflows to the 56 then in plain evm you just get model reduction in solidity uh starting with check you'll get the panic but snark what you have it's completely different you don't get panic don't get modal reduction well you do get modular reduction but this reduction is modeled a different number so you multiply 4 by this to 54 plus one well to get is 2 to 56 plus 4 but this model of P well this p is known it's a constant but it's not at all to the 56.

so the result is some weird number possibly 250 something bit long and as you can see from this example you have to take care of this so-called H cases so whenever you approach wherever your arithmetically approach to 56 bits you have to somehow constrain it so basically you have to have to prove that overflow doesn't happen in your case because if it happens it's very difficult to recover so let's see uh which problems it it brings us and let's consider the second example the second example is model reduction suppose I want to prove so I

execute and decode a modular model B well A and B are just valid numbers well it integers they're both bigger than zero and R is there is a remainder so uh is it okay if I program my circuit in the and I write this constraint that a is just Q times B plus r this is the definition of modular reduction right so is it enough a equals Q times B plus r well clearly it's not enough you should probably introduce R uh smaller than b then it's almost enough is it

it would be enough if it were if we worked in integers but we work in model of P what happens model the p in the world model P everything that may overflow will overflow so how it looks exactly here the thing is adversary who want to break who want to submit invalid data and get a valid proof at versic may be able to select both q and R maliciously the queue you don't even care here you may not even think okay what's what the problem with q I ignore Q I only care about r

but the thing is you do have to care about Q why is that uh the thing is in the field uh any number can be divided by any other non-zero number the division is always produced a valid uh operation and a valid output in the field and the thing is if adversary wants to get certain r as an answer for any R smaller than being bigger than b there exists a queue that leads an adverser to this result

so if you simply give this as a constraint what adverser gets what addresses selects he selects Q equal to a minus r divided by B and this division always works in the field ersen is divisible by anything non-zero and if you substitute a minus r over B to the constraint you see that the desired R will be the output so if an adversary is able to select both q and r then you are screwed um I will later see how we get around this problem but in this get around this

rather complicated so let me maybe outline several uh sources of back several kind of most error-prone scenarios when we have this similar problems so whenever we have arithmetic that goes over the entire domain so if you work with numbers then that with multiplication approach to 56 bits or close then there might be a problem because you have to range check almost every operation and you're arithmetic whenever you have divisions you see you have a problem because division in integers Works differently from division and Fields you have to take care of that that you have

to always keep in your head that everything is divisible by anything and the result May explode for example in a field you can divide two by three and the result will be just a huge number uh we never have branching in your code it's usually non-trivial in the circuit to implement it because you have to compute all of the so-called flags and you have to make sure that only one part of the circuit is executed or taken into account depending on the flag value and of course whenever we have so-called invariants

and you have to work with relations among the Dayton uh rather than direct functions with the data then you also have problems uh let's see if no I don't have this update Okay so this were the most popular things the less popular things are I just listed here so when if you want to program some kind of tint automaton like in Ezekiel sync and its relatives if you uh do range checks and sometimes you you may have problems if you work with

different flags like if a b c and d happens but e in depth don't happen do this and at the same time if B and D happens but e doesn't happen then do that and so on so all this sort of exploitable all the edge cases that in normal code are never executed will be exploited because in adversary can select all the variables that are part of a circuit that are not enforced from outside and usually an adverser can exploit these edge cases so this is cases that can't be reached in a normal code will be reached by an

adversary so you have to double double care about those and of course whenever you have some implementation of cryptography in your circuit you also it's also error prone because usually cryptographic schemes have very strict restrictions on how they are used and with which parameters and because of that it's easy to misuse those so uh getting back to to model a reduction let me see if I do have model reduction here no not exactly so with

square roots actually the problem with the square root also here that's so called geometric mean bug when you have two numbers both of those smaller than 256 bits and you want to compute their geometric mean the problem is that the square the multiplication May overflow and that's not even obvious how you how you deal with this overflow because both A and B are valid inputs uh so you can easily program the second part that x square equals to Z but dealing with overflow is non-trivial what you have to do you have to partition the number into kind of chunks and do kind of school book multiplication and deal with those

so you see how how it's done here you can uh you split actually not into two chunks but into three chunks because when you multiply these guys you have to ensure that they will not overflow themselves you have to switch the representation for a for B for X you have to multiply all these guys you have to check the equations for different terms and only after that you can uh make sure that this geometric mean is computed correctly it's pretty much the same thing happens for model reduction for a long

multiplication and so on and so forth so I think I'm running out of time and I will not go into branching bags but but those who are interested may go into our audit database where we have a number of audits for various zero knowledge projects and circuits and see what kind of critical and not so critical but also dangerous bugs we have uncovered thank you thanks a lot Dimitri time for one

question anyone okay cool thanks a lot 15 minute coffee break thanks everyone no I don't okay we have a break until 10 55 but we have good news we're gonna have coffee downstairs all day long foreign

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

[Music] yes yes [Music] oops [Music] [Music] [Music] [Music]

foreign [Music] thank you

[Music] [Music] let me see

[Music] all right exception all right [Music] [Music] [Music]

foreign [Music] [Music] foreign [Music]

[Music] thank you foreign

foreign foreign

we'll be starting again in three minutes thank you [Applause] foreign

foreign foreign

good morning everyone we're about to kick off session 13 monitoring and incident response my name is Maddie co-founder and director of Sigma Prime I'll be your chair during this session if you are still downstairs grabbing coffee croissants please make your way up to the auditorium we'll be starting with Andy Sue CEO of block SEC and professor of zeitang University who will be talking to us about securing web 3 through proactive threat prevention okay thanks thanks for our instruction uh my name is Andy I'm the CEO of block set today I'm going to talk about um uh the way to secure in web series through um proactive threat prevention

so our blockchain was founded in 2021 backed by some top investors and customers and we have a couple of products you know to available to the community and like the Falcon I think most of the security researchers they already use our Falcon Explorer you know to victimize transactions and we have the metadoc medicine which are free to the community um so why security matters in Webster right so even in this uh poor Market sorry even in the cycle of the board and bear markets the north is caused by the default hacks and the device scams are really increasing and it is not just the numbers right we receiving the emails

every day from the victims of the attackers and this game saying that they have been attacked and lose they lose all the money so they want us to help them so this is just another numbers they represent the individuals who who are facing the bankruptcy after being attacked right we have to help them so why D5 hacks are very uh common today I think there are a couple reasons one reason is that we have the attackers they have the economic incentives to you know to perform the Divine hacks because by performing The Divide hacks they can get paid you can get paid by a larger a lot of money right so and we also we do not have enough security qualified

developers some developers they are focusing on the functionalities of the protocol right they do not have enough security trainings and the universities they do not teach the block a blockchain security causes we do not have too many courses are currently available in the community in the universities and also you know some some hackers are performed by the Countrywide organizations I I do not need to talk too much about this I think most of them will understand that so um when talking about the security of the protocol most of most of people will think about the code audience yes and the cloud is the most common way you know to solve uh the security issues in

the D5 protocols I we think the code already helps but the code audit is not enough right that's because the qualified auditing services are very expensive and also time consuming right you need to like within two months or three months even half year to be audited by a top audit firm so you can some protocols they do not have enough time to wait right and also we do not have enough qualified Auditors in this space right so if if one auditor firm let's just issue this the auditor certificate and this certificate were eventually we are no longer being transferred by the community right so some because of these reasons the

protocols have to go live without some better tested strategy changing and attack operating solutions they just go knife without any security measures in their hands so we because of this we need to have a more proactive approach right so the more pressure approach means that a protocol needs to know what is currently happening to their protocol they cannot just put the protocol online then go to sleep right they need to know what what's what is currently happening who is interacting with the protocol then something bad happens the protocol needs to know how to automatically respond to such attack translation to to respond to such bad scenes right

so why is the proactive approach is much important in web 3 right because we also have the web 2 security and some guys saying that why do we need that in Webster because we do not have that in web 2 why do we need to have this inventory that's because the web3 introduced this much more attack vectors and the openness the openness in the production makes the attack much easier than in the web 2 because everyone can looking on the smart contract on a blockchain most of the smart contract on a blockchain are open source so the the good guys and the beta guys they can see all the same source code right you can find the availability in the source code

then if the is7 ability then they can attack the vulnerability to gain a large number of profits and also because the blockchain is anonymous it's very hard if not impossible you know to check the final flow of an attacker right so when an attacker happens to the D5 protocol we always saying that the protocol asking who can help us to contact Beyond who can help us to contact some exchanges because it's very very hard you know to track the phone flows for the attackers and also the reflection helps to enlarge the money that an attacker can have right so in the web 2 if you find out vulnerability and in

order to launch this attack you need to have 2 million US dollars but most of people you know they do not have such uh such a such a big money to launch attack but in production you have the flash known right you can borrow a very large number of money from inflation and also some private transaction Services it can be abused you know to launcher attack we have seen so many attacks they are abuse they were abusing The Flash Party Services you know to issue the attack transaction from being observed in the memory pool so because all this unique properties in the adversary the attackers happens

in Webster space cause more damages to the protocols cost more damage to the users right and it's much easier much harder to track the attackers in the F3 so because of all these reasons so in blockchain we have um developed a prototype system uh since last year since February 2022 we are thinking about how to solve these issues besides the code origin right so we've seen commit can we take a more proactive solutions to definitive High hex So based on this uh Source inside the Block Set we have developed a system called Falcon block so second block the

basic idea of second block is that we can listen to the transaction inside the memory pool we can listen to the transaction on the production we also listen to the reversal transactions right so why do we need to listen to the reverse transaction that's because the attackers they may make mistake and the attack transaction can be reverted right so if we can capture such reverted attack transaction we can also automatically make some response after that we can reconstruct right we can reconstruct the technologic by replaying the attack transactions and copy the essential logic Technologic of the attack contract to synthesize a new Rescue smart

contract anything issue the rescue transactions through some flashbacks or through or by giving a higher Gatsby something like that to to make sure that our rescue transaction can be much quicker or can be on a blockchain behind the attack transactions so by doing so right we can unblock we can even block the attack transactions right so because we are much faster and we are before we are we are in the header of the attack transaction inside the block so how the so the the the the essential part of this mechanism of this system is how to automatically reconstruct the

attacker transaction and the attacker contract so I think the basic idea is think about it attack transactions and and attack smart contract what what matters most in this attack contract right so what matters most is the attack logic inside this smart contract and also some the attackers we will do perform some authentications to the colors of these attacks micronium because they do not want their attacks my country has been called by others so you need to bypass all these checks automatically right so what do you what would you do so we replace this attack transaction inside the memory pool we

can get a change of the basic blocks or the trace of this uh uh attack transactions right of a change of the basic block so in this uh in this in this chain of the basic plus we can replace the jump I instructions we call the Frozen the jump height instructions into the jump instruction jump to the uh attack logic instead of the reverted basic block that because of the value of the authentication of the attack contract so we can simply replace right replace the jumper instructions to the jumping instructions so this is the basic idea of the how the methodologies

but when we use it but when we uh but just simply replacing the the instruction does not work in all cases because we have some technical challenges one of that when we replace one of that is uh how to deal with reuse a basic block inside the smart contract so we use the basic block is a very common um uh usage by the byte code generated by the compiler to to reduce the size to reduce the code size so suppose we have Nike are two different uh jump targets are a one and I zero and we have some new Jump targets right so we need to have a mapping between this uh old jump

Target and the new Jump targets so we use a sampling uh basically for this purpose so the basic idea is it's just it's just similar with the uh is a binary code rewriting which we have uh started and a developer I think more than on two decades right or even even even uh even even earlier for the uh for the codery written Technics so we borrow the similar ideas and used into the byte code uh Rewritten and by using this system we have a couple of successful stories to um to execute the funds to block the attack transaction for a couple protocols like

we are rescued 500 million US Dollars this year for the power space and uh 3.8 million US dollars for the sale of Finance last year and a couple of others so in the following I'm going to talk about a couple of Representative examples of how we block these transactions so for the power space uh which happened the attack happened this March right the attacker made some mistakes right so they do not give enough gas cash to a performance attack so the attack transaction reverted as I just said we listened to the reverted transaction on blockchain and we found it it's even the the transaction was reverted and the refund is a and it's an

attack transactions and then we automatically synthesize a similar attack contract but replace the profit addresses with our own addresses and we issue these transactions and the challenge exhausted on a production to you know to rescue the 5 million US dollars for perispace and we uh and another example is a is a purpose which was attacked in this February the the smart content has availability and the attackers uh they attack this this device protocol but the attackers he or she made a mistake there is no logic to withdraw the funds inside the attacks my contract so the question becomes how to withdraw

the remaining 2.4 million US Dollars inside the attack conscious inside the attack contract because there is no logic you know to waste all these are remaining funds inside the attack contract so because we have an internal system to automatically disassemble the attacks my contract and we have some heuristic you know to analyze this attacks my contract and we found a couple interesting five interesting facts about this attacks my contract first the financial callback of the contract is open second the usdc approved to the Platypus poor contract so what can we do we can upgrade the poor contract and use the approved

privilege by the attack contract to which your remaining usdc right inside this attack contract and a v shared the approval concept to the protocol and protocol successful and you know withdraw 2.4 million US dollars from just my current attack contract so another is the transit swap Transit swap was attacked and the front round by mua bot so we found the addresses of the enemy part was generated by a vulnerable profanity tool right prevented tour because the availability we can calculate the product key of this mua bot and we can you know uh with the other funds and return to the upper Toco so how to make this system more

effective I think we have some insights you need to active fast right you need to know fast and you need to active fast and accuracy is the key you need to you cannot introduce too much false positives as we have a panel last uh yesterday and we are talking about the false positive and monitoring tool if we are moving to report too much alarms to your customers then the product cannot be used right and we can take a systematic way to act not just from around the attackers we have some tools to analyze the contracts which disassemble country we have some uh heuristic you know to to perform more analysis on the body code we we take all these measures into to build a to build a system to build a product and we saw

armrest between the attackers and the security researchers we see some attackers they are using authentication some income runtime measures you know 222 Defender all these things so so based on this we build a fashion product system and we have within this so that if you are you guys are interested you can join our witness you know to um get updated information of the Falcon product system and we also have a teacher group some uh under the tutors you guys if you're interested you can follow us thanks Anna I I'm free to take a question if you have thanks very much thank you Andy so I think we have two

three minutes for questions um Heidi's here hey um I don't want to show their tools too much but they're really badass thanks second off um the one question I have is you guys do a lot of hackbacks let's just call them that right how do you guys protect yourselves from the liability of doing that and all the legal garbage that comes along with doing that uh yeah this is a very good question yes I know the the secure Asics is um we are taking very seriously so for the hacking back or for the blocking attack transactions we only perform these actions uh after we saw an attack transaction in place we do not perform such attack transaction you know without using otherwise it's

doing that yeah so I think because we had you know protecting users and we take a proactive approach if we do not take action then the better guys they will take action they will take all the moneys right any other questions we got a bit of time nope well ah we got one over there maybe that's a follow-up uh to a question but like so that means that if let's say somebody finds a vulnerability that has not been exploited and there is no attack transaction you are legally prevented from acting like on a like do like a white hat hack and save the user's funds

um so we are not uh uh so let me uh refuse so we are not hacking of hacking the the user's funds so we just automatically reconstruct the the contract by the attackers and the name uh move the funds inside another wallet then we will return back to all these funds to the uh protocol and to the users so yeah I think it's it's you know it's debatable for the uh S6 issue but um if we only do these things uh with the heart of protecting users I think we are good here got time for one more don't be shy yep

so so it you know it's clear you're doing the right thing do you have any actual legal protection in place do you have a lawyer sitting there Uh current innovate we do not actually yeah but uh we will considering you know hire a new one yeah all right cool thank you Andy thanks so much thanks for your time give it up for Andy thank you and um all the volunteers that have been working very very hard to put this together

um these events you know wouldn't be happening without their uh hard work so yeah thanks to every single volunteer who's dedicated their time to making uh this happen thank you all good and our next speaker is Adrian Hedman a tech lead of tryaging at immunify and he'll be talking to us uh today about stories from other side of the table how immunify is fighting for you behind the scenes hello can you hear me well great closer maybe closer okay yeah so hello I'm gonna tell you some stories

that shows what it takes to actually handle critical vulnerabilities at unify or basically whenever stories that shows the importance of proper handling of responsible disclosures I'm going to show you stories that actually haven't been made public until today of course I wouldn't be disclosing any confidential information because I don't want to dogs and executive researchers nor the projects but I will shed you some light on how immunify and triaging team Works behind the scenes what we do to actually make the project

secure and whiteheads rewarded so welcome everyone to the stories from the other side of the table on how MiFi fights for you next slide okay it's winter evening 9 pm I'm sitting in almost empty uh parking lot in my car groceries in the back I'm about to head to home to my lovely wife and to a newborn child I start the engine and suddenly I get a notification and look at it and it's from work I never got notified that light I open the notification and suddenly within two minutes I'm finding myself in

a war room situation because white hat has found a critical vulnerability that can shut down any evm or PC node number of affected projects on the MiFi 15. and yes that was actually just a Monday for me so how do you form a war room in a matter of seconds after you still experience some shell shock after receiving the news you take that deep breath and you remember that you've done this before we've been at unify in this situation many times before we've dealt with such cases multiple times dozens of times I don't know even the hundreds but possibly that could be true we've been in that spot before so we

stayed uh with the hacker communicating with with him over secure channels and we started uh planning the responsible disclosure because yes he has found the vulnerability but we needed to be sure that the impact is actually there that the report is Rock Solid that it wouldn't be this mess that it would apply to all the bug Bounty program rules for all these different affected projects and it took time and actually we wanted to a part of course uh keeping hackers best interest at heart the band viewers themselves we also wanted to have projects be secure so after Mass disclosure the Chase had begun we started

contacting every project that was affected to look at the report immediately some of them responded to us within minutes some of them within hours some of them with index some of them touch the issue resolve the bug report and rewarded the hacker because the report was well written because we prepared it so well before but some of them actually as it turned out didn't have this impact in their back Bounty program and some of them claimed that they were protected against this so through mediation even if I could officially step in and mediate this case we look at all technical details uh across all 15 cases and we managed to Showcase

a real impact on the out of scope back uh to some of the project and get the hacker rewarded took us five months of effort five months of constant back and forth between the project and the Wildcat analyzing every little detail of every bug report that they submitted yes the bug was actually common on every product on the same on the every project and the 95 percent of the background report was exactly the same but that five percent was so crucial to actually being able to resolve this issue and it took us five months of us battling for you battling for the

project to actually get their projects secure their user secured and white hat get appropriately compensated for this and it's important to know that whenever there was a slight dispute slight disagreement we always encourage Whitehead to actually called us in because in some of these cases if we wouldn't be called in the case wouldn't be resolved and by resolve meaning that the project would still be open to vulnerability and Whitehead wouldn't get rewarded because sometimes information can get lost misunderstood and we are here to actually step in and provide all unbiased technical

information to provide a just and fair platform to everyone to actually talk to each other and to report such vulnerabilities through immunify and you might sometimes be thinking okay this this took five months but does it always take that long not necessary some of the issues are more straightforward some of them are more complicated but we always do our best we'll do every length that to actually resolve the issue but actually what am I really to talk about this it may be a strange time to introduce myself but my name is Adrian Hitman I'm

the head of triage at immunify I've been in web free security space in since 2020 I've been in crypto since 2016. a personality triaged and mediated some of the most paid bugs on MiFi and I'm honored to stand in front of you and tell you some interesting War Room stories from my work our platform is built on the idea that the project and White House can collaborate to mutually benefit one another by utilizing their backhanding expertise whiteheads can help projects secure millions of dollars worth of assets and in return projects are a bit of that wealth with the White House

to thank them for their time and effort and however as much as we try to build objective metrics into bank monthly programs on our platform sometimes gray areas are still there sometimes edge cases happen and in such cases It's always important to call us in for a mediation because every crazy situation that we ever handle and that also I'm gonna present right now was eventually resolved through a mediation process because then we could officially step in and fight for you so let's now look at some of examples of different mediations that were eventually a war rooms situations or are worthy of the name of a crisis this is the case where Whitehead was

right this is the story that a few of you already may know pointing that if an elite white hat has found a critical vulnerability in Moonbeam twice within the span of two months he got paid for those two bags uh over two million dollars in bug rewards the first bug resulted in 100 million dollars of potential value address second back in 200 million dollars of value at risk amazing bug report amazing effort of both sides but you might not know all the behind the scenes details because you know actually those two bugs were

out of scope initially back Bounty program rules that Moonbeam has said so it was crucial as with every case to call for a mediation because yes Moonbeam wanted to reward the hacker they understood the severity of the vulnerability uh the severity of the impact but they weren't sure how to actually reward the hacker based on their backbone rules so they called us in and also we stayed online with the opponent and Whenever there is such case that bugment programs rules aren't clear as I said before call for remediation and we're always encouraging and pushing

for fair compensation as determined by value created for the project and in this case the value created was obvious in total 300 million dollars saved right but it wasn't that clear how to actually progress with that so through um many weeks of effort of navigating through the rules and understanding the technical details of the bug report itself we managed to showcase the real impact on foreign in both of these cases and through collaborative efforts of uh Moonbeam and polling.if act in a good fight just wanting to get this back

result fixed and later of corresponding that if getting rewarded an appropriately compensated after even if I held we managed to resolve this because as with every case I'm gonna repeat this constantly some of these cases wouldn't be either as successful or successful at all if we wouldn't be called in because we handled handled handled thousands hundreds thousands of cases difficult cases and we are expressing in that we know how to navigate uh bug Bounty program rules we know how to navigate impact we know how to navigate all the technical information because we've done

this before and through collaborative effort as I said uh back Hunter was eventually rewarded and by result we also updated lots of hours uh bug Bounty program rules uh created some updates because with every Edge case scenario every crisis situation we are always constantly improving because we don't want such case ever to happen again and if that case happens then we can just do business as usual because we already know how to handle such cases that's why we're making constantly uh smaller updates and each smaller update is based on one of the difficult cases that we have next case

um project was right because from the previous story you may think to yourself why on Earth Project didn't pay maximum payout immediately because it isn't actually always clear if the impact is actually real in this case white has submitted a beautiful report all technical details were already in there POC was working it was runnable uh he even included a fancy risk calculation 10 million dollars everything was in a report from trashing perspective it was a piece of cake to triage but it wasn't a piece of cake for the project

disagreed with this report and disagree with the white hat and after having a disputes on our platform uh between the White and the project we were officially called in we analyzed every bit of technical information that was shot in the back report itself in a POC and also within the conversation because a new information came to the light and we eventually got in a couple of the project because we had one information one piece of a puzzle that was still missing before we we could give our judgment and our accommodation and after that call it became clear that the liquidation mechanics because back was

around that was working as intended and project was actually right and project close the report but the issue lied with the POC itself because you see um White had made some assumptions about how POC uh should work how the regulation mechanics of the project should work and that assumptions were wrong those assumptions weren't tested and we always encourage everyone to actually test every assumption because we are dealing with facts and every facts that we that we have help us get to the resolution of the bug report and in this case we managed to looking at only the facts to state that

the project was actually right we provided with all technical reasonings and information to the white hat project did the same Whitehead understood uh what he did wrong so the case was closed and white had left happy knowing how to do better back bunches in the future next case middle ground because some of these cases are maybe quite obvious sometimes from the beginning sometimes after a while some of cases aren't as black and white and it can take months of constant discussion technical analysis twice or even three times analyzing the same

thing over and over again to actually understand what's going on on one of such cases we handled this year a few months back two Elite White cards submitted a critical vulnerability to a VIP project the attack Vector was very complex it was a weaponizing a Randomness and after the disclosure both white hats and the project were working flawlessly together to develop a fix to protect the project and from our standpoint it was the collaboration was beautiful until it wasn't because you see the the dispute happened when it came to deciding on

them final payout and disability of the of the bug the project uh for that this is this was a medium severity impact not a critical one and project of course disagree and with severity also the payout recommendations were way ways smaller than white has actually wanted and white has the pointer by point counter arguments project responded with the same and such arguments arose tension between between the two at a higher degree when finally one project still and didn't want to impact about the reasonings whiteheads acted in a bad

fight they threatened the project to go to make this case public to get a higher reward we admify don't take blackmail treated really seriously because we want to provide a fair and just platform to everyone to actually being able to act together to get the project secure and while in the end compensated and blackmail doesn't help with that we either straight band hackers or heavily worn them of course everything is based on on case-by-case basis in this case I cannot tell you all the technical

details which I wish I could but the end result was this the impact state are critical uh the project didn't pay the max critical payout that white had wanted based and they paid much less based on the actual funds at risk after our technical assessment removing all the assumptions from the pocs and the impact and middle ground isn't always in the middle White House were left unhappy yes they found a critical vulnerability but the payout was much less than they expected but they still got few hundred thousand dollars in reward and the project was also a bit unhappy because they didn't they needed to pay

way more than the initial effort but it's always important to emphasize in such cases why we reach such a decision a decision that regards the payment the decision all technical details to lay them out to every party so we can base our mediation on truth and of course we have many more cases I could talk to I talk about about gray hat activity and as with previous case this case could go really nasty if we wouldn't be called in we help to diffuse the tension and that's what we do in such cases we diffuse the attention we go straight in

analyze everything we clean everything and provide with clean technical information to everyone just looking at the facts to be fair and just to anyone because we have rules for a reason and we execute our rights to ban secured researchers or the projects if they go against them you want to create a fair platform for all parties involved and we won't accept any bad faith Behavior and each musician like the ones that I presented even if we cannot make it public always the results in some improvements on our platform in some articles that we write for the public to better educate the White House or the projects and we will always fight for you

no matter what but we need all necessary information to do that we cannot make a judgment call we need to analyze every possible scenario every possible Edge case and for that we need all technical information and as I go as I said we will go every length possible as long as you need to prove to prove your point if of course is a valid one making predictable outcomes out of bbps we host is something that we work on every day and for the future of mediation we're codifying our best practices learn across thousands of difficult cases

and we will form that into a new bbp that will form the basis of our work for a few years uh years to come and with that our common investment in other areas around the BPP we are making tons of improvements tons of new articles explanations to make a everyone to make everything more predictable when back hunting for the white hats and for the projects and with that I want to thank you for the talk it was a pleasure sadly I had a funny video at the end but it doesn't seem like it will work but

thank you everyone thanks Adrian thank you we may have time for one quick question all right you're very quick how do you educate your team on communication skills peaceful resolution and like negotiation with everything we are trying to be always respectful to anyone no matter who are we talking to even if uh to someone who's on a basically a great card and is threatening a project we're always respectful and we're always basing our uh communication on the facts we just want to have everyone to have a nice time on our platform and I and I

said that just unfair outcome and for that communication is a key and we're learning that on every case also because we uh constantly improving on the ways that we communicate we starting to add way way more information into our remediations uh analysis that we post to both sides and we still continue communicating with the white house or the project after mediation has been posted and with everything this is just a constant process we don't have any one way that we can say that we have we do this and that we're just trying to be respectful awesome thank you Adrian will be around I'm sure uh over the next few minutes

and give her to grab him for questions someone I've met a few days ago and was blown away by the breath of knowledge that that she's uh she's displayed if you can hear me um please give a big welcome to Heidi wielder Elite blockchain security researcher at coinbase uh the title of her talk is wrecked pill what to do when your dap gets owned and how to stay calm hey guys can you understand me okay is that is that good um I'm really excited to present this to you today um I've had a lot of conversations over this past week with people about um incident response and there are a lot of different takes on this most people

say oh yeah we just need better monitoring we just need better monitoring and then you know I go and talk to various different projects and I ask them what kind of monitoring are you doing today crickets usually right and they're not exactly prepared for when they actually get wrecked right and we're going to be talking about exactly what wrecked means today now um first and foremost I probably should introduce myself my name is Heidi I'm on the unit 0x team at coinbase our Big Goal here is to make web 3 more safe as coinbase is getting more into the web 3 space we want to make sure that we are creating sort of the most safest apps but also making these space a lot more safe one thing that you might say is

well wait a second why does coin days care about web3 security yeah sure you guys are launching base but why do you care about maybe the Euler hack well first and foremost any ecosystem threat is bad for us right it's it's bad PR for us but there's also Fallout from things like the Euler hack that you might not think about for example all the CBE being drained right there's also other Fallout from these sort of events also happening for example a threat actor might want to cash out with us so there are a bunch of different facets that we care about and we really are interested in making sure that dapps in the ecosystem do not get wrecked now I've got a couple different things on the agenda today but we're going to keep it

really light first we wanted to find as what does it mean to get Rector to get pwned right after that I just want to get a set up with basic 10 questions you as a project should be asking yourself in terms of being prepared for getting wrecked right I'm not saying you need a whole monitoring plan today that's a little uh over ambitious I think for a lot of projects today so let's keep it easy and then last but not least you might be asking yourself the question of oh my God my dap just got wrecked what do I do how do I even set up a war room how do I even think about incident response so let's get started what do we mean by getting pwned now I want to make it very clear and I love the presentation right

before mine about from immunify because getting pwned or wrecked is not the same thing as an incident an incident is kind of what you know immunophyte was talking about where a white hat or maybe you know someone on the dev team might actually find a buck yeah sure it might be a critical bug but it doesn't lead to funds loss of users right and so let's define getting pwned now getting pwn will depend on your DAP in and of itself and your adap's risk tolerance that might be defined by the jurisdiction that you're in it might be defined by um uh your lawyers it might be defined by what your total tvl is and also maybe your LPS but generalized

Pond basically means the unexpected sudden and significant loss of user funds now we're going to go into all of the specifics that I've underlined here but that's the basics of it and I think we can all agree on this definition because it also includes things like rugs right it includes things like hacks too and incl it's it's very Broad and it's done for that reason right because we need to all come to an agreement is what we what what do we mean here now how do we think about getting pwned now this is all going to be as I talked about before is based on your Project's risk tolerance so what is an unexpected event for you so that might be the usdc dpag I don't think anyone in this room

saw that coming until you know the banks I don't know on that Friday went under but I don't think anyone in this room expected that what's a sudden loss for you how do you define that what percentage of tvl would you actually classify that as right or would you say a sudden loss could even be something like maybe losering funds from your treasury that's something that you want to think about right so for example a sudden loss might be suddenly one million BNB being withdrawn from the BSC bridge now initially when this BNB Bridge hack went down I didn't think that that one million withdrawal was that bad I was like oh it's probably just some big Trader it was only until like I want to say it was like less than five minutes later there was another

withdrawal for one million BNB and I remember thinking uh this probably isn't just a big Trader will now the last thing you also want to think about is what's a significant loss like I didn't think that one million B and B was that significant of a loss at the time but maybe in for example in the case of Euler that 34 million usdc which was that was withdrawn from the pool that was the entire you know uh that was the entire Euler you know pool of usdc they had no more money left that is a significant loss and so when you're like just as a project start thinking about those three very high level things now many of you probably have been in incidents have been in war rooms before

but I want to bring us back to the more basic cyber security stuff and how the industry kind of thinks about incident response and then we're going to try to apply it to web3 and all of the kind of pitfalls that we might see with this kind of flow chart now first in the traditional sense there's some preparation that you do for incident response that could be doing a whole bunch of documentation that could be um uh writing playbooks that could be creating a contact list that could be even starting to monitor right next you have detection so that is all about your monitoring program setting up alerts Etc followed by patching obviously the bug

so you find a bug you want to triage it you patch it followed by obviously the recovery okay now you've patched the bug you want to maybe bring whatever your dap this back you bring it back and last but not least you also have lessons which you then are going to apply to your preparation okay this sounds all great right but how is web3 a little bit different from this well first off detection we all know right from crypto Twitter that a lot of the detection is done publicly that's not generally a thing that happens in web 2 or in traditional cyber security where you're literally put on notice by the entire community that something is up another thing that's also different is

when you're actually thinking about applying a patch let's say for example you're operating a bridge your Bridge goes down right and you want to okay you found the bug you want to bring it back well when you bring that back when you want to bring the the bridge back you want to create sort of recovery right what do you think is going to happen everyone is going to flee from your Bridge you will not have liquidity anymore right and so there's a very strange kind of balance that you kind of need to reach when thinking about how you're actually going to go about doing a recovery right the other thing too with recovery is it's not just bringing that bridge back online it's also recovering whatever funds you might have

lost right and funds recovery is a whole other subset whole other story and finally with lessons it's not just the you know the lessons are learned by the bridge in this case it's in and of itself but it's also by The Wider ecosystem we constantly are taking away lessons from various different exploits as to how we can build better gaps um in the future and I'm sure you guys all are as well and that's something very different from web 2. sometimes web 2 companies will publish incidents that occur but a lot of times they'll keep it as quiet as possible right because they don't want the bad PR but of course because everything's public on chain you kind of can't help it here which is cool now let's go through this exercise real

quick with two examples and I actually chose these examples because I thought they'd be a little different but in reality they're not so um and before I get into that one thing that I also want to mention is that today I'm only going to be covering mostly these two sections here that are highlighted in red detection we've seen a ton of different companies do a way amazing job of talking about monitoring and I think they do such a good job there's no point me like rehashing that all over again so let's go into the Nomad Bridge example that happened last August now we don't know what kind of preparation they did for this kind of event we can assume very little though probably but we don't know what kind of preparation they did now one thing with Nomad that was kind of fun or problematic was they didn't

really detect it they didn't detect when suddenly massive withdrawals were happening in one specific block that happened I want to say around 9 p.m um uh that night and unfortunately crypto Twitter saw this and I don't know if you guys remember in that one block there was one threat actor who was a part of the group of attackers that was really hell-bent on participating in that initial Block in the attack and they made the attack public because initially it wasn't and we couldn't unhash it but this attacker was just very greedy and wanted to push through their transaction and that of course started the free-for-all where everyone

could basically copy pasta the code just update write the um uh the input data to include obviously their destination address and boom they could withdraw a ton of um with uh rap BTC and all sorts of currencies now one thing that I have here is that it took the team three hours to respond right in reality and I updated this slide actually while sitting over there that's not actually the case because I was going through the Nomad tweets um the team didn't really respond when in reality happen is if you look at the bridge contract is the bridge contract just got drained within three hours right of course the attackers initially went for the highest denominations right but once they had gone for the highest

value coins like weth or or um uh rap Bitcoin they then kind of waited around and then they went for like lower value currencies like cards for example so they didn't really patch the problem and then it was took them almost an entire day later right because remember other people are copy pastaing this hack and I remember that there were several people in various group chats I was in they were like hey shouldn't we be withdrawing funds from this bridge as well because we can just hand back this money if you know if they publish a recovery address right it takes Nomad and day to publish a recovery address and even so it's been almost a year now since the incident they've only recovered about 17 of all the stolen

funds that's a very very small amount and of course Nomad has never come back in fact they've hardly made a statement since then I don't know if anyone from The Nomad team is here but I'd love to talk with you um to learn whether or not if you ever are considering coming back but to me uh you guys are just ghosts at this point now okay let's talk about something more recent right I thought okay we'll go for an older case now let's go for a newer one multi-chain that literally happened like what a week and a half ago okay so first and foremost preparation let's think about preparation they've been hacked three times so let's hope they prepared right this is hack number four by the way guys so let's hope they did some preparation not sure though we've they've never published any of it now

of course again how was this hack right we don't actually know if this was a hack we think it might be a CCP where it's still kind of unclear based on Twitter um based on what they've written on Twitter up until now but again the attack was detected by the public who identified this oh it was Peck Shield Peck Shield at 1206 PM UTC detected us on the sixth this is kind of important because it took them literally almost 12 hours later to then respond right on Twitter to say that funds have been moved to an unknown address that's pretty bad that is really really bad right so it was detected by the public and then it took almost

um I want to say it was like maybe a couple hours later funds were frozen then that so we kind of tried to recover those funds and why do I mean we it's because some of the funds were frozen on uscc so that was the one thing that you know um that could be done in some of these instances where uh protocols get wrecked or dabs Get Wrecked is that certain assets are freezable so ustc which is a conglomeration of Center and coinbase or rather Circle in coinbase um uh we're able to freeze those funds and that's something we were able to do in this case but it took them then it looks like an extra three minutes to then finally then make a post saying hey don't use our bridge at all right and by the way if you try to use our Bridge transactions

won't go through that's pretty rough right it's it's it's not a good look right and since then as we know they've then published saying hey we're still not sure of where the funds went to but we think it's the CCP who took them because our CEO is still gone but it's unclear again this is pretty bad response right and this is even I would say that in this case a lot of us knew what was going on we thought that it was rapidly kind of happening rapid rapid response was going on but in reality it wasn't in reality it was pretty disorganized I would say so once you start thinking about things in terms of this kind of flow chart things start to seem a little bit less organized I would say now okay now we know what a basic

incident flow chart looks like let's let's talk about some questions to ask before getting pwned and this is where I would say once I finish talking about the slide just take a picture of it because it'll be useful um but some questions to ask right first off with monitoring do you have basic monitoring basic monitoring does not mean crypto Twitter it does not mean creating a tweet deck of your favorite monitoring tools your favorite Auditors they're great and all don't get me wrong Peck Shield slow Miss we all know who they are who then published like these insane like um tweets like hey you might want to check this this transaction out uh tweets that is not monitoring sure that's a good interim solution that is

not monitoring you want to have those alerts set up you want to actually be looking at those next legal slash comms this is something that I've noticed a lot of teams don't think about unless they get a little bit bigger and they actually have lawyers but many teams when they first start they're literally a bunch of devs so the question that I like and would ask them is do you have a lawyer right because when an incident like this goes down there's a lot of legal liability and we're going to talk about that in uh just a minute but the next thing that you might want to ask yourself is do you have pre-written comms in case of an incident like this happening so let's say you don't have a lawyer right or let's say you have a lawyer and you're kind of on a retainer with them have

them just approve a pre-written thing just in case you ever get wrecked remember in crypto communication is key we know with Nomad we also know with multi-chain that the reason that like that their response was so abysmal is that they weren't public about what was going on but instead kind of Let The Chain speak for itself which is not the right move ever right the next thing is is do you have an insurance plan do you have any insurance plan whatsoever and have you notified any of your users or LPS of that right it's not to say that you need necessarily need an insurance plan but it's something that you might want to think about now the last question is a little controversial is do you have connections

to law enforcement now some of you guys might be like no no no we don't we don't want to deal with law enforcement at all nope nope nope we're out of here we're we're about a free financial system here but the thing is is law enforcement might come in contact to you and you kind of don't want that you kind of want to already have someone on your side from the get-go it's just some or something worth thinking about next is incident planning do you have an incident lead so when you have a war room and it was really cool actually the previous presentation here they were talking about having a war room now what I'm talking about here with incident responses going from war room all the way forward to trying to recover and actually learn from an incident which is a lot which encompasses a lot

more right but when you're in a war room what you need to have is an incident lead that person needs to be ascribed at and I've seen various different War rooms where it's a hot potato and no one wants to take it on just sign someone up immediately and just say hey you're you're down for this you got to take all the notes next what you need to have is you need to actually have a tech lead and what is a tech lead a tech lead is someone who communicates with all the devs to figure out where is the bug right that's followed by a calm legal person having someone in those War rooms is critical they can help very quickly help write the tweets help send out Communications help communicate also with law enforcement Etc whoever reaches out and another question is but for

incident planning is in order for those Dev to figure out where the hell the bug is how well have you documented your infrastructure and a lot of you guys might be sitting there especially if you're in a smaller project is like we don't even have time to document it out like that's a luxury that larger projects have we just do not have that just start thinking about keeping it simple and doing some sort of form of documentation and another question is is do you even have a list of contacts that you can reach out to in case any of any anything goes down right and what I mean what do I mean by contacts I mean law enforcement I mean people like uh incident responders even here in this room who have been through various different incidents Etc and uh last but not least obviously

economic analysis right what projects have invested in you and what are the wider ecosystem threats that might actually happen um uh if you try to turn off your tool or your dap or if you try to turn it back on and one thing that I didn't get to but I really want to even though I have one more minute left is the main point here which is what if my dab actually gets pwned and I just want you guys to First not panic and then take pictures of these slides because I'm going to go through them really quickly um but this is the step-by-step plan you want to prepare you want to set up monitoring and all this other stuff that I talked about then obviously you want a triage and you want to create that team that I talked about but here is the real

step-by-step flow chart so first off let's say you get an alert from crypto Twitter I don't want you to but you probably will right monitoring um and then um let's say you triage it and you know that uh oh we lost money what do you do okay so let's say you don't actually think you lost that much money it's not that big of a deal not an incident close it forget about it this is the one part of the slide that I really want you guys to take a picture of is when you call an incident what do you do so there are three big areas that you want to be scoping out you want to be asking yourself legal comms questions that are critical engineering questions but then also investigations questions because if you get wrecked you are going to want to try to recoup that money you really are

um and now you guys have taken pictures of this I want to show you guys two different kind of um uh offshoots of that let's say you find a patch right you need to then start asking yourself what your liability is for implementing that patch and do we have any insurance and what if we what are the wider ecosystems of us ecosystem threats of us turning this thing back on um and you know uh last but not least investigations wise we're still out all this money how do are we going to pay these people back are we actually going to track down this money and then because a lot of people like this is they believe that when attackers try to negotiate then maybe they're going to get money back I would say 99 of the time do not even

bother but in case you try to bother I wanted to do this slide for you um here are the questions you should be asking yourself if you want to negotiate the main point is here don't get distracted by negotiation it's not worth it and let's do some takeaways here real quick just prepare prepare prepare that's like the main point here and um obviously conduct exercises and if you guys want to talk to us more about some exercises we've conducted uh let us know but thank you so much thank you Heidi we um we have a bit of time before lunch or lunch is starting now but if you guys have any questions yep

okay I'm gonna start you can go next uh I wanted to ask isn't it a bit unfair to assume that the public response on Twitter is correlated with the time that the team actually began to assess and respond to the incident because assume like if your project and you get an incident that the first thing is not go to Twitter it's like actually try and solve the issue right you used to work for nomad no that is a great question and you know what we should give the project team some credit here's the problem though the blockchain is public all of this stuff is public if you don't make a statement people are going to make assumptions about you so you may as well just make a statement and it should just be a coverall statement like hey we've

noticed something weird we'll get back to you something along the lines of that but something that will protect you maybe a little bit more legally but at least that's the bare minimum because if you don't say anything the assumption is you're not doing anything is that unfair yes but have we all seen that time and time again absolutely yeah the uh great talk by the way um do you have like a example of good insulin response it was kind of difficult so I was thinking initially when I was looking through the flow chart of good incident response and a lot of times the best incident responses have been from companies like block SEC that actually presented earlier where they try to

literally front run an attacker right but I didn't want to include that in this presentation even though that's something that's very unique about this industry is that you can front run an attacker right and that the public is already aware and that there are companies out there doing that but it felt a little strange to include that in there because it should be actually the project team doing that right um so yeah any other questions yep are there monitoring tools that you recommend to help front run the attacker I'm going to stay unbiased here is that enough any other questions

we've got time don't be shy well Heidi's going to be around for a bit longer so feel free to grab her and ask questions thank you so much epic talk thanks [Applause] thank you all for joining the morning session thanks to Maddie and all the speakers this morning so we now break for lunch and we're going to regroup here at one so there's a fantastic set of talks and panels on formal verification auditing Bridges and many more so we'll see you soon and for those of you joining today the lunch is

downstairs everything [Music] [Music]

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

foreign [Music] [Music] [Music] foreign

[Music] [Music] [Music]

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

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

foreign [Applause] [Music]

foreign [Music] [Music]

foreign [Music] [Music]

[Music] thank you foreign

foreign [Applause] [Music]

thank you foreign foreign

[Music] [Music] [Music]

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

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

[Music] [Music] foreign

[Music] thank you

foreign [Music] [Music] [Music]

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

[Music] [Music] [Music] foreign

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

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

play ers [Music] I'm almost here [Music] immoral immortal

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

foreign [Music] [Music] [Music] foreign

[Music] [Applause] foreign

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

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

thank you [Music] foreign

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

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

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

thank you [Music] laughs foreign

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

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

[Music] foreign [Music] [Music]

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

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

thank you [Applause] [Music] foreign

[Music] foreign [Music]

foreign [Music] [Music]

[Music] foreign foreign

[Applause] foreign [Music]

foreign foreign

[Music] [Music] [Music]

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

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

[Music] foreign [Music] thank you

[Music] foreign [Music] [Music]

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

did you plug in the I mean I can do it without this is you have to plug this in interesting all right okay good uh welcome to the former verification session um Janice marathak is of ddub I will chair the session uh so our first speaker is natano from sartora and he's going to tell us about everything nice you can do with formal verification to avoid getting wrecked

wow thank you very much for the presentation um so actually my the title of my talk is uh much more modest just improving the security of defy mat libraries easy spec for preventing easy specs for preventing um complex bugs so let me explain the plan for the talk um I'm going to be talking about four things the first is kind of an intro to define exploiting the trade function the second is a prb matte Library bug we announced a few days ago the first topic would be how did we find it and the fourth would be one form of

edification is easy so okay let's begin so I assume that a lot of people have seen this kind of slides before but I'm just going to like talk about them a little to touch base um okay so what is an automated Market maker so I should first say what is liquidity well assets have as well as like a wharf they have their tradability which is the reason that you probably like uh oh thank you so you can't really buy lunch in the cafeteria with an antique 17th century piano and if you want to do that that's probably means you're in a bad situation so assets needs to be basically what

market makers do in classical Finance there are people who are willing to trade one asset for another were providing this ability to like convert two types of assets to each other in D5 this is done by an automated Market maker often and we have liquidity providers which can be anyone they give in the most basic model of this they give a pair of tokens token in token B and we get back an LP token which you can think about as a receipt to certain percentage of the amount of the amount of tokens in the pool and we have Traders Traders given some amount of token a and we get back some amount of token B right um

any questions so far this is familiar great okay so of course the main question you should ask is how does the mm know how many B tokens an a token is worth right and the answer is we don't need any kind of like Oracle or anything else because in essence a market itself is a price Discovery mechanism and for a mathematical perspective virtually every kind of like uh automated Market maker that's currently in existence I think on the chain is an example of a constant function Market maker which means its trade behavior is dictated by a function that has these four variables and it Maps into real numbers and these numbers

are X is the reserves of a tokens why is the reserves a b token Delta X is how much the trader wishes to like give and otherwise how much he wishes to receive and the key point is here is trade is executed if and only if the enemy believes it's profiting which means it should be that this C of X Y Delta X Delta Y is bigger than c x y zero zero which means if trade was not carried out so any questions here maybe I should give an example which is very this is much more familiar right this is the classical case right everybody's happy um you have c x y Delta X Delta y uh equal X Plus Delta x times y minus

Delta Y what does it mean it basically means we want to preserve the product of the reserves to be an equal number right it's x times y equals K that's everybody's favorite the idea was Martin cooperman and vitalik buterin and it was first implemented by uni swap in 2018 a lot of people since then so this is an example of a trade function there's nothing magical about this x y equals K formula and there are many other kinds of trade functions some of them are quite involved mathematically and different trading functions optimize the underlying properties of different token pairs okay so what happens if there is some kind of a

bug in the computation of the trade function so in our automatic flow in the trade function would allow an attacker to basically Force DMM to systematically accept unfavorable trait maybe just a little but consistently the key Point easier is money has to come from somewhere so this is kind of somewhat of a subtle attack because the number of LP tokens each liquidity provider is holding Remains the Same in the end of the attack what basically the attacker is doing here is kind of draining them of their Wharf um a rough analogy to this is inflation okay it's a rough analogy the liquidity provider still has the

same amount of currency in their account but it just can buy a lot less with it okay so the key Point here is with computational errors in the trade function would enable an attacker to drain the funds the liquidity providers deposited into the pool um I should probably okay I should probably say this is not really restricted these type of attacks to amms I took this example because I felt it would be very familiar to everybody it's also true for you know for landing in borrowing markets right we know from erc4626 we're telling you that oh yeah I

should definitely uh make sure that the rounding direction is in specific opposing directions to make sure you're never violating this like trading it's called the trade function the mm invariant or the CFM invariant in different places in the literature so how much damage can a simple rounding error cause that's like famous last words there's been a bunch of like attacks where was the alpha more hack where was the SPL token lending bank which was stopped by the developers inside the program Library there was the ELD HDL HDL distribution bug and I think two recent ones 100 Finance the second Midas Capital exploit okay so any questions so far

okay so I should speak about that bug it was such Discovery is a critical cover built in a non-life code of a leading D5 protocol and upon further inspection we realized that it's the root cause was actually a public library function well they've signed it laid dormant for almost two years it's present in every version from 1.05 to 4.0 and it's temporarily fixed in 4.01 where there is a warning if you can see in the net spec of it says that this is wrong and we'll get to it in a moment and the longer term solution is going to be part of a roadmap to support multiple rounding modes in prb mat so since I

mentioning prb mat I should probably just say a few words about it in case you guys familiar with it it's a solidity mat library for advanced fixed Point computation it was written by Paul Rosenberg and it's based on work over Michael blumen on the algorithmic side um it's popular it's fairly complicated it's very very gas efficient it makes heavy use of fuel it has a lot of like bite hacking tricks it has a lot of matte magic and a bunch of number theory in it um it's well written documented it's actively maintained it has a lot of commits a lot of unit tests um it's really very good [Music] um and I think this is to the best of my

knowledge the first uh library bhagavat was found by a semi-automatic tool maybe I'm wrong I don't know um so okay now let me explain the bug okay so I'm slightly simplifying the algorithm here for the purpose of presentation so the goal of this function is to compute the floor of X Y divided by D with full Precision without losing any precision so you separate the size of the absolute values that's the first and then you compute the absolute value by call you basically reduce to the unsite case by calling Maldive which is a function of the cap used floor of X Y divided by D on the absolute values and then you compute the overall sign by

taking zor on these signs so to give an example you take X you take x y equals minus 20 minus 13 7 so you get 20 30 and 7 1 1 0 and the absolute result is floor of 85.714 it's 85 compute the overall sign and you get the right result the problem is the second step is logically wrong when the absolute value is smaller than zero rounding taking a minus a flow a CO is an example if you take minus 180 114 you will see that like the absolute value is 12 and what you get is minus 12 but if you compute the right number it would be -13 so for example you know

it's possible you should have written 0 and you would return -1 okay that's the bug and it's in how did we find it okay um so formal verification process what is formal verification well very roughly speaking you have a bunch of invariants and you want a bunch of code and you put it into a big machine called as a store approver and it throws out either proof with every behavior is correct to the spec a timeout over the behavior vials the invariance this is not a fuzzer basically you convert the entire code into a bunch of logic equations and you try to prove that the

behavior is correct like try to prove basically a theorem um I should probably say any questions so far okay so the other point that I want to make here is it's basically spec writing in general is hard work okay and therefore it's kind of expensive um this is like security researchers you know they have to do a work perched on a pile of gold just a fact they do the best work this way but this is not always true encoding integer equations is really easy and for automatic libraries basically this form of specification just right

for themselves okay here's the example of the of this is the entire like uh spec we detected this bug it's basically automatic um the only thing that you're seeing here is basically I call mold Divine Computing code I can put the code result I compute I compute the result in logic and I ask Arvest the same the only thing that I need to write is this thing now this looks like solidity feels like solidity it's not solidity it's we worked really hard to make it look like solidity this is smt basically okay what you're seeing it to Matt int are unbounded integers we're not you're into 256 will represent the logical numbers in Z okay very present arithmetic

integers okay and the other thing is like well when you run on this type of like arithmetic libraries you also get really nice counter examples like the counter example I gave basically just came directly from like the prover just spit out this counter example so you get x y and d and you can just put this thing into remix for example and just check where things go wrong so yeah this is actually all the spec you need to detect this problem um you don't need anything else um and you don't need even access really to the approver you can there's a pay as

you go option you can just like you know just run the script just pay for the minutes and just find it it's a bit surprising like uh that this is found by such like an easy spec we were surprised matte libraries are the foundation basically of D5 but were not easy to get right I think that's maybe the takeaway these are things that Auditors usually don't like looking at I didn't include here the code of how the entire computation looks like but it looks there's a lot of like low level stuff there is a whole bunch of like uh number of favorites easy to get lost and to

miss with the point is like the entire logic is actually incorrect um so writing specification helps ensure that nothing slips between the cracks so this is a very very very well written Library um it has unit tests it has everything but because if you make often you do like frequent commits but sometimes you refactor a function and you forget to put some kind of a unit test to that specific function that is the function that you find a plugin so I think even just the process of like you know touching base and checking in the end writing a formal specification of what everything in the program is supposed to do sometimes can find bugs even without any automatic tool and the other interesting part is I think the specification really easy to write I

should say that this bug is very common it could have probably been found by a fuzzer like easily but in general we also found some other bugs there that are I think less interesting that you can't really Express I think using a fuzzer the point is like it's almost automatic in this kind of mathematical functions to write what the spec should be and to express it and you can't really write it in solidity because if you could write it in solid you would not need a matte library to extend solidity's functions to make it right um again I think the conclusion is in retrospect kind of obvious so if you have mathematics or economy like this kind of like core parts or just do computations any form of edification

that's like a really good match you have some function you don't know what it does you just throw it into the prover and it either tells you if it works or it doesn't it makes sense I think a lot of sense in this case to utilize semi-automatic tools for increasing security okay thank you questions [Applause] thanks a silly question how did you come to the idea that round and down for negatives means pushing further away from zero not closer to zero I think that's the kind

of in the first place that defines the difference between the two approaches that you at some point decide that you have to make the number more into negative rather than closer to zero so thank you for the question so the mathematical definition of floor floor has like a very Thorn sealer have a well-defined mathematical function so basically very rounding towards minus infinity I mean the definition of it appeared in the net spec was you need to round down okay what basically was changing version 4.01 is the observation that like it actually does not round down uh because the Maldive is based on the co on the algorithm veteranical blumen wrote which

takes floor but basically rounds towards zero because it is an unsigned numbers and when you modify it and you want to keep it efficient then you make it like inside numbers but then basically what you notice you can no longer it no longer gives you like floor it gives you basically rounding it towards zero which is not always what you want for example if you're raising it to some kind of a monotone function in the trading function Etc then it gives you the wrong result you're going to lose money from it I mean I don't know if it answers your question I mean the definition of floor is like rounding towards minus infinity definition of Cl is rounding towards plus infinity I mean that's a mathematical definition maybe I did not understand your question it's okay we can't hear you this is floor yes

that's the yes so yes that was the definition that's how I should I go okay um would you say there's any trade-offs between writing the specification and the CVL um language versus maybe like uh lower level proof assistant if there's anything that you know that you're trading off or missing from what you could get by specifying like the whole thing in a proof assistant I mean I don't have a lot of experience with proof assistance I think the main advantage is like if I remember correctly like proof assistance like K Etc are fairly are much harder to like you know to work with and I think like you need a lot more effort to like do the

verification so it might at this point like you know be actually easier to just go and do it manually I think the advantage of like CVL is that it looks like solidity and basically the specs of mathematical function are just literally okay take what's in the Nets pack throw it in and check like you don't need a special verification engineer you don't even need to put considerable amount of efforts I mean you just need to do it it's like easy hi nice talk um you I was just curious you've been using the Satora approver to handle these math libraries but a lot of these libraries have a lot of non-linear computation I'm just wondering which is like notoriously bad for smt I was wondering if you could just talk a

little bit about like you know what you're doing to address the non-linearity uh maybe you can talk and how sartora approver does on on those kind of um yeah so that's an excellent that's like an excellent question I'm very happy somebody asked that thank you um so it depends so for algebraic functions like quotes Etc we have Johan's work which helps us like actually we're able you need to do some manual work but you can like summarize for example square root and you can prove separately prove that the square root is actually equals you think about Newton graphs on iterations and loops and desktop type of stuff right and like hensel's lifting Lemma so yeah you can actually rely on for square root for example Johan's work which proved it it did like amazing work and for really really like

transcendental function like exponent and Lan it's more complicated I think in this case you really need to like either Black Box some of the things and either do like a very very careful step-by-step verification even manual or like he was a father or something else you need these things you need to Black Box out but if you're talking about algebraic functions there's like something to do we're basically out of time if it's a quick question we can take it thanks um so the Satora proof is obviously really powerful Tool uh is it open source and if not are there any plans to open source it so I think can I direct this to muli no

um I don't know how to answer that question of like long-term plans I think this is a question for my higher-ups okay let's uh thank Nathaniel again and take this question offline and our next speaker is Paulina talmak from RV and she's gonna tell us about using symbolic execution and scaling it to D5 [Applause] now you can use this microphone but you

cannot walk too far because the video needs to capture you so you need to be well I didn't plan to but thanks well I guess I can start uh bonjour thank you all for coming I'm Paulina I'm a verification engineer at runtime verification before that I was a PhD student and I also worked with maker Dao on improving the adoption of symbolic execution tools for a smart contract and defy security and that's what the talk is going to be about so let's start with why do we need something like symbolic execution and the short answer to that is because we want to eliminate bugs from our code base and symbolic execution can help us with that because it's one of the formal verification techniques and there is of course more to formal verification than

just bug finding but let's focus on this application in this talk um let's see how it works here I have a small smart contract example we'll use in this talk so here we have a function it's called backdoor it takes an input parameter X and in this function we declare a variable y that is set by zero set to Zero by default and then we also have an if statement what it means from the point of program analysis is that there are two possible ways in which which this function execution can take so there are two execution paths one if this if condition is true the condition says that X Plus 1 is equal to 1024 x here is the input parameter which means that if x is 1023

then we'll be taking this execution path in this execution path we set y242 and then at the end we have an assert checking if Y is not equal to 42. what it means is going to fail this condition is going to be violated since asserts are commonly used in smart contracts to express conditions that should never evaluate to false it means that there is a bug in this contract and that's what we'll be trying to detect using the techniques we consider in this talk alternatively if we take the else Branch nothing happens y remains 0 0 is not equal to 42 so the assert is not going to fail in this execution path um so what techniques do we have that can help us um deduct identify this issue here well one of the techniques the most

simple one probably uh is unit testing so in a unit test usually we assume that X has some concrete concrete value for example we can assume that X is five if x is 5 um the if statement this condition does not evaluate to true we're taking the else Branch Y 0 not 42 the third doesn't fail which means that we haven't identified the bug even though we know it's there and that illustrates the insufficiency of relying on unit tests solely for security and correctness Assurance in smart contracts because it provides us with limited information about the smart contract behaviors that'd be inside of course it's it's a very useful technique and I'm pretty sure that every project should use them besides that unit testing are usually used to analyze happy path and there

might be challenging to use in order to identify some unknown issues so in order to increase coverage we can do fuzzing as well that means that instead of just running our code on a single concrete input we'll be running it on a sequence of randomly generated concrete inputs fasting is is very efficient I highly recommend using that as well the problem with it is that all these random inputs can still drive the execution towards the same execution path which means that we'll be exploring it over and over again and we won't be able to identify the bug because it can be challenging for the father to randomly generate the value that will satisfy this very specific condition that we have here and that is in fact what happens I run foundry's father on this example 65 Southern times I think

and it doesn't identify this filter but you can also trade yourself um but I also said that symbolic execution can help us identify this issue and here is how so the basic main idea behind symbolic execution is that we don't restrict the value of x to some specific concrete input but instead we assume that it can take any possible value and that's what we call symbolic variable then we'll go down every possible execution path and we'll further narrow down the set of values that acts and other variables can take based on the conditions that we encounter in this execution path so the conditions comes come from things like if statements Loops assert require statements any conditional statement um here since X can take any values it

might as well be 1033 so we'll finally get to execute this true branch of the if statement on the left where the answer it fails um the formula on the slide represents the state where the assert is failing um so we'll finally detect it because that evaluates to True indicating that the assert can fail here the input to a symbolic execution tool usually looks something like this normally it's the source code or the byte code that we are going to symbolically execute the output we want it to look something like this so we wanted to tell us the tool to tell us that the vector function should be called with this particular concrete input for the assert to be violated symbolic execution is commonly seen as a way to generalize testing because it allows us to reason about sets of inputs

that would be in Practical to reason about using for example a test Suite we wouldn't be able to cover as much besides that symbolic execution can also be viewed as this translation from the source code or byte code to this more formal logical representation such as this formula we can see on the slide and we can reason about this formula but the question now is how do we get from all this logical formulas to the output that tells us with what specific values we should run this code for the assert to be violated and that is what symbolic execution tools use SMG solvers for that's a very sophisticated piece of software smt stands for satisfiability module of theories there are several of them some of them are on the slide but essentially what they do they take a

formula this logical formula representing for example the state where the assert is failing in our example it runs some analysis on it and based on the analysis it tells us either that this formula is satisfiable which means that it can evaluate to true if our symbolic variable takes some particular value such as the one we expect if the formula contains some contradictory Clauses which means that it can never evaluate to true it's going to tell us that it's unsat or unsatisfiable the third type of input sorry of output is I don't know so if you try out of resources it cannot really answer our question here on the slide I have an example of the manual encoding that I have performed of this solidity code that we

had in the previous slide that's the translation to the python API of these three smt solver so if we encode this example and ask if the assert can fail it almost instantly tells us that it is possible if x takes this value that we expected it to show us all together with typing this took me 33 seconds but if you type faster than me you can do even better so obviously it's a very simple example but I personally think that it illustrates that symbolic execution is a very powerful tool and technique and personally I think that a year from now it's going to have a very big presence in the smart contract development processes so maybe now is a good time to start adding it to a tool belt um in general there are many symbolic execution tools for smart contracts and

as part of our effort to improve and increase the adoption of this technique we have selected an examined um some open source tools the best open source tools for symbolically analyzing evm bytecode so these four tools here made it to the top of our list for usability versatility and being stable in general so the tools are missile by consensus multi-core by trail of bits hvm originally part of the adaptools framework currently developed by theorem foundation and ivmc which is the only academic tool that made it to our list that's developed by a group at Drew University at bochum so let's get back to our simple contract and as powerful as all these tools are only two of them detect this field is out of the box missile and hevm so all these tools are

rapidly changing and evolving but at the moment to use them efficiently and effectively you might have to tweak their behaviors quite a bit or slightly change the way the analysis is performed so here I'm also going to show some Landmark tips on how to use the symbolic execution Tools in practice for example monticore out of the box doesn't report this assert failure even though it's there however if we'll look into what happens it turns out that multicore only detects and reports failed asserts in solidity versions prior to 0.8 when the EDM representation of a failure had changed so even if we say something trivial like assert Falls it will not be able to report that either however if we don't grade solidity

version to 0.7 it's going to detect this filter in less than two seconds and we also similarly added the detection of filters to ifbmc ourselves so that brings us to the advice number one if the tool doesn't report any issues make sure that it actually reports something it's something trivial like a third false and see if it fails because there are a lot of reasons for the tool not to report anything other than Beyond just the code being perfect and correct one other aspect that we're considering is the support of several SMD solvers it matters because the performance of different SMD solvers may vary and for example here the timing all the timings are based on the same SM just over day three but if we use a different one in

each BMC we'll get an almost 20 times better timing here's another example of a tool reporting that everything is fine over a more complex contract so that is a simplified contract from the maker.o code base that contains a real bug that of course has been fixed it has a function that's called country example that deterministically fails an assertion expressed in an important invariant after the execution of four function calls um so the contract is called minivat however if you run missile on it uh it will finish the analysis in four minutes but it would still it would not report any issues however if we anticipate that there might be some smt solver-related issues which we should and that's the advice

number two uh we might think that maybe the SMS already is quietly failing due to the timeout in the background and in fact that's what happens and if You observe some inconsistent behaviors in the symbolic execution tool if it performs inconsistently between different runs there is a chance that there is also some messages over timeout happening if you increase this over timeout missile will run way past this for minutes does it help no it doesn't that happens because there are actually a lot of aspects that affect the performance of the symbolic execution tool and in general symbolic execution traverses all possible states of a smart contract so the number of states grows exponentially with the contract size so

one of the biggest impact on performance comes from limiting the scope of the analysis and also you can otherwise you can optimize the interactions with the smt solver for example we're querying it less frequently so all this might be achieved by the options that are present in the symbolic execution tools that you're using for example in the end we managed to make missile find this issue in less than two minutes um that's the advice number three know your options know the options present in the symbolic execution tool you're running and use them to limit the scope and optimize the performance otherwise for example you can focus on the detection of only some specific vulnerabilities not reasoning about gas and so on overall Miss Roland might require two

python-based tools are flexible and easier to use in general the timings on the chart represent the best most optimized run of these tools to detect the issue that I have seen shown in the contract on the previous slide the original Haskell and rust respectively are on average faster than the other two so it might seem that the usability versus performance is a trade-off in the existing symbolic execution tool but a lot of efforts are currently being put by the respective teams to improve the situation and one example of that is symbolic testing so that's one of the emerging Trends which allows developers to apply symbolic execution to existing tests that already exist in the project

that makes it easier to introduce symbolic execution to the development processes it also limits the scope of the analysis because the analysis will be restricted only to these things that are being executed within the test and in general I think it dramatically improves the usability of such such tooling so symbolic testing is supported by our old friend hvm we added the supportive symbolic test into his BMC by integrating into this Foundry ourselves but that's probably a different story um there is how much by a16z that appeared quite recently and also there is KVM by runtime verification on the slide we also have the same minivan smart contract but now we have the test instead of the country example function but it encodes essentially the same thing

and we'll use it for benchmarking these tools as well right so since symbolic testing is quite easy to use we'll be evaluating this tooling based on their completeness which we Define as the support of complete ebm semantics and cheat codes that Foundry uses to tweak the analysis KVM is by far the most complete one because it supports the complete evm semantics and in fact it also passes all tests from the ethereum conformance test suite for ethereum clients it also provides extensive cheat code support and a lot of work is currently being put to make the performance better for example when I run KVM on the same example back in April it took 32 minutes to finish the analysis and identify the issue on a powerful server and now it finishes less than in three minutes on

my laptop also take few minutes to finish the analysis but they are a bit less complete and hvm takes just 1.5 seconds it plays in Fast I don't have any other comments here the concluding advice here is that I recommend you finding your tool and learning how to use it efficiently so with the security guarantees that are inherent to symbolic execution that might give you an action safe smart contract development auditing bug bounties probably and all these tools get better and better and easier to use day by day because the teams are developing them very actively this talk is Loosely based on the two blog posts that describe the evaluation of symbolic execution tooling that we have performed and one of them is

available on this link on the slide and in addition we have also prepared some Docker containers with this tools fully set up so that you can try to run them seamlessly and that actually completes my presentation thank you so much and I'd be happy to answer any questions [Applause] so in your slide looking at the the

usability and the performance how much impact does the usability have on your performance as the person who's actually setting the thing up to run it thank you so much yeah I actually wanted to wanted to say something about it so I have to say that missile and monticor um rank them as more usable so one of the reasons why we do that is because they provide a lot of options so you can they're quite flexible you can turn off unnecessary detectors you can basically do a lot of things to optimize their performance and that's why actually multicore and Mistral in the most optimized runs don't perform much worse than usbmc or hvm that are faster on average but are less flexible so them being usable and and providing more

options to adjust the the analysis um well first make them more performant it's easier to extend them so we have added similar functionality to multi-coordinate BMC and it took considerably more effort to do this in epmc well it might have something to do with my personal skills because one of is written in Python the Azure is in Rust but it's easier to expand it's easier to add some additional vulnerability detectors and so on so I'd say that it has a great impact but still well so there is a limit to how fast Mysteryland monticore can be and for example neither of them can complete the analysis in 1.5 seconds as each evm because they take I think two or three seconds just to start um but in general well I would say it's

extremely important um well I hope I answered your questions sort of so what so what I'm trying to get at is you know if I go and pay someone to do this work you doing the setup and the thinking and setting the options that's expensive time right and and that's real time the difference between two seconds and 12 seconds and you know 112 seconds for a report doesn't make any difference it's like by the time you send that to me in an email that that difference is completely irrelevant right and unless there's a really really big difference right well to be fair that's a simple example and that's why

the difference is insignificant and uh in theory more performant tools and for example tools that support several SMD solvers other than one that might struggle with some particular thing we have in the smart contract and we have a lot of those might be able to do something in the end so there are a lot of at the moment there are some scalability issues that are being addressed but the question is essentially whether you can get some results with the tool you're using and it's easier to get these results from the tool that is easier to to tweak uh but in general at the same time if they're not if they're like inherently not performant if they want to use one SM dissolver that does not perform well on for example what we have there like

non-linear arithmetics for example or large beat factors and we have a lot of those in smart contracts then you won't really be able to get any results even though it might work you know better on something for examples so I guess the bottom line is that it take some work to find the tool that works best for you and yeah that's pretty much it the question is whether you're you'll be able to get some results You're Expecting especially if you're talking about a relatively large code base which might be challenging thanks thanks for the talk um so you showed a small example where the fuzzer couldn't find the bug but the symbolic execution engine could um and what I was thinking there is that a lot of coverage based filters may be

able to easily find that bug because they're going to be coverage directed right so could you just elaborate a little bit more on the advantages of using symbolic execution over a coverage guided fuzzer sure well I'm to be very less familiar with coverage based funding I think the question is still whether it would work in some very with some very sophisticated smart contract that contains a lot of for example nestative conditions if you have to very carefully devise what input variables should be in order to pass all these checks in general yes so I agree that definitely I think the fact that it doesn't identify these issues in the smart contract just characterizes the fathers that I have used as you know having limited ability

to reason because if you simplify it they'll be able to find it but in general yeah I would say that symbolic execution is probably is generally considered more useful when it comes to some conditions that are constructed in a way that is very hard to bypass them without some automated mathematical reasoning about what value should it take thanks thank you [Applause] and next on our schedule is a panel discussion

on formal verification and from now on Kurt Barry is taking over as the panel moderator and he will introduce our panel guests thank you Giannis I've got uh I got the fan club here [Music] thank you thank you somebody might have to share

all right this is going to be the spiciest FV panel ever well we'll see if we can deliver on that all right so the general context for this panel is how can formal verification improve web3 security and I thought we would maybe start by just having all the panelists introduce themselves say a little bit about you know the project they work on or how they use formal verification you know day to day just so you can kind of know who we have so you want to go ahead and start Gila hi everyone so I'm Gila Castle Nuevo I work in Centura and actually I have a vast experience from the web to security this is where I come from I was eight here in this field and

um sartora is first of all a security company and this is what we do we want to protect the web free ecosystem and we use formal verification in order to do that we have a lot of formal verification experts in our company and of course we implemented the sertora prover which is based on formal amplification and also one of our goals is to educate people to use formal verification in order to check the security of a smart contract so this is also kind of our mission when working with the community so I hope it answers your questions so nice to meet you um okay great hi I'm John I'm the CTO of

verdice and so veridice is a security and auditing company and so we perform audits in a number of different parts of the blockchain ecosystem including like smart contracts uh ZK circuits low-level blockchain implementations and so on and so we're also particularly interested in building tools because that's what many of the people in the company you know have a background in and so we commonly use tools in order to Aid in the auditing process and one of the tools that we use is formal verification and so that means for things like smart contracts we will formally verify critical portions of

contracts in order to make sure they're secure and that there are guarantees and then for ZK circuits we commonly use more semi-automated or manual methods in order to formally verify that circuits are actually constrained correctly and are implemented in a way that's consistent with the developers understanding hello I'm Fraser I'm the CTO Cubist and I'm also faculty at CMU I actually do more verification in my academic life where I focus a lot on verifying small pieces of security critical production systems um but at Cubist we've been working recently on a key management system and we're using verification to prove

properties of that system we've also used the sertor approver to prove some properties of liquid sticking contracts and we're collaborating with very dice potentially on some policy Checkers for user policies around Key Management I'm grigora rocho I'm the founder and CEO of runtime verification also professor of computer science at UIUC my specialties programming languages formal methods formal verification and runtime verification was the company that first ordered the uni swap formally verified uni swap also the beacon chain the deposit contract we develop

formal verification tools and techniques and foundations for us foundations are very important we need to understand why things are correct and why even formal verification tools are correct because we've seen so many bugs in verification tools we saw Paulina stock many formal application tools don't find the bugs or if they find the bugs sometimes they are just false alarms it's important to understand things from a very foundational perspective in our view performance yes is important but to us performance was never the critical aspect it's more important to have the right techniques correct by construction and then performance always comes this is something we humans are

really good at to improve performance once we know what we're doing cheers um hello I'm Julian so I'm the head of formal verification at nevermind so nevermind does a lot of things in the web 3 space but on the security side we focus mostly on auditing monitoring and form verification which is what I do and currently on primary focus is on ZK circuit verification so we have a variety of extractors for various ZK circuit description languages into various proof assistants particularly the lean proof assistant and we then can do partially automated and then par with some uh what you call it interactive manual assistance for the verification

and currently which is something I'm quite excited about we're working on verifying the risk zero zkvm all right great so a lot of interesting backgrounds here on the panel and I thought maybe we'd just kick things off with you know just very directly like why should web 3 projects use formal verification at all you know so many other tools out there um you know I came from web 2 we never really did formal verification there so so why should web 3 be using formal methods anybody want to take a start I guess I can do it uh go for it yeah so formal verification is very important

because basically what you have is um you've got very complicated code and uh people are writing these protocols that have very or that requires some very strict and variance hold and if those invariants don't hold then the entire protocol is going to break down and so that's where Proto or formal verification is very useful it can verify uh in a very strict sense that the invariant that you need to hold in your protocol will hold at all times and therefore that is great for preventing hacks and stuff like that because there's a lot of people who you know are very incentivized in order to try to make sure and variants don't hold

or Corner cases are exploited and all of these things are things that formal verification is built to reason about and to formally ensure you know are consistent with your understanding and that your logic is actually implemented correctly would like to add something here I think that the web 3 ecosystem actually is a very good application on where a bag can be very expensive first of all the exploit itself usually involves some stealing of money so this is why it's very important to have the the code properly verified by a formal verification and also fixing the backpack can be extensive too because

we're speaking here about upgrades and we had a lot of talks about that and how complicated upgrades can be and also I think it's a very good application because in first of all the code is open source so it in a certain sense it's also more vulnerable because many people are looking at that and looking for bugs so it's very important like to have like many eyes looking on that also good eyes and of course formally verifying the properties that we're interested on and of course the fact that the code is open source makes also um it makes easier to have it formally verified for for from many different people and also from Auditors and the third thing which applies to the web

free and it's not always right for the other areas and Computer Sciences that decoded smalls so we know that formal verification is actually a hard task and can be hard to do it like a very complicated system but usually in smart contract since like the price of having B code is high because of the gas then it makes the code like it's smaller and it may makes the life of the formally verification tools easier so this is why I think it's like a very good application in of formal verification yeah great answers there um any other panelists want to add anything to that I guess I just want to Echo that third Point like you can that's amazing I mean

if you're working on a web browser good luck you can't formally verify anything that kind of sucks for you but here you can do it so why not at least try right there are plenty of good tools that just don't exist in other areas so worth a shot all right so sort of moving on logically so we've upload projects why they should be using formal verification but now they say okay well I've got formal verification that's one thing you know but I want to also do security Audits and I want to do fuzzing and I maybe want to do some economic simulations and you know I want to have funds left over for a bug Bounty and you know but they often operate on under constrained budgets you know unfortunately then we wish we had unconstrained budgets right

so so when you look at the trade-offs between formal verification versus these other tools and like you know maybe a Project's looking like oh do I get an extra audit or do I like pay to have some formal verification done or something like that how should they kind of prioritize formal verification versus other techniques you know can you just do formal verification and nothing else does it replace everything um or you know how do you think about those trade-offs yeah so I think there's a lot of things that can be said there so formal verification I mean despite the fact that it definitely scales a lot better in this area it can still be a lot of work because um I mean I I think Giannis pointed it out at one point like you you need invariance and variants are very

important here because sometimes even though the code is you know smaller size and is actually more tractable there are things that can mess a verifier up and so depending on the type of technology that you're depending on non-linear arithmetic can get very complicated for at least automated verifiers um there's a question about asked about that earlier you can also have issues with loops and stuff like that and so really what at least we recommend to clients typically is anything that is security critical so anything that is going to be like storing money or maybe routing money or anything like that should

probably be formally verified so you have those guarantees but you know other tools are also great at you know Finding bugs as well so for that reason we commonly use fuzzers static analyzers and stuff like that and so like early in the lifetime of your project it's great to use a static analyzer it's great to use a fuzzer and property-based testing in areas that maybe aren't as security critical and then for those components that you really need to make secure that's normally where we recommend formal verification and then for ZK circuits we always recommend formal verification uh personally I can add that I don't think that person that formal

verification replace anything and but it cannot also be replaced by anything I think that there was a talk in the 101 maybe it was yours that Define actually security by like layers and you have to be or you have to have all of them because each each security layer will have like some holes so it and each and no one of them is sufficient to have a whole security uh a security coverage this is why I think that it's great to use formal verification but when thinking about having your code secure you cannot you cannot give up on anything this is my thought

and now we are doing formal verification but actually we are doing a lot of other stuff which needs to [Music] um complete it and also auditing it's it's something very important after formal verification and of course also verifying that the specifications are correct it's also very important so this is how I think it applies for formal verification so um yeah agreed with everything um one aspect of formal verification that doesn't seem to be entirely clear because many many think that oh I formally verify my code so it is correct is that formal verification really what it really does for us is to help us

identify the assumptions under which the code has the properties we think it should have and that's extremely useful because it makes us aware how things can can go wrong and also what to monitor after deployment as well so formal verification yes is a tool an excellent tool that puts some rigor in the process it helps us on many aspects but we believe that the most effective use of formal verification should be under the hood we believe that tools should be easy to use by developers and they should use formal verification without even realizing those form of verification same like you have type

checking and programming languages right user type Checker without realizing that you use a very complex algorithm under the hood that does something really that people put a lot of effort into same should be formal verification we believe that should be a smooth process from writing programs writing tests then fuzzing then formal verification then more properties so you shouldn't be like formal verification or no formal verification that's how I think it should be and but also you should have the full arsenal formal verification tools at your disposal if you really want to do heavy formal verification to specify absolutely everything and very fast with everything you should be able to but most of the tools should just be

consumers a formal verification techniques and we should all put an effort into educating the our clients how to use these tools themselves if as Auditors we should audit specifications not code that's what I think we should do I think that's a fantastic answer and this doesn't I'm now not talking exactly about smart contract verification but um a Cubist when we're working towards verifying um user policies we start with these invariants you're talking about and we can actually reuse them for fuzzing first then we can use them for lightweight static analysis and then one day we can actually build on them for full-on verification and we get like the benefit of that initial specification

throughout the lifetime of the code and we get stronger guarantees over time so we found that really really useful yeah I love the points about you know auditing specifications as well as you know just the code itself like I know of instances we had at maker where you know there was a bug in the code and the spec had just the exact same bug and so you needed another technique to catch that either review or unit test in that case there really should have been a unit test in that one but that leads me into another question I wanted to ask which is kind of like you know okay specifications and provers like these are yet more codes on top of the code we already have you know how can we have you know High trust and you know if the

software approver or the kvms you know spits out and says yeah the spec you know is accepted it's it looks good how can we trust that um you know what measures are necessary so I can answer about the circular approver so first of all it's really important as you said to review the specifications okay insertora we also offer tools but you can also have your own tools for instance to mutate the solidity code and just to make sure that if the solidity code as a bug then the specification finds it because sometimes this is not the case because as you said you can have a bug in the specification so this is this is a one option which is like to make muted the solidity code and

then another option and that this is something that also we truly believe in it is have as many people as possible to review the specification this is why we are doing like this contest in which like as as many people as possible are writing specifications and recently we're even awarding people for writing specifications because approver can be amazing but if the specifications are not good then the the the the security of the code will be as good as the specification so this is a very important thing and of course I truly recommend just to look at the violations I mean okay so if you have a violation let's just look at how it looks like

does it really represent a real example that can happen in your contract and another option also to look at the proof I mean we also offer a way to to look at the pets that were actually evaluated and this is something that we are working on and we really want to give to our customers but I'm sure that also other tools offer that so it's very important to as you said as you can think be paranoid about everything from the code itself to the specifications so this is my point of view on this yeah so debugging specifications and also

debugging verifiers in general is a very hard problem because you know verifiers tend to end up being a very complicated set of code I mean it's normally relatively large and it normally has a lot of dependencies because you've got an smt solver you might be trying to perform optimizations with abstract interpretation so there's a lot of areas where things can go wrong and so what's important at least in order to validate that your verifier is actually doing what you want it to is to have like a proper Benchmark set and I think right now most likely all of the companies that have verifiers have their own internal set of benchmarks I don't think that we really have a very good set of external benchmarks that everyone's evaluating on I mean in other areas

there are verifier competitions which we don't have in this area but I imagine every single company here has their own set of benchmarks that they're evaluating on internally and at least for us when we are checking to make sure the specifications that we write are correct we go through a very similar process where normally if something says verified then we start doing we we normally don't mutate the code but we mutate the specification and start changing the specification slightly to make sure that if we mutate the specification in particular ways we end up with expected counter examples so um oh sorry a bit loud uh so uh the techniques that we use at nethermind are

mostly based on interactive theorem proving so our trust base is the dependent type Checker of whatever proof assistant we're using typically the extractor because we'll have something some piece of code that extracts your code into into some version that lean or whatever proof assistant can use and of course actually the formal definition of the language inside of the proof assistant so for the the extractor typically it's a very simple piece of code there's a sort of a one-to-one mapping there obviously we set up very large uh test sets Etc but it's something simple enough that you know it's it's not considered to be too dangerous part of the trial space the dependent type Checker in our case we use mostly the lean proof assistant which has one of the largest corpuses of mathematics

being formalized into it so in terms of the amount of stuff that people throw at it to find bugs I think it's you know one of the better places to be and in terms of the formal specs we tend to of course make sure that all specifications for the languages formal definition is executable in some sort of way and therefore we can actually just like John described run it against some conformance tests do fuzz testing do a specification mutation all of these sorts of things to see if we get the expected so yeah similar situation um I've been in this field for 30 years maybe that revers my HPV and I've never seen

communities a formal methods people agreeing on a specification language so I think the only specification language I've seen probably the smt lib which is also used in the safety competitions other than that there are lots of tools for even for very simple formalisms like linear temporal logic which has only five constructs and different syntaxes different completely different names for the same thing um I think that would be a challenge um also for coming up with benchmarks for our tools and I take this opportunity to say that again all my years I've designed lots of specification languages and I approve

lots of theorems which turned out to be useless in the end it's very important to pick something simple that connects quickly to your audience mind and I confess that I really like tools like Foundry they are not formal verification tools by Design but they are excellent doors into the formal verification field so if you write smart contracts you should test and if you test you should go to the next level you should write property tests parametric tests and you should use fuzzing yes and then just push another button next to fuzzing symbolic execution formal verification and then you do form a verification

without you will realize you do formal verification and I want to actually maybe kill a myth there is a myth that property tests are weak you cannot express any properties so no that's incorrect actually property tester is powerful as whole logic preconditions called post condition assume code assert so you can write any word triple as a property test so it's not like they are not expressive enough they're expressive and they are practical and easy to use that should be the entry point I think that that we can build up on and I want to add on this I was just discussing with security people

actually hackers think by properties this is why it's very important that when you want to verify the security of your code you also need to think by property in order to to think about all the possible initial State and middle state that the the contract can get into because this is how like attackers eventually will think like so this is how we we want to protect our code so this is why I strongly agree with you and this is why I think it's a myth and I think that even if it's a myth we need like to to start doing that to make our code more secure I love it yeah I've personally experienced you know

thinking and variants or properties it's very powerful When developing and they also like you know the vision of it should just be something you know you just kind of do you've already written a test why shouldn't you get a way to formally prove things I know that yeah there are a number of of efforts along these lines I mean even at maker um Paulina actually gave the last talk right experimented with integrating symbolic uh execution into Foundry itself but this is actually a good lead into like the next question I wanted to ask because you know we aren't at this like you know Space Age future where you've just you know you've written some property tests and you know you just hit another button or you know run the right command and it's all automatically proven for you right now there are a lot

of different ways that projects can decide to apply formal verification you know they can hire a company to like write all the specs for them that company may or may not also be accompanying that with some sort of manual auditing effort they might you know use a SAS tool like and write the specs themselves they might do some sort of hybrid method where a company writes the specs for them but then they maintain them afterwards you know they can also do this earlier or later in the development process Etc so there are a lot of different ways projects can can use formal verification I'm wondering if the panelists have any thoughts on you know which ones are optimal or which ones they would recommend in different situations depending on the needs of the

project big question I know so feel free to collect your thoughts so developers definitely can and should be using formal verification like if they're right now we don't really have a button that can press in order to you know perform symbolic execution from Foundry but I know that's something runtime is working on and that would be something very powerful for developers but you know developers aren't going to have the security mindset and so really uh one thing is developers should try to do whatever they can to find bugs and

then after that it's the security Auditor's job to go in and basically try to exploit everything that they haven't and you know I am of the opinion that Auditors should be using tools like formal verification fuzzing and stuff like that in order to bring higher Assurance audits to their clients because all of those tools will one help uh you know the clients feel more let's say comfortable with the results of the audit but also it's something that clients can then keep and you know move in the future and or use in the future and so uh

yeah I think that essentially it's important for everyone to do whatever they can and I know that's not really a very satisfying answer developers should be using it they should be uh you know probably not using it quite as effectively as like security analysts but it's still useful and important to do and there are going to be people who are going to become very proficient at it and then for the properties that they're not able to verify because you know you eventually are going to have to fight with the solver at some point or something like that that's when a security company can step in and complete the form of verification and also review the specs that they have written and find the holes that they've missed because you know with some or

with most formal verifiers if they haven't thought of an edge case and none of their specifications Target that edge case then it's going to be missed I completely agree here the only addition that I would like to add is that um I don't think that formal verification needs to be done only once I mean probably like the the goal should be to have it in your CI because we actually so with our customers that the code gets changed and maybe they're working on another version of the same contract and things break like even the simpler invariants the simplest environment can break and this is something that actually a CI can be very helpful in detecting it because having

like the old code being audited again can be very expensive but once you had like the all in the whole process as you and you had like the whole specification then but very easy to just rerun the like any formal verification tool on the same specification to just make sure that nothing broke so as John said I think that I also think that should be like from the beginning to the end and baby also in the deployment itself I mean like I think it should be ideal to formally verify that also the deployed code a to the original specification because we thought before that something actually gets broken during the deployment so having made I think that

also we should even verify the code that it's deployed in the blockchain because it can be also very helpful there yeah I think that's a great point about you know verifying the actual deployed byte code because you know it is actually public you know you know you can't usually verify what's uh you know running on the servers you're interacting with but in ethereum you can all right so I think we've made the case to everyone that you know they should be using formal verification you know there are lots of options there are lots of ways to trust it um there are lots of ways to do it um

then how do we actually increase adoption of formal verification web 3 like I think it is steadily growing but you know not all projects are using it yet and you know what needs to happen I think we're already answered that question ease of use yeah I think there's one other facet here which is um we're doing pretty well on the smart contract front but there's a lot of other code that touches the ecosystem that is really really important um and also not formally verified and they're you know maybe we think of this as more of a web 2 problem it's like okay your key manager code that's just some Rust code or some C plus plus code

or whatever but that's really has to be right right or like your MPC wallet implementation that should not have bugs in it so I think more focus on the non-smart contract pieces of the ecosystem would really help everyone definitely agree there good I think that I agree here but I would like to add a point I think it's also we are like a community of formal verification and the thing that that it would be great like to motivate people on why it is important so like publish everything that it can be it can could actually was found it was actually found by former

verification so we need to educate also about the motivation and why formal verification is important and I think that like we are pretty sure about that here but probably the people the people in the ecosystem they're not they're uh they're not enough convinced yet so I think that like having like motivating can be like publishing things and explaining where it actually helped and in order to educate it more people about about why it's important yeah I think publicity can help a lot like the more bugs that are found with formal verification I think goes a long

way like the the talk from netnell earlier about finding the bug in prb math right I've audited code bases that use BRB math and usually you know you're told like oh don't worry about the math just focus on the business logic because you know the time is finite but you know it turns out you actually take a close look at that and write some specs oh there well there was some book in the math and you know that that's the best Marketing in my opinion all right I thought at this point I mean I can keep you know interrogating the panelists a bit but you know FV is you know mysterious um hard to understand I thought we'd open it up maybe and see if the audience had any questions and wanted to ask any there's one there

yeah at some point uh one of you guys mentioned that blockchain is a great place to try for notification because the code size is small but with all these like scalability stuff we expect that gold will actually hopefully at least in my vision should good as complex as a webto server uh well how does formal verification scale uh going ahead in the future yeah so code might get bigger code might or the the size of the contracts might increase but that doesn't necessarily mean that um I mean your transaction size might also be able to increase but really people have been able to do a lot with uh this kind of asynchronous model that we end up seeing here where you know in a lot of cases there's a lot of

functionality that you want to provide where you want to provide someone with an entry point that's going to be doing something very specific and so normally people are already I would say to my frustration designing code where you have an entry point it does something very complex it triggers like 20 actions and then that is just going to make things uh more dangerous so even though uh technically you know things might increase that also could end up having other side effects like making the ecosystem less safe I would say and not that it's necessarily safe now but uh I would be hesitant about having people write you know this really complicated

function where uh you know someone's going to be I don't know executing a million instructions in a single transaction I just don't think we're gonna also or I guess another way of putting it is um say if proofs get good enough that we can really scale to huge systems that means something fundamental has changed and the relationship between like proofs and verification is deep enough that probably means something has changed on verification too so and I guess another technique that we could use at that point is abstraction because I think that's an area that hasn't necessarily been explored that much in this particular area because for the most part we've been able to reason

very precisely about these things because of the code size but we can always abstract over contracts in order to perform larger verification which is what is kind of commonly done for larger systems anyway so formal verification is an old field has been used in many other domains before particularly in Hardware verification there are entire chips that have been formally verified and the key Insight not almost all instances or a formal verification was successful on large systems was compositional verification or divide and conquer split the system in components verify them independently and you can scale that way I think formal verification in the

blockchain space is just scratching the surface it just started there are Fields where very large programs have been formally verified already yeah so if I can add to that oh God sorry I'll get used to this um obviously we as I mentioned earlier we're verifying the uh risk zero ZK circuits and that is of the order of hundreds of thousands of constraints right and so a lot of the techniques that we've been talking about here would would not scale very well to this so once again we rely very very heavily on abstraction being able to break down things into sub-gadgets write specifications for them and then really in the end uh we're not when when we think about the high level circuit we're

not really reasoning about circuits at all anymore rather just how these specifications interact these human readable specifications interact and yeah so I think in ZK circuit verification particularly where you can have very very large circuits like this compositionality abstraction is incredibly important although at that in mind we do try and apply these same techniques to uh to a Smart contract verification too because yeah as we said you know they're getting bigger without another scaling Solutions so I think we're also in a good position where there's been a lot of verified software already and so we can build on what's already verified that's great it's kind of different from say the you know Os or

browser world or something where you have like millions and millions of lines of Legacy code none of which is verified and if you're just staring down that Behemoth it's like okay where do I I even with abstraction like good luck so we're in a much better beginning point so how does the the complexity and difficulty of formal verification compare to the difficulty of figuring out what you know actual humans are going to do with this system and how that's going to go wrong and and how to what's the relationship between spec rating for formal verification and working out what crazy thing a user will do that you know turns

out to be disastrous yeah there are some Works in that area where you combine you actually formalize humans and they they satisfy some physical constraints you cannot very quickly move your hand from here to here things like that but in general same like with verification in general you have symbolic variables and then you do constraint analysis humans can do stupid things and you have to take them into account but there are people who

do research in that area human computer interaction and have formal models of humans even of organs in humans like formal specification of your liver and they you know so yes thank you for the panel does it make sense to formally verify over component of the web with trigger system for instance blockchain clients definitely so uh yeah uh Julian and I both mentioned how we formally verify ZK circus all the time uh those can be integrated you know kind of in with the smart contract or it can be with the

blockchain and uh when it comes to formally verifying aspects of blockchains that's definitely important one of the first audits that we did actually we performed some like lightweight modeling and formal verification over that model of a blockchain because it can be really important to understand how monetary assets because again money makes people greedy and then hacks but how monetary assets are being exchanged because you can end up with really bad bugs in blockchains like double spin vulnerabilities and stuff like that and so again with a blockchain it gets a lot harder because it's bigger but that's where it comes down to isolating the critical components and then performing formal verification over

those critical components and then having a model of how other aspects of the system should interact with those and maybe not verifying but you could perform a more lightweight static analysis in order to ensure people are interacting with that component in a consistent and correct way um in the same level of thoughts is there some way that we can have a verification form of verification for economic models well I mean we can create invariants for codes but is it something that can be applicable to economic models or is this

something that is completely out of the scope actually this is something we do even more runtime verification than verifying actual code we work closely with our clients to formalize their business logic and then we prove properties about the models or consensus protocols you can prove properties about them like they don't Fork without even looking at any line of code yeah starting at the model level can be really important as well because if you're able to formally verify a model then that can actually be used to help formal verification in the future so if you can have specifications that describe the the model then when you

actually write the code you can actually reuse those specifications and then another thing is at least in this area if you have some sort of abstract model or some you know kind of high level model of what is going to hold one thing that we see pretty commonly is people mocking other contracts that you then have to formally verify against in some cases which can be dangerous because that might not be the actual behavior of the contract and so if you have some sort of model that you've performed formal verification on and you have verified that your underlying implementation is consistent with that it means that now other protocols can even make use of it to abstract away your specific behavior and then use that when they are developing their own

protocols which would interact with yours yeah I think in continuous cases you might have to accept some level of approximation because you know for example if you're really trying to address like a high level economic behavior like is my lending Market always solvent well you've got to model price Behavior you've got to make some assumptions about that like are you going to assume geometric Brownian motion well like that's not really true in practice right um and so you may be limited at some point by by assumptions but you know you can usually do something right hi uh thank you for a great panel um so I'm coming from the perspective of a smart contract developer and not a security auditor there are lots of different

types of tests to write so standard like unit tests fuzz tests invariant tests Etc and each of those comes with a certain model of uh how to like look at the code look at the design of the system and structure that test do you have any tips or general approaches towards extending testing from just that to using the symbolic tests of tools like almost or similar I think that it really depends on the language in which you are writing the specifications because for instance in territorial like the civilian language looks very similar to the solidity code and so it should be like I'm not saying that it's easy but it should be it should be quite intuitive to write the specification for one person who is

actually familiar with the solidity language so I think it really depends on the on the specification language and um so going from test to going to specifications is actually something very powerful and something that we use when we're developing uh specs for clients because tests end up encoding the intended Behavior normally you know there might be some edge cases that weren't considered but it at least gives you an idea of what the developers were thinking about and so a very easy way to go from test to let's say a property-based test is to instead of testing against a concrete value make that more of a symbolic value and now

you can use symbolic execution you could perform some sort of property-based testing and so just even removing those concrete values it can already get you part of the way to something more powerful than what you were starting with we've got about a minute left I wanted to sneak in one question of my own which is actually inspired by the previous but kind of flipped on its head so if you're writing detailed enough specification you're really getting into all the expected behaviors why do you actually have to write the code maybe you just write the specification and generate correct code from it is that is that science fiction or that's what program synthesis okay no that that's a separate field of study where uh you you write

the specification and then you have something generate a provably correct code and so uh issue my advisor is very interested in program synthesis but that will take longer to discuss so not feasible yet oh no it's feasible people do it all the time it's just uh it also has some scalability issues and so like one of my projects that I did a long time ago is I wrote a synthesizer that went from our specification to Smart contracts but I think to synthesize an erc20 circuit it took about four hours uh but you know that was something that I wrote in like a month so actually I'm a firm believer that people should not

write code they should write specifications and the code should be generated or actually when I before before being a professor I worked at Nasa as a research scientist for two years and what I've done was synthesis was schema-based synthesis and we generated very large programs thousands of lines of code I think the largest was 50 000 lines of C code and it was provably correct because the fragment of C provably correct from specifications for uh for a Markov models so it is durable especially for domain specific domains like smart contracts of a certain kind all right well that would be really cool anyway we're out of time so let's have a

round of applause for the panelists I think that concludes the formal verification portion we just look you know we got a break so get a coffee [Applause] oh no coffee apparently thank you so we are going to take a break till 2 40. and after that we'll go start with the panel on Bridges so see you back along

huh quick enough quick announcement if uh if you're one of the panelists on the bridges panel in and you're in the auditorium or downstairs please make your way to the front row so we're looking for Hugo from flare Network Irene from layer 0 Robert from autosec and uh

Valerian from Quant stamp so please yeah [Music] [Music]

foreign foreign [Music] [Music]

hmm ings thank you

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

okay [Music] [Music] thank you [Music] everybody

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

[Music] um

[Music] [Music] [Music] I don't care [Music] we are starting in a one minute please get ready I think so far and especially if you are attending remote so far it was a very

calm but now we're going to have some drama so get ready uh we're gonna have some drama we actually prepare these Partners we have actually two partners uh I think last year they were interesting I think this year they will be even more interesting uh we have the moderator so I see Moody is here for his first panel on the bridges and then after that there's a there will be a panel auditing during last year we know people there's uh companies doing auditing there's Community doing all these things their personal auditing so all of it will come together there will be a lot of drama get ready starting soon

can you bring your people 41. [Music] thank you [Music] foreign

thank you [Applause] [Applause] thank you

thank you hello everyone welcome to a fun panel on Bridges so we'll get started very soon but before that like let me throw in some introductions I'm madad Gupta I lead security and smart contracts at polygon and here we have a collection of interesting people so some of them you can see the names up there and we have a surprise entry in terms of Neve from hexagate and I guess I'll let everyone introduce themselves and talk a little bit about what they do hello everyone I'm yours again and I'm

working on two companies either fast uh I am take great at present network uh present network is optimistic and liquidity respiration focusing on ethereum layout day or two uh we support uh polygon arbitrum and optimism for mainnet and they will support uh any other reactor like linear and then base for testnet yeah and then we I I'm also uh technical advisor at uh Skyline Adventures which is japan-based RVC and then they are investments to they have Investments to Taiko which is uh DK VM and then they also have an investment

for Orbiter yeah yeah I'm very glad to be here and then thank you for giving me this opportunity hi thank you so much for having me my name is Irene I am head of strategy at layer zero Labs layer zero Labs is the creator of layer zero the protocol and omnichine interoperability protocol and Stargate the leading uh Native asset Bridge hey I'm Robert I help run auto sack we read a lot of bridge code yeah hi I'm Valerian I work for chronstop as an auditor and I made some audits on Bridges

hi I'm Hugo co-founder of flair network uh flares and evm layer 1 based around optimized data acquisition uh the reason I'm here is we've just released a bridge protocol called layer cake which is essentially follows an optimistic model but we think we've solved sort of or have good solutions for the griefing attack that comes along with optimistic models and the slashing issues that are very very hard to implement with optimistic models I can explain more later or you can go to our website flairlabs.org hello everyone and thanks music I'm Nev I'm the CTO and of hexagate we're a real-time web3 thread intelligence

company basically discovering all the threats and on multiple blockchains so we help protocols Bridges weapon essentially like any web3 developer to be able to detect and prevent any threat that might threaten the protocol or its users who are happy to be here thanks everyone for the intros we have a great set of panelists here I'll give everyone some context about this panel so everyone you see here most probably applied for a talk that was related to Bridges and then Molly was like Ah that's too mainstream let's put them all in a panel and let them fight let's have some fun let's have some drama and that's why we are

here so in like this 30 minutes of panel or whatever we can't really change the world but we can at least have fun so and that's the aim of this there is no scripted questions or anything it's just all gonna be from heart and hopefully we'll have fun and with that okay I'll shoot with first like a Kickstarter question I'll ask everyone for one Bridge uh they would recommend everyone to use and one Bridge they would recommend everyone to avoid I can start so I recommend everyone to avoid the multi-chain bridge following the last events and essentially like uh there are like

great widgets and I think they're quite unique in the way in the space in the sense that widgets are mainly off chain and that also brings a lot of opportunities to stop attacks because many times like you have a lot of time to protect before an exploit really happens of course like it Narrows down the attack surface and it doesn't mean there is no attack surface so all in all like there is uh both uh snark based Bridges like a ZK evm ones like polygon recently launched in uh it's obviously a great Innovation and consensus is also about to launch their theirs as well alongside like the optimistic ones which uh

and there are available which we've been using like extensively uh the ones from arbitrary and optimism and so on so all in all like uh they're great other Bridges which we're using like uh any day on hexagate yeah thanks for let's keep it like bullet points just one name to avoid one name to use I'm happy to go next I I'll say maybe a hot take but and to your point about reducing code exposure I would discourage Builders from integrating bridge aggregators and I would encourage people to use Stargate the most popular

native asset Bridge built on top of layer zero that's interesting so I'll come back to that but anyone else wants to pitch in okay I guess not then let's continue with this this is an interesting one uh why do you not recommend Bridge aggregators a few different reasons I think first one is around code exposure so uh with Bridge aggregators there's additional middleware that you're introducing there and on top of that you're also creating a basket of bridges and and thereby increasing the chances that one uh chart of it will lead to a hack and so if you're building a wallet for example it

might make sense for convenience to allow users to just sort of route to the fastest Bridge like in like an airline industry or those uh like flight aggregators I don't know what they're called price lines something like that but with bridging it shouldn't be an airline industry like security is actually a Paramount it's like don't take the the Jet Blue uh when you're transferring your funds and then I think the the other primary reason I would talk about is Services versus protocols a protocol is something that is immutable an evergreen open permissionless a service requires the Creator company to maintain the Integrity of the product and so if in

your infrastructure stack you're leveraging something that requires the liveness of that company it requires the founder to not be arrested it requires uh the devs to not get covered uh then you know you're building in a lot of dependency into your product and even things like is a service that you're leveraging uh does it require a significant amount of Runway will they close their series a in crypto we see a lot of projects that just poof and like the slat connect is gone because they've run out of funds and so you should be leveraging true protocols and ones that are not dependent on the Integrity of human behavior but also the liveness of a Creator company

FairPoint I wish I had someone from bridge aggregator here would have been a fun conversation but those are very valid points to like since we anyone wants to defend Bridge aggregators here go ahead um Yes actually this is something that we've started decent amount about um I think I guess generally when we think about these sorts of bridge aggregators um you have like some sort of like n Bridges and then you know you choose some threshold of the amount of bridges to sign um before you know you you pass some sort of message through right so for example if you want to optimize for like really fast messaging maybe you have like one out of n um you know if you want to optimize for for like um authenticity of messages maybe you

have like N Out of n or like n minus one out of n or like you know two-thirds of n Over N um and I think one difficult part you know I kind of I kind of agree with Irene like in the status quo I think right now you know there's not that many super legitimate Bridges um and I think one difficulty is that like you know n is probably going to be something small right like n is going to be like three or five or something and it's pretty difficult to to find you know maybe like seven or ten really reputable bridges that you can even put in some sort of aggregator set um and I think one difficulty there is like if you have you know only three Bridges you know if you have a 2003 that doesn't really give you a super

meaningful Improvement in security right I mean I think there's like two things you want to optimize for one is like passing correct messages the other is making sure that you don't expose yourself to unassured analysis risk right so if you have like a three out of three multi-sig for example or three out of c three out of three aggregator um you know if one of the bridges go down as Irene mentioned then uh your entire set goes down which is probably not great right so you probably want something like 203 or three out of five um that being said you know I think as more bridges um develop and they become more mature I feel like if we get to the threshold where we have like Seven Bridges that we're really confident about um maybe something like a 4x7 what let's say or even a three out of five could

make sense right you know if you're a four to seven three three of those bridges could go down and we still preserve you know critical properties of liveness and safety um and you know I think that gives you a lot better guarantees than if you just have one Bridge it might be hard to know which one um to use even though there's like you know a lot of relatively solid ones um this way you're kind of just like spreading out the risk it makes sense I for one like I'm not a hater of bridge aggregators I actually use them they're super cool but in a in a different way so I don't um as I reinvesting like integrating with the bridge aggregators is um I think risky at least right now the way I use them is like to search for the bridge that actually supports from where I want to

go like I want to go from this weird chain X from this weird chain B and like there is I have no idea which Bridge actually supports it like layer 0 maybe but probably not every these are two weird chains so I just go to the bridge aggregator and then it tells me like which all bridges actually support this path and then I can choose the best one I can go there directly and do it so it's a good like certain Discovery like I will say there is a huge green space or white space for a tool like this and even myself when I'm doing like daily diligence on different Pathways I have so many tabs open at once but then with bridge aggregators I will say there are oftentimes issues with the data that they're actually pulling there and I

think every other day we are in conversation with these teams about how to fine tune that yeah for sure they'll get better but yeah there's something there they can work on uh okay moving on to the next question so as we have seen like bridges are a technology that has that is constantly under attack especially now there are the last few big hacks in this space have been all related to Bridges multi-chain Nomad Ronin uh Harmony all of these Bridge like over 100 million dollar hacks so to the folks here on the panel on the bridges that are left not many are left but among the ones that are left uh and even the ones that have recently gone on what common weaknesses

do you see like what what problems do you see in the bridges right now the biggest fear I have for Bridges is uh essentially criminal charges over the essentially what a bridge is the majority of the bridge models maybe exclude optimistic maybe exclude layer zero but certainly the multi-sig base Bridges so there's essentially uh it could be painted as a conspiracy to transmit funds that have not been uh you know vetted and to me I think you know with the SEC losing you know pretty heavily against uh you know Ripple I

think that another Vector of attack is more sort of criminally based around money transmission without um without compliance um it's a weakness but it's also a consequence of a trade-off I would say that uh if a protocol wants to increase the security of some parts they would have to increase the centralization for instance and the instant realizations have some positive effects in terms of security over the whole system but in the other way it has also some drawbacks and

a lot of bridges have some weaknesses based on the components used but in as a in from another perspective we can also consider this as a choice a design choice and we have to be aware of the all the components of the bridge before trying to using it and maybe another comment from my end is that I don't really view Bridges as some unique creature like substantially from D5 protocols but only the fact this is there's only the fact that there normally are in charge of like casting lots of

funds because like they connect chains together and this is why they become so lucrative to attackers and the fact they're like a bit more of a complex it makes them much more interesting for attackers like to actually research because in a different protocols eventually like you've got a you have like a few Primitives that you can work with the protocol on a bridge you have so much so much more and many of the attacks that you've mentioned would it is uh were around like even private key compromises and that's only like just web 2 kind of threats for Bridges and this is because like the the team has probably haven't figured a way like to actually operate the bridge in a decentralized and more secure manner

whatever just like have those keys like there's a non-secure way so I would say like just really hard to Cluster like vulnerabilities on Bridges but whatever say that the attack surface is so vast as opposed to it's just vast as opposed to the different protocols so it just can be anything like private Keys managing possibly like the bridge all the possibly Merkel proof that can be like validated in the wrong Manner and then possibly tokens can be attacked as well because and then you get like unbacked uh uh an unboxed minting and and so on they were just like so

composable in their nature so it makes them the attack surface just bigger I have a feeling Robert will probably speak to this as well uh we've used ottersec for for audits but to your point around the the risk vectors for for Bridges being similar to just general protocols the majority of bridge hacks over the last year were due to Smart contract upgrades and largely made by protocol developers who were intending to introduce something that was positive like a new feature or patching something and so if you're using upgradable contracts to build a bridge you are introducing all of the protocols that have integrated your Bridge or all of the users to the the risk of like widespread contagion in the

same way that you would never accept an upgrade push to your treasure or to your Ledger why would you do the same for your D5 protocol you should be able to to opt into it and those contracts should be immutable and so that was something that really informed how we designed the layers air protocol how do you design a messaging protocol that is entirely comprised of immutable smart contracts but also enables Evolution with research over time with with better validation techniques since what we're using today should not and will not be what we use five to ten years from now and then to your point around uh my fellow panelists Point around uh like government crackdowns and things like

that also designing a bridge or messaging protocol to be censorship resistant for example from from day one and comprised again built with immutable smart contracts guarantees that your technology cannot then comply with or be perverted to fit into different regulatory environments if you build your technology in a way so that it can it will be but if you create these Primitives that are Evergreen and simply cannot then they won't um I guess I'd kind of just can I ask a question or can I disagree with people yeah sure okay um yes I guess one thing one thing on the legal risk uh I think one of my I think you mentioned like the legal risk right um I I guess I wanted to clarify a

little bit when you say legal risk are you saying that bridges are too centralized because there's like one entity that that is exposed to all of this legal risk or is it um like Bridges as a whole like if you send funds Earthly like the entire Bridge can be taken I know I I think it's essentially uh I think Irene's comment between the protocol and the service provision right which is you know if you look at you know a multi-sick bridge you have some set that have come together in some manner usually without you know a decentralized process to come together usually an agreement between each other that is if those people are transferring funds across chain that are essentially

from a rot in the source that could very easily be painted as a conspiracy to launder money I think that makes sense yeah for sure that's a definitely an interesting risk vector and for sure the governments have their eyes on that but us being more experts in the tech let's uh move on to the tech questions so I'll ask that like on Bridges it's true like there are different types of bridges not all bridges are same I broadly categorize them in three categories centralized MPC Bridges and then the decentralized bridges which work on proofs and so on um so on that the MPC Bridges have seen

lots of hack recently with multi-chain for example like turns out all of their keys were with one person even though claim they claim to be MPC similarly with uh with Ronin uh they were MPC but five by nine and four of them were one entity and that entity also had access to the fifth so again just one centralized player and similar thing with Harmony so an open question here from a technology perspective that how would you uh guarantee or trust uh an MPC bridge that they are actually using the proper uh MPC technology and aren't just hiding behind MPC as a like as a wall

um I think we should add some redundancy at the level of the communicator so between to change the communicator has a role to watch his to do to watch what happens on the source chain to verify if it's a malicious or a normal request and then to relay on the destination and the NPC is only one communicator and I think if we could add different Technologies concurrence and to make a kind of meta MPC with two out of three different

protocols or different solutions maybe we could have a better and more secure way to communicate and to relay the messages however I think it it would come with more commissions because more people would be um involved however the risk of collision would be lower mentioned yeah I mean I feel like this question is I guess more about like how do we ensure decentralization of any validator set right like I think you know the root cause of these hacks I don't think was like NPC I think it was that you know the CEO had all of the

validators on his personal AWS account and you know like once the guy got that got arrested it seemed like you know that was a single point of failure um I mean I feel like this is a pretty hard problem right it's like you know you can you can attest and I think multi-chain did a test in fact that they had you know a relatively independent validators that when we asked them I think they claim that they only own like seven out of 22 of the validators um but you know I think it's really up to to the community or people to like dig into the identity of these values and try to ensure that they are like indeed independent entities that are you know hopefully reputable um and and have their own control right because I think otherwise it's pretty hard like from a pure technology

standpoint like only looking at the chain I think it's essentially impossible to determine that like the end user of these eoas or of these private keys are actually different um you know it requires some off-chain sleeping or some additional analysis that you know to to paint a more complete picture I would just add that Amazon mechanism I've seen uh more or less uh implemented by the next solution of chain link is to have the the actors playing the role of the communicator split it in two roles one that is doing the communication uh part and one that is doing the verification that the

community is a validator are doing the right job or not and it's like a level of verification inside the verification components I think that approach of separating the roles and having two concurrent role both instant device to act in favor of the protocol could be a solution yeah um yeah I kind of agree I kind of disagree I mean I think that like at the end of the day you have like data from one chain and you want to get to another right and then like however you slice it you have you know different parties attesting that data and then you want to like you know in abstract that you want to like take some aggregate set of those

signatures and then come to some sort of conclusion about if that data passing is valid right so I think you know you could split it up in two you'd have like two different roles and you know maybe like one set needs to agree and then others also needs to agree and maybe that mitigates for us somehow um but you know I I think that still kind of runs into the same issue of like if everything's centralized you know you're still screwed but I don't think it really fundamentally solves the problem you know you could slice up to three roles like maybe you have like three different stages like one person proposes another person like approves and then the final person executes right um but does that really change anything like I think kind of at the end of the day if we're using these Bridges we

really need to dig deep and kind of understand like are these actually separate entities or are they just like depending or masquerading to be yeah I'll add one thing which again is more from the smart contract risk angle rather than the human engineering side which is that client diversity matters a lot as well we talk about it in very different contexts like ethereum uh validator context but in this case if a bridge has you know requires 13 out of of 19 validators to agree but all the validators leverage ultimately like the same code are created by the same Dev company than the vulnerabilities that are introduced into one are like multiplied across all of those and so

that's incredibly important to keep in mind as well and some of the architectures that exist right now don't actually encourage client diversity or aren't open and permissionless to allow other protocols to run some of these off-chain components and actively participate in their security layer that's a very interesting point so uh on that like how does layer 0 promote client diversity so is it's interesting that you were talking about chain link and their architecture ours is is slightly different layer zero deploys endpoints on all of the chains which we support so these are EVMS naughty VMS rollups apps chains Etc these endpoints are smart contract libraries and these are

immutable between the endpoints are the off-chain entities which we call the oracles plural and relayers plural and all in Oracle has to be is an entity which can retrieve and submit a block hash and all a relayer has to be is an entity that can retrieve and submit a transaction proof so there are you know two separate tasks that need to be put into play the protocol determines which oracles and relayers they select and of the oracle's Consortium it could be three out of five it could be two out of three that have to form a let's say like a yes from the Oracle side and same with the the relayer side the protocol can run one of those components meaning the protocol could run every layer of the

relay Consortium and one of the oracles could be let's say the top 50 delegates of their protocol and provide more utility to their protocol token in this way and uh it's the message can only pass across the protocol if both the oracles and relayers Consortium form an agreement otherwise if one of those consortiums disagrees the message reverts so this is sort of you know base uh security layer here and allows applications to price their their security as they'd like so if you're building a game and you're transacting five cent nfts between chains it might make sense to use you know the custom chain link Don that was built for layer zero and the layer zero Labs relayer but

if your circle and uh you are moving usdc between chains as an omni chain token you probably want to price your security a lot higher you might want to run one of those components yourself uh you may pull in a highly reputable entity to run one of these relayers and you can add on in more as you'd like if you're a decentralized protocol then your governance can vote to add more or swap in and out oracles or relayers based off their liveness and their performance that is is how we encourage client diversity each of these entities are built by different Dev companies and uh it's in the hands of of the application to to price uh therefore layer 0 is the

line of uh security there makes sense that's super nice so security with Bridges like it with everything it's a continuous process so we have discussed a lot about things you can do really before launching the bridges or like at any moment of time but there is one aspect which is monitoring and incident response which you gotta pay attention to once you have launched the code once uh everything is live so on that aspect an open question to everyone uh first of all like maybe let's start with the good things this time so any Bridge you are seeing right now which is doing something right any example you can share so well

um any bridge that is doing monitoring or incident response right or any protocol in general yeah so nobody is doing interaction yeah so I think like uh maybe this circles back to the recommendation part where you ask like for recommended videos so obviously there is a spectrum and obviously teams with less Personnel would have like less capacity to handle like security processes and all of that and when you have like bigger teams which like uh develop a bridge like they have much more capacity in order like to initiate like the right security processes the right like incident response plan the right monitoring in place like mapping

all the threats and monitoring for them so of course like there is a when we like I I don't like this term like the diligence Bridge because eventually like the ux has to be abstracted and it really depends on what what change you wanna uh move from uh but for instance like if you take uh big companies like running Bridges like normally what you see is that they're really minded about security uh and then the employee like things like monitoring incident response uh in and mapping out invariants in order like to look for those invariants in real time and so on and uh from our experience with working with uh with

Bridges like uh what we normally see uh when it Bridges like incorporated into securing the bridge like they work with us we map out like all the all the known threats like for instance just given an example like if you're running even a layer or two like which I treat like 32 to layer one token bridge if if it's doing like a zika evm or a type of bridge it's a very complex technology like for just a few Auditors to just audit and and include snark is okay like the arithmetics are okay and all the circuits are just makes sense and if the bridge is that huge it makes obviously a huge

opportunity for attackers to actually research that and find a vulnerability so for instance like mapping all those threats as a as a as a company operating a bridge and then monitoring for what happens if someone finds a vulnerability in the snark like without knowing what the vulnerability is like maybe we can monitor when the snark validation breaks so what we see as a company is that like normally when you mature and you grow like those big companies like like a polygon and others when they launch new stuff like that normally they also are really minded for monitoring mapping all those known threats monitoring for the unknown threats and

uh and so on so I think and this is kind of uh a quick way to do a diligence of who is like have the capacity and security Personnel to actually run an incident response plan and like security like the right security processes you know to protect the bridge yeah can I yeah yeah I've always been like a little skeptical of monitoring I mean I think like do you really care if like you really want people to tell you that you've lost five million dollars or would you like rather not lose five million dollars in the first place right like I think monitoring is kind of funny because it's like oh after we got hacked okay now we know that we lost 100 million dollars but it's like okay it's kind of late now right um you know I think Bridges

um I think there are like meaningful mitigations Bridgers can do I just don't know if they're on the monitoring side like for example one thing I think layer zero does and a couple other Bridges is I'm having some sort of rate limit on the total amount of withdrawals I think this this is pretty intuitive right like if you know if we have some sort of you know random chain it probably doesn't need to be sending 50 million dollars back to ethereum mainnet right like you know where does that money come from um I think there's a lot of sane mitigations in terms of rate limits that you know probably make more sense that could help mitigate you know even in the case of say a relay compromise um or like some sort of endpoint compromise on the other chain you know at least you can limit the amount of

Damages and I feel like that goes a really long way um as opposed to you know having some sort of monitoring setup that's like okay we lost 30 30 million dollars but that can lead now yeah maybe a small comment from my end on the monitoring side so like there are there is a spectrum from monitoring like so uh from our perspective like when we monitor stuff like our goal is eventually to detect the threat like beforehand so uh in the case of bridges like many times like it really depends on the bridge like many times especially for Builders because there is an off-chain component and sometimes there is a delay before anything happens and also like there is sometimes a natural delay for attackers when they deploy just the attack code the contract which gives like opportunity for companies

like us to detect the threat up front but in but again in bridges like you have much more opportunity to also detect fronts detect threats before they impact any digital assets like for example if you monitor like for a bridge which does like a multi-sig kind of uh uh signing so many times like before withdrawal is even possible like you could monitor like whenever the multi stick has concluded that some with some withdrawals is possible for example [Music] there are like there are many examples of multi-stick bridges which like do that and if you're monitored like in real time the fact that uh something

that is going to happen before like the malicious visual happens then you're able given like the right processes because it's Inseparable from monitoring you're able to mitigate the threat so monitoring can take like three like we're aiming for pre-hack okay I think we're talking about similar things then I guess you're talking about like monitoring as the transaction goes to the bridge and not like after it like lands on the other side um yeah not like I can so yeah go ahead so I think uh probably bridges that are trusted probably need a lot of uh monitoring because you know as we've basically been discussing this entire most of this conversation is how do you make a trusted Bridge uh essentially as

decentralized and least trusted as possible whilst it's still trusted um but when it comes to something like an optimistic Bridge you still need quite a lot of monitoring specifically to monitor you know are people submitting fraud proofs um you know and because if if a malicious event is is um you know missed your you know your window is finite one thing that we had observed and learned from with a lot of these Bridge hacks was you know issues with accounting for example that that show up in uh how these smart contracts are written and so we created something called pre-crime and we actually don't talk about it very much but I will do moving forward since we are working to

scale this so that it protects all applications that have integrated layer zero pre-crime is a proprietary security module which Forks every message that goes across the protocol and tests it locally against a set of invariants determined by the application only then do the messages get pushed back and run across mainnet and it's called pre-crime to stop a hack before it happens and so that invariant could be uh like accounting around avoiding the double spend problem it could also be you know if you're an nft project and integrating layer 0 to enable seamless movement native movement between chains it could just be like whitelisted addresses whatever you'd like for that invariant to be as the application developer and this is what has protected Stargate since launch more than a year

and a half ago through its peak of 4.4 billion in tvl the whole team just watching every single black hat attacker try and break the protocol this is what protected it and then in addition to Robert's point about great limiting which we have introduced when we launched the Aptos bridge for the new non-evm layer one last fall we decided to adjust the block confirmations and set them to be incredibly high it was you know arduous it took about three days for transfers out of Aptos however that was the security measure we took because it was a new chain and there were a lot of unknowns over time we've been producing those block confirmations but you know

one thing that layer zero enables and we built into the protocol was ownership of the application developer to determine those block confirmations and so if you're trying to avoid uh like reworks involved with a particular chain you might want to set those higher uh if again pricing your risk if you're just transacting five cent nfts maybe you set all of the block information is really low and that's okay 100 makes sense monitoring is like a lot more obviously than just detecting a hack once it has happened so uh yeah obviously like once the hack has already happened then detecting it is not as uh important at least for the protocol but monitoring is a lot more than that especially for Bridges where there is a

time delay between the transaction initiation and settlement you can intercept a malicious transaction uh in between that time so for optimistic rollups as mentioned like you need fraud proofs so someone needs to be generating everything happening on the chain to generate these fraud proofs for uh like other Bridges you can monitor uh smart contracts being deployed that might try to create malicious messages to your protocols and things like that so there are a bunch of monitoring uh tooling that is definitely important uh and even like oftentimes you can white hack during a hack a good idea example would be Nomad Bridge so Nomad Bridge was like

slowly hacked over Ours by many parties it was kick-started by I believe it was a black cat I don't remember if the return defines or not but and then like a bunch of white hats kicked in and started uh rescuing what they can so that only uh like if they had even better they had some monitoring and that's why like all of this they could respond in time but if you work on monitoring more maybe you have uh playbooks defined some automation around this that like kicks off automatically when something is detected then maybe you can act faster save more funds um and so on so it is important and this reminds me of a interesting war room

story I had and um I think we will let's start discussing some War Room stories ideally around Bridges but whatever comes to your mind I'll start with this one which is related to monitoring and why it's important so in this space lots of people not just Protocols are monitoring the chain for malicious transactions and I guess we have only one minute so I'll uh round off this story really quick but there is one one group which monitors for hacks so that they can short the token and make money so what they do is they I won't go into specifics of how they do it because uh like that that's also a secret sauce for them let's say but if they detect

anything that is about to go wrong they will short the token if something doesn't go wrong and now their short position is whatever they will reach out the protocol tell them hey like we detected this in your protocol have a look so it's a very interesting ideology which is like sustainable so I I was in one war room where they detected something and then nothing happened so they reached out to the protocol uh within like 10 minutes that hey we directed this but your protocol hasn't been drained yet the protocol without understanding what this is immediately uh blocked immediately pause the protocol as their response which is good at this point they only had a contract address which was Private source code um and all they knew was this contract

has been deployed by a malicious address a known malicious address and it interacts with their contracts so at this point they don't know if it's a hack or they are just using the protocol but they pass it and then we spent next one hour decompiling the contract understanding what it does and it turns out it indeed was an active attack that they were gonna pull off nobody knows why the attacker didn't execute the transaction maybe they were testing it um maybe gas was too high that was expensive times or whatever but they deployed the exact like the attack contract but didn't executed yet and within like one hour this team although detected by someone else but was able to

pause the protocol fixed the vulnerability and save all of the tvl they had so monitoring can be important just because like in this space although everything can be instantaneous it usually isn't people do things one by one like it's still being run by Immature kids like most of the hacks are being done by mature people if I'm being honest so you still have time to respond and that's why it's important before we uh wind up uh so I'll leave it open for like final comments if anyone has like really short 30 seconds maybe monitoring I think uh it is important to have a mechanism that can minimize the

uh damage even your smart contract other expert or hacked because uh like yeah okay yeah I think as a community we really should focus on Building trustless Bridges not making trusted Bridges safer oh that's solid so we have next panel on auditing I'll warm up the audience with an auditing question fun question here so everyone uh we started by asking everyone like name your favorite bridge and least favorite Bridge let's do it for Auditors name your favorite auditor and least favorite auditor

go ahead I can give a shout out to some Auditors and I'm super lucky to have uh like personal relationships with a bunch of them one sitting next to me which is Robert from ottersack uh we're also a huge fan of the zelik team the zokyo team uh Paladin team and always looking for more one thing I'm super proud of at layer zero is we have spent more money on audits across every single protocol in crypto uh so we're in you know tens of millions at this point and we are happy to keep spending money on audits every piece of code we push is immutable and even if it's four lines of code we will get multiple audits so if you're an auditor and you also want to be my friend come find me anyone else wants to name anyone

I guess not then we'll uh round it up here thanks everyone for being on the panel and thank you for the audience thank you [Applause] hi everybody I think this is the panel that you always have been waiting for so get ready uh stay calm it'll be fun I think there won't be Blood let's see

uh the panel is actually uh I think it's very different it's a bit different than last year I think we want to make it more like uh not just audit but more community versus audit and we have Rajiv here from secure well who is actually inspired this panel and will be motivating it yes so we shared this one sure yeah

all right yeah thank you muli and thanks to mudit for uh for the Segway and the spicy appetizer so um so yeah so I'm Rajiv the founder of securium um just to set the context we'll assume that most of you are familiar with what audits are but the topic of this panel is the flavors of audits right so audits have been around for a while and recently we have seen different flavors in terms of who performs the audits many other attributes as well so we're going

to focus on sort of a high level question of conventional Audits and the community oriented ones or the competitive ones right so but before we start off we have a fantastic set of panelists here um would like to request all of them to introduce themselves and their projects before we kick this off um my name is Hari one of the co-founders of spirit um previously I was working at the ethereum foundation building the sorority language and the compiler um yeah that's it co-founder of consensus diligence been operating for almost seven years now

mostly services off chain on chain a lot of tools as well for others symbolic execution engines so on and so forth and also we have a stealth thing well kind of stuff that it's called Creed that is coming out so that's cool hey everyone my name is Medi co-founder and director of Sigma Prime we are a blockchain security firm been around for about eight years doing a lot of small contract Security reviews but a bunch of L1 l2s and bridges and whatnot we're also the founders and maintainers of Lighthouse the rust implementation of the ethereum consensus layer currently responsible for about 35 of the user marketer hey guys I'm Jack Sanford uh one of the co-founders of Sherlock and Sherlock has

been around for about two and a half years we are a smart contract coverage protocol as well as in an auditor hey everyone I'm Rosner feis I'm the engineering director of the blockchain team at 12 bits thank you we got a Poverty of mics over here no no it's okay we're all good we're we'll share my name is Mitchell Amador I'm the founder and CEO of immunify immunifies the major the biggest bug Bounty platform in crypto so you know these specifically these Define Unchained exploits are bread and butter um everything we do is about making projects safe post post deployment and that ends up being a lot of things but uh bug bounties is always the name of

the game hey there uh sock from uh code Arena one of the um Founders and first uh first handful of people in the Discord on day one um the uh code arena is a uh creator of the competitive audit and um we've just really been focused on creating as many opportunities for people in the field to level up and to create as many opportunities for uh protocols to achieve a greater level of security at a more efficient rate than um than a traditional audit awesome so let's maybe level set a bit more so audits we just use the term we

may want to use reviews or assessments but I think we're just stuck with it at least for for this panel and maybe a few more years but what do audits mean to each of you right for each of your projects your missions because the way we see it we may think of audits as something the protocols may think of may have different expectations the users may have a totally different you know zero bug expectations so what do audits mean to each one of you and also what's conventional or unconventional about each of your approaches I think that'll be a good start and we can we can go around for this question because each of you is very

unique so maybe start with the you want to start on that side the Poor Side of mics well I mean the the reality is that you know I think actually there was a talk that uh Mitchell gave at uh trustex last year and was talking about the fact that bug bounties are really the um absolute last line of defense when it comes to security and the idea that um uh that in fact it it is an indicator of the immaturity of the space in general that like we have so much that's secured by bug bounties and I think in in reality I would actually extend that a

little farther and say that an audit actually should be the last line of defense that uh a bug Bounty is a break glass in case of emergency you know at the point that you're that you know kind of the going rate is maybe 10 of user funds uh that you're you're maybe overspending at that point in terms of what you might want to to spend and so an audit is intending to prevent at the you know last bit the as many bugs as you can from uh reaching production so that's the main thing that I see but it's actually an assessment of what you've been doing from day one when it comes to security okay so I mean you're you're totally right just to call out that one

particular point about the whole movie is this is move Left Right In traditional security right always move farther up the stack earlier in the process more and more preventative but if you feel that way about bug bounties you should see what people say about their auditor spend of course I think we've all spent a lot certainly I have and we we don't really have a a choice about that matter the reality of the fact is it's impossible to create secure software and and we've decided to put the most valuable things in the world in a extremely kind of finicky young immature technology stack we're like yeah this is a good plan and by the way let's move the entirety of the world economy on here while we're at it so under these conditions where we have the highest possible security needs and we just don't have enough time we don't

have enough people we don't have enough anything like you know what is what is an audit is just another type of code review right we have our internal tooling inside which is ideally in an Ideal World we would we would have tools or we would hire people and they would just find everything and life would be good and then we would never need any external code review but that doesn't work right for reasons that we all understand and so then we go to the layer of external code review and that begins the process and usually typically best practice teams will start with a traditional audit right which you're going to have highly expert people from highly vetted firms who've been doing this for you just just phenomenal phenomenal Engineers who will help you not just look for vulnerabilities in your code but say Hey you know is the

architecture here wise you know are you you're getting boxed into such and such choices have you you know foreseen the second third fourth order consequences of that and from there right then we have the the remainder of the flow right the new types of audits which I think are very very exciting and then bug bounties which is really just another type of code review right it's you could think of it as another type of audit but really it's the action of like of let us review this code and this the entirety of this infrastructure with the scope widening and widening widening as you get more and more closer to production let us review this and see if we can find anything that allows us to break the assumptions in such a way that causes you know irreparable harm to the mission of that protocol which in our

case of course is theft of money or damage of valuable assets yeah so if we if we think about what are our goals what are the things we are trying to achieve you know with like this Security review or audits um or you know list type of things from a traditional review for better lack of of term what we are really trying to achieve that we are trying to help developers to understand where they are at what are like the risk they have what Alex they are aware they should invest in terms of security and to achieve this goal we have a couple of things to do first one is going to be you know to look for vulnerabilities and that's the most obvious one but a lot of the work that we actually do during Security review is

to advise developer to tell them look here you have a systematic risk in the where you are designing your component maybe you know try to refactor it in this way maybe you know create like a single component for this like you know multi-component step maybe improve your documentation on this specific aspect so a lot of the work we do is really about helping and kind of filling the Gap with respect to the current maturity of the client and with respect to the risk they might have um that's interesting I would actually disagree with that I think the core there's only one thing you really care about in an audit and that is finding problems that will cause losses for

users like making sure whatever this protocol is supposed to do it does it well and it doesn't cause massive amounts or even a material amount of fund loss for users um and that should be the the main goal and gas optimizations informational you know findings that kind of stuff is great but it's not core to what an audit is um I even think of fixed review Sherlock includes a fixed review after every audit we do but I don't think that's core either um the core thing is did you find as many of the problems that could cause losses for users in that code base at the commit you were given as possible

um and to answer the second question what is the conventional or unconventional approach of Sherlock Sherlock is kind of The Best of Both Worlds so we have a foot in Both Worlds we have the conventional auditing approach where we reserve Auditors pay them a fixed amount of money to show up and do an audit and we also include an audit contest component um and yeah I mean in terms of the title of this panel conventional versus Community which one is better Sherlock thinks they're both absolutely essential to conducting a good audit and you need both of them and Sherlock is

the only one that actually has both of them um and part of my talk at 5 20. later today if anyone is interested is going through the last year of seeing which of those two parties found more vulnerabilities over the last year in Sherlock audits like who has been carrying their weight I guess between the conventional and Community side so stay tuned for that I'd be very interested to come to your talk because um I wonder how you were able to qualify the number of critical findings High severity findings that a firm like my my firm or trail of bits firm or Gonzalez firm has uh has been has been doing over

the past year just just because it's very difficult for us to publish some of our work right so it's oh yeah I'm just curious about your data collection method but I'll rock up in a few hours good looks like we are warming up see you in the audience a bit cold as well so um yeah sorry just circling back to everything that was said I don't disagree with anything that you guys have said I think everything makes sense um the way we tackle security audits at cqp is the traditional way their time box security assessments you got to think as well that not everyone's willing to spend you know hundreds of thousands of dollars on a Security

review right and in some cases people come to us and they're like hey we're cast strapped but could you work with us it's difficult to say no right especially if the project is interesting uh the team is you know Keen to work with you so in those cases you know we may allocate a couple of weeks um but everyone knows that's nowhere near enough to dive into everything to dive into every single component that makes up the platform so um I'd be hesitant to say you know we we shouldn't be working with these people we should only be conducting assessments when they're 100 thorough because circling back to what was said um earlier I believe that it's just

important to give feedback whenever you're ready for feedback right you may be conducting a bunch of experiments you may be trying out a whole bunch of features you don't necessarily know what's going to land in production but at some point you decide to take a snapshot of your development and reach out to one of us and that's absolutely fine right but this is again the disconnection in expectations right what does what do users expect from audit reports what do protocol teams expect from audit reports and this is a fight I've been fighting for way too long now where you know degen's out there would take this guy's reports and say yep cool sounds good to me I've only

seen you know a couple of lows couple of informationals there you go I can dump a whole bunch of money into this stuff right well have you even looked at the executive summary have you even looked at what you know trail of bits or Sigma prime or any other firm has actually looked at so it's a bit frustrating sometimes and you know some of that narrative has been relayed by you know some some people here and it's every time I see that on Twitter I'm just it's not helping it's not helping but all right I'll stop bitching for a bit um I'll answer the question uh what is an audit for me it's a checklist so I think this part like we've talked about it so many times we don't do audit that's the first thing maybe D5 safety

does audits we we don't we never did second I don't think bug bounties are our audits at all and and I'm glad that we go that we're calling it in the panel conventional versus Community Audits and nomenclature kind of doesn't matter because I can call a table whatever I want right like if I have a name for it and we all agree that that's what we call it that's fine but they are not audits in the or or Security reviews they they are a completely different thing I'm not saying that they don't have a place in the in the stack of security procedures that you should do to your project but they're not on it's the same way that uh Community audits are not audits so code arena is a bunch of people doing solo reviews that are then aggregated which is not the same

thing as a team doing a Security review so what we call them from now on kind of matters I think we should all have a like a group discussion the same way that we had for like um not calling these things Audits and their security reviews they should probably have the same conversation going forward for all of these things and uh but I guess like Sherlock's still winning because you know in different places we're winning yeah thank you yeah for spear but our approach has been to combine the best elements from all of these people uh we bring like some of

the best uh independent talent to then collaborate um on Security reviews um we try to incentivize them and we have a more of a Marketplace model where you know we just take a 20 fee um on top and some of the best researchers enjoy working with us because you know we are more fairer we try to like our collaborative approach like ends up like finding uh deep issues even and out of outer scope dependencies um yeah and and I do disagree with one thing by um the Sherlock which is I think while I agree that the end goal is to minimize the number of user losses you

can't really get there without focusing early on on like core architectural issues we do also focus on that I think the safer the safest Protocols are the ones that are like very well designed um so yeah we need to cover that as well yeah it looks like I just want to respond um I I want to go back to what my colleague from from Sherlock was saying because I kind of disagree um with a statement that what only matters are the bugs finding the bug is obviously really really important it's you know like you want to prevent loss of funds but that's not sufficient what's going to happen like in practice where developers are going to continue

to develop the software they are going to make like a new version they're going to iterate over it and if you want to kind of you know increase your security if you want to be in a better posture you need to understand how to build better software and to understand how to build better software is not just by getting a list of finding because a list of finding is not going to be that informative in the long term that's why having all this information I mean all this feedback about design about component about like structure tests is really important in the long term finding the bugs are only going to help you in the short term but not in the next iterative in the iteration of your protocol not like in the in the long term thinking and if we want to kind of

win as a security Community it's really important to focus on on you know all the suspect can I have a quick uh yeah so I actually yeah it's still disagree I think that um like sock was saying we want to make audits the last line of defense the audit is really expensive and it's something that you're trying to do at a point in time so that you can get your code safely to mainnet and helping a protocol team during its development you know helping with the architectural design that kind of thing that's really great that's super important but that's called Consulting in my opinion and the audit is a specific thing to find the problems in the code base

with the intention of having that code base go to mainnet probably soon you can ask just just one question because I really don't know Jack what what how does Sherlock work because I really don't know this is a genuine question like do you like if I'm a customer and I come to you what's the order of things that happens like what's the user flow do you um do you do the security review first and then you put up my code for a code contest all inside Sherlock are they different services do you do them always both for a certain client yeah so the right time to come to Sherlock and that we kind of recommend is is having it be your your last audit and that's because we find you know some other audits are more on the Consulting

side or whatever and maybe the code base isn't quite ready and Sherlock is really like the most intense audit I think you can get and the findings the amount of findings that come out of it are sometimes unmanageable for protocol teams um so we think of the audit as that last piece right before you're going to mainnet and a lot of protocol teams don't actually have a good experience because they think that it's maybe something else and they aren't ready for all of the you know findings that come out of they weren't ready for the final exam basically um and so Sherlock kind of thinks itself as the final exam before you go to mainnet before we add the smart contract coverage on mainnet and to answer your question

the contest piece happens alongside the kind of reserved auditor piece so it was happening at the exact same time and the reserved you know we could call them more conventional auditing model with those reserved Auditors are actually competing against the contest participants so both sides are kind of extra incentivized in that in that sense and it always happens you don't sell the services separately um we do not we have not sold the services separately as far as I know yeah so I think this is great I think we may be too deep into the space so we're probably making assumptions that people know how Sherlock works or how C4 works so that that was sort of the point of

the first question maybe you know maybe starting with sock can you take maybe 30 seconds and explain how C4 works it used to work in a you know in a certain way maybe two years ago but it has evolved right there are a whole bunch of services that you guys offer and same with Sherlock and we do by the way if you didn't realize so we do have the convention quote unquote the conventional bucket would be trailer beds Sigma Prime and diligence because they have been around for a while doing different things um and the the community one is again sort of a loaded term there is a contest base which is Sherlock and code Arena but then we also we have spear bit which is not entirely well it's a hybrid it's

a hybrid model so we you guys understand this but maybe not all of us can you take 30 seconds to explain that sure so code arena is uh a competitive audit which means that people show up in order to review as you know as much uh you know to review the code in the time that they're provided and find as many bugs as they can the compensation for those bugs works on a Model that was designed by Scott Lewis and Zach Cole um and the model is essentially that the more rare the bug is the more severe the bug is uh the higher the payout and the bugs are judged by independent uh experts

many of these originally were people who we sourced throughout the community Nick Johnson was our second judge after Zach Cole and had a number of folks just kind of come through on recommendation but today most of those are people who have competed in code Arena and have moved their way into the ranks of of being a judge the thing that we have added over time is uh We've in the course of in the course code Arena one of the things that I think is pretty essential as a piece that Karina contributes is I think until uh really until kotorina came around one there wasn't really a good way for people to

identify who were good solo Auditors and what the talent pool looked like in general there were people who out there were out there doing solo audit audits but there weren't necessarily people who could establish uh you know their talent in that in that same way um you know the the other piece that I think is a key contribution is the fact that you have coding has really driven down the price of uh well-known bugs and we see that all the time in competition where people who compete and have read all of the reports because one of the things that we also did from the very beginning was we put all the reports public we put all the code public so that people who wanted to learn could go

back and compare their results with uh the others who they competed against but as a result of that people studied those and things that six months ago would have been worth uh you know ten thousand dollars or a thousand dollars uh that you know there are times when those bugs are only worth a dollar uh and the first time I saw that I kind of freaked out about it frankly and uh I was having a conversation with Scott Lewis and he's like no that's the algorithm working like we want to pay as little as we can for bugs that are well known when people have not added any additional marginal value in finding those bugs that's a success it means that we've actually educated more of the market on how to identify those bugs and then we're

putting more energy into finding the harder more interesting ones and I think that is something that coderina in general has really helped to Pioneer for the space just in that openness in that process of learning um and that's something that we're really focused on the other piece that that is a part of the process that exists today uh as a result of that is we started doing bot races where people who are building uh um automated tools in order to identify findings are able to compete prior to the audit begins uh prior to the beginning on it so that way we sort of get those things out of the way and we have some really great Bots that have uh actually started to identify more and

more findings in the course of the um in the in the course of of competing but the nice thing about that is then every single auditor who's competing gets access to that report in advance of competing and those are all identified as known issues right so we're we're now not seeing uh we don't have to have everybody submit the same bug you know a hundred times in order to reduce the value of it to its appropriate amount because many times if they're that findable they're that they're usually more identifiable by uh bot so you know a big part of what we're trying to do and is really identify talent and help talent to show up in all the various areas for that same reason we recently added analyzes which are intended to

bring out the expertise of individuals who have more of a consultative view and are able to be when booking as solo are able to be uh taken in by protocols as a security advisor and that's a big part of where we see and why we are investing in uh really the profiles that we've built recently on the site and and enabling people to book solo engagements through the site because we do want to get people earlier in the process from an expertise perspective so there's a lot of elements to it but there's some anyone else wants to add to that um yeah I guess I'll go next since our

approach is uh similar to code Arena so the way to think about a audit contest is a protocol team has some code and they say here's a thousand here's a hundred thousand dollars and you can think of it sort of like anyone in the world can come get this hundred thousand dollars by finding bugs in a code base um and of course multiple people will show up to try to do that so then you want to split that hundred thousand dollars between different people and the way it gets split is by who finds the most severe bugs who finds the most bugs and how many other people found those bugs how rare they are and that's pretty much you know there's an algorithm that kind

of helps determine who gets paid what um out of basically anyone in the world who can come and try to find those bugs and you know we see code Arena sees 200 300 400 people compete in contests uh from all around the world and yeah you just find a lot of crazy things when that happens you find a lot of bugs that might otherwise get missed when that happens um and Sherlock also layers on a more traditional approach as well where we reserve one or two top Auditors who we know are very good and have proved themselves over time they're at the top of Sherlock's leaderboard and we make sure that they're going to show up and also participate in that contest and if they don't do well

they'll fall down the leaderboard someone will take their spots they're highly incentivized but we just want to make sure that there's you know a high level of quality in every audit like a default level of quality in every audit so we kind of combine that traditional piece as well they help with the Fix reviews some of these other things that you might expect in an in an audit and that's how Sherlock works just with those two so we have a foot kind of in both worlds on this panel how did you want to add yeah I'm sure our approach is like three different things um one we are like highly collaborative and the second one is we want to bring really the best talent to look into your code base and the third thing um

um of course is we believe in like multiple eyes uh being better we we want like you know four to five people looking into the same chord uh multiple times so that we can be sure that in a lot of the vulnerabilities are caught um do you behave as a Marketplace Harry can I choose who I who I get yeah you can yeah okay um I guess for the three traditional um players out there um uh correct me if I'm wrong feel free to chime in if I'm not representing our side of the industry well but uh you reach out to trail of bits intense diligence Sigma Prime and you kick off a sales process right um if you reach out to Sigma Prime you

get to talk to me usually and I go through a scoping exercise right you share with me your code base and I start going through every single contract in the case of you know solidity evm stuff that you would like to see reviewed and we essentially estimate how much time it would take for a team to perform a review to provide a decent level of security Assurance so for cgp we always include testing in our approach that's perhaps that might be a little differentiator between our other friends but um so for each component you'll have person days for a manual review and

person days for testing and testing can be done in different Frameworks you know Foundry Forge or brownie or um you know we don't really dabble in JavaScript but yeah um yeah and then we give you a proposal take a look at the proposal give you the timeline obviously the earliest we can get the job done and I guess an interesting part of the job is for us to be able to spot within our team the right members for that particular Target it's very important right I've got team members who have reviewed perhaps as of today for liquid stacking derivatives right they're across you know all of them most of them if not all of them so when I get a

request from a client who's building a liquid staking protocol I'm gonna obviously do my best to assign that protocol to the testers that have that level of experience we can Circle back later on on how we train people how we make sure that the knowledge is spread across the team but yeah that's essentially it you know we are a services company so if you're if you're happy with that we uh we then get started and kick things off and produce produce a report and a test Suite that you essentially uh yeah is yours you can do with it as you see fit yeah like I agree with everything I just want to take it back to the stack just

if we're trying to get people to understand I'd say that like I and this is my personal preference I I heard different things today but like I think that you have the manual review on top then you have the code contest Below in the bug body like the only Undisputed 100 market share that we have here today is Mitchell like I basically refer everybody to immunify right like bug bodies are completely Undisputed then we might have I don't know like a choice between maybe Sherlock and um in the code Arena or maybe not because Sherlock is integrated so it's monolithic and then you have us and so if any of these entry points I guess like the the five entry points over here because like spear which is also an

entry point it's probably the first people that you would contact right I wouldn't go talk to Mitchell first that's probably the end game so let's let's put Mitchell on the spot Mitchell if you had a protocol on your bug Bounty who which of these when vendors would you recommend well I'm in a rough spot today but um it could be all six you know so so actually this is a question that we have thought a lot about we get recommendations and I was you know pondering to myself as I was listening like should I give the audience this this particular model that we've developed for looking at the situation which is you know while these things all seem like oh you know here are Audits and you know there's all these different

types and flavors to choose from who's the best the way we look at it is that there are very specific things to prioritize the different parts of the stack so to be quite Frank you know I would not I would avoid I would you know if I was you know CSO or equivalent security lead at a project and they were asking me how do we want to allocate spend here we need to build out the ideal security setup you know what are you going to do Mitchell well I'm gonna and they're going to say hey do you want to work with with with C4 they got like bot races and so many people I'd be like no absolutely not that's a horrible decision uh not because it's not a very useful service in fact it's an excellent service at a certain stage of the life

cycle but that's not my problem right as I finish my internal review process so after I've made as many Investments I could on the internal side so that's hiring my security Engineers that's investing in tooling that's documenting the hell out of our stuff that's building you know a good secure code development processes as I can that's you know threat modeling after I've done all those Investments which are not you know primarily monetary but time then I want to bring my outputs right the outputs of my work to whatever degree is possible to the finest possible mind I can imagine okay and it needs to be and I need to pair that with my you know my finest possible mind and I need them both to attack what we have and see where it lands and to be quite Frank while I am like truly the most Pro

crowdsourcing person here maybe not truly but I'm trying to be uh I would absolutely go to one of the private firms first so I would go to a consensus diligence I would go to a trailer I would go to Sigma Prime I might also go to a spear bit but I think there are some questions you know that I'm trying to answer about their service before I can have that conviction right there's something excellent about them but it's not clear that they bring the level of comprehensive expertise that I would want at that initial engagement because that's where I'm having these architecture discussions right that's where I'm throwing them against my my engineering team and saying here's very expensive people we pay to tell you that you did everything wrong and we're going to have to go back and fix it all thanks man it's a good thing we got this now

and I and I'm not really going to I can only get that from an extremely you know impart someone whose brand is both expertise impartiality and you know awareness deep expertise up and down the stack broad it's got to be everything they have to have the whole world view they got to be smarter than me and the the firms that are most likely to have that Talent quite frankly are the traditional audit firms because they can best allocate resources to best attract that talent and structure their whole brand Mission and and the life of their their business around that that's something that the the crowdsource businesses will never be able to do right because we we have to select for a different set of conditions and priors in order to build a compelling product so I say that right would definitely

pick one of those now I don't want to name names specifically because then the other ones will beat me up uh but I want to make a note about spear bit in that so what's my doubt with Spirit like Spirit has this interesting model where they have effectively been capturing the top end of the the audit contest kind of population and many of the Auditors and it's great right they've they've taken kind of that that model in a in a Cost Plus fashion and just drove in it as far as they can they can they can pay big wages to people while giving them a lot of freedom and giving them and by freedom I mean you know they can do whatever they want they're not necessarily on contract to go and do the most interesting work I mean it's a it's it's a great deal but

is that right in my first initial engagement when I have to say architectural stage My First Security review and hopefully the most important are those people going to have enough sophistication are they going to be process driven enough are they going to have discipline right and I need to I need discipline really bad at this first engagement I don't know if that's true and that's my doubt about whether Spirit can service that if they do that's would be super exciting but that's an open question I need discipline I need process Excellence you know beyond what I have and I'm you know a guy who invests in best practices on exactly that looking past that now I have new needs for Audits and and for context to unify with any of the stuff that we do on chain which we do we always do multiple audits okay now my priorities are

beginning to shift so I may want to go with a younger firm that is you know more of an attacker's mindset from there I can tolerate less discipline if I know that they're really creative and so you know a great example of that is hacker founded firms okay hacker founded firms are crazy and that's why they can make great attackers but not alone because they can't be relied upon to get broad coverage of the potential issues only towards the end of this stage right you can see I might pick from a few different options only towards the end of the stage am I going to look at a a audit contest like the element where I'm really just you know throwing eyeballs hopefully as high skilled as possible but I'm throwing eyeballs at my code base to see if they can find what's left but knowing that

it's like I can't know I can't have any expectations that they're going to find everything I can't have any expectations that they have deep expertise you know it's a gig economy kind of stuff it's it's open doors and hopefully it's the best type of it but the reality is there are limited quality controls on it and so it's at that time that I'm like more eyeballs the better right and and I would do you know I'm very interested in that I think it's hopefully will eventually become a normal practice in our industry to get these multiple rounds of reviews this way so that you get the benefit of Top Class Minds on every major deployment and you get the benefits of you know the best creativity you can muster and you get the benefits of just lots and lots of eyeballs covering best practices that

would be phenomenal but it's very expensive all right well I I want to just answer the this favorite question there um we do provide like security across the entire stack um all the way from like you know early engineering uh we have a service called vcso um you can hire like one of our leading secure researcher to like in a work couple of hours a week uh over your entire entire dialogue development cycle to have like a gut check and give you like advice on on how to like architect the protocol in fact many times we have completely like re-architected uh work with clients to completely like

re-architect the protocol to make it simpler and much more secure by doing this um yeah so if you are building protocols today like talk with us right away we can you know help you build much better contracts so it can be like you know secure by Design almost hey so can we have like content and case studies on there sorry can you repeat can we have content and case studies on exactly that for sure for sure and I would love to to see that in public right because there's an open question like you know in a lot of ways you guys are cherry picking some Top Class talent that that could work out well this way but discipline discipline there's no replacement for that can you guarantee that rigor can you guarantee that Excellence you know beyond just someone can sure they can

find lots of vulnerabilities I can find you know lots of hackers like that that would not make good Auditors at all and certainly couldn't do what I'm describing right the the skill sets are not co-extensive with one another so I would love to see case studies uh White on the internet for anybody to see about your how you went and you re-architected something that would just be marvelous yeah for sure and very valuable very informative yeah I mean we have like architecture protocols to like you know just a single contracts um they were like pretty new to solidity and they were just you know architect or like contracts as if it was a webto app and this is the wrong mindset to like build uh things in in solidity um aren't you worried about the churn of talent like there's people just dropping out have you ever wished you could hire

someone uh I actually think our approach decreases turn we talk with a lot of secure researchers that work in traditional audit firms they're pretty much burned out working you know um four weeks out of a month uh 52 weeks perhaps um we we only recommend people to work two to three weeks in a month a lot of our Auditors they enjoy like researching uh as an example like I tell this uh like hiccup is probably sitting here he spends like two weeks uh doing Audits and the other two weeks he likes to learn CK uh this is something we truly encourage our Auditors to work on and we think this decreases like churn we speak with so many people who are like

completely burned out from working in a traditional firm and you know we like to avoid that yeah burnout is real burnout is real and it's to be taken very seriously [Music] um yeah we've had obviously occurrences of people burning up myself included and it's very important to keep a finger on the pulse of every single team member you have on your team and the way we try to do it at cqp is to allocate a bit of time between each review obviously you know every time djans decide that it's a bull market you know our inboxes explode and some of our team members are sometimes a bit stretched but um yeah this is this is a major point

and um we're obviously always looking for ways to do better um and you know hopefully you know I'm listening to my team and they're they're the you know the best people to give me feedback on how we run things uh but yeah I just wanted to say that it's everyone's responsibility as well to you know keep keep an eye on the work-life balance uh it's it's super important um because if we're all burn out then you know all of this is is for nothing so um you know check on yourselves check on your friends make sure that you know you prioritize your well-being above anything else because at the end of the day you know that's what really matters

so just to make sure I understand spare bit model um when they do like research and things like that are they paid or yes okay our top researchers make 20K a week um on base uh some projects pay even more um so they're very well compensated sorry sorry yeah I don't think that's that's the question the question is when they're not doing engagements when they're off for those two weeks are they paid uh no they're not but they are paid very well on the one the weeks they are working so they don't have to I think it's an important point because you know our trail of bits or engineer on average I'll build 50 of the time so over a year they are going to generate revenue for

six months what they do outside of that they are going to be paid but they are going to work on public goods they are going to work on tours like you know Sleater cerns are going to work on guidelines are going to work on presentation in addition to that a lot of the workers are going to do that they are going to Shadow at it this means that they are going to participate in an audit which is outside of their way of expertise but they are going to learn and they are not going to be built to the client uh this gives them like you know a huge kind of growth opportunity where for example you might be an experienced heredity you might be really really good at solidity but you have no experience in Cairo you have no experience in Western you want to learn

uh by you know shadowing like an audit with expire invest or in car or whatever you are going to learn a lot so it's definitely like some kind of benefit that people might not realize but you are going to get by you know working on this type of company um yeah same thing intelligence but but I have so many questions for you and like the churn one was not exactly what you answered so what do you do if someone doesn't pay you enough to pay the lead security auditor do you reject the work yes yeah you just say no yeah we say no to a lot of clients we we like I said I know when we see a client we do like we give our genuine feedback on what should be done um we tell them this is already you know

you have to like re-architect the whole thing and if they say no we don't really work with them uh okay and well you also don't care about deal flow because like you only pay people when they work so you don't have to guarantee to you don't give any guarantees to people and when I talked about churn I'm I was more interested in hearing how what's the bounce back rate like do people keep coming to spear oh yeah of course once once they get a taste of spirit there is no going back [Applause] good good what's up yep well I just wanted to jump in on uh something so I'm actually wearing a shirt from him I actually come from a traditional audit background

there's a firm that uh I ran with a partner who's here uh years ago and working with traditional Auditors one of the things that I know is the case is you know you talk about the question of discipline you talk about the question of what it is to show up and work and the fact is that traditional Auditors working in a traditional firm in a traditional process have off days and they do honestly because of just the nature of uh our the nature of our uh our capitalist Society they do push themselves well past where their ability to perform uh May necessarily be um appropriate so in terms of also by

which I mean they get burned out yeah yeah right obviously yeah yeah so if you talk about burnout yeah yeah exactly right so the thing that the thing that I see and absolutely love about the competitive model is the fact that there's a great quote from a guy named Peter block and community means always knowing that someone else is going to be there and that's one of the things that I think is absolutely fundamental to the way that code Arena Works in that it's not all on those individuals the the weight on individual Auditors and I'm talking about in web 2 when we were dealing with far less dire circumstances the weight on those individual Auditors was so significant I know many people

who burned out doing that after a few years just in web 2. in web3 it's even more even more intense and frankly most of the people that I know who work in and as Auditors work in the field and as Auditors they're conscientious people who actually care a lot about what they're doing and why and so when I look at the question part of the reason that I love the competitive model is that it removes the level of intensity and pressure on those individuals for things that really do matter let me quickly take back the mic for a second so I think we have less than 10 minutes left really yeah we're just getting started but we have only five minutes maybe left

so I think we've so can we just React to what what this is very important five seconds I was gonna say that like here I think that it's that is a fair that is a fair commentary but I think you're like we're thinking about like consultancy groups that are huge right like the typically that happens in euis mckinsey's we were just talking about this the other day we work more like Boutique shops right like um so there's a way way way bigger amount of care for the people that work in a 20 to 100 person team than there is in like a huge Behemoth of of a company right and and the the flip side to what you were saying about the community thing and I do agree with you look the

community is always there but we are a group of vetted people not everybody goes into consensus villages we take huge pride in the people that are in there right like where is Carolina like Mitchell was saying like it's they're always there it's just different it's just different and I agree with you some people time people's burn out this room is full of people who are absolutely amazing who got their start at code Arena and they're disciplined and they're amazing incredible Auditors I just want to react to one thing you said I I'm a big fan of code Areno um um you know the traditional side often recommend my clients to go and run contests one thing that people should keep in mind is that you're not hiring when you go to trail of bits diligence or Sigma Prime you're not hiring a

specific auditor you're leveraging the entire team and that's extremely important the quality assurance that goes through those engagements is Second To None like I've I've come from the traditional web security background as well and the level of QA that was done then was nothing compared to the stuff that we do and I know for a fact a couple of other people here do the same so I I have to you have to go to the next question I know we can keep reacting and overreacting maybe I was going to fire a torpedo but let's let's continue that so I I think by now we have level set context set people understand the different models all of us including so if let's sort of switch right if there

were one thing for the conventional guys that you like about the the community approaches and vice versa what would that be I mean you said you love C4 why is that last year Mitch said that last time we were the bottleneck the Auditors were the bottleneck to go to market like it was ridiculous right you couldn't get anything done within like six months nine months and I'm really thankful for everyone here for all the Alternatives that we can provide to the community and I think it's a great thing you don't have to wait six months three months to get feedback you can get feedback within days weeks sometimes right and and this to me is a really really good good thing this yeah timeliness pricing there's so

many things yeah Jocelyn yeah I think it's a greater so like learning opportunities for a lot of you know people that are newcomer and and wants to kind of try their skills um but there is a bet um I do think that people that are starting in the security space and go through kodawana Sherlock or other might focus on solidity security but might lack some Awareness on the spectrum of security and you know I might make a couple of friends here but we are a security event if you work around like with whom you are going to see a lot of independent researcher that look at their laptop

they don't have you know screen protector they look at sensitive information they are like 600 people at this event like most likely you are going to have uh you know government agency malicious sector working around and the fact that some of the basic operational security are not followed by a lot of people are disturbance it's kind of a signal to me that there is some lack of you know training in terms of security that's when you are in a competitive environment you might not get easily yeah I love them for all the reasons that I that I wouldn't pick diligence right like I said like the same thing that is a pro is also a con in in my view like you'll sometimes will have

scheduling issues like sometimes we we won't be able to attribute the individual person that you want because like that's just not the way but the way we work and if that's your need if that's your specific need maybe just need that one person that you really like maybe then you should go to Spirit but and then you should still do coloring and then you should still do bug bodies they're completely different so all of the things that you wouldn't use us for that's why you should what about the other side I just want to like uh follow up to Jocelyn I think training is like very important in the space are not just for like auditing films but across the ecosystem um in fact Spirit hosted the very first Foundry seminar um shout out to Nason and Brock for helping out with that uh

with that I think this seminar alone like to our seminar on Border like you know thousands of security searches and and projects like um building uh stuff and I firmly believe like today it's uh easier than ever to like build secure contracts um in fact it's easier to write a fast test in solidity today than in any other like programming languages ever um it just it's just a matter of like adding an extra argument to your functions it's easier to do for modification in in solidity than in any other language today I think the tooling is you know tooling keeps improving and you know we believe like we invest a lot in education there's like weekly talks you can go to youtube.com

to see like what's what's happening um so yeah that's it so Sherlock and C4 is a thing from the conventional space that you would like yeah I mean I think on the tooling side a lot of these firms up here have done incredible incredible things for the entire space in an open source way in a way that just benefits everybody and that's actually like if you look at what they've all built it's really really impressive um and I think another thing that they do well is um kind of going back to Mitchell's Point um I think they're really good at the Consulting side you know when you are maybe not ready yet for that final exam they can help you get prepared and they can help you you know design some things and have conversations about different

ways of structuring something um that I think are really really beneficial and you know that's not a knock like you want to have a you know a professor or like a midterm or some quizzes before you get to the final exam and then I think you know the Sherlock maybe the code Arena are sort of better structured to be that final exam where you have hundreds of people looking for bugs in the code um you know Sherlock reserves two top hackers uh in the world basically to look at the code alongside those other hundred people um and so I think you know both have a really important place in the space if you can afford multiple audits hold on you think Auditors are hackers I don't know about that man

oh the auditor hacker yeah debate I I don't know about that I don't know but I'm just saying but do I have to answer because I like everybody you know you know so the long and short of it is I am I mean I always loved working with the Auditors first they drove me nuts in the old days because I was like why are we doing this this way and then I then I you know experienced some of those problems like I'm so happy you guys are around and then with these these new crowdsource security products and by the way we're really only scratching the surface there's new techniques being developed there's new companies in the making there's there's new like what we're starting to see is the formation of a sub stack right within that territory just as there was a stack

within audits depending on the type of firm and the type of value proposition they focused on we're starting to see a sub stack emerge on the competitive audit side and that's I mean I'm over the moon for that in terms of the value it's going to provide uh to customers in terms of the value it's going to provide to users in terms of the opportunities it's going to create for everybody here it it's just right there but we should remember right we are I always say this in the best way it's not enough it doesn't matter we are dealing with the most hostile you know possible environment I have criticisms for the approach of every single model here some of which would be pretty biting I think and yet I am so excited for them to grow and expand and in fact we need more of

them because you know the dream is to put trillions of dollars through this infrastructure and to hit those bars you need to max out right the quality of security product that you deliver on every single measure I think some people get that the layer zero is describing their spend amounts and I was like yeah that sounds about right you know they understand they understand the seriousness of this game so I am incredibly excited you know despite all the limitations all the arguments all the you know friendly or unfriendly competition I hope all these things proliferate and we need more right calling out to the audience here if you have an idea if you want to create something if you want to contribute something we do not have enough as it is we need more Innovation we need more scale we need more participation and believe me certainly

at immunify but I also believe all my compatriots here would love to work with you and help you push these things Farther Along fantastic it sounds like we're just getting started but we're out of time so uh we should we should give at least a minute we have a break coming up so um but maybe we can give some time for the audience I'm sure they have a lot of burning questions foreign do you have non-competes with your Auditors uh how you protect that people cannot go directly to you Auditors this is first and second how much fees do you

keep to your company so that you run your operations from the uh is if no if it's a secret please don't tell it but it's very interesting to know we are extremely open very few Secrets here um we don't have any on competes we we want to incentivize the best people to work with us and we don't want to like tie them down um that's fundamental to our business model and our fees is like one of the lowest here we just charge 20 percent um the rest of it goes to the Auditors and that's how we incentivize some of the best people to come work for us do we have time for one more no okay

yes just a quick question and maybe a quicker response okay then the quick one is going to be if you don't have non-competes do you have ndas sorry could you could yeah with the clients and the Auditors but not with the Auditors yeah both of them we do have NTS yeah all right thank you so you'll find all these people uh for the rest of the evening hopefully so we now have a 15-minute coffee break but please feel uh please be back after that we have a whole set of focus talks [Music]

foreign [Music] [Music] [Music]

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

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

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

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

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

[Music] [Music] [Music] [Music] [Music] [Applause]

[Music] remember [Music] Waters [Music] it's very very useless

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

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

foreign [Applause]

foreign [Applause] [Music] [Music]

thank you everyone welcome back we are about to get started where an interesting set of focused talks first up we have run crypto fish from Electric Capital he's gonna talk about state of audits [Applause]

hi um I'm Ryan I'm an engineer at Electric Capital and today I'll be walking through the state of audits so smart contracts are are unique in a sense that it's kind of one of the first cases where we have all of the production code predominantly open source and transparent and running on chain so what you get is this massive graph of cross-contract dependencies and Rich data that is really valuable for both users and security researchers however one of the difficulties is publicly linking the con the contracts with the audit histories which actually we believe will make protocols safer to

use and easier for security researchers to dig into potential cross-contract impacts but today there's a problem with the audit space because there's a large gap between Audits and deployed contracts because in the workflow of Engineers and smart contract developers today audits happen pre-deployment but most of the users what they actually care about is the contract that's on chain and linking the gap between the deployed contracts and the audit reports that were done pre-deployment is extremely expensive and we actually find that a lot of security researchers they spend the majority of their time reconciling

commits with deployments instead of looking for bugs so as a result we we went out and we collected pretty much every other report on ethereum since 2018 in ethereum D5 and we open source this in the first version of the crypto audits mapping we collected other reports of a representative sample of ethereum D5 representing greater than 92 percent of ethereum TBL since 2018 but just collecting these other reports is very challenging there isn't a very clean or easy process to do so because if you start off at D5 llama what ends up happening is you end up going to the protocol website sometimes you go back

to the auditor website but eventually around 71 of these audit reports end up living on GitHub but these other Reports most of these other reports today are in an unstructured format they're predominantly PDFs which means parsing them and extracting information valuable information from these other reports is actually quite costly so we tried out using so we built embeddings across these PDFs using gpt4 and we subsequently asked a series of classification type questions such as what is the name of the auditor can you give me the critical risk findings but more importantly for us we were

really looking to link the audit reports with the contracts that are deployed on chain and more importantly the repositories in themselves one one of the interesting findings that we found which is should be pretty common sense is that the larger the TV of the protocol the more audits attend these protocols tend to get with protocols larger than 1.1 billion in tvl averaging around 10.6 audits with a median of round four audits so protocols into space are are get are are using audits but we think that there is still this gap between the other reports and themselves the GitHub repositories and the actual deployed contracts

luckily most other reports have references to a git repo or a commit hash so that solves the first link but it gets a little bit Messier when you actually try to as a user of D5 protocols to link audit reports with the actual deploy contracts because one thing that tends to happen is you tend to get a lot of audit drift between the time of the audit and the code that's actually deployed with only with less than two percent of audit reports actually referencing the deployment addresses and that's really concerning from a user perspective and it really highlights this large gap in the current workflow between audits happening pre-deployment but most of the users only really caring about what's

actually deployed on chain because that's what's actually customing the value and as a result we kind of see that most users instead of referencing audit reports or really reading the audit reports in themselves they end up falling back to a measure of lindiness of a protocol to determine if it's secure and whether it fits secure enough for them to put their money into so a user might look at a chart like a tvl chart like Lido and say okay this is a protocol it's been around for two and a half years it's custody in 15 billion dollars if I'm putting in 10 million 25 million probably okay because I'm assuming that everyone else has done their homework

and this is actually the thought process that goes through a lot of the users in the D5 side because it's so expensive and difficult to make the tie between the other report and the actual code that's deployed on chain we can we can view smart contracts as custodians of assets and live bug bounties smart contracts either are directly directly custodying assets for example an LP token a lending protocol a yield management protocol or they're indirectly customing assets through wallet approvals and because these contracts cut back because of the assets are a massive bug Bounty the longer the implementation of

the smart contracts is lied for the more Lindy they become but the most important thing is that what we're trying to come up with a metric that defines how Lindy a certain protocol is it's important that we reset that Lindy metric whenever a smart con whenever the protocol upgrades its smart contracts and they actually do quite a lot so here's a simple example of a protocol that that launches at time Step Zero gain some TBL kind of flat lines but issues to upgrades from a traditional user's perspective they'll look at that tvl line on the left and they'll think okay um this protocol has been around for a while like they're gaining tvl and

but but the problem is that with the upgrades the lindiness of the protocol actually resets to zero so let's get into I guess a bit of a spicy territory let's walk through an example of a defy lending protocol most users will look at a chart like this things seem pretty good this protocol is custodying 100 to 200 million dollars in assets that kind of equates to a bug Bounty of 100 and 100 to 200 million dollars that's been live for a year and it looks pretty good but when we actually dig into the code so here I'm using Code slaw.app I can dig in find the smart contract and I realize that it actually implements proxy logic that's actually not standard

ID code the relevant storage variables from the contract and I pull the history so for this I'm using tokenflow.live which is uh evm data provider and what we see is that this protocol actually has a lot quite a lot of updates at the top of the table you can see the initial deployment as the as the storage in the contract is being set from zero to the to the initial logic but then subsequently you get a lot of module and proxy upgrades because protocols do upgrade quite a lot especially if they're very early stage and if we overlay the upgrades with the tvl we can see we can start to see the issue of just relying on the TVO line as lindiness

so you can see that near December of last year there was an upgrade that subsequently led to the exploit but even after that upgrade was pushed another 150 million dollars went into this protocol before it was subsequently exploited and then they pause the protocol by issuing another upgrade most users will just take the line on the left the integral TV all as perceived lindiness but the security actually resets at every proxy upgrade giving this more Jagged chart we don't want to give credit when there's new implementation logic but we think that there is a lot of room for improvement on the audit side and that the current state of audit reports and the lack of linking between audit

reports and deploy contracts is not the future we think that the future of audits is probably an audit metadata protocol this isn't a new problem that the web hasn't faced before and they're examples such as robots.txt or the open graph which are examples of protocols that have standardized previously unstructured metadata to improve user experience so in conclusion we collected every other report on pretty much every other report on ethereum D5 very few of these audit reports actually link between the actual code and the deployed contracts but we think that these two first two issues are solvable with a metadata

standard but in the interim we think that users most likely unfortunately end up falling back to derived measure of lindiness but we think that one way to get around this is by exposing and making more transparent the prevalent nature of proxies and upgradability that is very prevalent within within D5 and we propose stvl which is a metric that resets the lindiness of a protocol whenever the logic and dependencies upgrade thanks [Applause] [Music] um thanks for the talk next up we have zeeshan who is engineer at constant and we'll be talking about

biggest hacks of 2023 so far okay so today we'll be talking about the largest hacks of 2023 so far specifically in the context of their root causes now any protocol that maintains collateral has to ensure that the user's collateral is sufficient to support their debt and so this is done by calculating a health Factor if this health Factor drops too low then the position can be liquidated so it's essential for all the appropriate protocol actions to um ensure that

um that uh this check is in place in these functions or the position will become liquidatable leading to unexpected States unfortunately some protocols do forget to implement these checks in certain functions and so far this has led already to a loss of over 206 million uh this year so far the largest hack of 2023 so far is still the Euler Finance hack and um the Euler Euler Finance is a landing protocol which supports liquidation which is very profitable in fact a liquidator gets a 20 discount when purchasing the collateral of a

liquidated position also Euler Finance has a function called donate to reserves and this allows a user to donate their collateral to the protocol unfortunately this function was missing a health check at the time of the hack and so this allowed the attacker to create a liquidatable position at will and then when they did this they could immediately self-liquidate taking advantage of that 20 discount and making a profit at the expense of the protocol and by repeating the steps several times they were able to drain this protocol the root cause of the Platypus hack which also happened this year was very

similar in this case the protocol was exploited through the emergency withdrawal function which was lacking this health check in the correct spot so the protocol did not check the health of The Possession after deducting the collateral to be withdrawn and so this allowed the attacker to withdraw as much collateral as they wanted to and essentially steal funds from the protocol um so you can avoid missing health checks by writing tests for all the appropriate functions in the protocol these tests can attempt to bring the position below the liquidatable threshold and you should assert in these tests that this attempt should revert or fail it can also use invariant testing

or fuzzing to win to find specific cases where this threshold can be reached now most D5 protocols require some type of configuration and when misconfigured this can lead to devastating consequences just this year we've already seen 25 million loss just due to a misconfigured markets now one of the first large hacks of 2023 was on the lenhub protocol a lendhub is a compound fork and it has L tokens instead of C tokens so what happened here was that there were two lbsv markets there was the new and current one and then there was the deprecated one the new lbsv market referenced the new comptroller and the Old lbsv Market

referenced the old controller so this allowed the attacker to deposit their collateral in the Old Market take a loan from the new market and then immediately withdraw their collateral from the Old Market without repaying any of the loan um the root cause of the 100 Finance hack also this year was very similar it and it's also a compound fork in this case the Comptroller was listing two different hwbtc contracts the one that was used by normal users of the protocol and then this duplicate Mt Market which had been completely unused and the hacker exploited this to uh steal funds from a protocol here's another type of hack due to a misconfiguration which happened on yearn

Finance this is actually a pretty old contract but the hack happened this year so the problem here was that instead of listing the fulcrum market for usdt it listed the fulcrum market for usdc this allowed the hacker to manipulate the reserves and steal approximately 11 million dollars worth of assets from this contract now Market misconfiguration can be prevented by writing tests for your deployment script and this can be done on a localized mainnet Fork before you actually deploy it to mainnet so you should not only assert the correct state of the contract but you also should have negative test cases such as checking for these duplicate or empty markets because as we've seen they can lead to various

serious hacks and auditing firms can also help to ensure the correctness of this state now some D5 protocols allow their users to pass in parameters which represent external contracts to be called and some protocols even let you specify the function to be called on this external contract when these parameters are not validated this can lead to some serious hacks and this has happened several times this year so a great example is the hack which happened on daxable dexable is a DEX aggregator and it actually allows the user to specify the contract address of the decks as well as the function the swap function to call on that Dex and so what the hacker did in this case

is rather than specifying a deck's address they specified a token address and rather than using a swap function they use a transfer function this effectively allowed the hacker to manipulate decibel into transferring its users tokens directly to the Hacker's account and this was possible because the users approved taxable to transfer their tokens a very similar hack happened on Sushi Swap this year in this case the hacker was able to pass an invalid pool contract into the sushi swap router function and this allowed them to take advantage of approvals given to this router by various users and they were able to perform a very similar hack to the decibel hack

now these types of vulnerabilities can be prevented by performing very strict validation on these types of parameters these external contract addresses and call data and um you can um you can also consider redesigning the protocol so that such flexible parameters are not required this would greatly reduce the attack surface so another huge Trend we've seen in 2023 is the rise of read-only re-entrancy hacks and we've seen at least four major hacks happen due to this vulnerability um the first one that happened this year this year was on the Midas protocol and so Midas is a lending protocol which allows

um curve LP tokens as collateral and the way it determines the price of this collateral token is it uses this guest virtual price function on the curve pool the guide virtual price function depends on the total supply of the lp token so the attacker removes a large amount of liquidity from curve and then this results in a large amount of LP tokens being burned resulting in the supply decreasing considerably so this in turn affects the value returned by the get virtual price function which is now going to return a very inflated price and when the Callback function on the attack contract is called it's able to take this huge loan from Midas which Midas allows because it thinks that the attack contract has a lot more

collateral value than it really does and there's been a couple of variations of this style of hack on D4 switch use liquidation instead of borrowing and then on sentiment and sturdy which use balancer LP tokens instead of curve LP tokens now this type of vulnerability can be prevented by using some type of function before some type of function with a re-entrancy guard before retrieving the price or by using a library such as balancers Vault re-entrancy lab also generally speaking we should be really cautious with LP token price calculations uh so this brings us to the end thank you so much for listening thanks for the talk

super nice let's see if any other hack beats these ones this year hopefully not but let's see next up we have janev from hexagate who will be talking about the best practices for securing web3 protocols hey everyone I'm super excited to be here today we're going to talk about building a stroke defense basically best practices in securing D5 protocols my name is Yaniv Nissan I'm the CEO and co-founder at exagate with over 20 years

of experience in cyber security and a Serial entrepreneur now everybody here is I'm guessing love to build Lego right and Defy is a money Lego like unlike the early days of crypto where a system were very simple now we're talking about complex system with many moving parts from Oracle to Smart contract that you are dependent on to token that you dependent on to configuration and uh and many many moving parts that just makes security very very complex so it's not only that everything is open accessible we have multiple attack vectors from cyber

exploits to financial exploits to third-party dependencies to Administration governance and many more and it makes the hacker lives like very very easy they are highly motivated into hacking into this D5 protocol and again it's not only like the systems are complex they have many moving Parts everything is open we have direct access to money direct access to value now a hacker in the traditional world when you hacks something you need to do some sort of a ransomware or to start a negotiation with the team to get money here we are one transaction away

from getting a protocol wiped and a hacker getting all of the funds and we are seeing all across like the last year and before that and I think like just the presenter before me from Quantum just like showed all of the hacks that uh that happened we're seeing it happening all the time right so it's not a question of if and we're working with many protocols and many prospects and like they're asking us I'm not sure I will be hacked I'm battle tested I did so many Audits and we're saying to them all the time it's not a question of if but rather when so what can be done

so first thing is get visibility and prepare and I think that if you were here earlier today so Heidi from coinbase 0x Labs Tim talked about it so much it's prepare prepare prepare some in some point in time you're about to get wrecked and I can see you here um so how you get visibility and prepare right so first thing is you need to map this is mapping your known threats so this is what you're doing with companies like sritora with formal verification with auditing you need to map your invariants you need to map your first body code you need to hunt the zero day vulnerabilities you need to map all of

your third-party dependencies and this is just the first step then you need to go and review your internal security procedures so you need to understand how you assess risk which Personnel do you have in place what are your access controls so for example like in muted panel about bridges so many hacks happen before because like people don't really manage their multi-six right so you need to understand your security procedures then you need to take into account your the way that your protocol operates like who is or what is the profile of your ecosystem right what is your risk tolerance what is significant

loss meaning to you because for example not all protocols can pause your smart contracts right so this is something which is very important and again prepare prepare and prepare in some point in time the worst case scenario will happen and then this is this is the moment in time where you will be asked to give answers to the ecosystem right so I want to talk about how we are moving from periodic audits into ongoing protection so you did an audit right you hunt for the zero day vulnerabilities now you need to basically shift this Paradigm and instead of hunting for

vulnerabilities you want to start hunt for the threat themselves you want to hunt for the hackers right so this is the next step after an audit so you need to have and where we talk about it a lot here you need to monitor for threats and again you are monitoring for the activity on chain for the malicious activity on chain because you want to detect this malicious activity before it impacts you you need to have the remediation plan right and having the remediation plan is for each and every type of alert because there will be alerts that you won't have time to react on so they need to be automated there will be alert that can be semi-automated there will be alerts that you will have a team inside you will maybe take your

developers maybe you need to have a security researcher in place but eventually you need to have playbooks and prepare for everything and of course Insurance response right worst case scenario happened what do you do you need to have red team you need to have proper War uh War rooms you need to coordinate everything and we'll touch upon it soon so the three pillars of ongoing protection the way that we see it and I'm guessing everybody in this uh in this Auditorium from the space can relate to that so you need to have early detection time is really important in D5 we are one transaction away from getting wiped you need to be very accurate and

of course you know I can't say that we are 100 accurate and if you will hear a security company saying that they are 100 accurate they lie right you need to minimize the false positive rate you need to have I'm guessing more than like like in traditional cyber security in some cases even more than one thread feed because you want to increase your accuracy and you need to have a way to minimum to minimize the response time so how can we manage pre and post incidents I want to give you a glimpse of how we work with our customers basically our concept of pre-incidence response right so if you take a look and

we did it uh and I think this is one of the thing the benefits in crypto in blockchain everything is on chain so you get data from the Genesis block it really helps us to build the models so you basically try to track malicious activity and malicious activity follows specific pattern right so it starts with funding and in funding you basically your goal or our goal is to detect this like funding signals on chain right when we understand that there is like a malicious funding we want to collect these signals and let the security team of the protocol that something bad is about to happen but it's still not decisive it's just funding right but you collect the

signals you want to reduce the noise uh you want to reduce the noise uh the noise in the system then you are in the preparation phase where the attacker is deploying a malicious smart contract this is where you want to start to react on right so we will send an alert to the security team and then we want to see how they are blocking the malicious activity again this is not one size fits all right you need to have the proper instance response plan you need to know what your block when to block but the goal will be of when the hacker will run an exploit you will be protected and the next phase which is laundering will just not happen right

because it won't be hacked but worst case scenario happened so pause instant what do you do first pause everything like we've been in dozens of War rooms we contacted protocols when they got hacked and we set them pause the protocol and they they take their time and like the first hack was small the second one the second one just wiped everything right so you want to avoid the next hack you need to be able to open a war room and everybody opens a war room right it's on telegram it's chaotic right everybody asks who who knows uh coinbase who knows balance you

need to be able to prepare in advance in the War Room you communicate with your community right you do a triaging you do a full process of understanding what is happening and what what are the next steps one of the next steps will be contacting the law enforcement you need to give them reports you need to contact centralized exchanges you need to contact Circle you need to contact feather and why is that because you want to limit the blast radius right you want to be able to freeze assets and of course you want to track the funding sources of the attacker because in many cases it will allow you to identify his identity

thanks if you want to learn more thanks janev that was a great overview we'll have the next speaker now of Felix from open Zeppelin we'll be talking about hundred percent test coverage but zero percent security but hi yeah thank you very much my name is Felix uh from open Zeppelin you might know our security library of smart contracts and we of course also do uh audits monitoring and many more things and today I want to talk to you about testing so

um we have like one really crucial question to answer if we get 100 test coverage do we get some security no security a lot of security I'm trying to answer this today so let's take a step back why are we testing at all uh typically you want to see um whether your code base actually has some kind of functionality probably the functionality you intended your code base to have that's kind of the point of tests but then looking a bit further you have like additional points of your tests typically you don't only want to do unit tests you want to do like some integration tests or some end-to-end testing and they actually have a

descriptive functionality so you can really see like what's the happy path through your code base what are like the interesting ways a potential end user can interact with your code base so this kind of descriptive functionality is also in there and then does it contribute to security well we are hoping that it does but um we don't know at this slide so let's let's move on and answer this question later now talking about the quality of tests after a while you want to be done with testing so we have like different quality metrics um the first one is a functional metric it's the test coverage of your code base and this is typically like a line

coverage or Branch coverage it's a nice number and we're assuming that it's like 100 in our test example so we're doing very good on on this case and then um again descriptive means that you have kind of interesting test cases not just like very small unit tests but some very interesting end-to-end test cases and now it's again the question do we need an additional metric or are we just like accidentally already done with security and have perfect security as well so let's look at a small example this is like a very small elc20 token I wrote you can see above in the slide 100 test coverage is ensured To Us by like

Foundry and you can see in the lower part of the slide well I wouldn't really call it interesting but because it's a minimal example it's kind of like the three use cases I imagined for this token that you can mint it burn it transfer it yeah they all work out they are all covered in this test case so basically we're doing perfect on the functional and descriptive side so are we secure no this has a public burn vulnerability so you can just burn any user's token and basically this is like a critical vulnerability and the security here is really like zero percent you need to fix this you can't deploy it in this shape but so what is missing

this test case is missing um if you don't know The Foundry syntax you see in the name that it starts with test fail so it's kind of asking for the opposite of what you see in the test case it kind of verifies that this test will fail and um yeah it's it's a typical test that just uh tests that like an arbitrary address like a non-owner address can like burn a thousand tokens of another user and yeah you really want to make sure that this cannot happen so you want to write this kind of negative test case now this was a small example let's move to the overall principle what we typically see when somebody says

they are doing testing is completely on the left side they do functional testing they are concerned with coverage but this is just one aspect of testing and it's good that you do it but it has actually very little to do with security if you want to do security testing you have to be on the right side and you have to ask yourself like how much testing of of an absence of functionality am I doing so for example for unauthorized functions am I really testing that like a message sender that is just an arbitrary person cannot interact with a contract in a certain way and so this testing for absence is what we call security testing here but now I want to take an additional

step back and wonder about like how does testing look uh in theory and in practice so in theory numbers provided by IBM is that yeah we should invest a lot in testing because it really pays off if you find something early during the design phase the implementation the dedicated testing phase your cost is kind of moderate and it really deploy it really explodes in the deployment phase and this is not for blockchain systems where like the number 100 you see might be even higher because of like the tvl attached to it but this is always already like across arbitrary software systems So in theory everybody should basically do the best possible testing

because the economics clearly tell you it will pay off now let's let's look at the practice testing is not sexy testing is really like uncool nobody says oh I'm really passionate about like QA testing I'm a tester um like all the cool stuff is basically associated with hacking so um of course for like your protocol that's kind of like a bad thing right like you don't want to be hacked but hacking is rather cool while testing is um kind of like a the ugly thing you have to do but no one really wants to do so let's now look at how we can like fix

that so this is my recipe to make testing attractive basically do hacking as part of testing so to do like really good security testing we start with while true because you can iterate this Loop forever what you do is you come up with like a creative POC exploit you're basically trying to exploit the your own protocol you're trying to develop then you verify that it doesn't work hopefully or you actually found something that you really need to fix and then you just don't throw this away but you integrate this as a test case into your security testing test Suite and that from like a day-to-day activity

of how you think about it makes this a lot more attractive because this is not like the unit testing or the boring kind of testing you you know and it's it's like the typical University curriculum but this is more like the modern kind of like hacking mindset you apply you just apply it to like an artifact that makes it into your test Suite so nice Theory but now to actually add more practical points to this uh let's look at the projects just this year that had like some code level vulnerability so this is no exposure of private Keys No Rock poles or something like this rather they had a bug in the code that could have in principle be

prevented by this kind of testing methodology and we see that like the funds stolen today in this year are 250 million already so I think this is like a good argument to potentially integrate this kind of like saw the security testing into the test Suite so now on a very high level if you are a decision maker you don't want to like recall the details here you want like a really simple metric count the number of interesting test cases based on proof of concept exploits in your test suite and make this the metric of security testing so to summarize 100 test coverage is

functional testing it's not related to security if you want to do security testing which you should you should test the absence of something if you want to do this in a good way you need to like adopt a hacking mindset and really do exploit pocs as part of your test Suite and unfortunately there's no Silver Bullet this is not exhaustive you can start this as uh as part of your project internally and then best reach out to your security partner to basically further enhance this kind of testing methodology thank you very much [Applause] yeah definitely people gotta start

adding negative test cases not just all happy positive stuff next speaker we have Jack who is co-founder of Sherlock he'll be comparing traditional audits with audit contests please do screen mirroring or anything full screen and you can mirror yeah let's do here okay oh

amazing perfect all right hey guys um cool so my talk today is going to be a little bit of a continuation of the auditing panel that we just had about an hour ago um about kind of conventional auditing versus the community contest approach to auditing um the title here is quality of Auditors or quantity you know which one matters more um and so last D5 security Summit Sherlock announced released the hybrid audit contest model which is sort of a

combination of an audit contest and reserving well-known top Auditors to also audit the code base in a more traditional fashion alongside it and it's a really cool model basically there's incentives for both sides to perform well if they don't perform well there are negatives they lose out on money they lose it on ranking they lose out on potential leading opportunities in the future um so last D5 security Summit was end of August so we're about 10.5 months into this new hybrid audit contest approach that Sherlock has been kind of pioneering we've done about 85 contests and we found around a thousand higher medium vulnerabilities in those 85

contests and so we're now at the point where we have like a kind of statistically significant data set that we can sort of look at and try to find some interesting things in um and one of the important questions or one of the questions that people are very curious about is who actually is finding most of the issues in these contests in these audits that kind of combine both the traditional and the community approach so just as a reminder in Sherlock contest there's usually one to two highly ranked Elite Auditors we call them lead senior Watsons they get paid a lot of money every week to show up and do the audit and then there's roughly

you know 200 Security Experts on average I think it's closer to three to four hundred at this point but across that data set it's about 200 on average that are looking at these contests and so the question for you all is who do you think finds more of the critical and important bugs in these audits raise your hand if you think the one to two highly ranked Elite Auditors are finding more of the critical bugs all right maybe like 30 hands uh raise your hand if you think the 200 kind of random Security Experts all over the world are finding the most critical bugs

about the same all right to split uh the split audience so we'll start with non-critical first these are like the medium vulnerabilities these are things that are not super critical they're not um kind of crazy in terms of could hack your protocol immediately as you can see one to two leads in your Watsons they find 46 percent the community finds 81 percent and that's not super surprising because a lot of these things are sort of creative they're sort of edge cases that maybe you would find maybe you wouldn't it's not the worst thing in the world if you miss one so having 200 people looking at code just kind of yeah you just find a lot more of these but moving to who finds the actual critical vulnerabilities it's really close so the one to two lead senior

Watsons found 66 percent of them roughly the community found 76 roughly um so I mean I would almost call that a tie but as you can see the community kind of edges out the senior Watsons when it comes to finding those critical vulnerabilities in Sherlock contests over the last 10 and a half months so we think that's really kind of interesting and the fact that both numbers are so high is really a testament to the skill of both sides in my opinion and another way of showing this data is basically if you don't have lead senior Watsons if you don't have those reserved Auditors doing this audit then you will miss roughly one quarter of the critical vulnerabilities you know in the code base and if you don't have that

Community aspect if you don't have the contest with hundreds of Auditors participating then you will miss about one third of the critical vulnerabilities in your code base um and so here's a small case study Sherlock did a audit on the Bedrock system of optimism their upgrade earlier this year it was the seventh audit so this was like a pretty well audited code base at this point Sherlock was still able to find three kind of critical High vulnerabilities we kind of categorize those together um and the interesting thing about those three vulnerabilities wasn't so much that we found them but it was how they were found um and you can see here one of the vulnerabilities was found by the lead senior Watsons and it was solo so only

the lead senior Watsons found him shout out to Zach and Trust I think Trust might be here um for finding those they were kind of the team the lead senior Watson team that took on this audit and then one person from the community found a solo finding that the lead singer Watsons did not find and that was he-1m really crazy bug we can talk about that in another talk and then there was another critical vulnerability that was kind of that was submitted by both lead senior Watsons and the community and the interesting about this is it's kind of a perfect case study for if you had only had one of those parties if you only had the community you would have missed a critical vulnerability if you only had the lead senior Watsons you would have

missed a critical vulnerability um and so Sherlock's stance on what's better the community or you know the traditional style of auditing is having both is better you know there's not like this you don't need to choose one or the other you should have both you should combine them in the audit and Sherlock is the only one that kind of provides that right now we're the only auditor that has both the contest model and that more traditional approach of including well-known Security Experts and paying them a fixed amount of money to show up uh and another show for Sherlock is that we have millions of dollars of smart contract coverage that any protocol that goes through a Sherlock audit is able to activate after they do the audit um

so yeah that's pretty much it and the last thing to talk about is Sherlock is shipping for the people who compete on Sherlock which I know there are a decent amount of them in the audience uh Sherlock is shipping a new feature that will go live for the index contest starting tomorrow which is anonymous submissions which people have been asking about for a while and that means that your Sherlock username will no longer be shown in the judging contest uh basically if you are an unknown security expert someone might see that you're less well-known than the lead senior Watson and they might say I'm not sure that issue is real now everybody gets the same

green spicy unicorn made up name and there's no way to tell who the lead senior Watson is you have to only judge the issue on its merits so that's coming out tomorrow we're excited for it and hopefully all the Watsons are too foreign contests are definitely a great addition to audits they don't replace them but a great addition nevertheless now we have Mark who is from Paladin security and ambed finance we'll be talking about importance of researchers and Auditors at a D5 protocol

if you have any slides to present where should I plan yeah see um yeah yeah is it working yeah

whatever hey hi I'm Mark Vice and uh someone some of you may know me as your exercise on Twitter and today I am going to present the importance of Auditors at the core of 35 protocol so I'm currently independent security researcher and a private auditor at Ambit Finance I do private auditor I'm also a lead senior Watson in Sherlock D5 and I'm a security auditor at Paladin security so as my talk involves how an auditor researcher could help in all the stages of modified protocol I will first

explain those stages and how an auditor could be helpful in them the first one is development it's the stage that goes from the ideation the design of the code base and the architectural decisions um normally researchers have audited or gone through hundreds of code bases and they know the best architectural decisions and how to better design each type of code base for instance if you are doing a borrowing and Landing protocol where you want to use an dynamic or a fixed interest model whether you want to use upgradable or an upgradable contracts which type of them you want to use where you want to use a proxy pattern TPP or

your ups and if it's non-upgradable where you want to use a registry based architecture Hand by hand with a testing suit so article Auditors could help similarly in both of them the third state would be the audit the audit would happen once the protocol has already the contracts ready for minute this would be most once the testing suit has a range of more or less 100 coverage whether the protocol already also used fuzzing or reduce the internal found revising or or Echidna or whatever tooling and for independent researchers and all it would consist in a Security review that would you would you would just give the protocol and give the the

report to them internally um once this report is done uh the protocol would go to mainnet or even they would set up a bounty with any of the bounty platforms and in Maine that the researchers are are very useful because they have already a lot of experience there and there are so many things that can go wrong that their experience could be very helpful to complement the stages we would have the root causes of hacks in edify protocol I would highlight six and uh the first one will be lack of knowledge lack of knowledge would be anything that has to do with like re-entrances under overflows or or even not understanding some eips like the AAP 150 that it's basically that you would forward 63 It

Forward 63 out of 64 of the remaining gas to external calls or other Apes like 2929 where you would choose the gas that spent on on all codes like call it changes depending whether the call has value or not the second the second root cause I would highlight it's like external vectors external vectors would be like private key leakages or something turned into the Auditors itself Point number three would be contract maintenance depending where you're having for instance an upgradable code base or non-upgradable you would have to upgrade the contracts point to the right implementations if you have a registry based architecture you have to deploy new contracts and just set up the new state variables and number four with the architectural errors architectural errors wooden glow

where you are handling correctly external contracts where you're having for instance fallback oracles if you need them anything that has to do as I said before with um interest rates uh models if it's fixed or dynamic for landing borrowing protocols anything like that type number five we have logical errors logical errors would be anything that has to do uh specifically from for that code base that the the developers developed for instance some state that has that should not be getting at some invariant that you broke or the code which just can get to an a denial of service state that you cannot recover from and six and last would be deployment scripts with its very underlooked but by

a lot of protocols and actually there are a lot of Errors there which normal audit firms neither independent researchers do review so I I prepared an example for them so this is a contra a contract where it has it has two permissions the operator and the and the owner owner being the root permission and a correct deployment script for the contract would be basically that you would uh call The Constructor and just set the owner address and after it was called set operator and set the operator address as you can see in this contract there is only one there are more functions with highlighting one function withdraw funds that it should be only uh be go going through with the operator address as you see on the require on the last required

that it checks that the that the signature recovers it's equal to the operator so the operator should be the only one to be able to withdraw the funds in a faulty deployment script for instance uh the the developers would just forget to call set operator because it's not on the Constructor and then would cause if this is underlooked and this is uh in mainnet and the funds are just entering the contract anybody would just be able to steal all the funds because as you know EC recover with a faulty signature would return zero and it would it would pass the required signer is equal to operator so to complement all the set on uh beforehand uh here we have the benefits of having Auditors and researchers in your D5 protocol

and this would complement everything like the like we spoke the root hacks and uh the status so firstly it's the benefits in war rooms the benefits in war rooms as we know a lot of researchers have been uh mostly experienced researchers have been in war rooms before War rooms generally happen once a protocol gets clearly demanded that now we know that happens pretty much every week so they are quite common and there's periods of time where it's critical to to act fast and and basically it's just you are in in a lot of stress and and Auditors and researchers are usually on that stress and they have experience on this so it would be a critical point where Auditors would be able to help protocols here secondly would be uh breakdowns of Bank

boundary report that goes together with proof of concept building pretty much any researcher auditor builds proof of context at least weekly and it's it's very critical for for for protocols to actually be able to do this proof of Concepts fast in case they are exploited as it goes together a bit with the expertise in war rooms and same thing with uh with breaking down background reports we know that backbund reports are not always the best quality it depends on the experience of the of the of the hunters and there are a lot of times that you can say where a bucket's actually valid or Not by just looking at the report but it's not always that case there are reports that actually come with a very low quality there are findings that actually go come

with a very low quality report that they are underlooked and they're probably not very good to understand by the protocol so as Auditors have really have been through a lot of reports they could just help breaking those down implementing the fixes then you have much cheaper than paying a critical Bounty researchers and Auditors are not cheap neither but would you rather spend half a million in a critical warranty or just hire two researchers uh that they probably are not going to cost that money and you might be able to save it and largely a security-based approach on designing protocols this goes a bit with the with the beforehand design explained it is clear that a lot of bugs actually are in the code bases because they are

not designed correctly it's it's it's critical that the code base have a secure mindset when designing them and and Auditors do have it so they could advise in the best way to those protocols so thank you um I am Mark any any increase that you have about private auditing anything about the the presentation itself anything you want to ask me you have my email my Twitter so yeah I'm open to answer your questions thanks Mark and that was super nice we have a short break now and then we'll reconvene later for another set of talks excuse

me [Music]

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

[Music] oh foreign

[Music] [Music] thank you [Music]

foreign [Music] [Music]

foreign [Music] [Music] foreign

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

[Music] thank you [Music] [Music]

foreign foreign [Music] [Music]

oh yeah [Music] [Applause] [Music] I was like [Music] laughs

foreign [Music] [Music]

foreign [Applause] [Music] is it last year [Music] [Music]

[Music] let's take this [Music] pictures [Music] hello uh just checking for speakers of the next session do we do we have Noah here you're the one you're the one yeah you

can go I was just checking if they're only here yeah do we have Noah here ah noise Fabrizio all right Elon Antonio who's missing Antonio and do we have Irene he's here earlier are we excited

it's the last session of the day so you have no one now yeah feel free take it away You're gonna talk to us about any pots right honeypots hacker traps on the blockchain take it away so these work yeah oh boy I have a timer I didn't expect that uh so hi everyone I'm Noah from hacken and today I'm going to be telling you about a really obscure exploit uh type called honeypots which are pretty much hacker traps on the blockchain so to skip about 25 slides let's go to

exploiting smart contracts um you want to exploit the smart contract and here is you and you find a Target and you think you got an exploit and there's two things that could happen one front running Bots somebody sees it on the mempool because you didn't use Flash but protect or something and you miss your chance buddy option two you are a bad hacker you did not correctly identify your Target and you were trapped by something called a Honeypot so what are honeypots uh well smart contract honeypots are a special class of smart contracts that look vulnerable but aren't the big idea is to make you

as a hacker or a security professional pick that you can earn some money by sending funds to that contract when in reality there is some quirk in the engine an eater scan or in the code that means that only the owner slash the deployer can uh actually withdraw These funds so some quick technical examples here's the multiplicator Honeypot that's like this cool level example and in this case we have a simple function that takes uh that's payable and it takes checks if your message value is bigger than the balance on the contract and if it is uh it sends you all the funds on the contract now uh

anyone here know what's wrong I mean it's written but come on uh so this is the balance already includes your value so this if check is really just going to be deleted by the compiler and nothing happens this is an empty receive block and it's beautiful uh and this doesn't really work in practice right that's too simple but here's one that actually does um so this is this uh gift box sorry this is a king of the hill game uh and in it you have a stake function it checks if you send more than the largest stake and if you did uh then you become the new owner the new king of the hill

and then using the withdrawal function on the right you can withdraw your funds right uh and this is all fair except those uh eagle-eyed among you may have noticed there's two owner variables one on the left one to the right uh the one on the left is set in the Constructor on the left and defines the modifier on the left and that one is never changed again uh well one on the right does absolutely nothing and is the one that's modified so the original owner of the contract is gonna stay the owner till the end of time and they can call the withdrawal function and take all your funds sounds silly does it well would you like some money because uh these people did

and look what happened to them uh it actually works and it's somewhat profitable again it's obscure this is not 200 million Euler hack this is like 1 million over the last five years uh micro hack um but this guy earned a few thousand Euros and nobody can tell him uh uh whether it was legal for him to do so or not actually it's sort of illegal based on the most recent legal advice I got just in case you want to run your own but yeah um the next example uh just keep it quick a gift box so everybody here knows how to uh how to do passwords properly right

you want to use chat uh you want to use shot three and not just set a password because everything's public on the blockchain and the get function it's okay don't worry about it the tricky thing is the set pass function which is also in general good ish it checks if the password has been set and allows you to put some money on the contract to set the password so pretty much set the get box but you come across this and you look on eaterscan and uh there's already some money on the contract right and it looks like uh somebody said the money because he want more of a reward but forgot to set the password and then hold the set pass function and by default that's going to be a hash of zero and I think that's

something that you can get to uh or you just you know call the set pass function uh and sorry because uh sorry you cannot get to that hash but you just call the set pass function with one eater and you get all the money out right but the thing is there's a problem with eaterscan for the last Infinity years and that is that it's not very transparent about contract to contract transactions uh and this is actually a good place for me to mention this because now you can all go to eater scan and tell them please fix this um you see somebody call this set hidden function from a contract and if you look at the inter scan nothing here if you go to internal transactions and turn on advanced mode and read into every single

transaction eventually we figure out that the state changed here which is a bit of work right so yeah that's a fun one um so yeah these are the Honeypot examples why do they work one hacking is a nasty business you've got about one minute to find your hack uh before somebody else does right when the contract is deployed uh two there there is a ton of hackers that don't really know what they're doing they're just running uh a tool like to is a big example if you know it uh but in that case somebody may be exploiting that tool and three just eaters can sucks um

how do we detect them so symbolic solvers uh heuristics as was mentioned yesterday you need to be an expert you need to know what you're doing and what you're searching for and then you can like create a solver that's going to check for specific scenarios option two uh transaction patterns so that's something the incident detection crew is going to be really good at and uh be able to maybe find them that way that only works for ones that have been exploited though because I don't know ml training on bytecode is sort of tough um so Standard Process get all the contracts uh get all the data generate your training data using the symbolic tool and classify using ml

right and what can we get out of that well there's in that period that was tested about 2 million smart contracts there's a lot more now and of that only 150k were unique I checked about two weeks ago and right now there's only about 600 000 unique smart contracts so it's uh it's still not that much honestly of these 50k cash flow and about 300 honeypots not very common which is two and a half thousand deployed ones when you account for duplicates um what are the types so balance that's the silly one somebody fell for that I know then we have a few like code issues and

then we have a few eater scan issues and as you can see the eater scan issues are the big money maker uh so there's some additional cool ones that have been discovered recently role encoding uh okay you know the Greek question mark you know replace the semicolon in someone's code with a great question I can just watch them off themselves yeah you can do that in solidity as well so you take open Zeppelin's Access Control library and you pick like a random language like German and you find the normal you know oh with umload and you find another similar looking Unicode character and you just mix those around as permissions and code and somebody's gonna fall for

that so yeah nice one another one is just you know do not put the parentheses on the call and watch what happens it gets removed by the compiler and you can make the code look a lot different uh for somebody reading it right uh insights uh again sorry this is really fast they work usually only once you would expect after some defaults for it you get at least some info from eater scan about uh it being maybe dangerous they follow price Peaks only when they're the most profitable uh so I really wonder how many there are right now uh probably a few more of these

patterns and uh they're not very big only 250 each so 1 million and that time period maybe like five six million till now not too bad and right now uh yeah you can detect them pretty well for the known types using uh the symbolic solving approaches uh if you're interested in finding out more continued research on the honeypots projects is within the smartbox project which you can find the GitHub repo for here it's a pretty useful General like uh tool aggregator so uh yeah check it out and I hope this was a fun

topic for you guys because that's all it is [Applause] thank you so much Noah I never liked honey or pots so uh next up we have Fabrizio from 20 squares talking about compositionality let's go [Music] [Applause] um hello everyone my name is Fabrizio from 20 squares and today I wanted to talk a little bit about a technique more of what we do or stuff like that so

okay this is the current state of the ecosystem I'm going to be honest I think that uh basically every Auditor in this room has had to shovel enough to know that you know we live in a time of often badly City specs uh badly implemented code and Auditors are basically called uh to fix that um if you you know listen around and look at what many people have to say about methods to improve the situation at least to me it really feels sometimes that the proposal solution looks a bit like this like many people you know propose some fancy new cryptographic

primitive that is going to solve everything and stuff like that but in the end at least my feeling is that sometimes what we still lack is a deep theoretical understanding of you know some of the things that go on uh in basically the smart contract and blockchain word more generally so uh for what I had to for what I experienced one of the uh worst Parts um where a lot of Errors basically pop up are around interfaces interfaces here is a very Loosely defined concept for

instance a contract calls another contract that stuff happens multi-chain interaction bad stuff happens you know off-chain on-chain interaction bad stuff happens it feels like a lot of times when you have something of type A and something of type B interacting but stuff can happen now uh basically if you ask to you know a programming language Theory experts and people that do that that kind of Kink they will tell you well we invented type Theory to solve some of these problems um that is true but sometimes that's not enough so in that picture you can see for instance a very well defined type a

very well defined other type a very creative type conversion between one and the other that yes works but it really feels like duct tape again so what we if we had a formal solution to solve this uh basically the kind of thing I wanted to talk about in this talk is exactly that uh there is a mathematical theory that is called category Theory um that I feel is very underrepresented in our community basically category theory was invented in the 40s and it's the formalism on which all the nearly

all of the biggest achievements of mathematics in the last 50 years have been built upon and the idea is that category theory is the super glue of mathematics it really makes you able to describe what happens when things interact so uh in this image here for instance we have the basic object one of the basic objects of category theory that is the concept of a functor so the idea is that a category is basically a mathematical object made of objects and structure preserving Maps between them if you are versed that could be types and functions between them it could be sets and functions it could be groups and group homomorphisms it could be I

don't know topological spaces and continuous maps that the list can basically go on forever but the idea is that you can package the idea of a particular structure a particular flavor of structure into the notion of a category and now you can basically have the notion of a morphism between different categories that is basically a kind of coherent transformation that allows you to morph this structure to map it to another kind of structure so that's exactly what happens there I have a notion of objects down a b and c and Transformations between them that can be composed and the idea is that I also have another category upstairs and a functor is exactly a map that allows me

to map objects into objects and Transformations into transformations in a coherent way now you could be like okay interesting but what do I do with that well funnily enough basically in the last 20 years or so a category theory has been used extensively to model things that are kinda not really related with mathematics so I mean not yet joking they are but not as much as you would expect so for instance this thing here this kind of a weird bunch of dots and stuff it's a pictorial calculus that allows you to do quantum mechanics basically these kind of pictures can be

manipulated in a very formal way and they allow you to reason about quantum mechanical systems and they allow you to instantiate Quantum algorithms and Quantum protocols without touching linear algebra at all like you can basically play like a little kid with these things and you can verify improved properties about Quantum stuff how does it work well it works because there is category Theory underneath that basically uh says to us that we can consistently mapping all the linear algebra that we usually need to do Quantum Computing into these pictures so the idea is that you do all this giant

work it took like 20 years or something and then you can hide it and you can basically let kids playing with these things and they are happy and you can do Quantum computing similarly here we have a picture of basically the bread and butter of what we do at 20 squares this is a graphical calculus that allows you to do Game Theory and in fact those things depicted there are basically the prisoner dilemma the idea is that you have two players that are the two triangles they basically perform an action this action gets piped into a payoff Matrix and the payoff Matrix basically gives back the um payoffs to the players uh again you can follow these as a

picture but the funny thing is that again there are categories in the back that basically tells you yeah these things compile to games in the traditional sense and I kid you not basically we implemented this thing you can compose this little Lego bricks and then you can basically push a button and compute the equilibria of this game um so yeah uh in here we have again other categorical stuff I'm not really going to talk uh in depth about this but basically I guess that the gist of this talk is that uh yeah category theory is really the math of composition and studying it

in depth will you know really turn your understanding of mathematics and how interfaces work interface between thing upside down so that guy in the picture is a guy that did a ton of category Theory and I mean you see how it started and now it went it ended probably that's not a good example but but yeah I mean uh and yeah so in all in all is root your research just theories but when you have a good obstruction about your problem I think that really helps you understanding what's going on so yeah I think that's it I just wanted to point out to you that this thing

existed and look it up on Wikipedia if you want I'm done thank you thank you so much this is really good next up we have Martin head of new initiatives at constant let's go all right uh thank you for the introduction so I'm Martin I'm from quantstamp and I want to be talking today about Flash loans and you know how we can synthesize such flash loans and attack vectors automatically so here is a list of protocols and very

obviously you can guess that all of them were hacked right all of them were hacked within the period of 2020 up until 2023 using flash loans most notably the largest one Euler was hacked for nearly 200 million dollars this year so all together this sums up to 300 million US dollars in Damages and I'm here today to talk about a tool at Quantum that we have that can achieve something like that if we had that tool three years ago nobody would have been hacked so what is a flash loan just to be complete in our definitions flash loan is simply an uncoateralized loan that you can take as a developer from a smart contract for the scope of a single

transaction right so you will say hey please give me a flash loan of size X if this liquidity is available the smart contract will give it to you it will run actions that you want it to run and at the end it will check whether you have repaid this flash loan if you did then the transaction will remain unreverted and otherwise it will revert right so this is what a flash loan is what they were developed for or designed for where or is closing Arbitrage opportunities and you know sometimes they're used for that but sometimes because you can actually borrow a lot a lot of money they are actually being used to exploit D5 protocols so you know attackers usually take flash loan they

manipulate some Market somewhere and then they exploit another protocol that uses that given Market as a price on Oracle for some purposes and the reason why I'm able to be here today and why I was able to show you that slide before is that you know unfortunately due to composability of D5 flash loan attacks and attack vectors they're actually really hard to find so you know for this reason I've been actually on a lookout for a tool that could Aid the discovery of such attack vectors for us uh for you know pretty much since the very first flash loan attack so the very fly first flash loan attack happened at East Denver in uh 2020 and right in 2020 uh we actually

had some first attempts to use automation to discover such attacks so the very first one that I am aware of that was Bernhard Mueller who used mithrail and myth X to discover flash loan tax and he actually gave talks here in Paris at each CC about that still in like July of 2020 but unfortunately he was only able to handle some very basic cases he was actually portraying it and framing it as discovering Arbitrage opportunities he was using uni swap contracts and you know the general performance and and the quality of these findings were not sufficient for practical use in the auditing industry then uh last year in August at the Stanford blockchain conference I

actually saw a really nice talk about something called Clockwork Finance framework which uses formal verification and the game framework to discover uh flash loan attacks it has a lot of caveats it's a purely academic work and it's also not suitable for you know practical use and finally uh there is also something or there was also something called Vanguard so uh Vanguard was a tool developed by uh very dies I checked it in December 2022 so last year uh it is no longer available it was taken down from GitHub and it was also tempting to discover flash loan vulnerabilities but you know was not

successful in doing so so the bottom line is if you actually want some Automation and if you want help from tooling uh you need some new ideas in here there is nothing out there or there was nothing out there up until this point that would work so I discovered this work by a student at the University of Toronto who we partnered with at one stamp and you know brought into a production a tool that uh Works roughly as follows it precedes the entire protocol and the sequence of actions that you can perform on the protocol as a profit function of the as a profit function of the potential profits to the attacker so you know imagine something like compound right you can deposit

funds into it you can withdraw funds from it you can liquidate somebody else and then there are various parameters that go into these uh into these function calls so these parameters those are some variables of a multi multivariate polynomial and if you sequence them if you plop in some particular values you will get a value back and that value back is what you would receive as a attacker if you were you know performing this action now if it is action is positive or if the result of this function is positive then as an attacker you would make money if it is negative then you would not make money right and if you ran everything inside of a flash loan call then uh then such a sequence of actions would revert because you would not be able to

um to repay your loan and so this is what we actually do we generate whole bunch of random sequences of these actions and parameters that can be fed into those and then we evaluate what profit would the attacker get if this was run inside of a smart contract that would take flash loan and run this as an attack and then whenever you know we just get these whole bunch of random points then we model this multivariate polynomial and we take a look at what are the local Maxima that give us positive profit right and once we find something that gives us the positive profit we actually take these parameters the specific sequence of action and we execute it in a simulated chain environment so imagine something like a fork of blockchain on Foundry or hard

hat or something and then if this confirms that such a sequence of actions actually executes and gives us the profit we have synthesized it automatically a full attack Vector that would exploit the given protocol and if it doesn't if it reverts or if the profit is actually negative then we have obtained another function point right another point of that polynomial that we can plop in back into our models and improve those models and keep searching and searching and searching and this is showing to have a very very very good results as I showed you on one of those initial slides we are able to find pretty much all the significant flash flown attacks and hacks from the past three years including Euler so you know here is an

example of an output how it looks in our particular implementation for the Euler protocol uh and that's about it so in summary what I wanted to tell you is that at constant we now have a tool that is actually capable of automatically discovering flash loan tax it uses completely new approach you will not find any symbolic execution or formal verification in there it just uses pure numerical analysis and modeling of polynomials um unfortunately you know for the whole time I was saying yes it's automated yes it is automated the search runs automatically but tool still requires a little bit of manual guidance and a little bit of you know retrofitting for every single protocol but thanks to all

the work that I have done together with Jeff within this past half year uh this pendum of work that is actually required is not so much it is very very comparable it's actually a little bit less of the amount of work that we do when we perform a normal regular audit so it is extremely applicable and it's extremely executive executable and repeatable in practice for discovering such hacks uh So currently we have an implementation it applies to all evm chains but you know as you can guess this technique is actually super super generic so it could be applicable to other runtimes and we would be able to apply it to other blockchains or even cross chains interactions as well but we have not done that work yet

and finally the main reason why I'm here we are looking for D5 protocols and blockchains and funds and whoever else who is interested in this topic and uh you know wants to Pioneer with us so if you do please get in touch with me there is a QR code in here that's the telegram contact for me I will be in Paris for the whole week and yeah thank you for your attention [Applause] thank you so much Martin Apparently one step has ended flashland attacks let's hope so good talk next up we have Alum a co-founder CEO of redefine talking to us about D5 scans and how to solve them with symbolic execution

hello everyone today we are going to talk about device cams and how with the power of symbolic execution we can detect and expose them let's get started my name is Alon Ram I'm the co-founder and CTO at redefine redefine is a web 3 security company specifically helping users and institutions to manage and mitigate mitigate risks including device scams and hacks prior to that I worked for the Israeli government for many years doing cyber security and crypto we all love defy because it's a permissionless and trustless nature but

the trustless ain't always trustworthy because you depend on the security and The credibility of the smart contract now anyone can write smart contracts even bad people over the past three years more than two billions of dollars have been stolen in D5 scams there are more than one hundred thousand scam tokens most of them are traded on non taxes like uniswap rockpool is the most common scam it's when a scammer develops smart contracts with a back door convinces user to buy it and when the price goes up Suddenly he withdraws or pulled the rug out from under the investors causing them to lose

their Investments there are several types of such vectors like prevent selling hidden mint and force transfer will cover them all what is symbolic execution symbolic execution is a software testing technique that uses symbolic inputs to analyze all the potential execution Paths of a program it is used to detect bugs to to verify the correctness of a program in Cut coverage and in security analysis we will see how symbolic execution can help to detect device camps

how does it work let's say we have a simple function with some computations and if statements the first step is to replace the concrete inputs with symbolic inputs the symbolic inputs can represent any given value any possible value in this example A and B are symbolic inputs then we execute the program symbolically operations in the program that involve these symbolic inputs are carried out symbolically in this example Z equals 2 times Y which translate to symbolic

expression Z equals 2 times B the symbolic engines create symbolic inputs and gather path constraints pet constraints are conditions derived from the if statement that the symbolic inputs must satisfy in order to follow a certain path in this example there are three possible paths and at the end of each path we can see what is the the pet constraints they that Define this path the final step is to solve the model we use constraint solver also known as smt

to find concrete inputs that satisfy the contrast the constraints in this example there are two solutions let's take for example one a equals two and b equals one it means that if I put this inputs into this function the function would follow this path sounds complicated let's try to explain it in in a simple way imagine you are in a large maze full of twists turns and dead ends normally you would have to go through the path making decisions at every Junction and if we hit at that end you would have to go back

and this is like traditional execution of a program you give it input and you see where you end up now imagine that you have a magic bird's eye view of the maze you can see all the possible paths at once you can see where each the each Junction will lead without having walking in this maze this is like symbolic execution you can see all the possible execution path of a program um let's see how simple execution can identify a H actually scam tokens their C20 is Stand Out only defines the

interface of small contract token and the functionality can be anything so here we have four steps the first one is to run the token smart contract symbolically like we've seen before then we add constraints on important variables of the token smart construct like balances total Supply allowances these variables plays essential role in the behavior of the smart contract and you want to make sure the behavior is fair by solving the model we will find concrete inputs that satisfy the constraints and will prove if the

behavior of the token smart contract is fair or not let's see two examples who can mint my token [Music] um the risk with an uncontrolled minting is inflation which can lead to a drop in price here we see a real world scam example where a scammer added a backdoor to the Token smart contract with a functionality to be able to mean an infinite amount of tokens to use symbolic execution we should first Define the constraints the first constraints is increasing the total Supply which means the total Supply at

the end is greater than the total Supply it start the same as for the balance of the caller at the end should be bigger than greater than the balance of the order at start now minting can be legitimate for example in rupt token and LP token so we need to find a way to differentiate differentiate between legitimate and illegitimate minting for that we insert we add another constraint minting for free which means the color doesn't give any value in return for the minting so we also Define value equals zero and

allowance equals zero by solving the model we find that there is a specific input that satisfy the constraints that we defined earlier there is a burn function and if you give it a specific input amount equals to 11 anyone can mean an unlimited amount of tokens if if you can see on the right the this is the source code of the the scam smart token smart contract token and you can see the if equals B if B equals 11 it returns a big number and the burn function uses this this function so actually instead of burning tokens

it's minting tokens the second example is who can steal my tokens let's um Define theft as a privileged caller who isn't the holder can reduce the holder's balance without an approved allowance without permission so we Define constraints the color shouldn't be the holder and the balance of the color at the end is less than the balance of the color at start and the allowance equals zero which means no probation has been given by solving the model we found that there is a function called approve with

capital A which isn't defined in the sc20 spec usually it's approved with the lower a and you can see here in the implementation of this function the owner can set the balance of any holder which means he can reduce his balance which means he can steal his tokens um to summarize there is a known phrase in crypto don't trust verify sometimes it's hard to do that even if you have the source code of the smart contract and sometimes the malicious functionality is hidden and we've seen

yesterday several examples of how can we trick the verification method of iter scan um and what if you don't have the source code symbolic execution can fill that Gap it runs on the byte code of the smart contract and can prove if there is a some functionality of the program of the smart contract that is unfair that is a scam it's a necessary tool across the board developers Auditors security companies can use it can should use Simple execution at redefine we automated at scale we provide due diligence API for users for

exchanges for wallet providers recently we announced the integration with Nosa safe and every of their users can benefit from it if you want to know more please reach out thank you very much thank you so much Alan this is great and now we go from symbolic execution to fuzzers and giver and welcome to Antonio and I hope I'm gonna see some Harvey in there maybe no hey okay [Applause] oh it's fine so hi everyone my name is Antonio vigano I'm an independent security researcher

and I'm currently working on Audits and tooling one of these tools is fuzzy FYI it's a automated fuzzer on the cloud so today I'm gonna show a comparative analysis of fuzzers effectiveness and yeah so for this talk um I'm just going through a brief introduction of how a fuzzer work and how to measure uh an Effectiveness the performance officer um what would be the methodology for that and some key takeaways um

yeah so first of all uh yeah like in from from a high level overview a fuzzer we'll just throw some random inputs into your code and try to break it but going a step further we can think of it as like uh you start with some random value and maybe a corpus of previous uh transactions maybe previous input that you have sent then until you you are satisfied maybe you have break some invariants maybe you have crashed your program you will pick one of those observations you will mutate them and if they are interesting you kind of keep add them to

the list and you do that until you are satisfied so maybe reach a timeout and maybe you'll find a bug so um yeah naively we can already think that all fuzzers kind of are equal because they will just throw random input but that might not be the case since of these functions and this kind of bold uh functions here they might influence on on the performance of uh or effectiveness of a fuzzer so uh yeah so like measuring uh how kind of how well a fuzzer can can can be at finding bugs is challenging so first of all because it's uh inherently random

um and and also because the performance can vary a lot depending on the run so you might find a bug or bugs in the beginning of your campaign or maybe like after many hours um also because like it's different it's difficult to compare different fuzzers because how do you know that you've found a bug um and finally because uh yeah so there are different ways of measuring uh like performance so some solutions that are proposed here uh they come actually from a paper shared by some folks from 12 bits so like the the methodology suggests uh not using the average like

average time to find anything because of the randomness uh you might have very different results from run to run so it should definitely compare medians and and standard deviation across different runs um trying different seeds so depending on the seed value you can have different results and also depending on the test environment so maybe you are running on a multi-core instance or maybe uh on like just a single worker you can have different results um also it's important to first over long hours like not over only like a few runs so that you can have a very wide range of of values tested

um yeah you should definitely try to look for unique bugs so not double counting the bugs are the inputs that will make your your code crash basically and uh and also using a statistical test uh so that you can like make sure that your observation is accurate from a statistical point of view um yeah so here uh the the um the research that that I that I've done is basically comparing Echidna the latest version and Foundry um using uh on uni swap V2 so basically I uh we injected different bugs on

uniswap like 12 different bugs and we measure the time to find invariants that would break under these bugs um and then we run them for 30 different seed values and we set a one day timeout 24 hour timeout and finally we compare the median of those um of those uh times to break those invariants and we use these uh statistical test to assess which median is lower than the other under uh specific uh like confidence level and here is an example more in depth of

what that looks like so basically um on the left hand side is an instance of the mutated code so basically when you're providing liquidity to UNI swap you need to make sure that you are providing the same value of tokens of both tokens so um on uni swap you take the minimum uh value of both tokens that you are providing liquidity to make sure that you incentivize LPS to not imbalance the pool so a mutated code like with an injected Bud would be taking the maximum value instead of the minimum value so this is like an example of a manually injected bug and on the right hand side is like what we are

doing for our Foundry tests and Echidna tests so basically we have a ad liquidity first test and then we check if any of the uni swap V2 invariants break so for example one invariant is that whenever you add liquidity you increase k um and also uh like uh adding liquidity increases the total supply of LP tokens and many many more ordering variants so we have 20 22 invariants and if any any of those break uh then kind of there's a bug and here are the results from the study so just uh take some time to uh like uh

understand the the the the chart here but basically on the vertical axis we have um uh the time to uh find uh to break any of those environments for the mutated code um and and on the horizontal axis we have all of these 12 this different scenarios so each one is a different bug injected there so uh it's interesting like from just from uh first uh Insight is that the results vary a lot so some bugs are much harder to find than others uh for example like bugs number six seven eight nine they are kind of very uh easy to find and others not that much uh the

ones with the like hires uh the bigger bigger bars and and also the dispersion is not the same across different bugs so for some tests uh you might have a higher variance than for for the others um and we can also see that the performance may not be the same for for any of those uh fuzzers um and yeah so here are uh some key uh takeaways so basically um the performance can vary substantially from run to run so if you are using a fuzzer it will pick like a random seed by default and it will use

that seed so depending on the seed you should find your you should break your invariant faster or not so up to 100 like 1000 times faster like that can mean either find a bug in one minute or one day so you should definitely perform many runs in uh let your fuzzle run for many hours and also like Foundry will break in variants faster in some tests a kidney and other tests in other tests it's not conclusive so you should uh you should definitely try using more than one fuzzer it's not that hard to do it you should just like change a bit your your code there is an example on on the Ripple that I shared and

yeah and that that's about it so if you have any questions about uh fuzzing or or Security in general uh please reach out to me thank you so much Antonio great talk and last but not least we have Irene I hope hiring yeah she's there Irene to talk to us and teach us how you spend tens of millions in security sure yeah I don't know I actually don't know how this works Rajiv muli yeah the cable is there yeah

it's not nine minutes for how long yeah hi nice to meet you all I know this is super brief and it's getting to American dinner time so I don't want to take up uh too long but let's see sorry about this we're going to be talking through security principles for cross-stream messaging protocols and three in particular that should inform how you select cross stream messaging protocols but also how you design them

that works no it's not updating yeah it is sorry okay I don't know if that it's actually not plugged in right now

it's still showing up hold on [Music]

what's the Wi-Fi password anyone know the Wi-Fi password Here all lowercase DSS 2023 exclamation point at the end is community engagement I appreciate it maybe you can try a little resolution okay otherwise we have it in the backstage if

you want oh why don't you just do that yeah can you do that thanks thanks and enjoys this yeah amazing okay thanks so much thank you guys sorry about that um I'm going to run through this really quick uh we'll be talking through security principles for Designing cross-train messaging protocol so we often see multi-chain cross-train omnichine what are the differences between those three oftentimes when we're saying multi-chain we're thinking about isolated instances of your protocol deployed to multiple chains for a cross chain it's actual value transfer between different chains so that could be through a wrapped asset

Bridge it could be through arbitrary message passing many different implementations and then Omni chain is the sort of concept of mesh Network and actually enabling seamless movement of assets and information essentially arbitrary contract contract invocation between chains and why is this important I think everyone in this room understands the security risks and we'll run through that in a second but also the user experience and developer experience involved for me when I first got into the space I started as a developer at layer zero and thought about different chains like different programming languages you would never think to yourself what can I build with C plus plus you would think I have this problem that I want to solve and here's the product I'm going to build what are the

tools at my disposal to build that and so with the piping underneath the hood which is a cross-chain messaging protocol you can now Leverage The Best of ZK sync or Linea or polygon ZK VM and then also file a coin VM for storage pull in liquidity from ethereum and maybe launch your own app chain for sovereignty and to avoid gas congestion for maybe the game that you're building in that subnet or supernet what is layer zero I'm head of strategy at layer zero Labs we are the creator of layer zero the protocol and omnitrain interoperability protocol and Stargate Finance which is the most widely used Native asset Bridge its arbitrary contract and vocation and our protocol architecture and design is

is very particular to these three principles I'll walk through and also the concept of evolving with research so these three principles are immutability permissionlessness and censorship resistance this right here is the architecture of layer zero which may be useful later but I think it also might be hard for you guys to see it so I'll dive right into the first principle which is immutability when I say mutable what I mean is the contracts are they upgradable or not upgradable and uh the issues with mutability or upgradable smart contracts are that when you push code to let's say the core contracts for your Bridge you one are actually

resetting the security that has been locked and secured all over time but also pushing existential risk for all of the projects that have built on top of your your Bridge integrated it and all the the users who might hold assets from that as well in the same way that uh and I was speaking on a Bridges panel earlier today and used this metaphor if your treasure or Ledger were to push an upgrade and you saw that you would likely reject it or give you a lot of pause why would you accept the same for your D5 protocol and for many cross-stream messaging protocols they do use upgradable Smart contracts and so even if the developer is introducing a benign patch or is trying to introduce a new feature with good intentions the

chances that there's a smart contract bugging that which all the applications built on top did not opt into is incredibly high in fact the majority of bridge hacks over the last two years were because of smart contract upgrades not because of architectural flaws so you know even great and well-meaning developers make mistakes we all know this this is a graph that demonstrates what I meant by resetting security uh when you upgrade the protocol it resets the perceived security over time which is measured by value secured in time and where you see that blue bar is the upgrade to the smart contract how can you design a protocol that enables applications to opt in to the smart contracts that they've vetted and

have seen secure value over time but also have optionality because let's say the validation techniques we use today will not and likely should not be the ones that we use five to ten years from now how can you offer that without doing a complete overhaul of your protocol and that's exactly what the architecture I may have time to walk you through achieves and here it is a solution Library upgrades so how we design layers here the protocol was by deploying endpoints on each of the chains which we support and these endpoints are entirely comprised of immutable smart contracts however we can always launch new endpoints and applications can point their contracts towards those that means we could launch a smart contract Library which are the endpoints that leverages

ZK technology or some new validation technique in the future in between all of these endpoints are the off-chain entities that are involved in validating separate components of the state data and as you can see here it doesn't reset the security clock there is no Force to upgrade it's always opt-in for applications and it allows for time and money secured to reach a threshold that is acceptable before applications opt in the second principle is permissionlessness we talk about this a lot in many different contexts in the context of cross-chain messaging what I'm referring to is the ability for a developer to leverage your protocol in whichever way they'd like and in the case of layer 0 we are open and permissionless and application devs can

use it to create something that we might not align with from an ethos perspective but there's nothing we can do as layer 0 labs to interfere it also means that participation the validation and and network is also open permissionless so if you'd like to run one of those components yourself the Oracle the relayer multiple oracles multiple relayers you can and it doesn't require any coordination with layer 0 labs this also enables and encourages client diversity since maybe you have a set of 20 validators and you're requiring 13 of them to agree but all of those validators use the same code ultimately that client diversity is is one by leveraging different Oracles and relayers provided and run by say like chain link talk to him in gelato layer

zero Labs your own team you have that client diversity the optionality but also the backstop if your team were to run one of those yourself without unilateral control or centralization and this also uh leans into the uh dichotomy between protocol and service so when I say service I mean a product which requires the Creator company to maintain its integrity and liveness and the actual uh like value it's meant to provide a protocol is something that is Evergreen It's A Primitive it's immutable you can use it as you like and when you're choosing these really important parts of your infrastructure stack you don't want to be one adding more code exposure but two relying on a

founding team that might get arrested which happened recently with multi-chain or a team that may run out of Runway and actually just shut operations down or a team that needs to constantly be patching code so without immutability permissionlessness is never guaranteed and the final principle is censorship resistance we talk about this a lot in different contexts but in the case of bridging and cross-stream messaging it's actually even more important in my opinion if you have the ability to reorder messages as they're submitted that means that a high frequency trading firm could extract more mov for example by rearing messages and front running it means that if a nation-state were to

leverage cross-stream messaging or just blockchain technology for voting it would be possible to possibly censor a tranche of those votes layer 0 was designed to be non-sword or enforced and so every message must pass across the protocol if validated properly in the order in which they were submitted and so I like I said cannot reorder delivery of messages or censor individual messages and applications can also always choose different off-chain infrastructure by swapping in and out and again without immutability censorship resistance is not guaranteed I have about two minutes left these two graphs just show the growth of contracts that are building

cross chain omnichine multi-chain these specifically are contracts that have integrated layer zero in some capacity so on the left hand side's test net right hand is mainnet this is back from April um and it has continued to to steep up and to the right so it's actually just really exciting to see what's going to be coming out over the next few months we're seeing uh and I personally have been involved in in traveling the world to be in person with teams building omnichine stable coins tokenized t-bills for example that will be native on multiple chains and seamless transfer between them leveraging layer zero games that under the hood are leveraging ZK sync and a polygon supernet and ethereum but

abstracted away so the end user is just playing a game there is no tribalistic Affinity of it's a Solana game or a polygon game and they use one gas token and do one click in order to move their in-game assets between chains we're seeing nft projects moving between chains as well Trad five leveraging cross-chain messaging to communicate from permission chain to public chain and then of course across all of D5 there are so many interesting things happening with lsds and also lending and borrowing from one chain to another land in one chain borrow across five different ones collapse it into one click and use one gas token so it makes me incredibly excited for the the next

year the next five years since some of these projects take a really long time to develop and security really is at the Forefront of this it's unfortunate that nearly every single month there's some sort of hack but it comes down to the violation of these three principles and something that I encourage all the developers in the room to think about so I have 20 seconds left I want to thank you all for helping me with my Wi-Fi and being super patient really nice meeting you all and Happy to answer questions foreign this is amazing amazing work I like the upgrading memories it's a really good idea I'll hand it over to Molly for the closing remarks

yes so I'll go up I go upstairs do we have time for questions yeah absolutely one question there's one question I Rings Irene there's one question we have time for questions God I hope it's not a dumb question um hi I was wondering if you could explain a little bit more about pre-crime because that sounded technically really interesting um and yeah I know there's quite a few experiments going up um around in the ecosystem with local Forks simulations Etc and so this is really cool because it sounds like it's something that's

actually used in prod uction uh yeah so pre-crime is a proprietary security module that we created actually prior to the launch of Stargate which is the native asset bridge that came out about a month after layers year the protocol went live last March and what pre-crime does is it Forks every message that goes across the protocol and tests it locally against the set of invariants that are defined by the application and so that could be a formula that helps prevent the double spend issue it could be a set of whitelisted addresses for an nft migration it can be quite literally anything the application developer wants

it to be and only then will the message be pushed back to midnet and run across the protocol and the idea of it is stop a hack before it happens and the efficacy of monitoring once that hack is actually happening is as ineffective as a Twitter thread saying a million 100 million dollars has been withdrawn from this bridge the auditor sitting to my right on the panel earlier today was was talking about that and pre-crime is is meant to solve that issue no but actually interestingly right now pre-crime is only opt-in uh and it was used to protect Stargate like I said two

weeks after Stargate launched it reached 4.4 billion in organic tvl which was astounding it was the fastest growing D5 protocol of all time in that respect since then we have made the protocol so much more efficient and we haven't actually even reached Peak efficiency which would involve I think around 200 million of protocol owned liquidity instead of needing external LPS but I remember you know all of our devs were at the time in the Bahamas and just saw every single black hat attacker try and and break Stargate and we built pre-crime just for it what we're doing right now and we'll launch in Q4 uh hopefully sooner rather than later is we're scaling pre-crime as we say like to Infinity so every project all of those 6 000 contracts on mainnet can

leverage pre-crime right now it's not at scale to be both fast enough and to uh well yeah to be fast enough in support all of these contracts thank you thank you everybody it's my pleasure I think actually when we started this event I think I told you we actually didn't know that this will be so successful I really want to thank first of all you to all of you thank you a lot uh a couple of announcements and uh so I think we told you but we are actually launching this virtual event

so it's coming soon stay tuned it's uh more focused every month we're gonna pick a topic and cover it we're looking for more topics but we have many ideas and please let us know about things I think we have a lot of people who already expressed interest in speaking in this event we will try to be as inclusive as possible please stay tuned I think everybody want to know numbers so basically what I was told that there are 700 people who participated thank you all [Applause] I also want to thank the people who participated remotely and actually it seems like today thanks to the auditing and many others it's actually bumped quite a bit I think

we have 4 300 is it true are we okay so 4 300 people attended it's amazing I think uh special thanks to the AV team they are working hard at the back please [Applause] uh and I think I'm now coming today sort of the most pleasurable things I think maybe I could have the volunteers if you don't mind don't be shy come come up front like the please [Applause] yes so

I think everybody here they work so hard and I think I want to thank specifically Nathan where is Nathan here from the Italian France basically making these events so successful picking them the event making sure we have the food getting the deal with everything here and I guess not many of you know because everybody thinks that I did something here but actually Rick Houston is actually been working here for two years actually taking care of everything dogs everything and of course thanks the speaker and thanks you and enjoy everything thanks a lot

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