DeFi Security Summit 2024: Day 2, 9 November

Transcript

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e your usdc in this case cannot be

prioritized over your mudang coin and so the solution to this is state archival so unfortunately we're going to have to kiss our mascot goodbye so with State archival each piece of ler state is given a TTL value now when this TTL this TTL can be extended by what we call rent payments now what the rent payment system does is it essentially reconciles the fee system where we have a reoccurring rent cost to now match this or a reoccurring rent fee to match this reoccurring cost that the storage puts on the network now after a TTL expires the entry is archived and actually deleted from valid databases freeing up these resources and any transaction that touches an archived piece of information immediately an atomically fails but don't worry even if an entry has been archived and deleted it can always be

restored back to The Ledger and used again to do this we store all archive state offchain in a series of immutable Merkel tries then if you want to reuse that state again and restore it you can do so by providing a Merkel style proof of existence to validators now to demonstrate how this works let me give an example as to how we construct these archival Merkel tries so here what I have is an example of a data or the validator state at the very beginning of State archival before we've turned it on and you can see here that we have a validator onchain with a bunch of entries that have live ttls and an empty archive offchain now some time will pass and eventually these ttls will expire and so we see the first entry expires what we're going to do is we're going to

remove this entry from the live letter State and put it in what we call the hot archive this is a Merkel TR stored locally on bile data databases and so we haven't actually deleted the fired or archived state yet from validators it's still maintained locally for now and so we have this Merle try here some more time will pass another entry will become archived be removed from the live State and add to this hot archive now at this point the hot archive is considered full and so what we're going to do is persist just the Merkel root of that tree and then delete the rest of that Merkel try and now publish it to the offchain archive database and so what we're left with is a validator that only maintains the Merkel root of this archive try but not the actual archive State this process then continues recursively and

you can imagine that over time the validators store many Merkel roots and we have many Merkel tries in the offchain archive so this is the highle design now I'd like to talk about a couple of the particular attacks that this exposes and how we defend against them beginning first with what we call the double restore attack so in the double restore attack consider that I'm an attacker that has a tenous DC balance and I'm going to allow this to become archived as TTL expires so here we have an image of what the archive will TR looks like I have my 10 usdc balance in the first archive TR zero that's offchain so I'm going to then restore my 10 usdc by providing a proof of inclusion to this Merkel tribe to the validator now because the validators maintain the

Merkel route they can ensure the Integrity of this entry and actually prove that the 10 usdc really does exist so it gets restored now I the attacker will spend five of my recently restored usdc and allow the new entry which now only has a five usdc balance to become archived again and so this new 5 usdc value will become archived but it will be in the next new archival try remember because each of these Merkel tries is immutable we can't actually remove the 10 usdc Leaf once it's restored and now I as the attacker have a new up-to-date 5 usdc balance in archive Tri 1 and an outdated 10 usdc balance in the older try and what I'm going to do is instead of restoring the New Balance like I

should I am going to restore the outdated tenuous DC balance and it will now essentially result in a double spend now the validators have no way of knowing that this is an incorrect value because a valid Miracle proof of inclusion does exist and so to defend against the double store what we're going to do is we're going to require a more complicated proof system and so just like before if I want to restore an entry that's currently archived in Trin I will have to include a proof of inclusion for Trin additionally I'll will have to provide a proof of non-inclusion for the given key in every newer try what this does is it enforces that that only the newest version of an entry can be restored at any given time now this does come with one uh unfortunate performance caveat and that

is in order to prevent against a double restore we need to write both archived entries as well as deleted keys to the archive you can imagine if I restore my 10 usdc spend at all such that the key is deleted I don't want to be able to restore that 10 usdc balance a second time in double spend so you have to record both the archived entries themselves as well as the keys of deleted entries so that you have protections via this proof of non- including property the second attempt or the second attack is malicious archival and so in this scenario the attacker is going to take out a loan and that loan is going to have some token balance as collateral now as the attacker I'm going to purposefully let my collateral become archived such that TTL expires and I'm going to then default on my loan now the

loan provider actually cannot Rec collect that cized material because it's in the archive and they don't have the private key in order to restore that entury and so to prevent this type of attack what we're going to do is consider that all TTL extensions and Restorations do not require private Keys State ownership or any sort of authorization now this is generally fine it has no drawbacks uh there is really no negative impact to having an arbitrary member uh extend the TTL or restore an entry they don't own there's no nothing negative this can do and it allows Liquidator in our case to restore someone else's state that they defaulted on the only issue with this is that smart contracts cannot use the TTL value for security enforcement because any arbitrary party can extend that TTL so you can't use TTL to enforce like a

signature expiration in this case that's fine because there's much other design paradigms that smart contracts can use to enforce these properties the final attack I want to consider is What's called the double kns attack and so in this attack I'm going to have a victim that creates a non at determines a key and that non is going to become archived now what the attacker is going to do is instead of restoring the non value that does exist in the archive it's instead going to recreate the kns at the exact same key but with a different value now the issue is the vales have no way of actually preventing this because the vals don't know what keys exist in the archive and what the result is is that this is an eclipse attack where the attacker has a valid nons live on The Ledger state that actually eclipses the

legitimate value stored offchain in the archive and so to prevent this what we're going to do is kind of like we required proofs of non-existence in restoration cases we are also going to require proofs of non-existence when creating a new key for the first time in particular when creating a key for the first time you'll have to prove that that key does not exist in every single try in the archive obviously this is really inefficient and not a very good situation for the end user so we're actually going to optimize away the proofs of non-existence and so for each merel try in addition to holding the root node persistently validators are also going to store a binary fuse filter set of all the archive Keys a binary fuse filter is just an optimized Bloom filter now the binary fuse filter uh does produce a false positive because

it's a propus to accept uh but the properties of the binary fuse filter are such that favors safety over liveness what this means is that a false positive will sometimes not allow restoration of a valid entry but it will never allow restoration of an invalid proof now in the event of a false positive you can always provide the real full proof of non-existence to override the false positive so that such that liveness can still be maintained now the reason we use binary fuse filters that they're super efficient and this has essentially zero storage overhead compared to the space savings we would have if we stored all these archive Keys as a traditional set so where are we at this is not a theoretical work we've actually imp this so earlier in February we launched the interface for smart contracts on mainnet and currently the full proof system with

entry deletion is code complete is expected to hit uh mainnet later in 2025 thank you very much if you have questions you can of course follow me on GitHub or ask me on the Discord thank you very [Applause] much thank thank you very much uh next up we have Robert presenting hacking on [Applause] saano

e e all

right can you hear me ah nice nice okay so good morning thanks for uh waking up so early um I know it's hard at a conference so um I will be presenting today about salana uh and specifically hacking on salana um briefly on my background I'm a two and a half year um Solana auditor previously I worked at neod and now I'm currently um starting my own security and research company focused on Solana uh it's called the creation and yeah I have 10 minutes to talk to you today I think it's not enough time to explain salana so um I think I also don't want to do like a common box type of thing

because you can find that easily online if you're interested in these kind of things so I want to try something else specifically um I want to spark the interest of some evm people to hack on salana maybe and obviously the favorite bug class of Ean people is reeny and what better way to introduce you all to salana than to rency right so I probably don't have to explain to you what reeny is because you know it better than me um as a Sal guy right so the gist of it though is the we have like a a contract and that contract has a function that can be called and during

that function call it might perform some kind of call back to the to the uh caller to maybe maybe Ascend and in that call back the the contract is in an immediate State and the attacker can abuse this immediate state to call back into the victim contract and um do some action twice maybe or some some other things um well and I'm here to talk about Ry on salana right and the question obviously is does it exist on salana you probably heard of um these things if you ever researched this that um yeah let's let's just read it out like calling a program from an

intermediate say blah blah blah in this case reentry is limited by a simple self reion and limited depth okay second Solana's execution model rules out a large category of attack such as reentrancy oh okay note that reeny is inherently limited on salana due to its execution model the salana runtime restricts CPI to maximum dep of four and for strict account rules blah blah blah okay Solana consider more secure okay interesting because um the execution model disallows reeny okay apparently I I got something wrong and it's not possible on salana um so sorry I guess um but actually if you think about it and read

this in detail you realize okay it's only self reentrancy that's for allowed on Solana so what's disallowed is calling another program and then calling back to our original program and the stack dep so we cannot call another program and then call another program and call another program and call another program because there would be five programs being called the St stack that is limited to four on Solana and somehow these articles through the conclusion that this means there's no rency bugs and yeah I think this is wrong um and it's simp works like this um the reeny type of bug that is disallowed on salana is specifically the

one that we saw before which is like this normal re-entrancy where the hacker calls the contract the call contract calls back to the hacker so far it would work and the hacker then calls the contract again at this point at one time sees oh we have another contract call that already exists on the stack and it's not a self reentrancy so we're going to abort this whole uh transaction however what works on salana is uh the second case where um the contract just calls itself so the hacker calls the contract and the contract calls itself so you might think okay why when would this ever happen it's kind of kind of weird um architecture so um specifically our plan would be obviously

to have this the hacker calls a contract and the contract calls itself specifically as a hacker we probably want to make the contract call itself in an unexpected way if we want to exploit a re agency right so we have to look for contracts that we can tell how they can call something else so specifically more like this the contract might expect to call another contract so what kind of contract does this kind of thing you think about it actually there's a lot of contract that does that do this first of all multi so multi works by you proposing some instructions and then this contract um executing these instructions on behalf of a group of people um the same as a DA

practically almost the same as a multi then there's a virtual machine um I'll explain it later and I think yesterday we had a talk that explained that letting Bridges call arbitrary functions might be dangerous because also on salana it could um have sof ancy and Flash La also might allow you to um call arbitrary functions so actually there's a a lot of candidates for this kind of bug so I have a example for you so first of all a multi self frency how would this look specifically so um yeah so multi simplified has a couple of operations that you can do you can propose a new um

instruction or proposal and people can vote on it in the multi approve it reject it and maybe they can also revoke once they have um approved a proposal and it hasn't been executed yet they can revoke their approval maybe something changed in the um yeah in the surrounding prerequisites that they taught um so a normal yeah and you can execute it so in a normal um operation a multi would like someone be proposing an instruction then everyone signs on it and then the last person executes this in instruction so far so easy and um I've also drawn this up as a little uh flowchart um um The Proposal life cycle specifically so first of all we have a

new proposal that's being created then people start vot voting on it and it's voted until the threshold is kind of met and um at any point people can like um withdraw their votes again and when the thr threshold is met the proposal becomes executable and once it's executable it can only be canell or executed right those are kind of all the state transitions here um and now let's inspect a vulnerable execution function so this would be the execution of The Proposal once it's approved uh and this case would be a vulnerable implementation for example so we first check the proposal state is

this proposal executable then we just execute all the instructions in this proposal by adding our multis signature to the instruction and then executing it and then lastly we mark The Proposal executed simple right and I think if you're uh Sol an ethereum researcher you should have spotted already the mistake here that we are doing uh checks and then interactions and then effects kind of pattern um obviously we want to have our effects before the interactions so it's a classic candidate for rency um the exploit would like this would look like this um first we just propos two instruction

one is to transfer one Soul second one is Bob who's a m multi member is going to revoke his vote only Bob Bob will be able to execute this proposal so this is kind of a weird weird case um because the multis will add its um signature to these instructions but Bob can also add his signature so um that's why the multi can revoke Bob's vote so let's think what happens The Proposal is in the state of being executable that's our um starting point here B starts execution of The Proposal The Proposal state is checked it's executable so the um execution can

proceed then once all is transferred and then Bob's vote is revoked it's the second instruction of the multi proposal and the um proposal changes because one in one vote has been revoked into the state of being cancelled and then the execution ends and suddenly The Proposal changes into the state of being executed so we have suddenly a weird State change that goes from executable and during the execu executing node we suddenly change into the cancel State and then after the cancel State we jump into the executed state so we have like invalid State Transitions and kind of unexpected Behavior so that's the kind of bug here now you might think okay um it's a

weird bug I don't know if this has any real impact um well uh it depends a bit on the implementation details um if you implement it in a certain way where um you don't like you do your effects first and the interactions later but you don't write your effects to chain which often happens on salana um if you're an experienced developer um then you might end up with the proposal being canceled at the end even though it has been executed so that would be a obvious bug another issue would be that events would be um um emitted for ex for cancellation and for execution so it might confuse your front

ends um so worst case your front end shows this proposal as canceled even though it's executed and um yeah if if there was no cancel state but the voting state that we're going back to when we revoke a vote we might even be able to execute the same proposal multiple times um so yeah the counter argument for this one is obviously that um everyone sees what they're voting on so it's kind of a weird bug we classified this as low when we reported this um but it's still a very interesting kind of bug pattern um I have little time so I'll go through this quickly um there was a second example with a critical um impact there's a evm on Solana which simply

means um evm fully implemented as Solana instructions um running the evm so ethereum contracts ethereum accounts and so on are encoded as Solana accounts and they can mostly interact with each other with other ethereum accounts on Solana it's not the ethereum chain it's like a different chain that's like ethereum but running on top of salana um so it's kind of looks like this these uh evm contracts interact with each other mostly but they added a new um new uh pre-compile contract yeah which allows these ethereum VM contracts to call Solana so to call to the outside

world of this virtual machine it's like you run a VM on your computer which like has a Windows machine and this Windows machine can just call your Mac um to the outside and um in this we had like a re-entrancy buug where these evm contracts wouldn't just call any contract on the Solana whole Solana blockchain they would call this specific evm contract that's implement ing this evm and re-enter into a different contract um and this would be like a re-entrancy through like a host Escape kind of thing and this led essentially to the issue that we could um double spend any erc20 um or it would like defy

constraints like static calls we could make them non-static so um yeah that was a critical issue yeah other vulnerable contract types as I said Dows pretty much the same as multi Bridges if they can call arbitrary contracts it can be dangerous if they can call themselves flash loans I haven't seen a vulnerable implementation for Flash loans yet but there's not many flash Lo on Sana so um they might be vulnerable as well but essentially what I'm saying is for every one of these types of uh contracts we found the same self reentrancy bug on Solana simply because most Solana devs think there's no re-entrancy on salana um yeah how to fix these it's

actually kind of easy you use this checks effects interactions pattern correctly you make sure that you write your effects to chain before you call your interactions um secondly you can enforce that all your critical accounts are only passed read only when you do your interactions and lastly you just forbid self reentrancy so every time someone tries has to call um another instruction you check are we calling our own program or you just disallow certain instruction call by doing introspection all right thank you um that was uh my talk the takeaway self fre ency exists on salana and you can find me

here um yeah thank [Applause] you so while we wait for the next speaker to come up uh I have a question so you talked mostly about self- reentrancy in salana uh we have another family of reentrancy attack which is cross reentrancy where you have multiple contracts that needs to stay in sync do salana have any protection against that or is that another attack Vector so you mean it's the same program that just has multip multiple subprograms I had exactly another bug like this for you for this talk but removed it because I thought it's not not self rency but yeah I had a I had like this exist as well because you're calling a different

program technically right perfect thank you very much yeah uh uh so our next speaker is I'm sorry if I'm pronouncing it incorrectly it's uh T TBO uh talking about the challenges of uh custodian a non- custodian embedded wallet thank you can you can you hear me okay

yeah uh yeah so I'm I'm tibo and today I'm going to talk about um embedded wallet security so uh what is an embedded wallet uh the goal of uh eded wallet product is to improve the web three onboarding experience um to like remove the friction of having to write down a list of word and like secure it in order to secure your phones and instead to um like get closer to what we have in in web to which is you can um create a wallet by click of a of a button and you can like recover your account uh recover your wallet if you lose if you lose your credential but we we still want to have

the web three guarantees which is like ownership where creating non- costal wallet and decentralized Trust so in term of um of UI um you we we start to see more and more on decentralized application so it's like when whenever you click the like usual connect wallet button you have like your metamask open Wallet wallet connect experience and then we start to see like enter your email to create an embedded wallet or like just scan your face uh scan your fingerprint and uh you're going to be able to create a wallet so that's that's the experience that you're exposed to when you uh go through the embedded wallet

flow so how is it implemented um most of the time for the decentralized trust you have some cryptographic protocol like shamier secret sharing or multi party computation where um the private key uh doesn't live in one place but instead you have multiple key share that are used to perform a valid signature and uh we also see like more and more pass Keys uh that are used in order to create um embedded wallets so for ownership whenever you have like Sam secret sharing or multi party computation I mean not always but usually you have like one key share that is push on the client side and that lives on the on the

browser local storage another type of implementation that we see is um you have like the anent private key that is decoupled from the credential uh that you use in order to interact with uh with your wallet and that creates like a dual security layer or we also see a mix of of the two where you have like some client CR cral that are that does not represent the onchain private key but that are used to unlock some specific onchain operation that usually require some like specific or blockchain protocol um yeah some support at at the uh blockchain level um the Stellar folks are doing some great things about that so you

should um talk with them if you want to learn more about it um so how how does that look um usually when when you have like um the embedded wallet experience you have three parties you have the clients that interact with the DAP and then whenever you click like the connect wallet button you're going to interact with the embedded wallet provider which is another party so as a user you're going to authenticate to the DAP it's us usually like a standard web to authentication and whenever you click the embedded the connect wallet button you're going to like the user experience of the embedded wallet is going to be uh loaded um through an if frame or through

or or or through a new um a new window and uh you're going to be able like to enter your email authenticate with the embedded wallet provider and then create a wallet and and you going to have a like a local share that is generated on your on your local browser um and then you can leverage that to perform a signature uh in addition to that usually uh we see an implementation of another flow at the same time which is a recovery flow implementation and so it's used to like recover access to your wallet in case you lose your credential or in case you uh like change device so like if you go from like desktop to

mobile since you have a share that is like generated uh locally um when you go to another device you don't have this share anymore so you need a way to like recover access to your wallet so how is it done uh what we've seen in production is that um during the wallet creation you have the embedded wallet provider that's going to share the authentication token with decentralized application this will usually be set as a as a cookie and uh so whenever you you change a device uh you're going to authenticate with the decentralized application and then the decentralized application is going to

return the embedded wallet Authentication token that's fine you're going to use this token to authenticate with the wallet provider and then you'll be able to like generate a new uh like perform a key share refresh and generate a new um new shares and so get B get uh access back to your wallet okay um that looks fine but if it's not done properly this can create some issue so as I said you have two step you have like the embedded we provider that's going to share the authentication token with a decentralized application and by the way can you see all the text oh yeah okay that's fine uh and then you as a client

you're going to use this authentication token to authenticate with the embedded wallet provider and then uh like perform a key refresh and and get back into your wallet so uh if it's done just like this the first problem is that the eded wallet provider is going to share an authentication token with a decentralized application and this authentication token usually I mean in some implementation lives as a as a cookie under the dab domain and so then um this cookie uh can be and we've seen that we've seen that in production uh sometimes it's the only thing that that is needed in order to perform the key refresh operation so to

authenticate with a world provider and perform a key refresh operation so in other words uh that means that the security of your onchain private key is as strong as the security of your authentication token so um that's the first problem the second problem is that this authentication token is shared with a decentralized application so in other words the decentralized application has access to all the secret that is needed in order to recover your onchain uh private key so they become uh sometimes without even um knowing it like a custodian of of your wallet because they can just access your private key also

cookie are notoriously very difficult to secure they can live on like different data store under your infrastructure sry data dog and and all of that and so remember this now lives under the decentralized application infrastructure and so it's difficult to secure it's difficult to understand who has access to it so like putting all of that together I was able to like write a simple script that takes as a input this authentication token that now you get whenever you authenticate to the decentralized application and um you can just like pass that to this script this script is going to make few API call to the wallet provider and then it's going to recover your private

key okay so now you may Wonder um this experience looks cool uh but how do I know if I'm interacting with a secure system or not so you actually have a very simple way of of checking that is whenever you expose on the decentralized application to the embedded wallet experience you can just open your uh console under like the application tab uh so you will usually see like multiple storage that are dedicated to the DAP that's fine you don't have to touch those and then you will see some local storage that belongs to the Ed wallet provider so under the UN bed wallet provider domain cookie and storage so

what you want to do is you want to clear those storage so like you simulate that you change device or that you don't have the authentication token anymore then you just refresh the page and uh if you see that the wallet is loaded again without uh you as a user having to input any secret that means that uh the DAP has all the information that is needed to like recover access to your wallet without uh uh any information from you and so you you're that's a problem you you're not like interacting with a secure implementation so now if you ever want to like develop an eded wallet experience my advice for a secure

implementation is so like two things the first things is to leverage as much as possible publicly cryptography so you want the client to have um like a priv key it's not not necessarily linked to the like Unchained private key but as a private key and you as embedded web provider you only have the public key and you only use this public key to validate authentication uh we've seen some embedded wallet provider like using top to secure access to their system uh that's not advised because top is based on a shared secret and so that means the embedded wallet provider has all the information that they need to

like fake access to your wallet and um you won't be able to prove that it's not you that access your wallet because this is based on a shared secret so always use public cryptography so that only the client can perform some signature to authenticate to your system like webon and pass key again are great implementation of that um and also another um um advice is to not expose the onchain private key uh inside the cloud uh like browser local storage because um um then when you lose your device or when you go from one device to another you need to perform a key refresh operation that's very sensitive

operation so advice would be to use a credential to decople the security of the credential from the security of the onchain private key okay that's it thank you very much uh what we can say is that when we look into that we encounter various flood operation in production we reported the issue to like the wallet provider uh each time and so we we've seen some mitigation that have been deployed following our report so that's great but we still have some insecure implementation in production and so um one last thing is I'm talking with a lot of people that perform like smart contract security audit security firm that are like

dedicated to Smart contract uh there is a a lot of things to do on the infrastructure side as well and and all these like like offchain uh system that interact with a blockchain and uh yeah there is a lot of like Improvement that can be done and things to do so don't don't hesitate to go look around that because that's that's an interesting area as well thank you very [Applause] much thank you TI for sharing the dark arts of embedded wallets and next up we have Carlos from Ford talking about Aid driven detection and prevention of malicious um blockchain transaction

great aome good morning everyone thanks for coming instead of staying sleeping I really appreciate that I know it's hard because it's 9:00 a.m. but really appreciate it I'm Carlos I'm the head of AI at the for foundation and I'm going to be explaining to you today how we are using AI to actually prevent malicious transactions and yeah in blockchain I know AI blockchain I'm a big fan of saying this keyword I promise there is only one more over the presentation but it's going to be fine so first of all I want to give a little bit of context of because now I'm talking AI for

prevention but fora started a couple of years ago with monitoring so we started using machine learning to analyze blockchain activity and we were looking at um how a particular address was funded the smart contract they were deploying and we were using machine learning in several different flavors to be able to detect when something was going to be attacked but we were doing monitoring right which means that we were finding that someone was potentially an attacker and we were saying you have an attacker here but that's it right and that's not so enticing it's not so interesting because yeah okay I know that's an attacker but

I don't have any of these tools to actually stop this attack today we are moving a little bit forward and instead of just using this previous part that we were commenting of we are looking at funding we are looking looking at the Smart contract that they are deploying we are just directly screening the transactions themselves to try to identify whether a transaction is actually performing an attack or not one of the things about detection especially in this last couple of years is a lot of people have been working on this thing and detection methods have been gotten much better and a lot of attacks that before we were not able to detect now we are able to detect before they actually incur into any losses

right right but we are able to detect does not mean that we are able to stop them and even in cases when we can see an attack and we say like okay this is coming you you might even start losing some of the funds because like a couple of transactions already went through and you were at bit too late plus there is the problem of there is not a very strong mechanism on what to do to actually stop this attack transactions right because you can stop your protocol but then it comes with a lot of other problems the people cannot do like normal operations and you are just like blocking completely and it's like a very extreme measure so we think that there is a better way of doing that and this is what we are introducing as fora fireable

which mostly what it's doing it's like it's looking at the transactions in a from a stess stateless point of view and this is something that I'm going to spend a lot of time afterwards because I think it's really interesting and it's really important in order to be able to stop transactions and this system is actually able to block these transactions before they are happening we are not talking about sping the the protocol we are not talking about further influence that literally just stopping the transaction itself that it's an attack transaction so there is no other PR to operations other than you are not losing your funds that sounds amazing right great so now let me give you some more information on I have stateless here I'm going to explain why I mean by

stateless at this point and I'm going to also explain a little be to you how to create these AI systems and what to do with them what's the process to improve them how to validate them and so on and so forth so great by stateless now imagine that we are looking at a transaction and we are just looking at a transaction right and we want to identify whether that transaction is an attack or not like are we is someone is is it behaving in a different way how it's supposed to be and someone is gaining money or funds or whatever in an illicit way yes then we stop it easy right well not so much otherwise we would have already be doing it like and no one would lose anything but let's

look at the transaction itself what do we have there we have what we are using to generate this transaction which is like who is sending the transaction right where it is being sent and what is being sent so the data and the state of the chain like you need the the block number just to have an idea of how things are there okay that's your input you have nothing else then what you can do is using that information since it's a terministic you can simulate your transaction and then on top of having the from the two and the input data you would get the logs of so what actually happened in the transaction and the traces so who is interacting with who like who is sending like whatever delegate call to whoever other contract

and know that information and that's it that's all the information that we have right it's quite different to how a normal person right now a security researcher would go into a transaction identify okay this is an attack or this is not an attack we are just looking at the transaction and actually in my opinion this one has a little bit of a problem also because we don't necessarily want to stop people just because of who they are or who they interacted with to actually stop things right so just because you are a person that was interacting at some point with tornado cash doesn't mean that your what you're are doing in in this particular moment

is actually legit and you just want to be completely Anonymous you don't have like any malicious intent so just the fact that you are funded by one of these mixers doesn't mean that necessarily you are going to have this illicit content right so the the from the two even though we are using the mass Flags because it's a lot of valuable information to know within the interaction who actually is started the transaction right like we know that a certain address actually is the one that is doing this call to this other address but we don't have any extra context about that address we just know that this is the address that initiation that initiated the transaction and that's it we don't know anything about it so this is what we mean by stateless like each

transaction is stateless is completely independent on anything that has happened before and this is something very interesting because let's compare it to how a stateful or like how right now any security researcher would understand what is an attack you would see a transaction that is weird that you have like a lot of there are a lot of funds moving and so on and so forth and then you would go to the other State starting you would check their funding you would check whether it's coming from a mixer whether they are like coming from other ilicit accounts like how are they getting funded how are they getting their initial money what is their past Behavior right so are they doing also Weir stuff do they have like a history of scamming

people before and it is known or do we have like any extra information about what this address is doing or like which smart contracts have we deployed we can analyze this smart contracts we can see whether they were good or bad they were potentially malicious if they have a story of deploying malicious smart contracts and were funded by tornado cash and how really scam people then well I guess this person is probably a scammer and attacker right so it's kind of dangerous but and then we also have like some heris rules of like okay you are completely emptying the pool blah blah blah that it's like either very general or very protocol specific so in the end what I want to say here is that this is a lot of extra information that we are taking into

consideration right and this is what we are considering by stateful detection because we are taking to State the previous state of everything that has happened and we need to have all these context for transactions and so on but have having this context obviously helps right because it's always nice to have more information about it but it's a slow like whatever you do you have to have this things somewhere you you cannot have it like excl you cannot have like a huge memory with all the others and understanding what each one of those is doing so even if you have like a nice system where all of this is together and you still have to call it you are still adding like a couple hundred milliseconds for every transaction that you are trying to detect and when you want to go at a

proper scale and you want to go more to like when you want to be working on a roll up instead of just protocol specific that is just too slow you are going to potentially break the stuff and this is something that it's just not acceptable to be that slow when you're doing this thing so this is why doing stateless and just looking at the transaction itself it's really valuable right it has like these two main points of first of all it's faster because all the information is already there and you just need to run code over it plus there is the um I completely lost my line of thought forever cool so now let's go to how we can train a machine learning

model of Ana right this is a very standard machine learning life cycle of what you would do and here you're going to have to apologize me I'm going to use the word Model A lot and it's going to mean two different things because like you have the model of when you're modeling the data and the model of like the Deep learning model when you're doing inference I'm going to try to do deep learning model if I don't you can hit me afterwards you can't find me for a coffee and should throw it in my face because it was confusing so great so how do we start we have the transaction right and we have like the from two data logs and traces and that's it the first thing that we need to do is model the data and

that in this case model the data means we check whatever input data that we have and we transform it in a way that it's it describes our transaction in a unique way and it's it has a format where it can be passed to a machine learning model in our case a deep learning model like deep learning models here and in this convers in this talk I'm talking about AI I'm not talking llms uh llms are not necessarily the best tool for this job but yeah it's a bigger umbrella there are other type of deep learning models which is what we're actually using just imagine what we have been seeing like some years back this

computer vision we were identifying things there the model of the data was the image itself because it's good enough but now what we need to do is transform it so just for the sake of the example let's let's imagine that we are modeling into a table which is an input that you can actually pass to a machine learning model so we can start with like a very simple model right and we start with something very simple and we will just assess and have it as a baseline for that we would create like a model that has and again I'm going to be extremely simplistic but what was the total profit of the transaction so which address profited the most and how much did it profit and how many traces did the transaction have so did someone profit a lot was it a complex

transaction that's like a extremely simplistic model of the data but that's something that already allows us to keep moving into this uh into creating this machine learning model what is the next step we have to collect a data set we are going to use what is called supervised learning supervised learning mostly what it means is you present the model with a set of data and you are telling the model like hey you see this observation this is bad you see this observation this is good and you do that a lot of times very eratively and in the end the model learns how to do over that thing so for that what we did is we create this data set of previous attacks of the the transactions that

we're actually subtracting the funds but not only you need to also have like good transactions to be able to differentiate them right so you create like this big data set with these hundreds thousands of attacks and these thousands tens of thousands of banning transactions and then you train the model right training the model here and this here is the Deep learning model and not the data model uh what you do is like you do this iterative process over a certain amount of aook I don't know how familiar with machine learning but this is like standard procedure you train you have a loss function and mostly the loss function what you are doing is optimizing a function so that the model what you are telling the model to

be true so these labels of the data set that we commented before it gets minimized and the model has learned what you are actually teaching him okay now you have a train model with that you can already defend blockchain yeah sure you can try but then since we are like at extremely simplistic point of time we have like a very simplistic data model it's not going to work that well so what do we do you go into evaluating the model and you take millions of transactions of normal operations of several blockchains and you evaluate that and you see that your model is bad because at this point it has it has not enough information to actually learn whether a transaction is

good or bad right so then you go back to square one and it's like okay I know that it's bad how can I improve my my my data model so you start thinking you take a look at your evaluation you look which transactions you fail a lot and then maybe you saw that there are transactions where someone has there are several people with profit and in those ones you were very bad okay then you add a new variable to your model data which is okay this this um this transaction actually has three people on profit and then you do it you do again in the collection data set you already have a data set

from the previous step but you can use the most representative data points that you have um collected during your evaluation because that's the way in which you can keep improving your model like you evaluate it you see where you fail you tell to the model you were wrong here and the model say thank you and it won't do that mistake again then you train the model go again to evaluate the model it's a little bit better you see another thing and then you keep doing this iterative process until eventually you have a model that actually you're happy with the performance and that it's actually able to detect attacks only using transactions and that's super nice and beautiful right this cycle is something that it's called mlops which is the other keyword that I was missing at the

beginning it's like this is the most keyword in ml after AI probably right now this is literally devops applied to ml so it's just a way of having like an interative way of improving your models and monitoring them to make sure that they don't get worse over time because that's something that kind happens and that you are still finding the stuff having this type of mlop Cycles is also extremely useful because imagine that you are working with some customers right and then there is a type of false positive that it appears often and here often means like once per month right but like once per month you have one false positive with one of your customers and it's always the same type of transaction when something particular happens your model gets confused and it says that it's an

attack even though it's not okay doesn't matter we have the cycle we put it into our cycle the next iteration of the model is not going to be wrong at that point so it's it's a model that by itself it's good it's already able to detect a lot of attacks but it's also going to keep learning and learning over time and it's going to learn over the things that we are actually failing so it's just getting better and better and the things that we actually care about what is the output of the model right because right now the previous slide was a little bit theoretical and was like yeah okay the output of the model what is what is this model actually giving us like in the example I was using before of pictures if we are using computer vision the output of

their model is like is this picture a cut or a dog is is it a cut or is it a dog but here we are trying to evaluate how risky a transaction is right so the way that we Define the because this is something that you have to Define in the model and it's something that you need to Define when you are defining your loss function and your objective and this is your end goal what you want to do in a beautiful world is that every transaction that is an attack is at one every transaction that is not an attack is at zero of course that's never going to happen because there's something in the middle but that's the goal right so what we end up is like with this spectrum and the model gets good enough when most of the attacks are as close as

one to possible and most of the no attacks are as close as possible to zero something that is also interesting is that since we are generating this risk score and this is not only like a single value right it gives us like a complete interval of data we can actually depending on who is using it they can decide how risk averse they want to be because some people they want to be like no if you are even a little bit concerned that this might be an attack I want you to stop it then you can say like okay everything that is over 0.5 gone you going to obviously have a lot more false positives because well um that's how things work in automatic systems but you can make sure that you are not losing anything because over 0.5

it's very extremely difficult that nothing is found on the other hand if you just want to make sure that it's a stop if it's like a very big attack and like the confidence is very high because you prefer losing a little bit of fun instead of annoying your customers then you just go over 0.8 which is recommended value that's why it's red and then you will only stop like attacks that are very obvious attacks so this is actually very interesting because it allows some configuration even though it's a little bit um esoteric at some point but you you can get like some understanding of how risk a transaction is and you can decide based on your risk aversion so now this was the detection part right like this is like when we

were looking at the transaction um what we actually can say about the transaction being an attack or not but I also prom I also promise you that we are actually stopping the attacks and preventing them how do we do that I'm going to go very low here like I'm not going to go into a lot of detail because the point of this talk was mostly to talk about the detection and the AI that we are using we have a workshop today at 3:30 where we are going to go more into detail into this otherwise you can find either Andy or me we are going to be around and we can explain a little bit better but the main idea is like this right so uh a user a transaction and the main point is that for users don't need to know that they

are already protected by fireable right like this has to be as easy as like users need to know that they are a little bit safer but they don't need to know how it works it has to be as easy as possible but it also needs to be very easy for actually protocols or rollups that actually want to implement this thing so I promise you it's very easy and like we are making it easier every time we have a couple of different flavors of of how this thing is implemented depending of whether you are a rollup or whether you are a protocol um it works a little bit differently but like both of them are very low friction implementation and once it's set you can just set your threshold and any transaction all transactions are going

to get screened and the transactions that are over and threshold are going to be not executed um and it really works like this right so a user sense a a transaction it goes normal operation as that user would be um the transaction gets screen at some point like it gets at going a little bit to for the firewall it gets analyzed we decide a risk score for the transaction based on our machine learning model then the transactions that are over the threshold that the user not the user like the protocol user actually Define are dropped because they were too risky and then they get l there is a dashboard

they can take a look at it Etc and they can decide okay you were wrong here you can your your next model shouldn't be wrong in these type of things and the transactions that have low risk So Below the threshold they go normally um the user doesn't see it because it's fast so it's very seamless and like most of transactions very most of them are never going to see any of these things so I'm talking Al a lot bit theoretically I want to show you some numbers of how this actually work right and like the results that we are having for with the model that we are having right now first of all like we did some test on September September had like around $40 million lost due to

attacks out of those 40 Millions we detected 99.8% of the transactions that lost this money so almost all of the attacks that happened were there out of 40 Millions we defended some we could have defended something like 39.9 million it's amazing because again it's just looking at the transaction we don't have any context we don't care how you were founded we just care what you actually promise that you're going to do like I think this is very important to take to take home that it's not about what you have done before it's exactly what you have already committed to do in the blockchain right now that you are being stop so it's not about previous you can do whatever you

want before what you are promising to do because it's the transaction that you are sending at this point it's the thing that might stop your transaction so when you are you you are showing that you want to to steal those funds then regarding false positives at the rollup level so when we are analyzing all the transactions over a chain we are having at like one false positive around every 150,000 transactions or so or better but like let's go one every 150,000 transactions this would be what um 10 full positives in the whole main net in a whole day like some other chains are like much better than this still so this is not a lot of transactions this is like for example

arbitrum this is like almost 500,000 transactions we have one FSE positive which is the one that is in the red part like this is the risk score that I showed you before just like a histogram it's in logarithmic scale okay like the one on the right it's a one the one on the left is at 445,000 so if it wasn't logarithmic we wouldn't see the risk one so that's why it's in this way then for example in base we also have one that it's at one right yeah casually this was around the block when the summer money incident happened so that's the transaction that was in summer money so we the only actual risky transaction that we have and this is already around 100,000 transactions is

the one that was actually an attack so this is something that we could have prevented and then it works a little bit different when it's for protocol because like they are more concentrating and things they are doing and like direct transactions are like easier to scan and so forth and here usually what you can expect is like to have one F positive around every three months but let's be honest like defending 99.8% of the money for just the pain of once every three months having to log out into your dashboard and say like hey this was not a false positive that you know it's going to get improved over time it's very nice and this is like an example of one protocol that we are working with so just for you to know know that there are literally nothing even in the yellow and orange

zones so this is for the firewall this was how we did how we are using AI to actually start H stopping malicious transactions anything that you want to uh to ask us like Andy and I are going to be around today we are going to be around in Devcon find us speak to us you can contact us by email whatever you find and yep I hope you liked it [Applause] thank you very much I don't think I'll throw coffee you but I'll definitely have some questions to escalator uh our next presenter is uh tun from Gauntlet talking about Dynamic restak security [Applause]

perfect thank you uh hey everyone uh thanks for uh uh coming uh I know it's early in the morning and some of us are also jet lagged so I I very much appreciate it um so we're going to talk a little bit about reaking security um I think obviously as these networks are going live there's tons of capital in them it becomes more Paramount to think about what a a security model is B what threat models are and C how to model them um I think I'm going to in this talk I'm going to sort of be more high level but almost all of the results you see or are mentioned are in papers online and you can find me to find them so we're going to kind of talk

about three things to to understand reaking first we're going to kind of Define reaking in a uh sort of more combinatorial and algorithmic Game Theory sense as a matching Market um then we're going to talk about different threat models how those threat models affect how you should assess risk in these systems and third uh we'll talk about what the notion of the minimum amount of security is uh that needs to be uh in these networks so first we'll talk about matching markets so reaking networks are effectively matching markets between validators who are already operating ethereum for instance or or Sal and the goo case and services services are extra new protocol extensions such as rollups

oracles Etc that um are are trying to to utilize the the security of these from these valers in classical matching markets you know this is sort of one where you're looking at sort of dating preferences and you can kind of see hey the the set of edges represents the set of all possible viable matches uh in the thing on the left there's a feasible maximal matching and the right there's a a contention so matching markets are sort of everywhere um I think you know people won the Nobel Prize for them but the main difference about matching markets and sort of things like auctions that you and MV uh are you generally have inhomogeneous Goods that have some

shared property on the supply side so this in um this in the case of avss is is validators so some validators might be running BFE Hardware can run your extra service that needs a bunch of gpus some validators are running on Raspberry Pi they can't run all avss so there's some sense in which all of them share the fact that they're running ethereum consensus but they all have slightly different uh properties um a natural place where where you see matching markets outside of uh these types of settings is is kidney exchange and in kidney exchange you have this notion of Supply like everyone has kidneys a lot of people can donate them but there's all these constraints blood type size um

kind of you know how old a kidney is whether it's it's had dialysis Etc right so you can kind of think of each validator as a different kidney in this case uh I'm sure those with raspberry pies are the ones with the worst kidneys unfortunately uh on the demand side you have services so that's oracles uh co-processors uh GPU networks Etc that are sort of demanding uh being operated so one important thing to understand about matching markets versus auctions you might say hey couldn't the validators just run an auction and say okay like you service Oracle like you have to bid for us to run your Oracle site light client or side client one

important thing is auctions focus on generally maximizing revenue or maximizing welfare for the the buyer and the seller matching markets are focused on stability which basically means when I match validators to Services there should be no one who's unhappy in the sense that they would rather have switched and been matched with someone else and in crypto we've seen uh especially over the last two years the micro structure move from a lot of auctions so me auctions uh poke pair chain auctions things like that to much more matching like things like intense and and reaking uh the natural way to represent matching markets uh is of course uh via graphs and the idea is you have a

bipartite graph that represents the supply side and the demand side those are the two portions of bipartition uh where one side is the supply so the validators and one side is the uh demand the services one important thing to note is that in most matching markets that are studied outside of crypto the this graph is static so it doesn't change so the set of people who could donate a kidney is not changing uh and there's usually a central planner so the central planner chooses the matching but in decentralized matching markets like reaking that's just not true okay so the first claim I made is is reaking is a a decentralized matching market so when we want to analyze the security of match markets uh they're a

lot harder to analyze than sort of the the classical ones that we know of one of the reasons is a permissionless means you can be matched and unmatched at will B without a central planner the only way to to construct matches is by correct incentives and C you have to actually have an explicit adversarial model so what then we'll see some examples of this but you know for instance if I ask you the following question ethereum has a billion dollars of stake let's say hypothetically what amount of Economic Security does it actually have right you would actually have a hard time answering that if you said it has 333 million for double spends that's a valid

answer but that's not really the notion of Economic Security for these other services so for an oracle Oracle manipulation might actually cost less because I only have to bid in Block building auctions for a certain number of time and so there's sort of some notion in which the types of attacks you're modeling can Define what it means to have a certain dollar amount of Economic Security and as you can see no one on the internet agrees uh so maybe we'll take a a tiny detour to try to talk about what the notion of Economic Security is uh I I think you know you can you can you know exercise left to the reader to to go find all the million tweets about people fighting and being

Inc consistent so as I said earlier you know what does it mean to have $333 million of Economic Security so there's sort of a sense in which this concept of nebulous concept of Economic Security in an absolute sense is very hard to Define you have to choose what asset you're measuring in you have to enumerate the attack space you know double spends are not necessarily the only attack anyone cares about in 2024 you have to consider competitive pressures for stake why would I lock up my Capital if I can get yield elsewhere that's higher and you also have to think about how much the the opportunity cost for capital is of doing an attack and also how long it takes to execute an

attack but generally the the kind of attack cost is linear in the amount of stake somehow so you're writing this in in formulas you know we kind of say the cost of attack is lower bounded by a price P oft times the amount of stake times some notion of compounding or opportunity cost based on how long it takes to execute an attack time some notion of a minimum threshold of stake needed to execute the attack so this is sort of just a generic way of saying this is what a lower bound on economic security is within POS for different attacks what does that look like for

reaking well reaking actually has two sort of competing pressures when you try to quantify what its Economic Security is the first is is participants purchase Stak uh to capture excess yield so if more people are buying ethereum to restake they're actually causing the economic security and dollar terms to go up so in some sense you can argue that reaking can improve if if a lot of new participants are purchasing on the other hand if people get slashed that reduces the overall network security right because I've basically burnt a bunch of stake that was locked and now effectively the total amount that can be slashed in the worst case event has gone

down so how would we represent this it's not so different from the last formula uh we have a notion of a a stake that's the capital Sigma we have a notion of a price numerator terms we have a notion of how much people increase the value which is this one plus Delta turn and then we have a notion of a risk measure which is how much stake is burnt what percentage of the stake should I expect in an average case or worst case scenario is is slashed and then I have a notion of a price impact function so what this is is if there is demand for Delta times the stake uh that is there how much does that actually push the price up and then

cause the actual cost of attack to go up so if we zoom out one of the reasons for to trying to formalize this is you're really trying to measure some notion of cost to attack oops I guess that one uh was there so one question is when is reaking safe uh and so one one very simple definition is the cost of attack when reaking is present is always higher than the cost without reaking and that's what this inequality is if we write that out we get this formula and if we write this out we get a formula that says the amount the risk the maximum amount of stake that can be slashed has to be as a percentage so this is from 0 to one has

to satisfy this type of formula G is a a value greater than one and so one important thing to note is that this this has this dependence of like the risk the slashing risk on the actual price impact of people participating in reing which is UN is not great right because from a say formal verification standpoint or for from a fuzzing standpoint I can't really check this condition I can't make this a a valid condition that needs to be met so the natural question is can we model this without needing the price or St demands Dynamics can we kind of have a static model for what it means to for reing to be secure and then you can construct formal conditions that you could

verify so to do that we will have to do some math so the the main object of study uh Within These systems is what's what is called a restak graph um a restak graph consists of five components first is the of node operators so these are the validators who are operating the network uh that's the set V second is the stake so for each operator you can think there a Vertex label for each operator of how much stake they have third is the services so this is the avss so this is your Oracle this is your co-processor this is your da layer Etc third is a notion of the maximum

profit from corrupting a service so in this model you sort of assume there's sort of a maximum Honeypot prize that if you were able to corrupt a service you get to get this amount of reward so that's what pi is the fifth component is a corruption threshold so in say a bft protocol it might be oneir which is the sort of double spend and proof of stake in a longest chain protocol it might be one half which is the sort of attacka longest chain protocol um and one important difference between reaking and normal staking which is extremely crucial to the security model is that I can use the same state to validate multiple services so this node operator V

intersection uh is actually operating both Services S1 and S2 with the same stake so they're putting up a 100 eth they're validating both of those Services if they get slashed by either one of the services it's as if they got slashed on both Services that's a crucial point that you have to keep in mind when thinking about this okay so now you might say hey is this graph real like are you bullshitting me and like you just wanted to do some math for fun this is the igen layer reaking graph um over time green are edges being added uh the right side is uh the services the left side is the operators or sorry am I getting it backwards yeah left side is the operator

sorry right side is services but you can see that this graph is changing as people are adjusting incentives over time and that as you saw earlier affects the security of this system so how do we how do we formalize in a sort of formal verification sense what an attack means so there are two conditions first is profitability profitability is give me a subset a of services and give me a subset B of validators who are colluding to attack that set of services and you need the profit to be greater than the slashing penalty so what this means the maximum profit I can extract from attacking those Services is greater than the amount of stake I lose

right so that's a positive uh profit attack the second thing is feasibility so what this says is for every service I'm attacking this cartel this set of validators has at least the minimum amount of stake needed so this so for instance if one service is a bft protocol the attacking Services have at least onethird of the stake in symbols this is what this looks like given the variables we saw earlier on the left hand side you see the total profit from backing the set is greater than the total stake on the left side you see the stake held by the cartel at each service is greater than the threshold so the first place was defined appendix B of the IG layer white paper

the second place where was cleaned up and formalized which you know a lot of the results that follow are Dural and Ru Garden uh this paper from this year okay note that these are properties you can validate of a live reaking system right because a live reaking system is defined by this graph this graph is public all of the data here is registered on ethereum if you go look at the igen Pod contract you can get all of these uh numbers on every block now what does a attack look like so in this graph each individual service is actually over collateralized so service one the maximum profit you can get is four but there's six stake so if all the stake is slashed you have at best a

minus two profit and the same for uh service 2 but if everyone colludes to attack both Services simultaneously it is a positive profit because I can get eight units of profit and I only have to expend seven units of stake and the real reason for this is because the middle node operator is sharing their stake so by slashing them once you slashed them everywhere so this naturally leads to what's known as a cascading attack so a cascading attack on a reing network work is imagine that some fraction of stake is lost maybe that's a operator that got dosed and is down maybe that is an

operator who was malicious and and and sent an invalid block and got slashed for some reason they've they their stake has disappeared once they've disappeared what they do is they create a profitable attack so in this case the middle operator can attack the first service once the first uh operator is gone and once that attack occurs they've opened up an attack for the second service to be attacked by the last operator so what this shows is that you can have these sequences of profitable and feasible attacks until you continue to lose stake and in this case you've lost 100% of stake so this says R in the formula we had earlier is one which is

bad because that means the reaking network has slashed all the stake of the underlying L1 which is obviously the worst case this is the proof of stake version of a lending liquidation Cascade so how do we formalize this so we Define a valid attack sequence as a sequence of pairs of sets of services and sets of operators such that each attack AI bi is profitable under the definition we had and feasible and we Define a quantity r s of G which is very similar to the r earlier we talked about which is like the

percentage of stake that is burnt uh expected as the worst case uh percentage given an attack if I lose size Stak so imagine the network has a shock and it loses sigh stake s could be say 10% uh then this says what percentage is the longest Cascade attack uh going to lose in symbols uh it's written like this just so you can see it's between Z and one so there's no hiding anything there okay so this actually helps us answer this question how much stake do we actually need how much Economic Security does our single AVS actually need to be secure we choose an RI

threshold that we're we're happy with so hey we're willing to tolerate a shock of 10% at most and if our SI is only 5% given a 10% shock then we're willing to tolerate that it lets you it lets you have some bounds on how much the worst case attack is so are we done uh not exactly so so this paper shows that there exists an infinite family of graphs with n validators where the entire graph is slashed which is very bad uh it's actually nice to see in pictures so in pictures each of these dots is a validator each of the boxes is a service so we have six services we have the the red L-shaped services so

there's four of those each with three validators each we have the blue box Services which have six validators and what you see is first uh operator is taken out you move to the right and then when you go down uh a row you see that that opens up an attack against the first service which opens up attack against the bottom row which opens up attack against the other services and then all the stake is gone and because this is a tiling there's an infinite number of them so the same paper showed sort of a maybe a a blessing in disguise which is if you're actually over collateralized then you can actually bound this amount of stake you lose

great we might be done however uh and sort of you can think of this as like the proof of stake analog of a decentralized stable coin needs to be over collateralized to avoid cascading depex the problem is this overcollateralization condition which we won't exactly Define is actually really strong so it actually says if I have a bunch of services I may have to have as much stake as the sum of all of the profits over all services in Translation imagine you have a reaking network that only has two Services where one service you can attack and get at most one eth of profit the other service you can attack you get a million e of profit under this

overcollateralization condition you need a million and one e for the one e of attack uh service to be safe which is obviously ludicrous at that point I would just start my own POS Network right why would I pay for 1 million eth to secure one e of attack profit so is this a dead end of course I'm getting this talk so the answer is no uh uh so one thing that this whole model doesn't consider is the incentives like how much are people being paid and how do we include that when we think about profitability for an attack so if we think about how restak went from0 to 15 billion it came out of people paying

incentives it wasn't sort of like a a free lunch that people were running validators and so we actually have to think about each service offering an incentive either a token incentive or points uh so we add one term here which is this term R which sort of represents how much each service is paying and in response to the rewards we assume the validators aren't Sitting Ducks they can adjust uh where they uh Place their stake and what this means is validators after a slashing event in this model can rebalance and they can in some ways halt these Cascades by pure economic incentive where you know someone gets

slashed if if it was profitable for them it is profitable for me to join and so I will join and prevent the Cascade which is what this yellow box is uh which is basically after a slashing event someone from the top row joins the bottom row prevents uh Cascades so in this model we assume the adversary is somewhat weaker uh in that the adversary has liquidity and cost to attack constraints uh and then we assume the node operators are smarter they can adjust in response to these incentives and what we what you show is that basically the maximum Cascade length actually decreases as the number of services gets large and that you can compute this efficiently so basically

what this says is if you have enough rewards you can actually and node operators are not idiots you basically can reduce this Cascade risk that we saw earlier again adversaries face costs not operator smarter avss pay rewards you don't have as many of these attacks so what do how do we reduce this in practice so you might say hey 's live like what how do they actually do this so they they actually proposed a new mechanism uh called unique stake which is a notion that every service can say some fraction of the stake allocated to me is only slash by Me by my service like no no one else can slash it so in

all of the Cascades you saw the reason they were were bad risks was another service could stake delegated to my service and then I lost Economic Security the point of unique stake is I'm I'm able to say actually some portion of the stake is only slash by me and so each service is able to reserve a percentage of stake uh which caps the maximum overlap between Services of how much stake is shared and so it's sort of a trade-off between Capital efficiency of these systems versus security and the key thing is when you have have this unique stake you can actually provide very verifi efficiently verifiable guarantees even before the

network is live some sort of uh like formal verification guarantees of taking all these constraints I've talked about earlier and verifying them ahead of time and you sort of have this verifiable collateral requirement and with that I think that's it [Applause] thank you very much um so for our last lecture before the break we have uh Hudson from polygon Labs talking about the 2016 shanhai attack I'm Hudson and here today to talk about

the 2016 Shanghai attacks uh a history and a technical Deep dive on this uh you're going to see some chat logs that have never been released before uh you're going to see some insights that may have been muddied at the time from everyone freaking out or just being so long ago so let's get started so why am I speaking on this who who am I why am I so handsome so I worked at the ethereum foundation from 2016 to 202 did a lot of protocol coordination stuff with uh EIP editing cev calls devop security excuse me uh you name it and now I'm at polygon Labs after hitting up

a few other places like flash Bots and zcash uh making sure that people know about the incredible stuff we're doing with uh eliminating L2 fragmentation and ZK so I want to do this talk because I think history is important and it provides lessons that get forgotten about over time I'm going to kill this microphone um so the story is really interesting and uh I have an important lesson at the end there will be an end reveal all right so this is when I joined the ethereum foundation Bright Young full of energy you know just so excited but uh this was what June 2016 and then uh September

2016 was Devcon so Devcon yearly ethereum conference uh that's why a lot of us are here this week in Bangkok um just to put in perspective how things were back then proof of stake we were working on it researching it we wanted it to happen but we were far away from answering even the most basic research questions around how to deal with it um the price of eth was $13 uh that's going to be really funny when you see how much the attacker spent that's coming up um we're still using proof of work like I mentioned and there were four clients that could sync to main net again all execution layer clients we didn't have consensus layer thank

you ah great service here yeah so the clients were gu written in Go parody written in Rust uh ethereum J written in Java and then ath aka ethereum Plus+ the C++ client which was Main use for testing uh arguably vitalic OG client py theum could kind of s to main net but not really uh that was kind of we were over that by then so Devcon 2 was happening in Shanghai it was going to be a think two or three day conference I was co-running it uh with a number of other people at the ethereum foundation under my role of devops events and things like that so it's 3:00

a.m. and devc con's going to have their first onstage speech with vitalic bu in in about 6 hours and I get a call the call comes from a phone that is in the toilet because I guess in Shanghai like we had the phone in the room and the phone in the toilets and I was so disoriented I jumped out of bed and ran to the bathroom and picked up the bathroom phone um and George halum who used to be the pr director for the ethereum foundation was on the line and said hey wake everyone up we're under attack so then I do a deep sigh I had not gotten much sleep any anyway uh it was a very stressful Devcon uh operation there so this is the start of ethereum

being under attack on September 18th um there were some people this was in Shanghai China there were people mainly in the European time zones that had not gone they couldn't go because of family or things like that one of those people was Gustav Simonson he used to be the head of security of the ethereum foundation likely 2014 2015 till 2016 20177 and he said alert gu nodes reported running uh out of memory and crashing on this block uh and then UDA Steiner who's now I believe still the CEO of parody Technologies uh or not parody uh yeah might still be parody Technologies she was also one of the security people at the ethereum foundation uh Nick Johnson was just

awake for some reason Nick Johnson's the creator of ens but was on the GU team at the time having just joined fairly recently in the year before um so they're like okay get everyone together can we get a hold of everybody so according to there's actually a like a hard Fork like celebration call that happened I think it was for like Denon or something where vitalic recalled the story and he said that he got a call at like 4 in the morning or 5: in the morning and it was me just going like we're under we're under attack get up and get down to like this weird hallway area um and he just like sigh Di and then went out there so I start like I don't say I shouldn't say I start freaking out I

start going quickly um and trying to figure out what like who I can wake up so the the funny the funny stories with this are we're in different hotels around the Hyatt in Shanghai which is like one of the main ones and where the conference was at and like I didn't know this was like 2016 so wasn't like you could everyone was on Skype like all the logs are going to see today are Skype or getter so like you could call on Skype but people didn't really answer Skype calls after a certain time because they do not disturb so anyways I go down to the registration desk and I'm like just look frantic and I'm like hey I need to wake up this person this person this person so they give me two of the names hotel security always just gives you what they want if like what you want if

they're you're just like sounding like fast enough but uh one of the names they said they're not staying here and I saides they're staying here I saw them here and then I stopped for a second and I said that's not their real name they've never used their real name with anyone have they so uh could not find the Anon developer on one of the client teams uh that was great um so anyways let's dig in a little bit to what actually happened so I can't pronounce that like fart knockos something like that uh some people think it means go home this is a a transaction that went to the attack contract that brought gu down with memory errors so we're not sure what that means to the today we really don't

know who did this or why or things like that but that's just one of the things that at first really hit Reddit hard uh cuz people like used it more back then as like oh wait someone's like doing this on purpose it's not just like a bug and gu so one other funny thing that comes up every once in a while is me and Peter will joke about how I woke him up in the middle of the night so marus is aord Dev with gu but he wasn't around in 2016 but Peter was the co-lead of gu um and so yeah like we we we like to joke on Twitter a lot about the shangh high attex cuz it really was probably other than the Dow hack one of the most stressful things to happen within ethereum core development work this is a picture the only one that

I'm aware of of the uh cevs and others in the spare room that we just found we literally just found like a big hallway in the Hiatt and then eventually was were allowed to go into this spare room to work um for the people in here top left uh is uh was that gonna be left for you yeah top left is Nick Johnson and then Piper Mariam um Martin send and uh Peter uh zagi zagi yeah all right so we're going to go over the first attack it's a transaction spam attack about a mispriced op code and we're going to go through the fastest lesson in op codes ever all right you're making a contract it's solidity it's Viper it's lll if

you're a really cool cool guy you compile it down when you compile it down it gets into the thing that the uh you know evm code and the E ethereum virtual machine can actually read that's on the left that's code generation from what you as a human or typing human readable computer readable let's go back over to the right now we're actually in the evm we have this code that we just sent in that's readable by the evm and we have a virtual machine that's running it and the thing that's running the virtual machine or the runtime process in this case would be gu or pay it then lower than that's the hardware level so that's like the base level of like that part now we're into like how do we know what when we send in a smart

contract and it says like 1+ one or a plus b equals c how do we know like how much gas to allocate how do we know you know like what's going to happen to this so code in ethereum is non-deterministic and the reason for that is whenever you run a plus b equals c in your smart contract every other node on the network has to run that so you can't have an infinite Loop or else it'll it'll just like go forever and all the nodes that are trying to run this are going to like run out of memory so you also have op codes and the op codes here on the left are like regular ones they're really simple to understand like add multiply

subtract and then you have ones that are a little more complicated the reason that we have these op codes um or to have like things built in that most people can use or extrapolate into bigger and better programs you want to use um we also have Dynamic op codes these are ones that are like a little bit more complicated they're things that like may be useful a lot of the time like doing a Shaw Three hash I might need to take a word and make it into a one-way unique function so depending on the word size depending on a lot of things you have to get that gas calculation right and doing that is a very hard problem that's actually if you dig very deep into it what I believe ultimately killed ewm which was an early attempt to have an alternative to the

evm built on wasm years and years ago so looking at this you know the gas for an addition it's three like that's fine like it's super easy for Shaw 3 and for exp it's going to vary by a lot of different things and if you misprice it you can cause a a flaw where an attacker can go in and just click sh three sha three sh three sh three in the contract really cheaply and it just take up a ton of memory uh in the system and this doesn't have to do with block gas limits or things like that it's there's going to be a block gas limit regardless of what you're putting in there what this has to do with is estimating based on what a general purpose computer that is

going to be running this or a general purpose computer running a Noe is what can that handle what can that handle before you're out of memory so here's the actual attack method gu clients were trying to process that block and it would crash they could uh Spam The Chain the attacker code with an EXT code hash op code to seriously degrade Network perform performance um it was underpriced compared to other um IO intensive operations so what I mean by that is you have uh gu at the time using level DB as their underlying database storage layer uh and you have parody using I believe rocks DB so that databases at the time weren't EXA and still to this day for the most part

aren't really maintained well if they're open source cuz like they don't get enough funding Etc and they also aren't used to dealing with a system like a blockchain that has to hit it so many times so when you're doing this and you're like uh exe hash code like it overwhelms the hard drive it runs out of memory it crashes so if it's if it's um underpriced then they're able to do that for like no money and over overwhelm the client there's a memory error it crashes but the parody client who was running on Rock DB stayed alive it like literally saved the network here was the temp solution so I'm sitting in the hallway and there's

like the core devs and we're all sitting there in a circle and like I think a few of them because like you know they were going to a foreign country didn't even bring their laptops because they didn't think they'd have to deal with something like this so I had had this just piece of T Sheba laptop I bought as a backup for Devcon that I gave to like I think it was Peter or Martin and and they were like trying to syn a note on it over the worst internet you've ever seen at a Hiatt in Shanghai so like that wasn't working there were people outside too trying to sink but it was just really hard to get data but what we did know was okay if they're calling that op code over and over again what can we do to stop this now parody's keeping up but

for how long so what we decided to do was lower the uh Target gas limit and this would be more of a lowering the floor of the gas limit uh specifically so as we are doing that there has to be a coordination effort so I'm leading that part at the time I was in contact with every major mining pool and the ecosystem uh and a lot of major Miners and on top of that in Shanghai uh some of the biggest miners including F2 pool and eth fans which then turned into spark pool were there in person they're in Shanghai they were at Devcon so we literally just called uh Jen from uh uh like eth fans in the middle of the night and he's just tired as hell and like

drives up or rides up to the Hiatt and comes over there and it's like me a few Chinese Miners and they're like calling all their other miners and we send this out uh to change their setting on their node the thing with changing the gas like the max block gas limit is there is a special formula built in where where the network looks at all the miners that are putting out uh signals putting out blocks and they say what what do you want your gas price to be and if enough of them agree they lower it one uh one over 1024th uh gradually over time so amazingly within about five hours or less we lowered the gas price to like

something incredibly low it was like four million no was less than that it was like 400,000 it was something like super low so now when the attacker tried to call that same contract it wouldn't fit in the block like it literally just wouldn't fit in the block and if they modified it to try to hit that op code over and over again in a new contract it wouldn't do as much damage because you're limited by that block gas size and by the contracts you can put in there um it also increased the cash size on these uh mining nodes so that's another thing that kind of helped deal with this along the way so this is the temp solution so it's September 22nd it can continues I'm still in Shanghai devc con's over um and uh let's see I say

attention multiple reports of death failing is this an issue um and parity struggling as well so here's the second attack method so the same attacker set up a separate set of contracts and this was another type of attack and this one actually did take down some parody nodes if I recall but um at the on the initial denial of service attacks that were happening with the EXT code hash uh they exploited another flaw where they could cheaply create a large number of empty accounts in state um that might be a little foreign because that no longer can happen and I'm going to explain in the next slide why um this was done repeatedly using the suicide op code now it's called self-destruct we don't use

that as the original name from the yellow paper um and uh the op code's ether transfer function poed new accounts into existence over and over again even though there was nothing in those accounts the state kept up with them which was really weird so now uh bro is making 19 million empty accounts and so suddenly State bloats like and uh yeah it was it was kind of like a oh wait are we gonna be run out of dis space eventually if he keeps doing this so that's the state bloat attack so empty account versus non-existent account I actually forgot about this till the other day this is one of those things that reminded me when like there's some weird thing in like job

script where it's like why is this equal to zero but then this does null like it's the same kind of thing so I'm glad we fixed it um an empty account is an account with a zero balance nson Co code empty accounts are like the same thing but the exception is uh it has a few gas calculations and they can be easily turned into non-empty accounts by sending an amount of ether to them so like basically whenever you try to make that account even if you don't do anything in there it like cost number one computation but that's actually less important than the actual like memory on storage on disk so yeah why can't we have 19 million empty accounts let's have an account party

well it waste hard drive space increase a sync time if you've ever synced a node and looked at a graph there's going to be this funny time in 2016 where it's like ah and then like it's done and you'll see why it goes back down in a second and yeah it slows down transaction proc uh stuff because a lot of our way we do our storage stuff within the client level is through Ram so we um set up uh two hard Forks that dealt with these two problems the first one dealt with the problem uh when it came to like the immediate effects which was the uh mispriced op codes and then the second one was cleanup we need

to clean up all those you know empty accounts there's no reason to do it um so yeah the process of writing testing and coordinating these eips uh was done actually fairly quickly under the circumstances um Tangerine whistle was first and it did it uh repriced a lot of op codes and there were a few Corner cases of other op op codes that we discovered and then patched um and then spous Dragon uh went in and like made it so that if you touched an empty account on chain using a script and I'm not sure who ran the script uh it would go away so you're basically basically cleaning up State at that point um the attacker used 300 ether during the attacks uh worth an estimated $4,000 at the time uh

but now is worth $875,000 so you so who came up with spous dragon and tangerine whistle uh this has been discussed a little bit on Twitter this is uh a gter chat that I discovered um where we have uh paw who uh does a lot of the stuff around at the time testing I believe they do uh a few other research things now at the EF uh Christian W Reasoner obviously um Christian's like let's name it 150 and 158 which are the eips involved and then Martin is like Tangerine whistle spous Dragon let's make t-shirts it's an icon I'm like I'm like what but like yeah no I'm all over it though that was pretty

cool because I mean h hard Fork 2 the ethering I don't know who came up with that I didn't scroll up but like that would have been cool as well so what did we learn multi-client blockchain networks are the most resilient uh so uh ethereum didn't stop that entire time it was under attack didn't halt I could always put a transaction in and it would go through the fact that we had two clients this is like what a year after launching I guess 2016 about a year and a half they're both running on the network as an attack crashed one node and the other stay on that's the importance of separating your specification from your client um Bitcoin has their specification

intrinsically linked to their sole reference client so I always say bitcoin's specification is their reference client ethereum specification is in GitHub and we make clients and that's incredibly incredibly important so my spicy take is bitcoin's going down well before ethereum would go down purely because they don't have a multi-node setup uh for the ones in there the well um actually yes there's like JavaScript and node implementations of Bitcoin core however there's so few people running that and also so few people running that with the ability to connect to stratum miners that like I don't really think that that's going to do anything if like that were to

happen um and I believe that's my last slide I have time for a question if anyone has one oh yeah yeah we go yeah cool so I guess um talking about like uh your last slide when you're like it's multi-chain client or multi client chains are more resilient um I guess the question is safety versus liveness though because guess like for this particular example when the bug was a crash bug you were able to preserve liveness of the network but if it was

for instance a fork bug would it not be actually less resilient to safety because for instance if it was a fork bug then par might take one chain versus the other one versus if you're all running one client then you'd Fork together such that uh that's a great question so it depends on your blockchain I feel like at least back then Bitcoin and ethereum were really all about like liveness because it was like decentralized chain staying alive staying alive like the BS but at the same time um I do see your point Forks in ethereum have a lot of I guess uh cultural around like manual intervention from the community so you roll back the chain or whatever that like uh and not

like the Dow Fork but like you basically have the longest one and then you figure out how to deal with that so it's kind of a thing where that wouldn't that happened in Bitcoin too like Bitcoin had a thing in 2013 where they had a fork or because they had a bug in like 0.7 or 0.8 or whatever and um it caused them to split so all the miners in about an hour got into one room and uh they said okay this one's the bad one this one's the good one we're taking this one so minor two mined on that fork did not get their rewards however the transactions did stay from what I understand and I don't know how they did that um lastly there's like things like salana which I feel like you know obviously are very

different in terms of what they prioritize compared to ethereum uh but you make a good point it's what the community wants and what the blockchain is kind of initially or culturally designed for uh where that could be a problem I just trust ethereum's like resilience as a community and the protocol devs and the processes we've had and the you know hardening we've done to be able to deal with something like that and maintain liveness yeah sure oh yeah he had one uh sorry maybe M's actually a question if you can go back um I'm curious about the script that would uh close those accounts yes can you explain it more yes

okay so um I think the ethereum foundation may have run it I don't know but uh you basically have uh all those accounts the hard Fork made it so that if you were to send a specially crafted transaction and you said hi I'm touching that account it goes away so the script itself I don't know where that script is and I don't know who did it or who launched it I'm going to guess the EF because it probably cost a lot of money or at the time a good amount of money to like run that through 19 million accounts like concurs but yeah thank you all so so so [Applause] much thank you very much I was an

ethereum back in 2016 just incredible to hear the story um so we don't have time for the break uh so we're going to move to the next section and our next moderator is toor from Stellar who's going to present the people thank you very much hey everyone uh as you might have noticed I was not supposed to be a moderator for the session there was a different toer uh that was supposed to do it he's not here so they went for the next available toer that's me um and uh yeah we're going to have some amazing sessions we're going to start with two a sessions the first one is evolving slow systems in the age of speed Ernesto

[Applause] light can see

that light NE lift it back okay good okay hello everybody so yeah and I'm Ernesto B I'm the co-founder of BD labs and this is the first it happened to be the first session like of uh AB morning like because after me there will be like ail also like from from from the Upp side like so um today I wanted to to talk about well first maybe I can talk of what is from where I'm

coming from BD like so yeah as I say I'm the co-founder of BD labs and we are like a team contributing to the a protocol like for core development security and a bit of basically everything on on what relates like with the with the existing a protocol B3 B2 like everything around and yeah coming back to the title like of the talk like the objective today is just to tell a bit shortly um how it works inside like we could we could call it inside like and certain details related of how we how we think about

security and and and yeah some some kind of inside view of the of this system and its maintainance so uh yeah about the team I already mentioned like so we are well I will elaborate later like but is pretty pretty decentralized in terms of organization yeah following a model that hopefully someday will be similar to ethereums and so our team it's called B Labs is not called but because we are completely independent like from the founding team even if I was part of that founding team and yeah we we work that way so er yeah as overview like first I I

will I will show what is sa at the moment like then and the core of my of my talk will be of putting two examples like of how do we move features like of ab how do we think about those features how we evaluate them security wise and and some other details uh and then at the end we'll yeah we'll talk about the security procedures that we applied on those features and some other things and how maybe they are a bit different than than other systems or or maybe not so different so H about the the title of the of the talk um yeah I think that right now like defi reached the point on

where everything moves relatively fast in terms of like developments ER like if we compare like with Early times so yeah I think that it helps that the tooling is completely different like in than it was in 2018 or 2020 on where yeah technical limitations were actually a thing when you wanted to do something and and especially when you wanted to do something safely so that definitely has helped a lot like on yeah ab and this ecosystem being pretty big nowadays um we have new types of in what relates more with defi we have new types of

assets that are appearing all the time like yeah like it can be liquid staking tokens or reaking tokens and and some others this yeah now at least I have the feeling that these lsts are have existed forever like but I think in 2020 they were still an asset as say asset class that was was growing and liquid restake tus is like one year old so but in terms of of size now nowadays they are pretty huge um then it also helps like for this speed that nowadays like there is factually way more entry points into the fight

than there was back in the days back in the days mainly it was ethereum and and some alternative l1s now rollups I think it's pretty clear that the they they got some yeah some some boost like so so you get you get yeah a lot of like base like arbitrum like you can name it like but there is like real use cases there and any users entering even dly to those to those L2 and not only to ethereum and then maybe going to to some other place um and well I mean the conclusion is that for from all the previous like new protocols appear like every

day maybe it looked like slow down a bit last year like but like in practice there is actually a lot of of new ideas getting getting created in production like and and well yeah lot of innovation so H yeah the slow part which is kind of a yuk is AB because I think it's AB is quite quite perceived noway like as the stable place like the like this kind of Bot like but maybe it's not so low like because AB is in 11 networks at the moment the the V3 protocol with 13

instances there is also still three instances of no yeah this is wrong there is three instances of B2 of the of B2 in in three networks assets there are like yeah I put more than 100 but I I don't I don't even keep the count at the moment AB also has a stable coin it has like cross chain messaging system it has like uh governance system based on storage proofs like yeah basically you name it and probably a has like some some infrastructure related with with something so H yeah it's a slow system but uh it's also is pretty big like

so yeah this number is something that I took yesterday today I think it's more or less similar but yeah AB is pretty big like with some some billions in in Market size and well with with this and with all the previous infrastructure of course H ER stability is very very important and something that especially on on my line of contribution and and the team I'm part of like this is kind of the key like of yeah we are the technical team that needs to make up appear as like seamless and things work like completely well behind the scenes ER so something that maybe like people

doesn't I mean for sure is not so so public is like how is the procedure of like adding features to AB like how we decide like yeah to add something to not add it quite frequently to how we decide to remove them like uh so so in in in that direction like one one of the things is that we we believe pretty hardly like that the all the systems should evolve because it's I mean quite natural like yeah so the idea the idea of pure immutability is I mean is nice but even like on the base layer like let's say ethereum like well things change over time that is one of the strengths we think of of of thether

community like so onab with try to kind of reproduce the same but like on the smart contrast layer so um at the same time like obviously whenever like you you add new features like or or any type of change well the attacks will face on a protocol Oni protocol like a like it it increases like so the more you add the more potential issues that that you can have in all senses but the ones that really matter are security wise so something like very very important is like to when you are like the development team of of a system like this is to find a good point of equilibrium like of this like because

well you cannot remain too static meaning yeah you you you put a system out there like and and you wait two years like until you probably die no you need to move a bit and continuously but you need to do it with certain order or as much order as as possible so uh yeah I want to just put the examples of of two two features that we introduce like actually this year both of them so because a right now like it's not the protocol is ab3 but technically like the protocol that is that everybody uses that probably some of you at least

use in this room uh on chain is right now v3.2 so there was yeah some minor version then 3.1 3.2 and and some extra coming soon uh so yeah how we do and how we think about those features so the first one is um liquid modes I will just explain a bit maybe some of you already know what is like the ab modes but ab3 introduced like a mechanism which was called e modes which comes from a efficiency mode and what that mean is that like in you have listed assets on a but then you

could have like each asset could belong to any mode was called which had like higher risk parameters whenever like those the assets on D mode were correlated like so the main use case of this for example was having s uh the LST of e and e on on a singly mode so in that case you could have like quite quite high risk parameters because they are correlated like so the risk of liquidation is is pretty low and that enables strategies like high leverage or things like that so what we introduced on on ab3 point2 was what we call Liquid modes and and this is kind of a technicality but it

made quite some difference before like each asset listed on on an a pool could only be on an OTE like the moment that you add let's say e in in emote one it could not be in any other emote and this was limiting factor even if the normal modes like help AB to to grow a lot like this this was kind of limiting like especially during this year like when what I mentioned before when new assets appear like the the system was not powerful enough to cover all the use cases let's say with lrts so what we did like with these liquidy modes is to allow that each asset could be in multiple emotes which seems like

something pretty trivial like but it actually enable a lot of use cases so for example right now there is like an instance in main which is the the light with3 pool which is heavily using like this concept of liquid modes with yeah subgroups of assets and each one is for a particular use case lrts against lsts lsts against normal asset stable you name so how do we thought how how did we think sorry about the the introduction of these liquid otes usually this is kind of there are some other steps probably like but high level we think this way so first we think that if the feature makes

sense like because it's not only about like introducing technical technical aspects without thinking high level how much s it makes then we always think on on how is the complex add to have because well it's we are not creating a system from scratch we are changing the code or something that is like billions size like so the complexity that gets added or not is a deciding factor basically even to to move a a feature or not and then also we think quite a lot on on how difficult and and how how long will be like the the security procedures associated with the feature which frequently they are different between each other

so in the case of of liquid modes well if the feature makes sense is what I explained before like it really made a lot of sense because abb3 was being limited like with with use case like a liing tokens against others so yeah we needed to do something and the Alternatives were yeah not so good in in terms of user experience then how much complexity it added this feature to have not really so much like it really looks like a complete change of Paradigm internally but the reality is that when you go to the details uh

the changes were not so so aggressive like so you could isolate the logic like the storage affected like was I mean was not so not so bad like and and it was generally a pretty small footprint for the the power of of of the feature itself and then yeah third question how difficult we estimated the security procedures was that well it was pretty review friendly that is one of the advantages of a because even released like quite some years ago AB is quite modular code base like so sometimes this is not so good but sometimes like for the reviewers

this is extremely good if you follow like if you do Improv following the same patterns like so this was the case here like the change was relatively isolated and and easily understandable which also work like with quite well like with an idea that that that that we practice that is like we we try to introduce like new security partners and firms all the time so yeah of course we work with our typical security Partners like the ones that we we trust from a long time ago but also from time to time we trying to introduce new people because well I mean you you bring fresh ideas and so on so it makes sense so yeah we evaluated this and

um and and that's it like then during this implementation however like we always need to think okay how how powerful we make this feature how far we go like so um yeah usually it's very important to understand that it's not about being as generalistic as possible it's about enableing what you want to enable and even if you know that you can improve certain things just stopping there um what I mentioned before of like following similar architectural patterns in a system like gab is very important because sometimes just by following like the the the organization you will not I say shoot yourself like with an expected bug and also thinking very careful about

Integrations like because AB is well I mean the users integrating is not and users is protocols like so we need to be pretty careful with with that uh yeah the the other is like um another feature which is quite different in nature is virtual accounting this was actually before liquidy modes and what we here is that like AB was operating all the time from inception dynamically in terms of checking I say how much available liquidity there is using balance off of the tokens and how it work is like at some point I will pass to the to the typical questions but

at some point we notice like that there were more and more exploits related with inflation attacks and any type of manipulations related with with balances ER so we did like some introspection in the team like in in the protocol we also involved like extra security researchers like and and then we decided like to to mement this this virtual accounting so yeah when we analyze like about the complexity added to have it like actually was not so much um mainly because it's kind of incremental defense like or we call defense in depth to meaning that there is not really much

you can destroy like by by by introducing this the only thing that that could cause is like maybe over protection of the system but is I mean of course if you do it wrongly not but it's not so easy like to to actually introduce a very big bug like because of the nature of the logic itself and then also yeah it was review friendly like the the code footprint was relatively small I would say which but that it had like high level implications like because certain invariance of the system that before they were understood by by using balance off like on certain smart contracts like it's not anymore now they involve like

storage variable like which will be the the virtual balance and for that reason this particular feature we thought that it was good to to have a security contest too like because it's well quite non a specific like so in this specific case like the like having more ice and fresh ice like it could give value while in certain other a features like having certain expertise on AB or or a lot of expertise on AB really gives like way more value than than coming from scratch so yeah the same as as with the liquid modes still like we we we did this last question of how

how far we need to to go on this like so yeah like the main priority here was to make it as non invasive as possible the feature um then evaluating all the effects and like potential consequence that that could arise like because of what I mentioned before of not being so Dynamic anymore not using balance off but having internal accounting and especially like something that is a recurring um let's say challenge like on AB is that every time that we do an upgrade of the code you have production data like of thousands and thousands of users like of capital so you need to be very very careful like

whenever you reinitialize that data or when whenever you do any type of so-called migrations of data so in this specific case obviously this virtual accounting didn't exist before but the moment that upgrade happen you need like to just initialize like a the whole thing so yeah uh yes to to end like a like a small small overview of how are the how we I think that maybe our the a security procedures are slightly different and mainly the ecosystem around more than the procedures so yeah I I will not repeat but obviously we do I say typical stuff like testing review formal verification

fasing like that you call it probably it was done at some point in of of the chain in AB but I would like to highlight this which I is a practical example of of of something that is not not not so so common like so in I say like that we have organizational defense like what what that means is that similar as with ethereum I think that like like the resilience of ethereum sometimes is because there are so many teams contributing to ethereum because there is I mean there is not really like a boys with full full Authority like in in the road map of ethereum or like almost any aspect so yeah as I say before like

in a we we try to achieve the same like so at the moment a is I mean is really fully decentralized controlled by like onchain governance contract best example is that my team like is just engaged with the Dow like which release certain budget and and and authorize via Smart Contract Services agreement let's say so this well natural consequences that there are multiple also Tech technical independent entities involved with the with the development of and the security of the protocol so yeah I mean it's of course us there is I put also Cur which contributes independently on the on the security side even obviously

we collaborate closely there is also like avaps I mean and there are multiple others actually um and then even yeah we have also like independent emergency entities which is can be in the shape of multi6 or SW for yeah emergency functions of a bage detected and if the system let needs to be ped so yeah this this gives quite a lot of value ER another another point is like that the all the changes of fa need to happen via the governance or the I mean the 99.9% of them and they are not even created by the technical team of fa like and what

we do is review those changes but at the moment there is like I think regular four or five entities out there some of them are not even so so technical which are creating governance proposals for whatever like listing new assets on a changing parameters I don't know proposing new deployments on new networks like yeah countless thing like so yeah there is a some repository where people just do PRS we review them then there is even another layer of review by seror and and then they get voted on ching and if everything goes well it gets executed on the abist uh yeah right now we are even like trying to decentralize like the

organization on on GitHub which is a bit challenging but so like the other protocol lives in this in this sa and and progressively the idea is that multiple contributors like will be having the repositor that they maintain which is associated with the Dow so is kind of everything is property of the Dow and then you have like the yeah the maintainers or steers of of that and and yeah well I mean we maybe treat a bit different like of like the relation with the Security Experts like so this is more about like U our team but for example we we like quite a lot

like to have continuous communication with when we do security reviews is not are not so much into the business of like giving some code review and coming back at the end we prefer just to talk quite a lot with the auditor because it's it's pretty good both for us and for the auditor to get better understanding ER it's true that also like in some cases certain isolation is desired but we are quite I mean we think quite a lot about this these topics like so depending on the feature even maybe we want to have more communication and in some other features not ER and yeah well we we try to put a lot of focus in documentation which requires like some improvement still

like but yeah we think that one of the problems of on the communication between developers and and security firms like is that well is not well explain what the developer is trying to do like so that just creates like a snowball effect on on everything else and yeah that kind off an overview if any question thank you so much Ernesto um maybe while ailio sets up a quick question from me um so I think a is seeing one of the biggest uh Evolutions which is the first non evm deployment of

uh of of it happening how does how do you evaluate that type of of decision with regards to the framework you presented I mean like is a slightly more challenge like because obviously we have Frameworks to evaluate like the evm deployments by themselves um but those Frameworks are unavoidable I link like ebm characteristics like so in the case of the one know evbm like this changes changes a bit but I think that we can adap because at the end of the day like it's more about having the procedures and the steps well defined and then if you need to adopt some of theep steps well I mean it's is just fine but

hopefully it will be yeah in the next months I think there will be up in nbm pretty sure so awesome thank you so much ernesta um and next we have another a session approaching security with a V4 with amilio okay perfect microphone is

on cool great nice to see you guys everyone we I was already here yesterday I see some familiar faces so that's pretty cool uh quick introduction I am my name is amilio I work uh for aabs as a contributor to the AAL and we are currently involved as um contributors to the DA uh to develop like the new version of Thea protocol uh long story short is that a few months ago aval laabs came out with a proposal to implement a new version of the protocol uh this new version of the

protocol steams from observing how the protocol has been behaving and evolving over the last couple of years we just saw the great presentation from eresa from bgd labs they are the main uh contributors and Main maintainers of the other protocol and they have been responsible for some very interesting up upgrades of the protocol introduced liquid emotes they will be introducing the umbrella uh upgrade for reamped tokenomics and like developed around go and we have also seen the procedures that are in place uh in the within the Dow to make sure that any uh new feature any advancement any upgrade to the

protocol goes as smooth as possible and uh without any risk for the user users and this was also when we started um brainstorming about what we could improve with a before this was also one of the I would say one of the topics that we discussed so what was the process the thought process behind like the idea of a before so what we have seen with uh V3 is that there are quite a few great um I would say features and great um powerful points for I3 that make make

basically make I protocol the largest uh dii protocol in terms of dvl so there are many actually I just pointed out like what I believe is uh relevant uh to me for this particular presentation so I can think like of the great Capital efficiency of the protocol because the p pulled approach of the assets because some of some features that the protocol implements like emote and most recently liquid emotes introduced by bgd Labs uh which allow basically higher Capital efficiency whenever you are using um whenever you are using assets that are kind of correlated with with each other uh because of the pool model we also have uh great ux for borrowers

because uh rather than having multiple positions to manage and rebalance uh as it could happen for example with protocols that have that have higher uh Capital segregation uh in a in general you can manage everything in one big position and like collaterals are treated homogeneously and uh depth positions as well so in instead of having to uh move your Capital across different positions that are maybe single collateral single borrowed assets it's much easier to manage from a user perspective um and what are some of the minus of the current implementation that we believe can be improved over the current version of the

protocol so one pretty clear feature that we are missing at the moment is that we are basically unable to price risk efficiently so one of the main problems with have3 is that we do have quite strict risk management but the only thing that you can manag there is actually risk exposure so you can say how much you want to be exposed to a certain asset but that's actually not enough because you should be able also to say how much a certain asset should pay for that risk that the the protocol is being exposed to right so H for a collateral is not enough to be activated as collateral and to have certain cups that limit exposure but it should also

be possible to say that a certain collateral that bring a different risk profile should be paying a different um different amount for the liquidity that is provid provided against that collateral right one example is like the CRV situation that we had a few months ago where there was this large position that like at some point went under the threat of uh liquidation and because it was so large it could have basically posed a a risk uh for the of insolvency for the protocol and what the ideal course of action uh for the now in that situation would have been uh to actually rebalance the risk by increasing the capital

requirements to borrow against crb so that the the the position is either paying uh an amount that is equivalent to the borrow Capital that is uh the amount of the capital that is borrowing or that borrower is incentivized to leave the system and to reduce the exposure and there therefore the risk um one uh it's harder with the current implementation to allow permission permissionless Innovation uh one example is that like the current approach that we are having with uh um custom hok markets where you can basically uh have markets that are

deployed and uh configured for certain specific use case so I thinking of the heery market of the Lido Market uh shortly after will be the Athena Market market and so on and so forth all of those require quite lengthy uh processes in terms of deployment and in terms of uh governance uh requirements like variety of proposals the full governance process and so on so forth it would be better in my opinion if there were there were a way for users to actually and for entities that actually want to use and want to configure their markets for their own needs it would be better if they could do them by themselves and then eventually being endorsed by

the Ava and being supported with the risk management and everything else that comes uh by being endorsed with the Dow there is a lot of governance work with the car implementation so besides the deployment of the new markets we have seen uh there are a lot of risk parameters change uh there are a lot of um uh configurations that are applied all the time uh the market the deployment of the market requires a lot of governance work and from a strictly security perspective the I3 code base is really big so we are talking like 7,000 lines of code uh and can we do actually better can we optimize it further so to reduce the

surface of attack so all of these are the thoughts that basically uh brought us proposing the new version of the protocol I already did some presentations on the topic so I'm not going to focus on the features because I would be talking for 5 hours so like I will be very quick on these features because I want to focus more on the architecture that we are thinking um in terms of features I already mentioned uh in the past like Risk premiums Dynamic risk configuration of f interest rates uh these three are aimed at solving mostly or reducing mostly the impact of these two uh shortcomings ditioned before inability to price risk

appropriately and reduce the governance overhead so for example Dynamic risk configuration will allow Risk Managers to create uh new risk configurations for only for the new users without affecting past users uh which will basically allow to the Dow to offset completely risk management or almost completely risk management without changing the security guarantees of the system um f interest rates which is uh which is like um uh control mechanism we are implementing right now and it's uh with the idea of being able to adapt the base rate and the slow Point dynamically of the interest rate curves so that the

interest rates can change accordingly to uh market demand more quickly without requiring requiring governance work and then the risk premium that I already mentioned before is like the giving the ability uh to basically price the risk of a collateral independently from from the others uh so these are a subset of the features that kind of cover some of of the aspects that I mentioned before but I what I want to uh Focus today is a bit more going a bit more in in detail on the architecture that we are thinking about and how it will look hopefully when the implementation is going to be

finished so uh part of the work that the da does today I think is due to the archit Ure of the other protocol because of the design of the other protocol the pool design and like the monolitic approach that we took when we designed a V1 V2 V3 it is a bit harder to to do um to allow permissionless changes so for example listing an asset requires again a governance process with accordingly risk evaluation that is done accordingly um uh Oracle creation and so on and so forth uh deploying new markets as I mentioned before requires a full governance process plus the complexity

of trying to bootstrap the market because the market will start from zero liquidity and to attract users to the market you will need to some find some way to bootstop liquidity and risk configuration like there is no way of changing risk configuration without aect affecting P users so every time you try to reduce the liquidation threshold if you want to have board an asset for example you need to slowly reduce it by one two percentage point to prevent users from getting Mass liquidated and so on so forth there are a lot of aspects so a very general I already mentioned in in in previous presentation a very general uh um abstraction level uh we are thinking of separating part of the

protocol in a way that we can create a more modular approach so what I mean by that if we look at the current a protocol implementation but even the past that's the in the part that kind of sparked this idea of modularizing a bit more the architecture uh in the protocol that is a monolithic piece of software where there we have this full contract that basically handles all the user interactions of course internally there is modularization so we have split the code in libraries subcontracts and so on and so forth but this modularization is I would say um um top down because a top level of abstraction you don't see it you see one piece of software is the pool and then going deeper in the

architecture we'll see the different aspects and different modelization and the within the code and we can basically Identify two main liers within uh the the other protocol uh code one is the liquidity management part and the other part is the borrowing management so if we think specifically about the liquidity management and we observe how that part part evolved over the three itations of the other protocol we can basically notice that there was essentially no change so everything that was related to liquidity management interest rate management indexes accounting and uh positions management and so on and so

forth is basically unchanged compared between V1 and V2 V3 most of the changes that we can see where happened at the uh borrowing part where we kept adding features so we added the stable rate uh we added a credit delegation uh we added e mode isolation mode liquidy modes recently uh different liquidations mechanism and so on and so forth so uh from this idea and this and by noticing this particular aspect of the protocol we started thinking okay why we don't take the liquidity management part out since it's basically un changes since from the beginning and then think of it as a component that can leave by

itself and then the borrowing part we generalize it in a way where the liquidity management part doesn't actually know about the borrowing part this makes would make things much easier right this is also uh kind of an evolution of one feature that we added in av3 that is called portals so uh with portals the idea initially was to um essentially uh allow other entities of other markets POS possib cross chain uh to draw liquidity from the largest other markets to bootstrap them on to or to optimize the capital efficiency right uh this Vision actually never uh took traction for a variety of reasons

because we when we developed V3 we were thinking that probably l2s would gain much more traction earlier much earlier than we actually are witnessing so uh that reality has not really fully uh uh realized yet and also like there were a serious of complexity relat to bridge security and so on and so forth which I'm not going in in detail right now so whenever when we pair like this idea of portal which it was basically first attempt to uh move liquidity out of the markets to optimize the capital efficiency and the realization that we have a part of the prodal that never changed essentially since the

beginning this brought like the realization that actually we can take this part out and start developing it independently so that then we can build on top of it other modules that actually also work independently and this will hopefully bring much more uh simple code better Capital efficiency and uh also reduce governance overhead as we will see later so uh we are currently developing 4v4 this component that we call liquidity Hub uh the liquidity Hub basically handles everything that is basic user function so Supply and withdraw handles the accounting so interest rates accounting the interest

rate strategies and the uh liquidity premium um and it's actually completely agnostic to uh the modules that will draw the liquidity uh and will extract the liquidity out of the liquidity layer the liquidity layer doesn't need to know what's going to happen with that liquidity the only thing that needs to know is that like modules that will build on top will pay the interest that the liquidity Hub is actually asking for so the liquidity Hub will have like a generalized accounting for all the modules that we built on top of it and it will not know what's going to happen with that liquidity you know so it can be a borrow module that actually works exactly the same as V3 it can be a module that I don't know borrows against

RW that are um that are um held in isolated vaults can be a lot of things as we will see uh later so what about the borrowing it can be completely if we follow this design it can be completely abstract way so we can take all the features of ib3 and Implement in a module that works by itself that doesn't need uh any knowledge about the inner dynamics of the liquidity Hub except the ABI so the the the interface that allows communication with the liquidity Hub and can be tested separately which is great uh liquidity Hub can be mocked so we can build the liquidity Hub and the borrow

module in parallel which is something that we could not do with previous version and most importantly we can have a variety of Bor modules not just one you know so um that's part of the thought process that is shaping like the form that I before is taking so we call this we call this a hub spok design so Hub spoke is in general is a very common architecture and um the modularized design uh philosophy that is very common in a variety of Industries in common in uh transportation is common in uh data science a lot of different uh fields and so the idea is that we have this

liquidity Hub at the center that handles the assets and handles all the accounting and then we have a variety of spokes we have spoke number one number two number n potentially these spokes they draw liquidity from from the liquidity Hub they use them in a certain way they will return it at some point by paying a certain interest plus a premium that's the idea okay and so this generalize the design that we saw before and opens up to the possibility of having multiple Sports within one liquidity layer so uh this is the general flow operation of how it would work uh users apply liquidity to the liquidity h liquidity

Hub tracks the total liquidity the US usage ratio the interest rates and the average premium the spokes whenever a user requires borrowing draw liquidity from the liquidity Hub uh and liquidity Hub keeps track of the total liquidity drawn and eventually the liquidity Lo per spoke so that you can set caps for every spoke eventually to limit the exposure that the liquidity Hub gets to a certain spoke and and spokes whenever they return the liquidity back they pay the liquidity rate that was accumulated plus a premium and the premium is decided by the spoke through the risk configuration of the specific spoke and spokes can fetch the balance spokes have one major requirement when when users borrow

liquidity the major requirement is that there is a proper collateralization ratio that is not violated otherwise there is risk of insolvency so the idea is that the spok can fetch the balances from the liquidity Hub to understand uh the capital allocation of a user for example and how much collateral they have right so this poses a few challenges so what we are thinking is okay how do we manage H multiple spokes fetching balances from one liquidity Hub that gets can get very very complicated very quickly and the reason is that it's really hard to understand uh when a user supplies liquidity uh if for example a user is borrowing from a variety of different spokes to which spoke that collateral is being allocated to right

so uh we are thinking uh of a variety of designs one uh one design that we are thinking about is the potential of using for example a master spoke so we will have a master spoke and that Master spoke is the only one that is allowed to um draw liquidity from the liquidity Hub and also use the accounting within the liquidity Hub to calculate collateralization factors and then we have secondary spokes that can be n and unspecific number which the only capability they have is basically to uh draw liquidity and return it but the collateral is and the collateralization ratio needs to be accounted in and uh stored in an different uh um venue than

the liquidity Hub uh so basically this would be a fully generalized portal Design This is currently the design that we are evaluating for the uh for the liquidity Hub and the the spoke design but it's not the only one the cool part is that the thanks to mod modularization we already started the liquidity Hub and we have the luxury eventually to decide which design we want to use much further down the line because because we can afford to develop liquidity Hub basically in dependently from the rest of the protocol so um the secondary spoke if we go with this design which is still not 100% guarantee but it's is currently the design we are leaning into the second

secondary spokes can be anything they can be isolated collaterals they can be rwa based or they can even be other liquidity hubs which is the cool part that enables a lot of interesting aspects that I will uh talk about shortly uh so if we look at this diagram here I put like an example uh that how it could potentially look uh going forward so before I EXP explain uh in detail this diagram like I want to uh like uh clarify that one of the features that we are going to implement in V before is called smart accounts so one we want to

give the users the ability to borrow from a without actually supplying the collateral into a this was a feature that was requested for a long time H the collateral would be in a separated uh smart contract that it could be a vault it could be a safe we are actually evaluating to build on top of the safe so you would be able to borrow directly from your safe within the a without supplying the collateral first into into the liquidity Hub and this was requested uh for a long time and the reason why users are requesting it is that either they don't want to take the risk the liquidity risk uh by earning I don't know like just a few percentage point of

Interest or they cannot for legal reason mix their collateral with other assets of Unown origin within the a pool so this would basically help them allow to to solve and then we have uh isolation mode that we already have in V3 but it will get with this design we will have a completely different uh approach uh within iv4 so in iv3 is implemented as a standalone feature in within uh the monolitic design so it's a feature and with with a variety of edge cases uh with this approach actually isolated asset they become a separate market so it's going to be a separate Market with a separate liquidity Hub with only

assets that match the much the same risk profile and what we can do is that we basically uh connect this liquidity Hub through a secondary draw module to the main liquidity Hub so that the Dow can for example give to the isol isolated assets pool the ability to draw liquidity up to a certain cap to uh to the from from the main liquidity Hub so you have basically the same design that we have today in terms of um dep ceiling but with within a separate model a separate liquidity lier and a liquidity Hub which also gives the ability to eventually users that want to get

exposure uh to higher Ys by supplying direct directly against isolated asset they can do so we can we cannot have this feature uh as it is implemented today in av3 so with this design we can have users going straight to the secondary liquidity hub for example and earn a higher interest because like assets that are isolated usually should pay thanks to premium a higher interest rate and also the smart account spoke could for example just draw liquidity from the liquidity Hub and then keep the collateralization in safe wallets for example where uh custom hooks can be in install to prevent users from moving asset if they are borrowing and so on

and so forth so uh this particular uh diagram is interesting because it shows how uh rather than having a very big and complex monolithic borrow module with this design we can split them in separate parts and have smaller easier to test easier to implement modules that actually interact with one uh s coordinate main coordination Hub which is the liquidity hub um so to to finish because I think I don't have any more time yes uh the from a security perspective and uh like ease of implementation perspective there are a variety of advantages like spoke and liquidity Hub can be implemented

separately which is exactly what's what's happening at the moment because we are mocking the the the features that we expect to have into the borrow module and we can actually implement the liquidity Hub uh uh by itself uh thanks to the completely obstruction that we are building into it everything can be mocked which is something that we could not do before so we don't really need a fully functional liquidity Hub to test the borrow module we don't really need a fully functional borrow module to test the liquidity Hub that's very cool and that makes implement the development much easier because then we can Implement for example the modules that we saw here all of three in parall we

don't need to implement like them as a unique uh like um monolithic piece but we can Implement them separately and uh in the future it will be also easier to replace spokes or Implement new spokes so there would be a lot more to talk I don't know why this is pixelated but it's it's good enough and yeah there will be a lot more to talk about on this particular topic it's been very exciting uh for until now and we hope to have something to show uh to the Dao and to the rest of the community very soon uh that's it thank you guys

for listening and if you have questions I'm well happy to answer yes thank you very much Emilio uh I'm really excited to see do we have time for question unfortunately we don't have time for questions I be here would be happy to answer questions outside thank you so much Emilia uh next talk is by eigor it's going to be about the specification and model checking of the ZK sync governance protocol take it away eor okay thanks a lot thank you for the

introduction and having me here so what I want to talk about here is specification and model checking of the K governance uh the K governance protocol that's actually the work by danis colleague of uh of mrrbs and myself and I want to say that Denis wrote a large part of this specification and I helped him with a choice of proper abstractions right in the protocol invariance and mod cheing experiments so it doesn't click okay uh so before we start uh talking about the specification let's just have a brief look at what ZK SC guance is about basically in the cas in

governance we have four entities the largest one is the token assembly that consists of the token holders and the delegates who can propose uh some uh contract upgrades and the other three entities have to ensure that these upgrades do not do anything bad essentially so the talken assembly can propos these upgrade proposals and other three entities can vote on accepting them or rejecting them in addition uh these entities can also uh do some kind of uh emergency upgrade proposals and execute emergency upgrades and in addition to that the security Council can freeze and unfreeze

Layer Two which is quite important in this case so that's the case in governance in very brief there are a lot of happy pass scenario the simplest one here is that this emergency upgrade board executes the emergency upgrade very simple essentially one call all done how about more complicated uh scenarios shall I click okay so actually if you come to to this protocol as as I did as an external external person how do you find this Cy paath scenarios one way is just to talk to the Developers but another way as I did is asking the model Checker in this case I'm just

challenging the model Checker and tell it look it's impossible to find a proposal that has been executed and it was approved by the Guardians and the model Checker comes back and says no it's not true he's a counter example of five states how does it look like I'm not going to give you the actual counter example here but I'm going to give you this graphical picture that is much nicer and the count for example looks like this you have the security Council that starts an upgrade then some time passes there is this magic period of 72 hours then the Guardians approve this upgrade another period passes of 800 something hours and then someone

executes this proposal are a lot of scenarios like that it's not just two scenarios right and for this reason uh we want to have this protocol specified and also to have have the specified in in this work I'm using the language called Quint it's a relatively new language it's actually quite old because it's backed up by the tempal logic of actions that was proposed by uh Les Lampard long time ago but it's a new syntax that uh makes it more friendly for the engineers to write and treat properties and the specifications what I find very useful about Quint that we have essentially three tools here one of them is a

randomized simulator think about it as property based testing stateful property based testing or a simple form of fing as you can see in Foundry for instance and what you see here are this yellow Lightnings on the radar these are basically concrete executions the simulator tries it might find bux it might miss buxs as always right there is a randomized symbolic executor that covers larger ctors of this radar picture and it can find more bus but it can also miss them and there is a bounded model Checker that covers the whole Rider up to some range and it's not going to miss bugs up to this range

but it can miss bugs up to larger longer ranges uh the tool the tool set requires very minimal setup it's written typescript basically nodejs and F code or maybe Java if you want to run the model checkra so that was way too fast let's talk about U protocol specification basically how do we go from the solidity code to the specification written Quint or any other language actually um where is the cat here so Quint or CH plus uh they are not tuned to solidity they're not tuned to ethereum Virtual Machine they have no idea about blockchains these are General specification languages it's kind of a bad thing because you cannot use uh the

standard Primitives there are no standard Primitives like this but it's also a feature it's very easy to add additional reason capabilities to your specification so at a very high level what we have here we have the protocol specified as a state machine the circles are basically states of the evm and the arrows are the transitions between the states these transitions corresponds to transactions or what we call actions and you have uh the computation tree that progressively changes the states what's important here that actions may have nondeterminism which corresponds to choice of different transactions and choice of different

inputs so okay since I told you that there is no buil-in evm State we have to model it how do we model it in the case of this protocol we just add all the necessary features that are required uh in in this protocol for instance we add the block timestamp because it's important here we add the states of all the contracts we modeling here in addition to that we add the abstract states of L2 only the information we need from L2 and we add some history variables because we use these history variables in the invariance so it's very simple just record no

magic how do we specify the contracts again there is is no solidity so a contract for us is just a record that has uh fields that basically corresponds correspond to the fields in the contract there is no Constructor so we Define an operator which is basically a function from the arguments to the result and the result can be okay which gives you the state of the the next state of the contract the new state of the contract or it gives you an error is an error message so that's basically how we construct the contracts how do we specify the behavior again nothing complicated we just have pure functional definitions here which take as a input

the estate of the evm plus the states of the contract as you have seen it it takes uh the definition takes the input parameters it does some comput computations no side effects no exceptions just straightforward functional computation if you like and it either returns error again with an error message or it returns okay with a new state and basically we capture the behavior of the smart contracts by doing this functional specifications so once we have done uh with the behavior of individual functions we combine them into actions and the difference between operators and actions is that actions

can contain non determinism so nondeterminism means we can pick input data nondeterministically you see that on on top uh the choice of sender from the set of all senders so just pick non terministic uh then we execute some operators which are purely functional as I told you once we have executed them if everything is okay we updated the state variables our state machine progresses that's one of the actions we have many of them and again we basically say that the single step of the state machine is a Cho is an non teristic choice of different steps who makes this choice we don't know right but that's your state

machine so that's basically the protocol specifications there are a lot of definitions like that there are a lot of actions like that I would say probably 40 actions or something like that uh how do we specify the invs this is a bit more interesting because here we don't have any solidity code we have only English right how do we go from English to to this specification for instance this is one of the requirements we have got from the developers which is saying unfreeze may be called from any address after the freezing period has been reached how do we specify it actually in Quint we can just write a state inv varant which basically says that if the current state satisfy these conditions

that the block time stamp is greater than this freezing period and the current freeze status is in freeze uh soft freeze or hard freeze then we can execute this functional operator and it should return us okay since there are no side effects we just execute it and check the status very simple that's a state invariant we can check it in any state of the evm and that's it right so that's a very simple invariant we have plenty of of those there are also more complex invariant for instance this is a this is one of the requirements from the governance procedures that I actually written in an actual document right once Frozen an

emergency upgrade may be executed in order to remove the freeze and or initiate a subsequent freeze how does you specify that there are some formal methods people in the room they would tell me it's temper logic but I'm not going to use temper logic here actually we can specify this stuff as as a state en variant again what we do we go all over all possible parameters here we execute some operators we check some preconditions here and then we do something interesting we can actually execute one of these functions check that it was okay and then based on the state this function has compute like evm

3 here we can execute other functions compute new States but since it's all free of side effects we can actually compare alternative feutures we can say that from from evm 3 you could go could go to evm 4 and execute uh execute soft free and it should be okay or from evm 3 we could go to evm 5 execute a hard freeze and it should be also okay this is very interesting I have never seen anything like that before actually can talk about alternative Futures inside the state in variance so that's a very neat modeling trick if you want to reason about things

like that uh and basically we don't use any Temple logic here which is a bit surprising so by applying these tricks we basically specify a lot of uh invance from the governance procedures we have like 45 invariance uh some of them are more complex some of them are simple and so on so forth so how do we check these invariance I told you that there are three different techniques uh what's the difference basically if if you look at the actions if you look at this step and if you look at the definitions of each actions you will notice that there are two key constructs here one of them is called any and that's basically saying I choose

one of the actions nondeterministically that's what we call control non termism and another construct is this nonde new time stem blah blah blah one off one off is data non determinism basically either you choose an action or you choose a piece of data both are non teristic how do we resolve this non termism and the difference between these three tools that we have is that they resolve this non- termism differently in three different ways so when we are talking about the randomized simulator it picks everything at random it picks actions at random it picks data at random very easy very simple to

understand maybe not so powerful when we talk about randomized symbolic execution it Peaks actions at random or transactions if you like and it offloads the task of picking the right inputs to the smt solver to Z3 and this is done in the model Checker called apalachia and the third way we actually offload the task of choosing the proper actions and choosing the proper inputs to the smt solver completely that basically gives us the bounded mod Checker which analyzes computations up to some bound so these are three different tools actually the two tools below are the same tool just uh implementing different

exploration techniques and what I want to stress here is basically we are not doing complete verification with these three tools what we do we do somehow progressively uh more complex more expensive analysis we start with a randomized simulation which is essentially cheap it probably doesn't have this good bug coverage then we go to random randomized symbolic execution it's more expensive but it gives you a bit better bu coverage then we go to BU bounded M checking it's in some sense exhaustive because it analyzes all executions up to certain depths but it can miss long execution executions and in the very top you have this golden grail of formal

verification we are not kind of trying to achieve that but we are trying to uh analyze uh the bug to find bugs faster and this somehow resonates with this recent talk by Mike dots of gala where he says we should try to make our favorite formal verification methods cheaper and move them to the left that's how you can move them to the left basically um okay so that's basically about the techniques and now I want to give you some some ideas of how how long it takes to check all of these enires so for instance is it here there keep keep clicking it um so for instance when we check one of these Inari uh we

have specified we around 100,000 randomized RS up to 30 transactions each and it just takes 3 hours it's actually not a lot right it's very fast in some sense it could run 1 million random runs and it would take well 30 hours I would say 1 day would we find all bugs we'll find a lot of bugs actually in not in this case but in in other cases we would find some bugs um will we find all bugs actually not when we run the randomized symbolic execution takes longer even for 1,000 symbolic runs up to 30 transactions it may cover uncover more bux and in our uh

in our activity of Rights and the specification and variance actually found a lot of bugs in the specification itself and in the invariance the Rison and finally bound at model Checker it's kind of slow right it takes 5 days uh to analyze all runs up to nine transactions but it's all runs even though it's slow and this figure gives you an idea basically uh when the ran bounded model Checker up to six transactions it was run for half a day not not so slow but actually it has uncover it four problems in the invariance luckily these were not problems in the protocol itself they were problems in how we wrote uh the enir but it still has found some bugs

which actually surprised me because we did a lot of randomized stuff we did a lot of randomized symbolic execution we did a lot of randomized simulation and still the bound model Checker has found some issues then we ran the bound model Checker up to nine transactions some of of these experiments timed out uh it took 10 days really really a lot right and it has found no further issues so we're kind of convinced it should work more or less right um so there are some kind of questions of how you do more advanced modeling if you want to check it I'll give you the link to the slides I don't have time to discuss it one thing that I want to stress also that there were other code audits done in parallel to

this work and there are some submissions saying this issue can happen or that issue can happen what we could do we could first of all reproduce these issues in the protocol and after fixing the protocol we can check that these issues are gone which is quite useful if you have a protocol specification and the in variance and right in a new invariant once you have written like 40 of them is not even hard okay so that basically finishes my talk um if I can go to the last slide basically a summary what I want to stress here that understanding the protocol is essential it's not only about the lowlevel problems like

overflows or some problems calling uh a strange address which is of course important but also understanding the logic of your protocol is important and we believe that protocol specifications help you to write in variance because looking at the code it's a bit hard to write in variance also I want to stress that we should use all the tools available like randomized simulation I was kind of skeptical coming from formal verification I was like I it's randomized it finds nothing sometimes it finds bugs very fast but sometimes it misses bugs so we have to use different tools that have different strengths uh of course this work doesn't replace code aits there's some code aits done in parallel uh and they focus on

different things finally if you want to check all these things here's a QR code uh you can check my website uh we have a blog post that's summarizes all this experience you can write it read it in detail and you can check the tools we using thanks a lot that finishes my [Applause] talk thank you so much eigor we have time for one question one question for the audience there is question the lady in the back um thank you for that talk what

scenarios would ZK sync freeze the protocol for what that I couldn't hear what scenarios would there be that would cause ZK sync to call the freeze could you hear that well I I mean that's basically the security Council can invoke freeze and there were like different different ways you could do freeze you could do with soft freeze hard freeze and there were also some issues when when basically where you could do like could do hard freeze and and without executing emergency upgrade you can uh unfreeze and do hard freeze again for instance there were

scenarios like that you have seen and they were basically fixed uh they were basically found in par loits I cannot claim they were found by us right but we could repr you them okay thank you so much eager uh and for the next talk we're going to have Andrew tell us why web 3 security is embarrassing andw tell us how you really feel about web 3 security okay

cool uh yes I will really tell you how I feel about this uh this is my talk wave three security is embarrassing and a very small text that you can't really see while we can must do better um so a little disclaimer at the beginning I really love security like I go to a lot of security things I always have people who are like oh I enjoy bouldering and cooking doing other things I don't in my free time I also enjoy security so I do security at work and then I also do security for fun I also love drama it's great that's why I work in crypto um I will definitely be able to convince you why you should watch Survivor if you do risk assess uh and I also love ranting so that's

likely what you'll get here uh okay so who am I the Alias I usually use is Andrew Mohawk you'll never figure that out why I picked that uh it's because I'm very creative uh no I picked it when I was very young and now I have to deal with it so uh my background is I worked at Boba for 10 years we built multigo uh then I did instant response at bitm I set up instant response and detection response at Robin Hood then I was a head of security at uniswap and now I'm at uh privy and big shout out to privy for letting me do this talk after a month they're a embedded wallet company and my talk is about to rage about wallets so that's really nice of them uh also I'm

part of the black ad review board and I've been part of seal for a while now okay so it'll be a short rant in four parts it's short because this is the longest slot we have if there was a two-hour slot I would fill that up um so start with web 3 it's obviously web 2+ one I'm really good at maths that's how I figured that out uh if you take like the traditional Web Two stuff are connectivity the things that we add on that are like really functional here are it's inherently more financial right everyone is using it to uh you know do things with assets that that have value so obvious has a much higher returnable investment for attackers um and that there isn't really a safety nit of providers like we see in

traditional web to like especially in fintech so you have a user that directly interacts with a chain or with crypto rather than saying oh it goes to a bank you know if I if my mom takes a card and she tries to draw all her money out an ATM the ATM is going to be like whoa you should go to the bank but if she tries it in crypto just getting she W then it will allow her to do it uh it's obviously digital so there's 24 coverage and whatever you do you have irreversible actions so the first part is we are genuinely failing our users like it is Security's job to keep everyone safe to make sure the people make safe choices and we are losing to uh I don't know if you can see that on the slide we're

losing to ransomware there's more there are more funds being lost from fishing than they are from ransomware how can we lose to that that is always in the news that's terrible um then also we have oh uh 314 million lost in fishing in the first half half of 2024 these numbers are crazy uh so we should all feel embarrassed then also drainers are really cheap and easy to find you can go on telegram there's hundreds of them um this one is like $600 for f fully featured drainer you don't actually need to understand crypto at all so they will help you set it up they will teach you to go through Cloud flare they will tell you how to deploy it uh they have

automation that will help you and they also have redundancy so every now and then they get they get banned telegram where the channel gets banned and they very quickly can communicate with all the people who have made purchases and get them into a new channel um I mean that's a lot better than most crypto companies that I know sorry the App Store is also rif with fake apps uh so it's really difficult for us to get our real apps in there and I think this was the part where I was like wow we're really losing uh so when I was at Unis swap there was like a fake Unis swap app that was in the store and I was like well I got free time I'll take it apart I got the IPA decrypted it uh reversed it and inside that IPA was just a web View and it

opened up and there was just this big text at the top that said enter seed phrase and then there was a big block it was a text area that was it and then there was a button that said submit I was like this person did not even skin this like this is in pink there's no logo like I'm losing to someone who literally went through like an HTML tutorial uh a few days ago and you know they're making millions of of dollars so but upsetting um then also obviously we have dependency issues uh you know more recently uh with the L files but also like we see it regularly on mpm we had The Ledger connect thing but this is something that we don't see in web 2 like when was the last time Robin Hood served up malware from their core site uh or any Financial place I can't even

remember the last time that happened uh also I'm not going to get to Smart contracts there's lots of attention to that a lot of your Auditors you're great at this also every single workshop at def5 security Summit is about either smart contracts or evm except for one uh so a lot of coverage there it's also outside of the scope of this talk and if you're old like me then this is a layer eight talk um also really good at graphic design uh so I've uh carefully crafted this that it's going to get worse okay so we still at the top your daps uh so daps obviously the crypto applications they're the pivotal point between the users and their wallets and the providers and underlying crypto okay you

have a responsibility to your users if you build something you should know that users are going to put their life savings into it right you need to at least turn on logs I've been in way too many incidents now where we'll get there we'll be like oh something bad has happened I also love incidents because it's drama something bad has happened I'll be like oh great let's get the logs let's have a look no logs they be okay we turn them on now unfortunately time doesn't work that way so you cannot also if the application does really well huge application dprk or going to try and uh cause some trouble steal all your funds that sort of stuff uh so it's really important that we help our users right because you're a super high uh value attack vector and I think one of the core things that we

always see is that we need to do web two before web 3 right we don't have to speedrun all of the web two security problems like they have solved some things we should just take those and move on from there um and then our goal be that if we're building things we should be trying to help users make safer choices that are easier and that they want to make like you don't want to tell them hey if you need to sign something go to the roof have your em shield on make sure you type in your password into your Ledger every single time you need to go to openc and say oh I'm signing in like that would be ridiculous right sure it is more secure but it's unusable um and I think a good example of where it has been usable is like the UB keys and pass keys and also

I'm a web both so if you don't believe in that come find me I will convince you uh then the other thing is also is like it's not externally facing only right if you are a group of Engineers even a small team that's running something please just get a password manager and either use UB keys or pys like that will cut out 80% of the risk that we see um and it's it's really important like you're taking care of people's funds you should do this then of course you need to secure your code you write code let's secure it so if you have the money get an audit of it okay we see places with like seven smart contract Audits and zero front end audits it's really important that if you're going to let users interact with

your things you should order all of it right if you don't have the money you can also use something well I guess even if you even if you do have the money you should do this anyway you can go to Frameworks right Frameworks is great has a lot of like the foundational things that you'll need um you can see there I got at the corner repository Harding cloud provider gardening these are things that you want to do anyway um then I'm going to go on again about this please turn on logging so if you're looking at like your risk assessment you're going to say what are the things that are going to totally wreck my company those are the things that I'm going to try solve first and then you're going to say like what are the things that will totally wreck all my users I'm going to try solve those

but actually what you should do is at the beginning turn on all the logs right make sure that you have logs of everything that happens just put it in a database it doesn't really matter um and then you can try and solve those things that are very critical because in the event that something does happen you want to be able to say like okay I can see what happened I understand it and I can provide like a a fix of this doesn't happen again right um so I think that's that's really important then obviously you want to do the secret code and dependency scanning okay you can do this for free there is no reason that you shouldn't have this on by default all of these things will integrate with GitHub whatever your cicd is um and you can use the free versions if you're making

something that's open source all of them are free so truffle hog will find your secrets and it'll find it where you know you committed that key and then you were like oops and then you write a a commit over it and then you're like great no one can see it um you will everyone will find it you just run truffle hog you'll get it I found one in a very large nft project last week um they can use s.d they do their dependency scanning for JavaScript things really good they'll be like hey this package suddenly has network access or this package suddenly has new Authors um you can also use sneak code for scanning code so they'll be like oh there's a vulnerability in the code that you developed this is how you should fix it uh then the last thing

is plan for when and not if so have a big red button that says I'm disabling everything right have a plan that says like oh if our front end is compromised and the CTO is on a plane we don't wait for him to land we can still be like hey this is we're turning this off right practice rotating credentials cuz so many of the attacks we see are people who have like left the company had those credentials from when they work there and somehow leaked them right you should just be able to rotate credentials always um and we see a lot of these okay then also you should promote good engineering and security culture so if you're building a Dap and this is one of my favorite uh modos that we have at privy is all engineering is security engineering right whatever you are building users will use it will be have

a financial impact especially if you're obviously building Financial applications okay now we'll talk a little bit about providers um there we go so security is kind of like an arms race okay everything is hackable there's nothing that's unhackable if you give me enough time and money I'll break in um you just need to make that bar you know higher what we want to do all the time is like make it more difficult for attackers I don't want to see them make a text box next year um but one of the things that's really difficult is to try and get providers to to change right because usually you don't have a choice if you want to have DOS protection you can't use any anything but cloudfl basically right they provide the best service um so you're probably going to use it but

the only time that you're going to get a provider to make any changes that you want or to add anything to their road map is during renewal season okay so if you're a company and you buy from a provider just wait till it's renewal time and then be like hey what are you doing about all those web3 fishing sites um so that's the best time please if you have that do that okay as part of seal myself ampled this uh block list it's like a metamask block list that we update automatically by scanning for stuff so we can try and catch drainers ahead of time um and now it's Sam and others and tiny bit of me um and that you'll see like when you get the red window that says like oh a deceptive site so what I did was I went to look at all the all the domains and

all the things that we've put in there and I say okay well who is hosting this where are these registered uh so we have like some stats about it there's like 226 uh, uh 173 still have who data and 127 you can still get to like you can BR to those things still which isn't great uh also it's very difficult to do 220,000 ho requests and my girlfriend will be very angry if I got a house Bann from the internet again so uh I reached out to some people they hooked me up with uh who is XML who was super nice and they were like send me a CSV that's you know two 200 Megs and I will send you back the who information which is really cool um then I built some scripts I mean just

kidding Claude built some scripts I ran those scripts so I have a lot of job safety um and here's what you'll see so this one is the most important one I basically have this whole section so I can have the slide um clle hosts 68% of all fishing sites that we have seen everything that we've seen for uh like known bad they host more than half of it and someone brought up like oh what maybe CL does you know more than half of the Internet it's like okay but in their Q3 report from last last year they said they do 16% of the internet so while they only do 16% of the internet they are hosting 68% of these uh malicious domains uh and there again cloudly please reach out to them if you use them during your reew time a them what

they're doing uh they also have a way that you can uh submit but you can only submit one domain at a time and I'm going to tell you that if I have to submit 128,000 domains it's I will kill the computer before then okay regist draw is kind of the same thing uh they're a little bit more diverse um and I have the data if anyone wants it afterwards Twitter they're going to give away your account 100% if you are worried about this you should be planned for it already follow the seal guide to set up Twitter but at some stage know that that is outside of your control uh they almost made a really great thing where they said we could disable links and replies which I think would have made the biggest difference in crypto to anything I could ever do but they

decided against it 18t Verizon these places suck they're doing our Sim swap protection really badly they've been forced by the government to do something and they've done the bare minimum so adding a note to my account that says hey if this person phones to have a SIM swap ask them if their dog's name is Sandy and if I say yes then great do the Sim swap that's not any protection so that's really annoying um and if you are worried about this move to Google F it's basically the only choice you have your sim is locked behind your Google account and your Google account can be locked behind Hardware tokens or py so you don't have to worry about uh Sim swap okay now my favorite section ooh we're running out of time wallets wallets are obviously like evolving

rapidly I'm going to be mostly talking about the extensions um and they take like I guess the the complexity of the underlying crypto they make it easier for us to understand right they have great UI and ux uh they have cute animations and sound and colors and it's really easy to onboard to crypto with it uh Unfortunately they don't have the same guarantees right because you can't say like oh I send all my money away and someone says Whoa is that what you want to do like you have to go into the bank to check that no obviously that's what we want we want to be in control but you know we lose some of these guarantees okay so then I was thinking about wallets and I was like well what does a wallet know if I use it it's on my computer it knows where I am right

now it knows my IP address it knows my time zone all of that stuff it knows where I connect you because I've clicked connect and the wallet was like hey do you want to connect right it knows where I connected to before because I use the same thing so it knows this right it also knows who I sent funds to so if I send funds to andrew. e you're all welcome to do that that's no problem um it will remember that okay and I understand there's like a spoofing thing I put a little star there and they also know what you usually do so they know like oh after 5:00 p.m. you go to pump tot fun and just buy every meme um so these are the problems that I have with wallets the first one is look Alik addresses so this is an attack where an

attacker will see that you've sent money to some or send assets to some other um account they'll pregenerate a public key that looks similar to that so like the first four and the last four digits are the same um and then they will then they will make it seem like you sent money to that address then when you go to send money again uh send assets again you'll click on the last one that's the malicious one okay you've sent all your funds away um I spoke to someone yesterday who was like this has happened to me this week um in this list you can see see that the very bottom one is the rocket pool transaction that they did and then all the ones above that are just malicious actors trying to get their their cash uh most of the wallets

in terms of protection will give you a popup that says hey you've never sent this address before okay the odds of you finding a dress with just the same first four and last four are one in 18 quadrillion I promise wallets you can just block that just don't let that happen you have all the information and if you hit that if you hit those odds I will buy your a hat okay I will buy a hat for every time you get that um do we have similar URLs like let's say you were like o I like unichain I went to unit train.org the wallet knows where you connected to it knows what you've done if I connect to unchain dotop it should be like hey this is pretty close to something you connected to before but it's not the same like maybe we shouldn't let you do dangerous actions

or things that are sensitive right and you can solve these problems pretty easily this is well documented in web to we have lots of stuff like the Levenstein distance to see how close they are together we can have a list of known good domains we can do an SSD Pat against uh good domains and say like hey this side looks very similar to one that we usually connect to that's worrying uh we can also look at domain age so if the domain is one day old just don't let the user connect to it uh it's it's crazy uh then we also expect people to be Crypt native which is kind of like the equivalent of when security people used to tell everyone one that they need to check the headers of the email I promise you if anyone checks the headers of every email I will also buy your hat

apparently this is my go-to now I'll buy hats um but if you look at that like no one is going to understand what is happening there even if you have it as you know text it's put out the forbit it says get my money and a recipient address you can guess what that does but like how are you possibly going to understand that um then understanding the permit permit two and approval flows I promise you my mom is never going to figure this out uh there is like a huge page it explains it really well it's really nice but there's no way my mom will figure that out um if you love your mom I love my mom then you wouldn't let her go on Twitter with metamask right now right you know that she's going to get wrecked there are loads of like scams it's super easy without that um

you know without any any training that that will be the first crypto experience that someone has is losing all their funds um what I really want is this thing called Mom mode this has come up before uh where it's a safe mod I can say hey here are all the deps that I approved that are good I want these to to be the only places that you can connect to okay because if you have that then I know well my mom's probably going to lose her money on shitcoins but at least she didn't get scammed and I won't be embarrassed okay because that's my job so that would be that would be bad um wallets don't warn users when things are unexpected so if you are draining a wallet you have to do multiple transactions like you need do an approval and then you moove the funds

you have to do it for each asset type um there there are some intricacies there but W let neighbor warn you the never like hey all your usdc just left do you want to do something about this maybe we can have like a a backup plan of this seed phrases these are terrible we suck at remembering passwords we suck at keeping things safe this is just a combination of two things that we're bad at um for seed phrases there are alternatives so this is the one slide I got to say put the company in so that's great see I support them uh if you use something like privy or some of the other embedded wallets then you can sign in with things that you know before like Google Twitter you can use a pass key so you can just sign in with your pass key

and get it every time you don't need to send uh a seed phraser across and the other one I really like is how uniswap handles the from your mobile wallet to the extension when you install the extension you can scan a QR code it will then do an OTP and it will verify that you're on the same land so you have to be at home you know if an attacker is in your house like you've got other things to worry about but at least here like we have a good way that I didn't have to copy a seed phrase put it somewhere you know copy it again okay loads of improvements oh I'm way out of time so weboasis it's fish proof authentication we've got to have this like we can solve fishing there is a solution to it allow listing mom mode I love this High net worth individuals

like we see people who get drained for millions and millions of dollars but if I'm a high individual and I go to a site for some reason I have millions of dollars in this scenario that would be great if I go to a site and it wants me to interact then why don't you just spin up a new wallet for me it takes no time I will pay the $2 extra so that I know that the rest of my assets are not at risk um we don't I don't see a lot of emergency buttons like revoke all or I want to move all my assets I feel unsafe about it um and then rethink of their approval flow so ux people are incredible they're super good at what they do let them do it um and then of course clear signing people need to understand what they're

doing I know tons of wallets already do this and you're the best I love you long time okay security this is my last one oh I have 18 seconds it'll be fine security folks need empathy so I think that a lot of the time I see that real people get scammed and people are punching down like don't do this this is really hurting uh the industry uh people are going to you know feel ashamed uh feel guilty they're not going to want to say oh this is what happened to me without that information we can't make security better right this is something in a thread uh that was part of someone said you know what's sad is I know a victim they sold their house for a scam and then another person said well you know what's more sad is that I warned

the project 7 days ago I promise you you warning the project seven days ago is not more sad than someone losing their house um they not a security folks to dog food like security advice is difficult um but if you want to give out security advice I expect that you are doing the same things if you say oh you want to put your phone you think everyone should put their phone in lockdown mode run your phone in lockdown mode not everything works I promise you my phone has the worst rendering of all websites you've ever seen so understand what the difficulties are like do you have a hardware wallet do you sign every transaction if we're giving out suggestions you have to be able to run this yourself um and also being able to run it yourself means that we can work on good and workable Solutions because

you need to be able to use it as well oh okay security folk should also support people so callock good security work if you see something that's good be like hey this rocks you're awesome I love this like we don't only need to be like wow these people suck um then also share your knowledge so people are very hesitant to share their knowledge they have like they know a huge amount about something and they'll be like oof but if I share it then people will steal you know my credit and the place that I can be in I promise you that one blog post will not steal all your knowledge and then you will lift up other people and you have a chance of like expanding it uh then also you can submit a bug without getting paid a million dollars uh okay so that's the end let's

make crypto safe enough for Andrew's mom that would be great thank you thank you so much Andrew I think we do have uh time for like one question anyone why don't Cloud play take down those demand oh no someone does have a question I was going to ask it's fine really love your comments on asking all the developer and the D app like enable locks but one thing I do do want to add as a common is that based on our experience very often people didn't pay attention to protect their locks and also didn't pay attention about what put

in the locks so that actually are some of the you know vulnerability or security risk we have found before so we really want to hear your suggestion how people should you know pay more attention protecting their logs thank you cool um I mean I I think that it if if you're look at like the uh extension wallet side or the the application side then I think the main thing is that there's a huge push in the industry that we need to get out features fast people need to deploy stuff as quick as they can we don't spend enough time being like okay how does this work do we have unit test for everything that makes sense um and I think that calling out like hey here are some things that cost other companies in similar positions this much money and

losses like is why you should spend extra time but mostly I think that it's it's just a time thing discussing with the dev team I find is really good I'll be like all right you're all criminals now tell me how you're going to break in they know the code better than I will ever know the code so um a lot of that stuff really helps I think like you know normalizing normalizing that thank you so much Andrew uh thank you all for being part of the session thank you for our esteemed uh speakers and thank you mly for making my dream of becoming a moderator in DSS reality happy lunch [Music]

it's okay they left yeah to's a lot saw

for e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e we are about to start our first after

lunch session I hope people start flowing in and hopefully everybody El had a coffee after lunch because this is going to be a very interesting session that I hope everybody going to understand very powerful testing technique going to be explained by not it's called invariant Focus code bases so that stage is yours right all right hey everyone I'm Nat um

just a little bit about me I'm an independent security researcher um I spent four years at trail of bits um I joined as a junior and then um I did a bunch of security code review I did a lot of invariant testing and um I did a lot of uh kind of like fuzzing um before that I was doing blockchain development um as well as teaching uh for blockchain so the focus of today is primarily going to be uh kind of discussing the practices of secure code review um and this is kind of the I think there's a lot of overlap between code review and invariant development

which I want to touch on here so a while ago um I was talking to one of my friends about um just the process of doing a secure code review and we sort of settled on the fact that um trying to figure out what developers in ended to do um tends to take up the most amount of time within a secure code review and the quicker you can understand what the developer intended um the more fun the code review and usually the more complex bugs you'll find I think that's also similar for invariant development because the more the faster you understand the code base um the better

invariance you come up with and the better um or the higher quality your fuzz test star so I want to start off with um kind of a disclaimer that this isn't going to be like 10 minutes of like here are all the things you need to know about unit tests fuzzing and like formal verification I don't think that's effective um I think given infinite amount of time ideally you would Implement everything um there's trade-offs to everything and the purpose of this not this talk is not to debate which which one is better um so to start off um I've been

getting a lot of questions on just what an invariant is and at the end of the day it's very broad um it's very high level um it's essentially just a property that needs to hold true on a code base so again very broad it can be Access Control related it can be how functions um are expected to work and not work together whether um it can be data structure related and so um it's kind of hard to provide very strategic guidance on how exactly defin invariance um and so this talk is mainly going to be kind of tips and tricks on um building invariant driven code bases

such that from developers and for security researchers we have an easier time and one last dis claimer is your invariance are never going to be 100% complete I've been on engagements that have been very long um up to 12 weeks and even then the list of invariance that I came up with um or the process still wasn't complete in any sense of the word um this talk will not be either and I could probably go on for hours on end related to um how to figure out invariants how to find them um so this is just kind of an in initial starting

point so from a developer side I think um one of the most timec consuming pieces or practices as a security researcher is looking at a code base reading a function and then realizing oh that function doesn't necessar doesn't do at all what the function intended to do it said one thing and then you actually look at the what the function does and it's completely different if you from a develop perspective if you do create accurate function names it helps in variant development and like the process to make that way easier um and especially to commun adequately communicate what the

function is doing um the other thing is if you can adequately name your functions then you can more easily determine what the relationship between different functions are um and then you can also have an easier time um to essentially figure out how functions are related um generally if you have like one function that uses multiple helpers um having those at least close together visually helps a lot this is kind of repetitive from my talk two days ago um but documenting everything in terms of assumptions because any wrong assumption can result

in unidentified or unexpected Behavior which is very likely going to result in a bug um from an invariant development perspective though this ends up being way more useful than I think people realize because you can essentially read the documentation and any that is different between the documentation and the code is something to look at and something to report the next thing is just to comment um all the expected data validation of the system um ironically I've actually found some bugs while looking at a code base um pseudo coding the data validation that's ex that's that the system is

currently implementing it and then sharing it with the developer then they're like oh no that's that Clause is missing some specific access control or some specific check um and I think it goes a long way to commenting um all expected data validation because then you can more easily determine what the function is expected to do and then my last one is um kind of the relationship between um developers and security researchers so I think there's um each party brings like something slightly

different to the table devs I think bring um how users are expected to use the system um what is expected uh kind of the um functionally um how users are supposed to interact with it security researchers bring a different understanding of security risks protocols um different things that maybe other protocols got wrong um and I think there's it be and very development becomes way easier when you take advantage of the fact that developers know or should know how their system works um so that can be async that can be um through calls but making the time

to talk with developers on what is expected um can also go a long way to understanding the system um I'm going to keep this kind of shorter um helpful practices for developers it's really easy to identify when a code base is built with um invariance in mind because it's much easier to know like when State changes it's really easy to know um how to get tests up because you can just look at the code base and you already know um it from reading it um if you do end up practicing tests while or writing tests while coding

um you're kind of forced to think about invariance by default when you're coding um obviously I think and and probably something that's been talked about for the last couple days is maximizing test coverage if it works um gives you an idea of what might be missing coverage what might have more coverage and give you an idea of what to focus on um and explore automated tools the tooling is going to help security researchers because then you can leave the tools to find all the low hanging fruit and leave the security researchers to find all the fun stuff and hopefully the automated tools as well um for security researchers I think thinking in an invariant focused way is

a lot harder than we realize because we're not used to taking a step back from the code base um we're too used to going into the weeds and seeing how the deposit function Works how the withdrawal function works and not necessarily um the in depths of or the the higher level view of what is expected um I found it useful to just pick a code base try to find some invariance on it try to bounce ideas and see whether um you can you may not find the same invariance um and your invariance are likely very not are not going to be correct in the beginning um but it's a very useful practice to start thinking about invariance in this way because you don't need to set up a

fuzzer or you don't need to set up aover in order to test those invariants you can start um identifying them and then doing your code review with invariance in mind and I will emphasize um to just take a step back and make sure that you get a bird's eye view all right so that was pretty quick um I left some time for questions so I guess we have a few minutes hello hey so a lot of good stuff in that talk um one thing you said that I

particularly liked is putting code you know functions near each other when they're related how would you advise developers to balance that against common coding practices that would be applied to large code bases like oh we put all the public functions up here all the internal functions down here and there can be benefits that kind of uniformity as well so you you know how how would you advise people to find balance yeah honestly it's really challenging because I would say personally I found if like the depth if if it's a relatively um if there's not that many helper calls then have I find it just easier to read in the same function um but obviously if there's like many different helper functions like kind of putting that into like

different different contracts um honestly I would say um the thing that I found that helps is just just cloning the repo um and then having like say like a split screen and Bs code either um side by side or like I guess up to four quadrants and seeing how hard is it to swap to like jump between um the main function and its helper functions so that you can kind of see visually um which one I guess is is the clearest in terms of its links okay any more

questions we are meanwhile preparing for a panel if no more questions for the crowd we will thank not for presenting and uh and uh we're going to start a panel uh moderated by Raji a about web 2 versus web 3 what's the difference is it a rebranding of an old Paradigm or there's actually something new there um so I invite medie Pablo pet and Anto to get on stage I guess and I guess

good all right good afternoon so looks like uh people are trickling in after a good lunch um so hopefully we'll keep this interesting and uh interactive at least definitely want to have uh the audience ask ask the panel questions um let's I don't think the people here need introductions they've been giving talks multiple talks and multiple panels but we'll do a quick round of intros I'll Kickstart it I'm Rajiv I've been a security researcher uh my whole life founder of secum one of uh the organizers of DSs and uh really trying to get the community rolling and this is

a topic that's really um close to my heart um because I've been doing security for a long time so so what we could have renamed this panel multiple ways but what we really want to talk about is what are we doing with web3 security right is it are we really trying to reinvent the wheel or as Andrew said it you know we shouldn't be speedrunning all the things that went wrong with web 2 in the web 3 space so that's that's really um the goal for this let's look at sort of all the historical things what went right what went wrong can we learn something or should we you know really restart that but before that quick round of introductions by all the panelists here

okay I'll start I am Paulo Sela pit. I'm a SE 911 contributor I founded obsc where we do operational security Audits and trainings for web3 companies and I have the blockchain security series podcast and well operational security is is my stuff I like I I I enjoy hacking people more than systems that's my my stuff uh hi I'm Andrew who did the talk two sessions ago uh I previously worked at bitmax my crypto experience and then Robin Hood and then in Swap and now I'm

at privy doing a better wallets I like all factors of security and mostly my goals are just not to be embarrassed a lot of the time not to look really dumb in front of my other sec friends um so that's my motivation for doing security amazing so am ano uh I work as a principal security engineer at aanl uh previously in my web two job I've done Hardware security mobile security Android that kind of thing and I got into coinbase so that was my first crypto job uh did base and now I can l so security has always been my thing love breaking things and uh trying to

fix as much as I can hey everyone uh May co-founder and director of Sigma Prime we're a blockchain security and research firm doing a whole bunch of security stuff across the entire web three stack uh we're also the founders and maintainers of Lighthouse ethereum consensus client responsible for a third of the ethereum network today my background is also in web2 security I've done a bunch of pen testing web app security assessments and so on red team engineering uh social engineering and whatnot so yeah web to security is a concept that's also really really close to my heart and Keen to dive into this hey everyone I'm Peter krinsky I'm at coinbase units ZX team I'm also the editor of the blockchain thread intelligence

newsletter I had a lot of web two experience in the past anywhere from Mau reversing exploit riding red teaming blue teaming just kind of keep on hopping security jobs so so Web Two is fun but web 3 is even more fun fantastic so I mean as you heard right so we've fantastic set of panelists whove been around way further back than than web 3 so that's that's really the the motivation for this panel but before we kick things off right just just some fun historical facts for for those of you for those of us who are are new to sort of web 3 security or even for those who've been around for web 2 a lot of these things are not new right Fact one the first message that

was sent on arpanet right the the predecessor of the internet the first message that was sent from UCLA the university in Los Angeles to Stanford SRI yeah we see some hand pumping um so that crashed the machine on the other end right so there was actually a memory it was a buffer overflow it was a memory corruption so they tried to remote log in and the story is that yeah you can look up Wikipedia they started having l o and before it got to G machine on the other end crashed the bit rate they expected was way I mean they expected was way smaller they had a 10 character 10 BTE uh memory buffer allocated but

that didn't uh really fit right so the details you can look up so this was arpanet right I mean this is uh what 1969 I think W but of course security goes way before that right I mean ciphers cryptographic ciphers have existed since the Greek and Roman and Indian civilizations and social engineering I mean Pablo talked about it I mean that's existed as long as humans evolved right so this is sort of not new while it may seem like that specifically when it comes to security right some of you may have heard of the salzer and schroer principles so this look it up so this was in in the US 1975 set of I think 10 principles really captures things like

least privilege common mechanism user experience um separation of privileges we talk about multisex lot of that has been sort of talked about captured formalized in a different context right obviously they didn't have ledgers back then now blockchains the reason we talk about blockchains consensus security is the bantine Fault tolerance bantine General's problem right was formalized in the context of distributed systems in 19 what 78 so things have existed in the blockchain space in the web two space in the web one space so for a long time right but just want to sort of kick things off sort of level level set

ourselves and the audience with how do you guys think about what is sort of web 3 security versus web 2 security do you sort of compartmentalize it or is it one big thing anyone would like to hear all of you I can KCK kick it off um I guess I look at web 36 security is kind of like a a subdomain of a larger security field like it's a it's a domain specific thing and domain specific knowledge uh we have very unique challenges right we have to think about everything is decentralized wide open to everyone you can't submit a secret to someone without everyone knowing about it um but it's it's almost like a like I think it's a misnomer to say that web3 security is

this own this special thing and it exists in isolation and we have to forget about everything else that exists no it's a it's another domain it's it's it's a lot of fun but we also have to remember all the different lessons that we learned since I guess the 69 got to send messages that crash things we still send messages that crash blockchains and uh we have to learn from that as well yeah um kudos to both of you in your talks for you know sharing with people that web 3 systems are typically deployed on web two systems right and I I'm sick of seeing people get popped because of poor security hygiene that's got nothing to do with onchain activity and solidity and the evm um we're we

don't have to reinvent the wheel um people have come up with great set of standards that we should all be following I walk around in the conference and I see a lot of people having leaving their um workstations their laptops andm monitored and unlocked in security conference like that's wait I have a problem with this yeah okay I'm allow of controversial topics all the time right yeah yeah how many attacks have ever happened from someone leaving their laptop unlocked heaps uh I I don't believe that there was any of the big attacks Rel left from someone's machine unlocked well that doesn't mean that we shouldn't prevent that from no I I agree but I think that security people focus too much on that one no that's one example of um so back back back to your original point of you know being um

aware of of of some of the limitations of of our space um I think think we're among a lot of people think that we're amongst friends here um you at me when I like I'm sure we're friends but this is this is like just don't leave the machines open please yeah this is a prime um this is a prime conference for anyone wanting to potentially attack Founders right and backdoor laptops those laptops will potentially be deploying sensitive smart contracts sensitive systems and and protocols in the future so um yeah so that that's one example one of my teammates said that he even found an unlocked phone in the bathroom today so yeah I I think we can do better I'm not saying that like this

will automatically lead to compromises of web three protocols but the bar is so low at the moment that we should all be um you know working towards raising it um and yeah it's a lot of people think that you know oh I've I've gotten 10 audits I have a bug Bounty program on IMM unify so you know my protocol is safe but not not really not really yeah I I think uh we see a lot of smart contract attacks early on and now we have gotten to the point where Protocols are getting Audits and it's difficult to exploit maybe not difficult but it's it's a higher bar to exploit protocols so attackers would probably want to go

for the lower the low the low low-lying fruits right so web to like if you do not not have your web to security down you do not have to be exploited on the smart contracts you could be exploited in the UI so the recent attack people saw something in the UI and they signed that but they never verified it on their Ledger devices that is a very web to attack it has been going on like you know remote code executions uh so we are seeing more Web Two attacks than web 3 attacks because hopefully we got our solidity smart contract security right now attackers will go on to the next

thing which is web to so I think we've also seen that in web too so previously there were like loads of server side attacks like people would attack is-5 for you know days and days because you could just get it to drop shells all the time and now that that security is improved like people have moved like further up the stack or closer to closer to real people um but I I don't really differentiate between the two like I I don't really have a differentiate between web2 and we through security like it's it's all security it's slightly different um you know there are some like some differences in how it's used but the same would be like if someone was using a completely esoteric language or there was some other way that we deploy things um I think that the nice thing with web 3 coming in is

that we finally have a chance to change some of the web two things so if you look at web two companies like everyone is very stuck in how we do security like there is a basically a hard and fast rule but coming into our space like we have a chance to make a difference so like if you if you wanted to be like I'm going to flash the machines every single day before you get to work I there is no web two company that is going to going to go for that but I think that you have a have an option with people uh in the space being like you know like more fresh and dynamic like they're okay with taking with trying new things um and that's that's really why I like it I think that uh especially if you work in ABC like you have a chance to make a

significant difference um in what do and like have a cool way to do it yeah uh I think that well as you have already said uh there's no web three without Web Two And I think that we shouldn't make too much of a difference but I think that that the key thing with with web 3 is that it's much profitable and cheaper for threat actors than going and I know stealing credit cards database and then doing stuff with the credit cards so I think it's a matter of incentives uh first of all uh and then I think that a very big issue that we have is that I don't know banking industry has regulations and they tell them you have

to do this this this and that and they do it and in the crypto industry there's no regulation everybody does what whatever they think that they that they should be doing but we have no processes no standards no nothing there are some things that are being created around that now and I think that's pretty important but anyways we are realizing that that's important because funds are getting stolen like in the thousands H sorry hundreds of of millions so when that happens we say okay we have to make a change here and another thing that they think that it's very important is that lots of web two attacks that are on on defi protocols for example I don't know taking over a

domain or a Twitter account affect users and not the protocol itself and sometimes protocols then don't reimburse users or whatever so some of them don't care too much about their users I think that should change H and that's why they say okay no our contracts are okay we we if there's a fishing campaign that's not relate that that's not our responsibility let's say I think it is uh um but I think that it's mainly a thing of incentives and due to that we are we are paying more attention to that all great points I mean I didn't think we would disagree that you know web 3 and or web 2 security is not important

it's a bit of an echo chamber right I mean in this room and amongst ourselves uh so it's really to get the word out right so good glad we agree that you know this is critical but we do see that I mean we do have Anto sort of representing the protocol side of things right and uh so maybe just a simple question I mean you did agree that web2 security is critical as well so that's good but we do do see that when protocol uh when we say web3 security I think my guess we haven't done a poll the first word that comes to people's heads is audit right and that is smart contract audit Andrew talked about it uh Peter talked about I mean all all of you agree with that so protocols don't have a budget right

for whatever reasons to get a web to to get an infra audit or any of the other things what I mean why is that and what need to change uh to make that happen I mean protocols pay a million dollar I mean depending on how big your tvl is Right a couple of tens of thousands hundreds of thousands goes up what do you think maybe Anto you can sort of give the protocol perspective and we can all chime in what what is that mindset and what can we do to change that mindset I me oh did I say Andrew I I mean I can I can do this from time so we let Anto sort of yeah okay go take the spotlight first

victim okay yeah so um protocols do spend a lot of money on audits we we get like the audits from the top security firms and uh we we do not have unlimited budget unfortunately right we I would like to get audits from all the security vendors that I met here uh I think you're are all amazing but we have limited uh money to spend on these audits so we have to unfortunately pick a criteria and uh go with uh who is the right uh audit firm for the specific audit that we are doing so if we do anything with Beacon chain which we do we would like someone uh who has

experience with like a light client or or like a a consensus consensus client because they really do write that code right so we definitely pick our Auditors based on what is it that is being audited but security doesn't stop there uh there is a lot more you can do like we do get infra audits uh we do get web two audits I'm an absc guy who became a crypto guy so I understand how important it is but there are Stacks that you do not control uh so uh like for example you have a uh X account right like a Twitter account right uh you can do everything right but

uh you do not control that platform it's not a blockchain you have a username and password in a database yeah you can you probably know what can go wrong with something like that right and uh that does go wrong a lot especially in crypto because the incentives are so high but what can you do as a protocol to prevent that unfortunately not a lot uh you can follow all the best practices and and I'm sure like we all have contributed to all the best practices dock here right but there is no guarantees that even if you follow all the best practices you won't be popped I see Peter has uh I just I just wanted to point out like I just kind of I'm

sitting here and watching you talk about the Audits and how we have to invest you know hundreds of thousands of dollars and millions of dollars can we just recognize just how much time we spend as protocols thinking about security what do you think is going on in the web two world how much do you think a typical web 2 company spends on their security budget and how much time do they think they worry about this cool mobile app they're about to dump on everyone that's going to collect everyone's you know credit card numbers and passwords and Social Security numbers how much money do you think they spend on whatever security audits just I just want to point out just how far ahead we are and just how much more paranoid we are as a

web three industry as a defi industry just worrying about those things that said we have no choice but to worry about those things because once the money's gone it's gone and one thought that I have is we still have to worry about audits we still have to invest in that and if you saw my talk I'm all about like oh you have to build your Security Programs just teach your teach your entire team to be a security Team every single member of your team has some kind of security role like I don't care if you're a marketing person well now you're responsible for social media security and you're supposed to hunt down the fishing scams if you're a Dev obviously worry about smart contract code but if you're infra person freak

out about your Cloud infrastructure so dividing up responsibilities may be able to alleviate like some of the fear and just all the load that we have uh as a as a defi industry and a typical defi project which has like five people on it great point so um I'm sure we can talk about so many topics that you guys have talked about right Key Management uh all the things from the web 2 space and the web 3 space right but just sort of to start dialing up the heat a bit right here we go so anyone should we move slow break nothing or should we move fast break

something or in other words should we treat web3 security like Hardware security I know there's a school of thought here that believes that we had talks from a as well on on that or should it really be along the lines of we2 software security right where move fast or you break up update upgrade life goes on Okay who wants to take that maybe there a whole bunch of yeah so so there is that need for security versus the need for uh product Market fit right right like we can move really slow but uh your competitor might just go all out

and uh there is always that first mover Advantage which is a very real thing and so you cannot just sit back till even if you look at Hardware security sure they go slow and they still have bugs like how many micr code updates have you applied to your Intel processor very slow process right even Apple M1 chips they have bugs that can never be fixed so moving slow doesn't mean you don't have bugs you still have bugs I think you should design your protocol to localize your failures so the whole thing doesn't blow up but like localized failures so you can move

fast still have localized failures which is I believe more of a practical approach than of course you should do your Audits and all that don't be irresponsible with that but you have to also understand that you have to ship yeah cool can I ask a question just following this how about uh capping deployments that's something that I've seen some of our clients do when they don't have the time to um perform all the due diligence that they want to perform before going live they could potentially cap user deposits at like let's just say a few hundred worth of that' be a good good Str in your op yeah yeah localized failures right that is exactly like capping deployment guarded

launch few tokens have a certain T exactly exactly incremental stuff yeah I think there's a a like when we're talking about like fast or slow a lot of people see like security as a blocker for deploying things and I think that as like security practitioners everyone needs to realize like one you will never be a good engineer like I can make any engineer a good security person but going the other way is very difficult um and then also uh you know normal devs are paid on like the features that they release things they get they're not paid on how secure their codes or how well they did in an audit so every time that you stop them and be like hey you need to do all these things and make it slower like you're literally taking from them so you need to have a lot of empathy I think to be

like okay we can find like a middle ground I think that like empowering the the development team um you know is a good idea and the you know the base metric is like people will reach out to security I think that is the that's how you know like your security is making a difference cool all right so I I have a few of these yeah just one more thing you can also do other things right like you can still move fast as long as you think of like compensating controls for example you deploy your contract really really fast and you're scared that you make a hack but if you build some kind of functionality that can allow you to respond to incidents either automatically or at least fast enough you can kind of mitigate or control how

many funds you're going to lose in case of a hack so if you have a system that can just pause the prot protocol right away just the second you see the funds started moving or one of the volts is getting compromised you can kind of speed up the process maybe a little bit if you have like a faster incident response program built in you can you can kind of speed things up a little bit so it's a game it's a balancing game that you're always playing like how how much do I invest before the deploy versus like how much how many controls I can build after deploy and that can allow you to maybe take slightly more risk than you normally would yeah absolutely I mean so that's a great segue to the next question right I want

to I want to come back to because I forgot to add something to your question before regarding budget and what I have found because I I offer this operational security trainings and audits is that it's not a matter of budget but something that I see is you know this concept of security by obscurity many companies have a very shitty obsc but even with that they say no we don't want to we don't want you to audit our computers or our phones or for example devs devs hate to be told to be to have to install something in their computer or to be told that you have to do this in this way in this way they don't want to be told that it's very difficult to convince them to to do it in the end we can do it most of the time but it's very

difficult and then they are think of no I don't want you to know how how we have our setup right and the reality is that you can get to know how they do it anyways without them telling you but they have this idea that we have known for years that doesn't work of security by OB security no I won't tell you what software we use which are wallets if I have Windows or Mac or Android or Ledger or trestor or how I have configured my Twitter if I have a u key or Titan and they think that doing that is far more secure like no no no no we don't want you to know anything if you audit us you will know our setup and you will be able to hack us right so this is literally sort of speedrunning the web two thing right of

we don't want to reveal anything right you may attack us the whole yeah so this is this is a great checkway so there's a lot of surface attack surface to cover right I mean Web Two web 3 you know add them up web five I don't know uh but obviously we constrained right time bound budget bound awareness bound all those things so if you were to pick I mean the question is what's the weakest sling in vet 3 Security today you think it's software sorry it's fishing humans fish okay yeah so software Hardware you're working with wallets right or is it really people wet wear I I think that just maybe we can go around

to answer that huh yeah you literally had to talk about that yeah I I think the number one is SOA engineering conf mixed with fishing and with malware that's number one I think so people yeah yeah people people yeah Andrew I mean I definitely think it's it's people as well I think it's it's you know things like oh people were like oh we'll do fishing training but the data says that fishing training doesn't work spend that money on buying UB Keys you solve this problem like it is it is a solvable problem that we somehow have still mhm which is very frustrating yeah I I love that cuzz things like pasis is actually better than fishing training yeah you know like a decent solution and I think

we need to do that for wallets too how many people understand what is a private key like like you know it's it's a very Niche thing to understand or should they even need to exactly exactly it's even in the name private key private they should be private yeah right but oh yeah yeah know people write their passwords on a sticky note and they put it on their computer right so they the is like difficult for them to write down the full private key you know what I mean we they shouldn't be doing that like we can name them whatever but just having a user custody a private key do that whole Ledger thing is probably not the way we'll get Mass adoption we probably need

something familiar ux like account obstruction right and then things with things like pasis maybe the fishing will go away web2 has been trying to solve fishing forever and ever since they invented browsers we've been trying to solve it and it's been like what 30 years or something now yeah it just seems like it's much worse in web 3 somehow yeah because there is money involved right yeah so yeah no I I can't can't disagree I think humans are always going to be the weakest link of the of the chain Pablo pointed out U but I also strongly agree with Andrew I think it also highlights failures of the security industry I think we should all Thrive and aim to provide tools that are

inherently safe for users to actually interact with and we've done the shittiest job at that I think as an industry over the past I know 10 years that we've been doing this stuff um yeah your your talk Andrew is just I was just watching you and like amen please everyone hear this um yeah but I think humans are always going to be the weakest link um I like a quote from um morelan from optimism who said said you should design your processes so that even if you hired 49% of dpk agents are still you know resilient to to actual attacks um because you know I don't know if you have plans to talk about this particular topic but um it's it's

certainly a a thing right like we we're all being actively targeted by that particular threat agent um and yeah um you will most likely hire one of them you know within the long run you'll fall for that so it's about tweaking your processes so that even if you do hire some of those malicious actors you're not effectively going to get popped to the extent where your users are going to lose their life savings so we need we need a honest majority right bftd at the dev level really I guess I guess um yeah it's a it's a complicated um topic but um I think optimism for once for like they they've set up set of guidelines that are perhaps worth uh sharing and

following um um and one thing to add with that uh is that apart from from saying okay I have a North Korean guy working at my company I don't know it I think that we should always know even with companies that have more than 30 people that any normal Dev can I am convinced of that many people don't any day can turn evil as as Peter was saying in his talk the other day we say no no but we know these guys we screen and we talk to them they you you never know you never people are people and that can happen totally it's the same as people who have an issue with like they're like oh Sim swapping the people who are doing the Sim swapping are terrible like that person earns zero money compared to you and someone was like here's your entire

year salary all you need to do is click a button they're going to do it y like it would be insane for them not to make that choice and I think that that's what you need a budget for like spicy spicy take wait that was I have good good the food was spicy I think the panel should be spicy exactly uh St SP we all know the human factor is always there yeah so we're running out of time but I think we have talked about the past and sort of touch the present we can go on but want to sort of talk about the future as well right so if I can request you guys to bring out sort of your crystal balls and look into at least next year you know Peter does a state of defi every year so how do you guys think web 3 Security will be when

we let's say reconvene for DSS 2025 will we still have the same you know six guys talking about the same things from 20 years ago people software Hardware you know or or is is it a sort of a more optimistic future I mean one year is a long time in the crypto industry right I think the future is optimistic we we'll still be talking about I hope we're still talking about human the human factor is always going to be there we'll still be talking about this but there there's so much interesting Tech that is coming out which is unique to our industry where we can do so many more things that we could we just cannot do in web 2 for example I'm watching every

every time there's a hack I immediately see Mev bot just swarm the attacker you know the attacker drained one volt and then you have these automated Mev Bots basically draining everything and then saying like it's all it's all happening on chain they're saying oops sorry we hacked your project by accident here's your money back I imagine five I don't know how how many years from now probably a lot sooner we're going to have a degree of insertive response automation which is simply not possible in the web two world because everything exposed everyone can see all the transactions mles I'm not sure where you going to stick that automation could be just uh in public or private mle sequencers Bridges whatever there's such an amazing opportunity to build

something that will hack back the attackers even before they have a chance to execute their attack I'm actually seeing those Bots come in and steal the money from the attackers before they even have a chance to do what they need to do and that happens on more than one occasions so that's showing me the future that we can do even better than Web Two World on the user side there are also opportunities look we have wallets we're we did not have any user protections just a year ago we did not have any monitoring just a couple years ago look how far we move forward as the industry so it's hard not to be optimistic when you see transaction simulations coming in we're still lost $460 million or something like that so

those transaction simulations obviously not simulating everything they should be but this is year one so I hope that in five years we get smarter uh our approaches to user Security will also get just as good so we'll be able to catch more stuff so things are dark but they got a lot brighter this year and I think as we go year after year we'll focus on maybe problems we can't even anticipate today yeah I I think as always say that it's a matter of incentives and there are two things that we are doing very good that are changing the incentives for third actors first thing is uh creating uh standards and procedures for

example the Frameworks that is created by my Mata like having a guide on these are the things that you you that you you have to do well mat and a couple more from from seal and and so no yeah it's it's there and if you want to do it it's there and we know it works so that's for thing so we will make it more expensive for a third actor to attack someone and the other thing that I I think it's very important is that now third third doctors are being followed right we have people like Taylor Monahan or Sak xvt or many that are following the money freezing the money making it more difficult for them so I think that that will help a lot those both things will make it far less profitable uh and that

will will help yeah uh one thing I also see is sequencer level commitments so if you are a app like unisoft right you have an invariant you do a lot of invariant testing before you deploy but maybe you haven't thought of like a specific Edge case right so what if you can enforce invariance at the sequencer level right so so in web 2 we have firewalls why can't we have like web 3 firewalls which are in like sensoring but enforce these commitments and we can have decentralized sequencing and this

would give us even better guarantees in production and if we are to like get all the consumers on board I think we need that level of assurance and I think we'll see a lot of that at least on l2s and l3s uh L1 is tough but it can be done uh yeah I I think I think we're running out of time so okay I I think I think it'll be just as bad next year um all right I think I think that there's going to be like a lot more abstraction um in terms of like users account in terms of the change like everyone you know well a lot of the LTS are using the the upstack and I think that as we abstract further like

the lower levels can focus more on security and Hope hopefully it will it will Bridge up but I don't think in one year we will have any difference to what we have today all right we going to have the same panel next year then Co so um I I think we're out of time I don't know if you have time for maybe one quick question but all the panelists are going to be around for the rest of the day hopefully we have a question from Mata oh thanks um so the Microsoft Esa framework was deprecated in December 22 but in left in plays a lot of really good guidance around guard rails for hierarchical administration of systems have you seen similar guard rails put in place for human and non-human identities

between like identity providers and security systems in a tier zero space flowing downwards I'm don't all answer at once I haven't yet yeah no I'm saying no I don't think so no I don't think everyone is very focused on their code Audits and smart contract audits like this stuff is Way Beyond we should we should be thinking about that like we should get there but maybe we should distribute that uh that uh the Microsoft article report everyone all right thank you gentlemen I think that's all the time we have [Applause] so so I'm inviting Lis from albor on

stage to present on the topic of breaking the RAS based blockchains all right Lou stage is yours

okay hello guys after flying over 32 hours being a squeezed in a tiny airplane seat it's a pleasure for me to being able to stand up in front of you and talk about a topic that I really enjoy uh after wine of course that is web three security so let me introduce myself my name is Luis k Gonzalez I work at halor a company specialized in web three security I have been Hing for around 13 years different Technologies web mobile ATM Swift you name it and the last four of them focusing on web three security so right now I'm working with the five

projects cryptography layer one layer two a solution Etc uh of the record I'm a wine lover so if you enjoy this talk you can invite me a glass of wine or a bottle you decide so today we are going to see two things mainly the first one is how a Ras based blockchain works and the second one is some very interesting vulnerabilities my team and me have found over this time okay before starting this intro we like to know how many of you are web three security researchers or are dedicated to security please raise your hand oh I L so and from you how many of you have

audited before a blockchain oh a lot of expert is in the in the room cool so what happens most of the web three security Auditors are used to audit smart contracts most of the time but what happens when appears a blockchain and many words comes to our mind validator full no consensus execution BM so how to hack this kind of Technology uh every time something new comes uh to my home so I remember this Anonymous philosopher on Twitter if I'm building a house I would spend half

of of the time looking at YouTube videos uh and to be honest sadly there are not YouTube videos on how to hack a blockchain maybe soon so first we are going to understand how a blockchain Works through a transaction life cycle you not you know that in security we most of the time use very common names like Alice and Bob right but we are going to change that this is old school let me introduce you a year actually AA is a real person she's here among us if you find her say hello to her she doesn't bite anymore okay so AA uh AA loves money and she's a very

smart investor so she decide to put H to add he's going to uh pull liid liquidity so er what she think is that after some time passes she will be able to claim some reward and the time passes and she tries to claim the reward what happened behind scenes so first we have AA with his client in this case a wallet and the wallet tries to build a transaction let's name it transaction 14 why 14 because before that transaction she execute 13 transactions successfully

so if you we take a closer look to transaction 14 we are going to see a row data we are going to see a public key and a signature obviously the signature is so any nobody can impersonate her if we take a closer look at the row data we are going to see different fields like AAS address we're going to see the payload so basically what she wants to try to carry out we're going to see some gas related data Etc and now the client I mean the wallet send a transaction to a full node here comes a new actor full node so to to understand full no it's the typical name it received from

different blockchains uh in some specific one like Casper for example the name is nonv validator node and so on but what a full node does basically this uh full no needs to have a copy of the blockchain inside it could be a full copy or could be a PR version of the blockchain and number two any one of us can run a full Noe we just need a computer and we can have a copy of the blockchain there then we also have a component called mol so menol basically is a temporary storage could be in memory could be on disk but the idea is that in this mol all the unconfirmed

transactions is wait until they are confirmed in a later phase uh something to say here it's before a transaction is added to the mol there are some basic checks that need to be met for example Syntax for example balance um fee check Etc okay we have so a full note with a mol now you have to know that a full Noe also works as a relayer and it sends information to a validator very interesting here a validator also has its own copy of the blockchain and as the name suggest validators validates and add blocks to

the blockchain important to know that not everyone can be a validator you need to invest a lot of coins you need to stake that coins and if you do things correctly you're going to earn some rewards but if you don't do it your stake coins are going to be a slash obviously validator has its own mol so again full node sends a transaction to the validator validator adds the transaction to its own mol now what happens this architecture is very common in many of the blockchain but some blockchain for example Aptos have a different schema full note

doesn't communicate directly to the validator but send that transaction to a validator full note and this validator full node send a transaction to the validator at the end so it varies a little but at the end the information comes from from Full note to validator so what else here important to understand H one of the validator received the transaction but not of not all of them so using a sharing Meo protocol validator one the one who received a transaction send the transaction and exchange the transaction with other validators so at the end transaction 14 remember transaction 14 is in the mol of

all the validators participating in in this blockchain now time for a new component called consensus so consensus er every blockchain has its own version of consensus for example uptop has uptop bft and so on what happen with consensus in every round the validators need to decide who is going to be the leader in that round so they agree in which one of them is going to be the leader and the leader ER will be selected with different criteria depending on the consensus mechanism that it applies something interesting the leader is going to

change every round again will depend on the consensus mechanism so now let's imagine that the leader is validator X so validator X is going to take the transactions that are in its own men pool and will coordinate with other validators to understand what is the order of the transactions in a block and this point is very important why because at the end order matters it's like attending a conference it's not the same that you in a typical scenario you buy the ticket and then you attend a conference vice versa doesn't work you cannot attend a conference and then after saying goodbye paying the ticket

so it the same for the transactions now H after consensus component each one of the validators remember that at this point each one of the validator have some transactions and they will try to execute those transactions so let's see at validator X the information goes from consensus to execution layer and this layer this layer execution is going to make a transaction ordering but wait Lis didn't you say that consensus also order a transaction why execution is ordering again good question L what happens is that execution layer is going to respect

consensus order however we'll try to apply some optimization for example if two transactions two transaction are going to affect different resources they can for example execute in parallel also important to mention that execution layer is going to be the orchestrator ER who is going to be the slave is going to be the virtual machine layer virtual machine layer is going to actually execute the code I mean run the the buy code from the smart contracts also it's going to apply some rules for example ownership and also and very important this part is very important it will update the blockchain in simulate weight at this point no blockchain has

been updated it's a simulation remember that word simulation obviously depending on on the blockchain you will have different virtual machine layer for example Aptos use move BM Casper use H web web assembly BM and so on now virtual machine will give the results to the execution an execution will append transactions in American Tre we have seen a lot of time or we have heard about different times about merel Tre how it works well each one of the blockchain have its own version of Merle tree but let's see a simple example so imagine that this transaction trans transaction a and

transaction e are the successful transaction of of this block so we are going to have a hash for each one of the transaction we are going to take every pair of of hash we are going to concatenate them and we are going to create new hashes and so on until we we reach the last that is called Merle route this merel route is going to be added to the to the head of the block this is in general a mer a merel tree now after generating the Amel tree for the blood header you you can H wonder why do you need that uh that hash it's a way to find very easy if a transaction was present in a block or not but after that and here very important the

validator is going to generate a new hash called root hash you remember that some moments ago I mentioned a simulation a draft blockchain okay do draft blockchain these execution layer are going to generate a root hash or hashes and it will depend because if we talk for example about Aptos Aptos will generate only one root hash on the other hand for example Casper will generate one root hash for each Shard Shard basically is a a slide of a blockchain sui also will generate root hashes for each resource that is affected so at the end ER once the execution layer generate those root cches send information oh

well and it's going to be using different Merk tree and it's going to send that information to consensus layer and consensus layer are going to talk to with other consensus in other validators to understand if after each validator have execute its own trans transaction they reach to the same root hases root has or root hashes if that's the case consensus send a signal to execution layer and execution updates the blockchain state sometime some moments ago we are talking about a draft a simulation and now we are talking about a real modification of the blockchain state and finally it's going to be a stored permanently in the storage layer that's how it

works now that's everything that happens since and finally you can see that AA now he has 25 coins after claiming her reward and those coins are reduces from the contract very easy that's the happy part now let's see from security perspective what happens AA can be malicious her client can be malicious the full Noe remember anyone of us can run a full Noe can be also be malicious also some validators can be malicious so the Last Frontier to protect the security of a blockchain relies on protecting the security of the different components of a validator so let's see so I'm going to

show you some real war ex vulnerability we have found ER the first one of them oh by the way a cussion of War all this vulnerability have been found in real life projects all of them have already been patched so they don't apply anymore just in case you want to know the first one is related to the project called sui and the compon the component affected is the execution lawyer and how we found it through manual review so uh talking about this you know that every time you send a transaction you have to pay a fee could be a fee for computation could be a fee for storage and so on so what

happened and most of the time in this kind of blockchain consensus validators reach to a consensus about what is going to be the fee for storage and for computation So in theory nobody other than the validators can change those parameters actually if we see the the code we see that we have different kind of transactions and one of them it's called change EPO and is a system transaction so nobody else any external party is supposed to call this transaction and if we see the function ER on how to verify the transaction we are going to see that the verified function calls another one called ad sender blah blah blah function if we

take a closer look to that function we are going to see that here we have a verification if the transaction has already been verified just continue don't do anything not make sense but if the transaction is a Seas transaction also don't do anything just continue so if we take a closer look about is system transaction function that you see here we are going to see that this function verifies this transaction is change EPO yes or no if it's yes don't do anything so apparently we cannot bypass that or we or can we so if we see the def the definition of the transaction we are

going to see that there are two kind of transactions one of them is a single transaction a classical transaction and the other one is a batch trans transaction so basically in a bat transaction we create a vector of single transaction and we can send it so how to attack it very easy we create a single transaction and we put that transaction inside a a vector and we create a batch transaction with only one transaction with change EPO and we apply it and as a result we we are going to successfully execute that transaction transaction to change the EPO very easy we can for example put a zero fee for a storage and zero Fe for computation so free transaction transaction for

everyone the second attack applies to a Ras based rollup and this is uh regarding the gas fees so what happened uh in this case we have a that the affected component is Mull and also we have found this vulnerability through manual review so if we see here in the submit uh transaction this function adds a transaction to a m pool but before adding to a m pool do some verification so for example it verifies if the sequence numbers the number your I mentioned some moments ago transaction 14 remember that's a the sequence number if the sequence numberers is less than the current sequence number s through an

error message in this case the error message is sequence number 12 why does it happen because Meo is the first Frontier we don't want to to use resources from the validator unless we have validate something else in the mol however in this validation we don't see anything about higher uh number sequences so if for example right now the sequence number is 10 what happen if I create a transaction with a sequence number 11 12 100 1,000 at some point makes sense that the sequence number it's higher than the current one but not too much so what is going to happen let's see here we have a T when we has we have

two kind of transaction that are invalid the first one I'm going to try to transfer ER more coins from Alice to someone else because we are trying to transfer more coins than she has the transaction is going to fail and as expected even if a transaction fails it's going to going to cost you some fees right that's the expected behavior in the second scenario we are going to send 1,000 trans transactions using a high sequence number is it going to cost to the attacker any fee or not so in the first scenario you can see that the initial balance is 100,000 after sending only one

transaction with does when Alice doesn't have enough enough balance H some fees will be reduced from the total balance this is test number one however in the test number two you will see that even sending 1,000 transactions our balance is going to keep the same so no fees is expended so why this is bad for a validator because remember after adding to the main pool is going to send at some point to the execution layer and every time a validator use its own resources to compute something or to storage something it costs money so if you're able to send transactions and it doesn't cost you anything attacker can

start spamming with transactions to the validator at the end it could create a denial of service situation uh and the last one inadequate the serialization it against affects sui to the mol component it through it was found through fasing so very quickly what is serd serd is a library for serialization serialization in Ras it's very popular we have more than 800,000 uh people using it okay this is the structor of a trans action here we have the data row data and the signature and look at this this is the happy path client have this ex structor of a

transaction and validator well it sends to the validator and validator has the same structor of the transaction so everything happens correctly I'm going to pass this you see that in this tab we have the validator I'm going to run the validator here and you will see that it continues working this is the validator and in the other tab we have the client we are going to send this transaction and it's it's a published transaction it's like deploying a contract it's going to work without any problem okay Finish correctly generates a certificate and if we go back to the validator everything work as expected continues working so happy path doesn't happen nothing happened second scenario

errors that can be handled so CL now instead of sending an instructor with the expected fields we are going to add one more field we are going to put any name for example other staff with value equals to false we are going to send that through tonic to the validator and remember the validator doesn't expect the other stuff field so what is going to happen let's see when to going to run at again the validator this is a validator and on the other time we have the client so we send it and appears an error message this error message is in the client but if we go back to the validator the validator

continues working as expected okay if we see the the error message we're going to see that we can we try to debac that and we are going to see this I think doesn't look H big enough but this is macros and you know that the bagging macros is an nightmare but we have some tools like cargo expand and at the end after the bugging we are able to see that the the error was raised because the the number of the the transaction was not found so we we have only five different kind of transactions okay it's okay the validator the validator uh found it finally we have the same scenario but instead of putting

true false we put true what is going to happen let's see go faster we are going to generate we're going to make it the validator work again we are going to send it from the client the same the we're going to deploy the same contract and generates an error message but if we see the validator the validator stopped working so we Doos the validator with only one transaction how many validators are in a blockchain 20 100 with 100 transaction we are able to DOS an entire blockchain and nothing works finally uh going to go to the last slide some tips

uh if you can use this mental model of blockchain it's going to be very useful for this kind of blockchain or others the best combination is making manual doing manual review do some fasing and formal verification if it applies consider the security of third party libraries like in this case lerd and please deep a lot in how Ras works I'm talking about currency I'm talking about macros I'm talking about ffi Etc and finally remember that Ras song particular macros to to panic the program so be careful with those and that's it thanks a lot thank you Lou unfortunately we don't have time for

questions but going into what you just mentioned the best combination is the formal verification I'm inviting Dennis from inmax Denisa yeah sorry from inmax uh it's going to tell us how they verify int Max 2 okay thank you

so yeah hello can you hear me uh thanks um hi so I'm Denisa let me oh is this working okay yeah let me present myself uh a bit so I am with nethermind not with inms but we work for uh with with inms um so I'm a conservative researcher at nethermind I'm also an associate professor at the University of Bucharest where I teach uh formal verification and functional programming and that's my corner if you want to check it out um so yeah well okay so today as I said I'm going to speak about inmax 2 and how we what

we did at nethermind with the wonderful team behind um inmax which is actually we formally verified um their um their white paper but so I will touch a bit on the formalization which is um we are wrapping it up but I would like to focus more on trying to sell you Inox and show you you what a cool solution it is and the protocol is extremely beautiful and their white paper is just a beautiful piece of mathematics so I invite you all to to look at it so now if you should I beave closer to it yeah okay so now what is in Max what can it do it's us I think probably if

you try to put it in a box you can think of it as a based um validium rollup but it is a scaling solution for ethereum and let's leave it as is uh which has amazing performance um so they are claiming five bytes on chain and I will try to convince you of this the beauty part from a consensus researcher and I will be without job probably is that it is stateless and permissionless so that we don't need an underlying uh consensus protocol it just has to rely on the consensus protocol on dl1 um I will not touch today much on the Privacy using ZK proof so I will just show the Easy Flow the simplest version of the of the protocol and I

will just show at the end that you can use um uh ZK proofs now it is by nature sensorship resistant and it is among the fewest protocol I've seen that by design it is sensorship resistant and I will try to prove this um for the moment they say with the current block size on ethereum they can they have a limit of uh 7,500 transaction per second but there is a very nice twist here because actually a transaction is just a batch of transactions in which a single send uh sender can send as many uh transactions or tokens to a lot of other participants right so I will try to

convince you of all these points and why they're valid now at our at um nethermind we have a very strong team on formal verification and you have Julian there who is the head of formal verification so for all the technical questions you can go to Julian so we are as I said we are formally verifying their their white paper and we're doing this in Lin 4 so the code actually mimics and mirror the white paper um and here you can have for example when we show that the that the balance is is like we will manage to compute that um is monotonic in the in the first argument um the formalization

will be open source and we are wrapping it up so it will be um available soon and the white paper will contain references to the formalization and for the moment we have around uh 3.3k of uh lines of lean but now let's dive a bit into the protocol and see which are the key insights that lead to this um to this nice scaling solution right so first of all if you look at payments it's true you don't need underlying consensus and it's necessary to make available on dl1 only a commitment to a set of transactions and to the set of senders who have signed the

commitment and the nice part is that they delegate the da um aspect of the protocol on the user side so it will be the respons responsibility of the users to compute the balance of of their accounts to compute the um to keep track of how much money they spent how much money they received now the only part in which you have to check that everything is sound is like when you have to do a withdrawal and you have to compute that from scratch and I will try to show you how you do this okay I think I will just be more

efficient and stay here hope okay so in Max is a as I said it's a permissionless block building um that can be performed in parallel and it matters only the order in which they will be the blocks they will be stored in um on the L1 contract but now that here a block is not in the sense of a traditional blockchain because it doesn't have to refer to the previous block and and so on it's just a storage um uh on the L1 now the blog Builders and this is important to understand is that they don't need to verify the validity of the transaction so it's stateless and you don't need to coordinate the builders they don't need you don't need to pick

your uh a a leader for for for um for building a block so now users they have three actions they can deposit they can transfer and they can withdraw it's a payment solution now for deposits an L1 user will just send funds to an L2 address on the rollup contract on the underlying L1 which is going to be ethereum and that's stored in the contract storage now the transfer is the interesting piece of um um uh of the design and it has two phases so first of all senders they have to pick an aggregator anyone can be an aggregator

there can be several aggregators you can and probably they they're going to use Rel layers in order to make sure that you don't have a malicious aggregator that can postpone uh uh posting your transactions and so on so let's say we pick an aggregator that we trust and the senders will start to send a bunch of transaction uh meaning that that send is just a function everything is a function uh they send um okay they announce to how many participants how many many tokens they want to send they send this information to the aggregator the aggregator creates a merker merker tree sends the proof to to U of inclusion to to the to the user to the sender the

sender checks it classically it signs send it back the aggregator collects a bunch of um valid signatures aggregate them and post this information on on the L1 right now the other part that is missing uh is the fact that so this is just me explaining that you have to have um a bch of a transaction bch now the other part the the phase two of the transfer protocol is that the senders have to send to the each recipient as uh a proof that they actually send the transaction right so each each sender will send the mericle proof that they receive from the

aggregator to the recipient that they have in mind plus with previously proves that he had at that point and that's not that's done directly not via the L1 contract nothing right now the withdrawals are quite simple but there is a Twist to it because in order to withdraw you have to even if I want to withdraw my own funds from the from the from the rollup I have to engage first in the transfer Pro protocol in which I will send the the transaction the the amount I want to to withdraw I will send it to an L1 account and that will be posted on a on a

transfer block and then I can use the proof that I built and give it to the and send it from from from an L1 account using this proof that I I I have send it to the rollup contract and you do the withdraw so um as I said when you transfer the block you the the L1 contract doesn't automatically send the funds to the L1 you have to go through the transfer protocol before and U after that you can do it you can trigger but in order to trigger the withdrawal you can you have to go through the transfer protocol now what we are formally verifying is their security well the safety property saying

that the rollup contract is secure if every rra is um is fulfilled it's succeeds so um and we show that okay you have to have a TR assumption at at the point so breaking the security result is like either you collapse the HH function or you break The Binding of proper uh property of the Au underlying authenticated um dictionary now let's look at the protocol right everyone can be an aggregator you can be your own aggregator it may be a bit more expensive for you but you can do it so you don't need Escape hedges for this protocol by Design you have it so

everyone can be an aggregator therefore you have sensorship resistant modu of the sensor resistant on the underlying L1 now the r contract as I was trying to show in the pictures manages deposits transfers and withdrawals right and for each type of the user action you have three different kind we call them blogs but as I said they they don't have to rely to to address uh the previous block and S so the contract the rollup state is just a list of three kinds of entities which can be deposit blocks transfer blocks and withdrawals now in order to convince you the of the five bytes on chain let's

look at the transfer block which is put on the on the storage contract which this is the biggest part and it actually contains uh the an L1 address of the aggregator so 20 fites this extra data string is used for security reasons such that you don't have um such that um um the aggregator will not postpone on on on posting your blog then you have the a authenticated dictionary the senders who actually sign it and an aggregated signature and if you do the arithmetics at which I'm very bad you would obtain this information but now notice that here you rely on the size of how many many senders you have not on

how many transactions you send and this comes from 96 because you use BSL signatures and now you can add compression I will not go too much into details you can add compression using a relayer contract and if you with the current version of the block size on on L1 you get this number right and if it will increase if they will if you'll have more space on the L1 blocks you can reach this point which is even more than how much Visa transactions you can support at the moment but now what I want to get into is the magic behind the protocol because it says okay but what happens with double spending who is doing the verification a lot of paranoia can come up here right so the magic

trick is a balance function uh which uses a very nice algebraic structure um called latis ordered a billion groups and you have to use this Balan function when user have computer balances or when you have to do when the rollup has to do a withdrawal now if you don't know what latis order groups are is no problem there are some algebraic structure that they are used in fzy Logic for example basically you have a group such that you can do uh you can add your tokens but then you also have a lest order such that you can compare uh tokens between

them but not it doesn't have to be totally ordered so you can have uncomparable uh tokens and you don't care about that right um and there are scenarios in which you can think and then usually you in a group you have positive con and negative con so obviously the balance of accounts they always have to live on the positive con of of the group now the balance function and how why does it work is the fact that you have to split the information between two parties you can have the the list the history of the rollup you can have all the all the blogs that have been added to the rollup contract but without

having a proove from a user side you can't retrieve the state of the of the accounts the balances of the accounts so you need two pieces of information you need a proof that comes from the user and you need the history of the rollup that is on the L1 um contract R right and a state will just compute this B here are just functions which says okay which is the uh how many tokens each account has and you have to compute this value right um and in order to do this you have to split it in two parts first of all you have to if you have a proof but you don't know anything

about it you can have partial information there it can it it can be rubbish you don't know and then you have the list of the history right so first of all you have to extract a list of partial transactions from these two information and after this list of transaction you just apply a state transition function and you compute the balances this is not optimal but there is a version in in which this can be faster but I I will not go into that um here but the trick is because you are in an scenario in which you have partial information the best thing you can do is just compute a lower bound of the balances actually and you reason against

that and you make sure that they don't withdraw um More Than This lower bound so let's look at an example right here b0 it's a deposit block and let's suppose L is deposit El token in the rollup now we have two transfer blocks the yellow one one in which Al sends seven tokens to Bob right so he she will go through this transfer protocol and she will get uh a proof from the aggregator let's call it P1 now let's construct a different uh transfer in which Alice now wants to sends three tokens to Charles so she will take a different proof from the aggregator P2 and Bob will send seven tokens to an L1

account he's preparing to do a withdrawal so that's P3 now if you look at at their wallets which are these proofs that they have to keep up with Alice will will merge the two the two proofs P1 and P2 Charles will do the same while Bob will have the P1 received from Alice and the P3 um it receives from he receives from the aggregator and now if you unfold this one I know this is quite heavy you don't have to go through all of it but what I want to show is that for example if Alice will send her wallet to the to the rollup contract and wants to compute the balances of all

accounts against the history that happened this part here comes from the deposits this part here comes from the second Block in which she sent seven tokens and all of this part here comes from the last block in which she showed that okay I send uh three tokens to see but in that Block B appears as well as a sender but Alis has no information about the proof that that uh Bob received so we compute this as a partial transaction we don't know anything what happen we don't know what Bob did there Alice doesn't know and she shouldn't know right so we put this as bottom it's like undefined we don't know anything and then when you start to compute the

balance function okay it does naturally so this is the account of this is the value of every account and okay for example here we are expecting that okay here after Computing the three transaction Alice has one Bob has seven and Charles has three right and this is the source account which is like the almighty account that is used for the rollup contract but now when you try to reason about the partial transactions of which you don't have enough information and they they don't know what Bob did they will say okay I set the the account of Bob to zero and I will reason about this and as depending on how many blocks and how many

entanglement you have in your blocks you will get this this part right now if you look at the information Bob has at this point and you try to compute the transactions that come up there so remember Bob had P1 and P3 right so Bob's received seven tokens from from Alis but then on the second transfer block Bob has no idea what Ellis did at that point right so here we have two partial transaction on what Ellis could have done right but we Bob knows like I want to send to this L1 account seven tokens I want to do a withdrawal and you reason about this and now the tricky part is like how is the double spending happening right and now that the

withdrawal step ensures that the user cannot double spend the the withdrawal um the fun um to withdraw the same funds twice or to overend pent and this is the very nice part of the mathematical behind the paper and I will Let's Twist a bit the scenario and let's imagine that at the end Bob wants to send nine tokens initially he had just zero let's suppose he wants to withdraw nine tokens right he wants to to to to send to an L1 account nine tokens which obviously he doesn't have at this moment and what happens if we go back and we we do the same process we compute the same balances and at the end the protocol at at this point will just set the the

account of of Bob to zero but actually because they use La disorder groups they are taking the minimum available between the the the the all the time they reason about the lower bound the minimum of the values that they are possible to move so it will take the infimum between what Bob had in his account and how much he wants to send and all that spendings are set like this you the protocol this magic balance function will set everything will not allow you to overspend more than you want and everything is just doing Meats in latices and that's very beautiful and there is a very nice part because here it allows a partial transaction right it

it withdraw just seven tokens because that it it is what he had in in the balance right um the protocol is so so General that you can twist it and playing with the balance function you can obtain whatever design you want for your protocol so I invite you to look at the white paper look at our formalization and see the the beauty of the protocol now obviously what I presented here and I said from the beginning for sure this design the simplified design lacks privacy because transa by the proofs they receive the users can see the accounts of of um of other users and that's not okay but you

can use ZK proofs for this and that's fine and nothing nothing bad will happen and then it's not super efficient because balance proof are large and are expensive to compute on chain and they have a very neat way of solving this problem but I just wanted to show to go to the latis orders and show you how how you can handle this okay and please reach out to us if you have further questions thank you thank you Denisa um I think before we go for a break we have time for a question no questions okay good thank youa thank you

and uh with that we concluding the session and have um I think 15 minute break 14 yeah better if you be there already in 10 minutes so thank you everybody [Applause] [Music] [Music]

n [Music] [Music] n [Music] [Music]

e [Music] [Music] he [Music] [Music]

[Music] [Music]

[Music] n [Music] [Music] [Music]

[Music] [Music] [Music] he

[Music] [Music] [Music]

[Music] [Music] [Music] he [Music] [Music]

[Music] e [Music] [Music] [Music]

n [Music] [Music] n [Music] [Music]

[Music] hello perfect hey how are you pretty good how about you exhausting I'm I'm doing it yeah yeah you're doing it two talks in a row yeah I had a workshop in the morning too three talks in a row and I had to go for

a fanel right after this oh my gosh yeah that's like a speared thing I don't know I'm just doing it I don't even know how I'm doing it I'm impressed and this is just day one tomorrow we are hosting the world computer day yeah I guess you can say something and hopefully people will yeah sounds good yeah that's a good

all right we're starting anos securing cryptoeconomic systems uh all right we'll give it a minute uh so let's people start trickling in and uh yeah let's get into it all right so my name is Andre Joseph I work for uh this protocol uh Igan L I work at igen Labs the creator of IG Ian L the protocol uh I am a security

researcher there uh so what is igen layer igen layer is a protocol built on ethereum that introduced the concept of reaking so we have since gone past just reaking and we what we do currently is shared security so you can provide security and bootstrap networks uh built on this shared security we call it programmable trust and I will dive into what that is one of the core problems Igan lay is

solving is bootstrapping decentralized infrastructure so if you are a new L1 you know that it's really hard for you to get stakers operators and uh get them all to like run your software right so this this problem has been solved by ion layer so before we dive into reaking we should understand what is staking ethereum staking right so a very high level of what ethereum staking is it looks something like this you deposit 32 e into a deposit contract it's spending for a while and you run your validator

it verifies the blocks and then your e becomes active on the beacon chain if you follow all the rules uh you get rewards for it if you break any rules you get slash for it so what is reaking reaking allows stakers who have already staked on the beacon chain to use that same e that is available on the beacon chain to secure additional networks so how can we do that right we want want you to set the withdrawal credential of your validator to a Smart

contract and we call we have the smart contract called igen pod which so as a validator you would set your validators withdrawal credential to the smart contract so we are able to slash for any actions that you may have carried out while you while you were validating any of these additional networks so for example if you are a bridge and you made a commitment to do a certain task but you didn't then when you withdraw from the beacon chain your e would end up on the smart contract and then we can slash for

the that particular amount and then you you will be able to withdraw the rest so that is how reaking works there is it is also Capital efficient right when you bootstrap net new networks you are splitting up Capital uh so if you want to like run your own L1 you have to have a certain amount of Economic Security backing it but when you talk about the concept of shared security uh with ianl you you are sharing all that Economic Security among your abss I will dive into what those are but you can see that it is a much

better system pooled security versus monolithic so these are the four components of an igon layer Marketplace we have the consumers which could be the rollup users uh we have the stakers who deposit funds to us so that's really what economic security is and we have the AVS developers so something like a network you could call that call that an ABS and operators who runs these AVS so something like coinbase Cloud so uh we have experienced good tvl growth and these are some of the

operators with different capabilities that are currently on iglay so if you have like a PR Network you can pick the operators with gpus if you are running a te Network you can pick the operators with those cap capabilities and yeah this category just keeps growing right this is just a screen cap of like what we have right now and we have about 18 of those on Main net 40 on test net and 100 plus in development right now so a very high level overview of what the protocol is before we dive into the exciting bits which is slashing which is on a pre-release on devet right

now and we are very excited to share that architecture with yall so 30,000 ft overview stakers deposit their tokens onto a smart contract stakers delegate that Capital to operators who would run this software the offchain software so just like how rocket tool or Lio would work you delegate your Capital to an operator and the operator runs the validator for you so just like that the Staker delegates the capital to an operator and operator runs the software now there is a slashing

contract so what is a slashing contract right imagine uh you are a bridge and a a validator a bridge validator has to follow certain rules so a a slashing contract enforces those rules so you can think of it as how e how ethereum works right ethereum has certain rules like do not double sign a block that is a that is a rule that is enforced by the ethereum clients if you do you get slashed so just like that you can write smart contracts that is a slashing smart contract which verifies

if you have committed a fault or not if if this Faults Are cryptographically verifiable then it is easy to like write a smart contract and you know you can use like fraud proofs you can use CK proes like you can use many mechanisms like even a Merkel proof to prove something so it's completely up to the AVS how they design it but we obviously want the slashing contract to be really secure so please get all your audits when you write something like that okay so we talk about programmable trust right so what is programmable trust the amount sted we call it

economic trust the geographic diversity we call it the decentralized trust and a lot of ethereum validators also opt into running these abss so they can make make commitments like when I when I get to propose my next block I will include this specific transaction and you can verify that on chain so that is the ethereum trust so what can you do with programmable trust right you can build apps with commitments so what are apps with commitments the OG Bitcoin there is a commitment only 21 million Bitcoins ever

right right and what is a commitment from Unis swap find the fair market Price uh and what is what is it from a the lenders assures the lenders that borrowers were never under collateralized so we have unisoft Bitcoin a poly Market all of that today and these are the technologies that under underpin the services but can we create an Uber competition that makes a commitment like I will never take more than 5% take rate can we do that today with what we have this is really where apps with

commitments can make a difference so we have this analogy we call ourselves the verifiable commitment cloud and you can see why we are doing it so at the Staker operator and developer level you can make certain commitments like we will not censor we will not double sign and the these These are at at that ABS level and then you can have app level commitments depending on the app that you're trying to build right uh so if you are Unis swap I I make an app level commitment to make sure I always have Fair ordering and uh finality and uh so you can see how it

applies for a and poly market right now to have apps with commitments you need a carrot and a stick the carrot is the rewards the stick is slashing so we have rewards on Main net already so I I'll will not be going into that but what we don't have right now is slashing so I'm really really excited to say that we have slashing pre-release on devet today so if you scan the QR code you can find the GitHub repository which is a pre-release things are going to change but if you're are

excited this is pre- audit uh things are going to change but we are excited to put it out there uh play with it and slashing is a two-part release so the first one uh that we have on the devet is where the malicious operators delegated stake is slashed and burned so this the stake is burnt and the V2 The malous Operators delegated stake is slashed and sent to the harmed parties so you can think of it as insurance so we have a term here called Stak Shure

that is the white paper that we put out which talks about the insurance model on Igan Lair so if you're interested just Google gole that and you'll find a nice white paper out there so some key Concepts uh with slashing uh we introduced this term called operator sets so operator sets is a grouping of operators who have been delegated e so when I say eth it could be like any token because we accept any arbitrary ERC 20s now so when when when you see e it could be like anything else so who have been delegated these tokens by the stakers and are assigned certain

tasks by ABS so what are tasks right so imagine you are a pro Network and you want to generate a ZK proof so you can assume that it is a task and this is a task that an ABS have to respond to so operators run these avss and the task is to generate a CK proof for this data that that is provided to you so tasks are dis dispersed to these operator sets and we have this concept called total State the total amount of e delegated to an operator is the total

stake of that operator and an operator sets total stake is the sum of all the operators total Stakes so uh as a Staker I might choose to like delegate to like a solo operator uh like solo Staker right but you may choose to like delegate it to like the operator that is run by coinbase or something so the total stake that is delegated to an operator right that is really what we are talking about here and unique stake this is what is very different from our previous slashing model uh operators allocate a percentage of their e or any token that

an operator set is permitted to slash so a this unit of e can only be slashed by a single operator set at any given time so you can be assured that multiple parties do not have claim to the same e so you have like unique rights to slash a certain amount of e so that is a guarantee that the protocol gives you with this new slashing model and we call that unique state so this is what uh operator sets look like uh you can see uh a Staker has 300 e and they have delegated 100 e each

to like three operators and they all run ABS one and you can see that AVS 1 has multiple operator sets so and operator one only runs only has the operator set one operator two and operator three is opted into both the operator set one and operator set two and you can see that s some tasks are only allocated to operator set one and you can see certain tasks are only allocated to operator set two so B and C task B and C is allocated only to like

operator set two so this is a nice way of abss can have multiple operator sets with varying levels of total stake and unique stake so it is very versatile and you can use it depending on the task at hand so total stake right so this is an operator one with the 100 each Stak uh so this is an ex example operator allocation of unique State the you should an operator can allocate less than 100% of their stake and you can see that the operator allocates like 50% of

their stake to ABS 4 uh on operator set five and abs3 gets 30% of their e which is operator set four and operator set three gets 5% and operator at one gets zero so what that means is that an operator can run multiple avss and out out of all the stake that is delegated to an operator they can choose to split the percent allocated to the operator sets and that stake is uniquely attributable to that operator

set and as you can see here uh this is how unique stake Works uh a unique stake is the amount of stake that is uniquely slash by an operator set so this is a combination of the previous slide and the slide after you can see that avss have have multiple operator sets and there is unique stake allocated to operator sets and you can use a combination of

total stake and unique stake because they have different properties right total stake is just like the sum like you can see that the total stake is a total amount of e delegated to an operator and the unique stake is is the amount of stake that you have unique rights to slash so when when you if you wanted to for your abs you can choose a rule like I need 50% uh consensus on both Total stake and unique stake so these things

have good property so total stake raises the amount that is required to attack your AVS and unique stake also Burns attackers funds because that stake is uniquely attributable and slash by an operator set so by making u a decision to like maybe have a 50% consensus on total stake and unique stake you raise the bar for attack and you increase the damage to the attacker so you can read a lot more about uh the

slashing model uh in this blog post uh so you can just scan the QR code if you are interested so this is our new and improved flashing model I know someone was trying to scan the QR code sorry about that got it okay so this is the new and improved slashing model what is what is good here right the greater control over slashing risk and you have guaranteed slash stake there is no more a need for a common veto committee and you have permissionless onboarding of

abss uh and what are the risk and mitigation right so we have cryptoeconomic attacks avss with not enough security budget imagine your security provider passing for an upgrade what happens to the security of an ABS right so these are interesting things to talk about we have this concept of an allocation delay within the protocol this allows takers to react before for the stake becom slash in a new abs and this protect against malicious operators we also have a deallocation delay which prevents

withdrawing stake immediately after malicious actions so the stake remains slash during this window and uh it it is is one of the most important things the cost of crime should be bigger right so if you do not uh if you do not have cryptoeconomic safety you will get attacked and we will have insurance in the next upgrade so it's fun to think about all the things that can go wrong when you when you have heard of insurance fraud in the real world right so this protocol becomes a lot more complex and interesting once you have insurance and uh we cannot forget about

web 2 security so we have Docs if you are an ABS developer if you are an operator uh please follow these best practices and uh that's pretty much it I have a lot more slides but we are out of time uh I'll be over there so if you have any questions I'll be taking those and uh thank you so much [Applause] all right our next talk is going to be

from iron blocks it's about firewalling decentralized protocols by us off Works hey

everyone I'm Asaf from iron blocks co-founder and CTO and also from V and we are going to talk about about the V ER the ne the first V Network the first decentralized firewall for dabs and for chains H I'm also a former core creator of benor if you remember H since 2017 H faced the first defi hack that happened on 2018 then we could block and saved more than 3500 million dollar uh the biggest act ER at that moment and uh for the last

eight years researcher and web three security architecture and and what the talk is about we are talking we are going to talk about the missing block by our point of view in the web three security the concept of onchain firewall and security networks and the test that we conducted for the security network uh so just a little bit about the evolution of security in web 3 H in the left side we see the vulnerability Zone this is the all the wide area that the exploiters can use to exploit protocols h on in

2015 2016 we didn't have uh a standard for security 2017 the audits becomes a standard and then it the vulnerability Zone becomes narrower and H but we still have a lot of ax happening 2021 the boom of defi we have still a lot of value added to the blockchain but but a lot of hacks also but when we have more tools like fuzzing formal verifications and more automated tools like static analysis H then the vulnerability Zone becomes ner and in

2023 last year something like that we starting to have a monitoring and incident response tooling as a standard for protocols we see a lot of protocols taking these measures to reduce the damage to their uh protocols and as we see it 20 2025 and onwards going to be the onion firewall the decentralized firewalls that actually going to Prov prent hacks from happening to that uh to these protocols and this is the the state the life cycle of a protocol when it's deploying to the blockchain of course we have the build the test deploy and then maintain in each phase we have uh the

primary tools that used to protect that phase the build and the test the the Audits and the formal verification and fuzzing and so on are used primarily for the build in the test phases and we have for front running back running as incident response as monitoring H in the state of after the deployment and the maintenance and uh of course we have a incident immediate incident response and late incident response immediate incident respond means that moving the funds and the liquidity from the exchanges and later incident responds is trying to track the funds and to get back some of them maybe negotiate with

the attackers H and we see that in very specific window which is still open for the attackers to exploit it still has no measures to to prevent that it's after the smart contract is deployed and until the ACT actually H changed the state on chain this is where we still have a window which is not protected h and a little bit about the life cycle of an exploit funding of the address that going to perform the the exploit preparation deploying a smart contract that is going to to help with that execution and of course running

away and hide all of that can happen H in one transaction one Atomic transaction and can and can be from a private mol so the assumption that we take that it's going to surprise us and happen just like that in one moment in one transaction and we want to fill the Gap that we saw previously the Gap this window that the exploiters can take advantage of and and block it from to uh for him the option to change the state so what is on firewall Onan fire wall is uh some middleware we call it a

middleware that's actually implemented inside the smart contract of the protocol it's very simple one it just add modifiers for example to the functions with the hooks before uh pre-execution Hooks and post execution hook and each one of the hooks runs goes to the firewall and runs the policies each policy h define a specific checks that going into one and the protocol can decide what logic he wants H to use with that uh policies if he want wants to use that policy and that policy to work together or that policy or that policy to work together and so on and this way he can perform each kind

of uh logic he wants to for each kind of a a transaction so each call that goes to the firewall will go to that and it can decide which function he wants to enforce that on them and which or not H but we have still limitations in that uh approach also H we have a very limmit limited H context with the call function H we have only the parameters that the call got we have the the general Global H parameters that we have with the transaction but we don't have the TR that we got before that we don't have

General data that we need and so on and so on so we with the data that we have on chain we also have another limitation which is very important it's that if a detection system sits entirely on chain then the attacker can see that and of course try to bypass that to think of a way how to go around that logic and also to Fork the the chain to his computer and run as much as test as he want we can't and adap can't H know about it anything and when he finds a way to slip in then he again will uh H surprise us and surprise the protocol so it's a very

critical uh limitation and H A lot of the det detection logic is not feasible to sit on chain for example AI models or if we need some data that sits uh outside the chain or or if we need another states of a lot of other smart contracts on chain then it will cost a lot to the user and some of that we just can't do on chain and this is where we combine offchain capabilities with onchain ER enforcement so on the offchain components and we see a more decentralized approach that we take that

each security logic connects to other security Logics and sign their own voting about if the transaction is okay or not so the transaction will go first to security validation with all of other operators checking with their own logic if the transaction is okay then it will go on chain or then it will go to the sequencer of the chain if the chain decides to implement it in the chain level or any RPC that can Implement that also this is how the node itself the ofin part actually works the transaction goes into the inspection uh flow ER then

it can use for the assessment external detectors it can connect any detector any logic every operator on the network can their own logic use other Logics to check the transaction he also send the transaction to the other operators that sign their vote and then aggregate all of that together with their his own H signature we using BLS for that and sending the transaction we will see that H in this case he will send the result to the user that send the transaction in the beginning and if it's connected to the sequencer it will just go to the sequencer H this is how it looks on the clan side on the web application side H

the user sends the transaction data getting back a secured payload actually the approval payload which is transaction data connected together and uh then he signed all of that together and send it to the blockchain if he wants Pro to send it for a private mle or for a regular node it can do whatever it likes and uh we can see that H the user when you send the transaction it it works just like estimate gas when a user want to send transaction to the blockchain it say first send to the node the transaction data the node does estimate gas tell him if he has enough balance if H the transaction is not

reverting return the transaction to the user the user sign it and send it to the node so it works exactly the same the user send the transaction data to the security network and then gets the transaction that it needs to sign uh we conducted the test uh that it's kind of a PC but more of a proven before go to production PC we took uh something like 22 months of ethereum ER and in the future it's going to be a lot more months and not just ethereum but also other chains H we took 22 months of ethereum since January uh 2023 to September uh 202 for uh it has

something like 60 or 70 x inside the time frame and the goals that we have for that test is to to see that we actually can do prevention which is the first one most important thing H we need to keep the user experience ER if it's totally disruption the user experience then we didn't do nothing because no one would use it and of course decentralization it must stay decentralized and uh without that atos in our test and in in this system and approach no one will use it so let's start with the what everything means prevention means that

the false negatives and false negative means when a malicious transactions comes to the network we need to detect and decide that this is a malicious transactions if we miss that then the transaction will slip away so the false negatives means that malicious transaction comes and we didn't recognize that so Force negatives needs to be for this test that we conducted h less than 10% we need we don't uh think that at the beginning all the acts will be prevented but most of them will try to prevent user experience achieved by false positive means by false positives and response time false

positives mean that if a legitimate transaction goes to the network the network approve that and let it h continue as usual and not blocking that so false positives needs to be below 1% and response time needs to be below 500 millisecond so the user won't feel any difference when he's trying to send a transaction and decentralization achieved by multiple actors that each one of them will run a different logic and vote by himself and so on and modularity the modularity is very important the protocol should be able to decide which logic he wants to add to the to his firewall he needs to

decide if he wants to he need to be able to Define if the f is working now or not working out or not working now it's very important H just a a small H introduction about what the acts are what the variety of uh hacks that this system needs to detect and protect from so we have of course a protocol Logics like calculations that are going wrong or something in the formula that it's not right and cause someone to take advantage of that PR Oracle attacks infrastructure means like a something that happen in the

front end of the application it calls uh the protocol to be hacked access control and codeb like reentrancy and so on a lot of uh things that the system needs to uh detect um so and this is the result that we got er from our uh test that we conducted false negatives below 5% all of that is going to be public by the way it's not just in our close system you will see all the tests and all the results and everything can be tested by anyone H everywhere H false negatives below 5% false positives way

below 1% it's a 0.004% of false positives which is very low and response time below 200 milliseconds most of the time way below 200 millisecs so uh we actually achieved most of the all of the things that that we wanted to achieve and we will talk about the decentralization also in a moment so we proved that most of the exploits are preventable we we not just notify about the hack after it happened and not just H respon into what happened and reducing the damage we can H prevent the damage in most of the cases H the

minimum Interruption to the user experience very important in most of the cases it would be totally AR to the users you won't even notice that there is a firewall behind that a protocol integration which is also very important is very smooth we have automated tools CIS and everything that help him in a few seconds H to implement the firewall and add it to its protocol and decentralization we have a lot of security operators working with us ER to secure the network H top firms top security firms and top monitoring firms and so on H that work together to create a decentralized network to protect the

protocols and um that's it uh feel free to ask anything and um H jump to the of course to the website and we have a playground over there and you can see all the all the documentation though [Applause] hi I wonder um do you think there's any Prospect for using this to detect transactions from drainers but I didn't hear do you think there's any um potential to use this to detect transactions not from exploits but from drainers yeah so we did that to

demonstrate ER exploits for protocols some of the transaction there are actually H fishing uh campaigns so we also added them to the to the detection system and to the to uh detect them so it's also against drainers and any logic that the security operators can provide to their operators to detect fishing we have chain ptor over here for example uh to detect fishing campaigns and so on are also provided to the security network and the protocols and the users can use that to protect themselves any any more

questions exellent all right thank you for the talk [Applause] all right next up we have a talk from doob about smart contracts for embedding from marel e

okay sure yeah we can wait so I go sit and like okay sure is the mic so should we inform okay for all right this talk doesn't actually

start until 4M um so we're just going to take a short like five minute break and then start this talk at um 1600 [Music] ni

e e e

e e e

e e e e

contracts to embedding by marela from d [Applause] uh hello everyone uh do I sound okay or do I have to speak louder good okay so today I'll be talking about smart contracts to embeddings uh what is that why do that and how we did it in case you're interested so first I want to start with this code from yans marakis stob you may know him as my boss uh it was from uh DSS actually last year and go something like web 3 is a perfect playground for

security tooling it's the only opportunity one ever gets to have all the code open all the state all the past executions permanently recorded and I wanted to include that because that is true and it's a unique feature of the web 3 domain like you have literally everything that's happening open and if you know how to use that effectively all the uh real time data you can do some pretty incredibly incredible security tooling but that is also true for machine learning you have all this information all this data and that's the perfect conditions to do machine learning applications that's uh the main thing uh machine learning uh researchers are

looking for and it's a shame not to use that in this domain so I'll start with a little bit of background so you all don't think I'm speaking Greek but I'll try to keep it high level so uh you don't have to understand uh everything I'm talking about and don't worry there won't be any math uh so the main thing I'll be discussing today is how to do similarity smart contract similarity we won't be talking about any other applications so that's the reason we're talking about embeddings uh the good thing about embeddings is that you can use them for similarity so if you have two code Snippets you and you can create some

good embeddings out of those uh code Snippets and you get the distance uh between those vectors that's a good metric for similarity that of course depends on the quality of your embeddings you may ask why do I care about similarity that's a good question I'm sure you can think of other applications as well but let's say you have a vulnerable contract with a specific code pattern and you want to find similar ones uh you may want to find similar contracts from a speciic specific hacker identify Other M BS and so on uh this is an overview of what we'll talk about today so uh first of all uh I'd like to say that llms uh I know llms

and blockchains bunch of buzzwords but they are useful that's why they're buzzwords so there's a lot of uh embedded knowledge in pre-trained llms so if you can take something out of the stock is that you can do a lot of applications with very little effort and that's a good thing uh the second thing is that you need to do it correctly in order to get results so one uh very important thing is to adjust for example your input to match what a model may have been trained on otherwise you're not going to get uh much out of it and finally okay you get all those embeddings or whatever uh and you may want to find for example which have the

smallest distance don't do it uh Brute Force don't do all of the uh calculations that's going to take forever use something like an approximate uh closest neighbors algorithm and the good news is that you can probably get this for free so tldr embeddings high level is just a way to represent data uh as a vector of numbers as a list of numbers that's code in our case but it can be pictures can be whatever the simplest form of embeddings you may all have heard of it is one hot one hot vectors so uh let's say we have 15 bits uh whenever one bit is one that's a

different uh entity that's a different thing but as you can tell that's not a great embedding good embeddings have to be semantically meaningful what that means is for example uh if we use the uh example of word embeddings uh That's a classic uh example in word to V and glove where if you get the uh Vector for king and you add the vector for woman you get the vector for Queen uh that means that embeddings have the this uh feature that they embed relationships within those numbers they may not always be linear like this but uh that's the idea finally uh it means that similar entities will be closer in the vector

space so for example if you take the distance between king and queen uh that will be smaller than the distance between King and rat for example next uh you should know that not all embeddings uh sorry good embeddings are learned that's a different uh slide so uh what that means is that you need to do training to get good embeddings there's no magic algorithm that's going to give that to you uh you need the statistical properties of a big Corpus uh as it it's a special code in the NLP word you shall know a word by the company it keeps that means that words that appear in similar contexts will

have similar meaning so however uh not all uh embeddings are created equal so we were speaking so far about word embeddings so if you were to embed those two words words those two those words in those two sentences uh I went to the bank to deposit money and I went to the river bank you will get uh the same embedding for the word bank but it is clear that in those two sentences it has a very different uh meaning so what we want are contextualized embeddings so that's where Transformers

and llms that you've all heard of uh come into play high level Transformers have the attention mechanism that's probably what you've heard about them and the high level idea is that it gives you access to all of the input it gives you context so if you get the embedding of a word from a Transformer it will have the meaning of the sentence kind of embedded into it for example uh in BT that's one of the uh initial uh Transformer models if you uh do the classic training task of mask language which is uh you mask part

of the input or a word of the input and you tell the model to guess what that word is uh the embeddings that the Transformer creates internally for each word uh will be forced to learn the contextual information of the sentence so that's how you get uh contextualized embeddings you may be wondering why I'm talking about word embeddings well if we treat uh code as a set of words that uh that's what we want to do so we have a set of embeddings how do we uh embed a whole sentence for example one way to do that uh it was uh with the

bird model for example uh what they did was add an extra token in the beginning of a sentence uh which uh then later the embedding of the model will get trained on a sentiment analysis task so if is the sentence positive or negative what that achieves is that it teaches kind of the model to encode in this embedding the meaning of the whole sentence so in a way that's how we get our first sentence embedding that's not the best way to do that that's just an uh initial approach a better way to do that is with cm is

networks cm is networks is just you take the same model twice you embed two sentences that you know are similar you take the the embedding of those sentences and then you calculate the distance of those two and use the distance uh in the loss function what that means is that the model learns how to minimize the distance so similar sentences will have uh more similar embeddings and no we didn't chose CMS networks because of Thailand um so what are some of the challenges in creating smart contract um creating embeddings out of smart

contracts well first of all there are too many of them so you have to keep that in mind just in ethereum there are tens of thousands of contracts deployed every day uh to with in total to the millions of thousands of contracts so your search has to be quick and your embedding creation also has to be quick another problem is that uh we don't have Source maybe that's not entirely accurate we have source for about 60% of contracts but still a 40% is left without source so doing similarity on the source code is not very reliable and most interesting

applications like malicious contracts or maybe MV Bots whatever uh don't really have an incentive to publicize their source so there's even more uh reason to do so some other challenges uh our onchain data which are bite code in assembl code uh is too low level so it won't have very um uh in intricate information about the contract we want to embed we have to take into account that if we're using a LMS they have a specific uh a specified size so you can

um use very big uh inputs anyway and finally uh even though we do have a lot of data available we don't have a lot of labeled data that takes a lot of manual effort so we either have to use out of the box approaches from other domains which means uh pre- trained models or we have to creatively use what data we do have okay so then what are some of the things that we can do well first of all the compiled uh code is a good uh Middle Ground approach it only depends on uh onchain data on bite code it retrieves high level information like

uh array operations uh function calls uh Loops IFL statements stuff like that uh and it looks like other objectoriented languages so you may take advantage of models that are already trained on code another thing another uh revelation we had is that a public function of a smart contract can be considered as a sentence of the contract so so it encapsulates a part of the functionality of a smart contract so you can use that as your building block to do similarity and if you combine that with a three

sing algorithm uh which just means uh include underneath all of the private F private function calls uh the function definitions of the private function calls of the public function you have all of the information uh that's uh encoded in that function effort free approach is to use that as your input for a sentence encoder that's going to give you a pretty good encode uh embedding because it has been trained to produce that it may not be the best like if you do a more uh fine-tuned approach if you have for example a data set of pairs or whatever that's going to be much

better but uh for example in this case because because the code is transformed to something that uh the model has seen something similar before so high level code which most llms have been trained on some extent during their initial training are you going to be able to benefit from transfer learning which is when a model is able to perform well on a task that it hasn't been uh trained on but is uh similar another idea uh what if we use some of the data that we do have available in the blockchain so one thing that we do know is that

public functions are associated with a function selector what that is is just the H of the function signature that function selector is then used in a function selector piece of code in the bite code which uses that has to call the appropriate public function in that way you can build the data set of public function uh selectors and names and then reverse engineer the names for contracts that don't even have verified source that allows us allowed us at least to build a label data set of decompiled code and name of uh this function in this decompiled

code as you can imagine uh having the name of a function tells you a lot about a function if I tell you these two functions are uh have the same name you're going to guess they do similar things so we thought well what if you train an llm to uh predict uh what the name of a public function is going to be based on the decomil code which already has a lot of information about it and then use the internal state of that LM as an embedding turns out that is a pretty good uh sentence encoding sentence as in public function and the the reason I mentioned earlier the CLS pooling is

because it's kind of the similar uh intuition it's asking the model to distill all this information to a descriptive function name finally uh how you're going to actually run that so you have all your code you create all the embeddings and you want to run a query how do you do that well don't use uh classic indexing uh in the indexing algorithms for classic databases are not meant to be used on uh vectors use a vector store the reason Vector stores are better is because embeddings can be seen as uh nodes in a

space and the distance between those nodes uh is are the edges of those nodes anyway so you kind of create a graph that enables uh Vector stores to use graph type of searches to do for example approximate approximate nearest neighbor and find uh closest embeddings much quicker than just doing all the distances with all the embeddings in your data set also the good news is that whatever data set you US datab base you're using right now already support some kind of um Vector extension all the major ones do anyway and if you're building something from the

ground up you can maybe consider using a vector focused uh database which um some these are some of the examples but there are many more so uh we did this how did it work we deployed it uh September this year uh we support most major uh chains that have VM bite code and you can querry any public function and you can get results in on average Less Than 3 seconds that's like the worst case I've uh seen funny story uh this past fall on our company Retreat uh a few like weeks or something

after we deployed our feature we had the chance to use it in real in real life uh when we discovered vulnerability uh fun story we were doing a competition between amongst our company uh for whoever finds a bug will win a PS5 uh we ended up founding uh finding the Bedrock vulnerability uh which as you might have heard was an infinite mint vulnerability and that meant that 5 uh 75 millions in dollars uh were at stake the code that had this vulnerability was deployed on eight different chains and at least in one of

those chains the code wasn't even verified uh that enabled us to try our Tool uh in real time to find all the deployed code and ensure there weren't any other uh Forks or pieces of code that use similar logic and had a similar vulnerability in the wild if you want to try it uh it is live now on our app on our site app. d.com if you go on any contract on any public function we have a little button that says find similar and if you click that you will get something like this that shows you the similar functions and the addresses and let us know if you have

any feedback ah sorry there's the last one almost forgot about that so uh what we talked about today there's a lot of information and coded in pret llms so take advantage of that it's free uh representation matters you have to think about what your input to your model looks like and finally don't use uh Brute Force to do your comparisons there are much uh better things that are for free to use and that is all I think I'm a bit early all right any questions

so uh thanks for your talk uh can you use this to let's say you find a bug you define it in some way and then you can try to find a similar type of bug in different chains is this what you're doing uh so that's a good question and that's actually a feature that I would like us to implement at some point point it wouldn't be hard it would just be you would have to submit that code and it would be the same as doing a query as we have it right now but at this point no we don't have that you just you can find similar code with already deployed code uh our site is also a block Explorer so you can go to any uh deployed contract so you can only use it on deployed contracts at this point right right but

like you you if I find a piece of code and let's say it has a bug and I want to find similar code I can do that uh yeah you can use the find similar uh we support it on public functions and if there is a public function that has a similar coding pattern that's kind of a clone I guess of this uh function there's a good chance you will find it and a queries yeah I've actually used it a queries uh like the blockchains you support now and maybe you're going to add support or which blockchains does it query uh so I at this point I think we sub I don't remember all of the evm based uh chains we support we can you can go on

our site and see and like check uh we definitely have ethereum binance and optimism uh right now the feature doesn't work cross chain but that's a feature that's coming soon okay thank you uh you said the database is available is it open source can we download it uh it's not ours uh most databases have extensions that are free yeah and uh if you have an open source database the extension is also open source I don't know ask hey um thank you for the talk um I

was wondering if you tried embedding not only the code snippet but also maybe an llm based like LM generated summary of the code because I don't know how how llms work with code instead of like natural language um yeah uh that could be a good idea then there's a question of if an LM could create a good U summary of the code maybe it can create a good embedding for the code so it depends on the kind of code you will use if it's something that model has been trained on maybe it will do well uh but they seem kind of like similar tasks what you're

explaining so if you can do one thing well I don't see why it wouldn't be able to do the other one as well and yeah last one um you said you fine-tuned a model uh is that like compared to using open Ai and Bing model is there a like a super good advantage or like is it like slightly better well uh we don't use uh open I mean we have used uh open AI uh TPT uh that's on projects I think it creates a summary but we didn't use it for this it's not super cost effective uh and

also yeah you can do a lot more things with your own model you can create more lightweight models uh you can do all sorts of things so it's I'd say preferable to using that but of course it has its applications as well all right I think that's all for questions then um I think there's a short break now and the the talks are going to start again at 4:40 thank you

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e e

e e welcome everyone to this uh almost I

think it's a final session uh it's nice that you're all still here um this is going to be a round of short lightning talks 10 minutes each um and I'm gonna be one of the speakers uh first for you uh there's Shahar uh talking about uh officiation in drainers or a specific trainer I guess good luck all right thanks yeah we're going to be talking about the appication of the agent drainer we got 20 slides to go over in 10 minutes so good luck to us all I'm Shahar uh I've been doing

security for the past 15 years uh past three years at fireblocks where I lead the product security team uh we protect 200 million wallets for our 2,000 customers worldwide um and before jumping I also want to give a shout out to Matan from my team whose work has been the backbone of a lot of this presentation so hopefully you've heard about the engine Riner but if you haven't it's one of the most notorious drainer kits out there uh it's been responsible for major losses over $20 million for hundreds of

thousands of uh victims and it also recently merged with its uh rival so it's just became stronger and more complex so when you look at that it's pretty obvious it's a it's an Ever evolving persistent threat in this industry so we should study it but when you you want to study the code you see that obfuscation is holding your back and this what made us jump into this research and understand how it's working and how we can remove it so what's obfuscation obfuscation essentially is turning this piece of

code into something that's really complex to understand uh to read and to get to the bottom line of why would you do that from a malware developer perspective from an attacker's perspective you want to slow down you want to get uh uh resilience for your Mal so you want to make reverse engineering hard you want to slow down researchers you want to limit detection capabilities you want to drain wallets at scale you want to make profit side note there are some some legitimate use cases for alisation like protecting your IP rights it's not all bad but this case it's really bad and

you want to tackle it so y obis skate what the exact opposite we want to make reverse engineering and debugging really easy we want to boost researchers want to make uh uh our detections better we want to protect wallet at scale and we want to present at DSS so in terms of goals for our research we have three goals here we want to be able to understand the code so we want to be achieving Clarity removing all all the appliations and and and uh have the code easy to read but that's not enough we want to be able to also execute and debug the code because we do not believe in just static

analysis and finally we want to leverage open source wherever possible because we don't have to recreate and reinvent the wheel so I'll start with the shout outs of projects that have been important for our work um couple first unminify and web crack are doing an amazing job with removing some of the alation we had to build on top of that and I'll expend on this in a in a second so un Minify removes the minification of JavaScript code and web crack does some of the decationized framework uh to uh work with JavaScript code you can think about

this as a parser for JavaScript uh so we don't have to write the entire thing ourself so jumping in looking at the angel uh JavaScript kit we see like any malware loader at the first stage is just loading a payload um it was minified code meaning had almost one and a half million characters in one line uh so we had to run it through on minifi and when we run it through on minifi we got this um in the yellow box you can see the encoded payload this is a essentially compressed with XZ and then encoded in Bas 64 when it sended this is what it does so we did a reverse we uh uh

decoded and then decompressed and we got this so this is as you can see it's a lot of code and you can maybe uh spot some uh computation going on which is a good sign for alisation and unpacking going on and you be correct after unpacking we see a code that's uh off fiscated with opor doio which is a very common JavaScript ofation uh um website it's protecting the core logic so we want to go uh uh and break it we tried a couple projects uh we saw that web crack did a way better job in terms

of keeping the code debuggable so we can actually uh use it which is one of our uh goals here so we chose it and we got into this this is a code snippet out of 28,000 codes line of codes uh that we have and webar helped but we can still see some funny struct and some indirect relations between different parts of the code specifically we're going to identify three players here which are going to beat one by one call them E D and W okay you can see on the on the Green box where uh e is being defined uh is being called and defined on top and uh with d also some kind of indirect

call to another function so first thing we did which allowed us to remove uh and simplify remove E from the equation was to use Babel transform the code into a an abstract uh syntax Tre which essentially again Pars in JavaScript looking at the code in a logical way you can think about about this a sort of a smart find and replace so whenever we see a a menion we can just replace it with the direct uh code or the direct string and have the code way easier to understand now this is still the end goal would be a clear easy to understand JavaScript code and this is not it yet right we can

still see some some funny things going on some numbers and the next Target is is D okay you can easily see that strings are missing right like within JavaScript code uh references to struct references to uh Json objects are doing are deal by strings and that's missing here so we realized this is a string uh um mapping essentially and we try to reverse engine now that was hard so instead we did some pre-processing and then realize it may be easier to just run it so we created a standalone

version of that function and run it through on a Sandbox environment as it should do with all malicious code uh we run it through the entire code and used the actual the unpacking function to remove that complexity you can see this is now way better way easier to understand but we still haven't gotten to our uh bottom line which is to get code that is as clear as if you wrote it yourself but we are getting there and so the final route was to get both readability perfect readability and

executability uh with the runaround of as simplification after the the string fetching um which was like on Dynamic execution and finally in order to debug it we had another round final round of webcraft which removed all the anti-debugging uh features they were present on the engine Runner which allows us to get to discod which meaning after few weeks of work or 9 Minutes of uh presenting we got to realize this is actually just closes the popup which is amazing um which kind of shows you the benefits of oppos getting the code from an attacker's perspective

right it's we had to work really hard to get to a function that really doesn't do anything important but once we solved that we solved everything and now we can inspect the code we can debug it while it's being run and while it's being uh trying to drain us so because this is a research presentation summary and future work so we achieved uh executability and readability of the code like uh like like we wanted to and if you want to dive in I recommend first you'd look at angel X which is the latest version of the agent drainer um a good starting point is block is research which is up on their blog uh and also the onchain command and control mechanism that angel

uses which leverages uh smart contract storage in a cool way um really recommended to dive in and that's it thank you uh for coming and listening you can find us on uh Twitter and in person all right uh thanks for your talk unfortunately we don't have time for questions I'm sure he'll be around uh next up we have himim and he'll be talking about a similar topic that we had a panel discussion on earlier today uh namely the web two to web 3 trans position what the difference is uh and

yeah good luck all right thank you uh I everyone everyone I Kim Kiker I a chief information security officer uh at starwell been working there for the past two years also in web free for the past two years I'm here to talk about challenges I had as a security officer and also as a security

professional uh in web 2 coming to web three and the biggest challenge I hope will be to make this in 10 minutes or less so good luck um about myself I've been working two decades in cyber security started as a researcher a malware analyst and then later uh exploitation mobile uh web uh later on manager of security engineering and research team I like to keep hands on and uh solve complex problems uh that's one of the reasons I wanted to choose blockchain and web free and I'm very excited that I have done it um but uh when I came to stare and web free

nothing prepared me for uh web free uh security Mayhem so many attack vectors interesting uh assets to to protect and from Web Two from web three and I'll share a little bit about the the threet actors the Frets and what I think can be good for Security leaders in protecting web free and defi so let's talk a little bit about Web Two uh threat actors uh the first we have the skip kitties they open command line you know and they think there hackers so these are not really threat for us this is one example but we have also back bounty hunters sometimes they

can be also black hats white hats uh usually uh um issues that related uh are reported and and being paid for sometimes they're deciding to do also be Mal uh next we can have an example of activist group like the anonymous team usually doing dasas uh in web to as far as I have seen and essentially the I wanted to mention the inside of thre uh in web two uh which can be devastating up to an extent um when it comes to web free attacks or or threat actors uh the malicious Insider uh the same one from

before as much more incentive because this is multi-million dollars and it can do a lot of damage right compromise private keys for example when you have access to the company sometimes there even worse project that can do rock pools like uh it can be related to a malicious Insider or Executives or the entire project is malicious in order to pump and trick users essentially stealing money so this is another uh big problem we have in the industry uh we have also the AP groups organized crime that are not behind nation state that also decides to deal with crypto which we need to deal with and the lastly the most uh threatening thre is

the uh nation state ERS like dprk Lazarus Group which can be very very uh and have done a lot of damage so my point is that web free threats are much more targeted than Focus uh uh they are behind social engineering Mastermind sometimes they can for example have lateral movement they hack a Twitter account or a telegram account and then they reach out to people that they know trying to install or download something some recently even been hired as it or Dev uh which is devastating because they can cause a lot of damage inside they are highly skilled they are usually patients and most of them know

how to mix and demix very quickly TUS allowing them to do money Laing uh we talked a little bit about web 2X and this is also a problem in web fre because Web Two hacks are easy leverage into a key compromise for example if I manage to have a Trojan or on a computer we have seen recently a lot of attacks against multisig where troan ores can be used to steal or or or trick users into signning with cold wallet uh important uh on a fake data we also have application security that we need to be taken care of cloud security misconfiguration and social media so

yeah we don't have a lot of time but there are so many threats to deal with in web 3 also coming from Web Two uh as a seeis so it is not the most relaxing job in the world because if the attackers have built correctly their uh way of exploitation the execution is usually Within on chain uh running attack is one examples of very strong social engineering where they stole more than $600 million uh Wormhole wasir X more recently uh so very very big damage in minutes so how do you prepare for that uh on web to my previous companies you call an IR from they come they take a m

dump but we do not have the time for that right it's minutes we don't have hours we don't have days we have to react quickly and above all after all we also have govern government and legal risk which I know is a bit controversial in defi but as a ciso you also have to swim between the lanes and also keep due diligence and compliance wherever you can in order to support uh the users in various countries so with all those threats and risk how what do we do now uh what I did in every company that I come to do a security I usually do a risk assessment sometimes I use framework like nist like Mitra so I had to adjust the threet actor and how it's

bigger than usual in web three than in web two and their capabilities uh there are few minutes to effective immediate response it's now a decentralized risk assessment versus centralized it's not one entity and it is not your typical ciso SO2 or ISO 271 checklist it's not like you are going to install a EDI do some uh encryption and you are safe maybe you are safe from so ISO 2701 but you are not really safe from uh web free hackers so this actually presented an opportunity for me as a sister to be practical to focus on the important areas rather than just the

checklist and I tried also to navigate between constant changes uh in various countries and even do diligence by major vendors from different countries um sorry yeah so addressing web free risks the first thing that you have to do in order to be prepared is to have an incident response plan ready with pre-b play boook play a war game with your security team imagine the worst case scenarios that can happens and have a prepared list afterwards build a realtime monitoring for those exact

scenarios how do you track them work with there are many good web free security monitory companies that you can work with and build those pre-build playbooks in order to detect them in real time and you also have to have a emergency response for those exact pre-build playbooks those responses should also be decentralized by some kind of Security Council like if there is a risk of uh several uh companies that you work with report that there is a a risk of um Lo lost money or still asset then you can maybe freeze the network maybe pause but you have to do that in a secure way without false positive because otherwise this false

positive can also become an attack Vector so this is challenging and also need to be decentralized uh proactively navigate the rapid change in regulations as well other things you can do uh War Games as talked been to In in this conference already SE is doing war games and other organization and companies as well do it internally do it externally train your people with the IR plan that you have pre-built secure development fuzing formal verification when you can testing coverage uh internal Audits and once you are ready do the external audit and audit competition which is also very useful at the end do an effective bu Bounty program make sure that you Scope

the things that you care about so you don't get not you can waste a lot of time if your bug Bounty program is not is not scoped um community and ecosystem involvement is highly important for stet we have a starnet security community and also it's important not just to have the community report to you issues and have a way to uh wake you up it's also important to protect them uh work with uh protect user from fishing for example we work with wallets like our wallets uh braavos and Argent uh they we we work with um blockade to protect users within the web free from fishing so invest in

protecting your users uh and at the end if you are hacked make sure that you also have follow the money solution so that you can return some of the funds uh that's also important so I'm run out of time summary there is unique challenges in securing web free and coming from web three from Web Two to web three I learned a lot I hope that other people will learn from that as well thank you okay thank you so the next person to talk is me uh so little introduction there um the slides there

okay I'll start by introducing myself for a bit uh my name is Yan and um uh I've worked mostly in uh security Automation and tooling uh but I'm also a um an active Bounty Hunter and um sorry to use your laptop oh okay sorry I need to set up my laptop e e

okay so um I thought it would be fun to uh talk about some Buck Bounty horror stories because usually what you see on Twitter is g to be like your stories about hey I made a million bucks holy this Bucky thing is really really cool uh but something uh you hear less about is all the cases where it goes wrong although a lot of examples that I have today are actually uh probably going to be somewhat familiar uh so there's going to be some spooky stories and it doesn't work okay so this is the first one it's a nice old one this is not the way you do a bug report

um so this is the par wallet uh someone uh was able to take over ownership and delete the contract self-destructed uh and uh they actually did so on mained and then reported the bug through a GitHub issue uh I forget how many millions were locked because of this uh but yeah this kind of it's kind of scary if you wake up see a getup issue hey I accidentally break your system um for the rest of the stories I'm going to try to not call anybody out for multiple reasons in some cases like it's hard to know the full story uh and also like some of the ones are probably in

the room so you know uh not to make it too spicy um it everything should kind of be prefixed with this back B bug bounties are great but you know um things happen uh let's go to the next one uh oh okay so this one happened not too long ago it's kind of buggy let me just move here this one happened not too long ago uh a kind of large exchange uh Kraken you might know it um there is a security company that found a bug and to test the bug they stole I think more

than three million and reported it only uh a couple days days weeks after I'm not sure about the details there but uh yeah that's got to be scary too because as a as a exchange operator suddenly a bunch of money is gone and you don't know if it's like real hackers or not uh so this is kind of like a a lesson Lear for a white hats maybe don't just steal money and maybe you should report the bug first another horror story this is around a year ago uh protocol uh was hacked 55 million was gone uh it's

actually in November if anybody can guess which one it was no okay it was skyers Swap and this is one of the most hilarious like whad negotiations in my opinion uh because the guy had well like first was like okay I'm tired my demands will come tomorrow uh so I hope he slept well and then the day after they got these demands and he basically want the whole company um I don't believe they complied but yeah so I'm not sure if there's a Lessons Learned here but yeah I thought it was a fun horror story because that's kind of crazy like you

get hacked the hacker responds there sometimes these negotiations actually work but then yeah you get this um demand um this is a actually a super interesting story I think um it's a story I think happened one and a half years ago uh uh someone found a bug in uh that was out of scope for a major protocol that's operated by a DA uh and their Buck Bounty I believe was managed by uh like this this separate company they because it was out of scope they weren't able to uh like spend too much money on this

bounty so they agreed with the white hat that the white hat would suggest like an extra payout on the Dows Forum uh when it was proposed to pay out the base Bounty now this didn't go too well um and it's kind of a signal that buck Bounties in Dows are kind of difficult to do so bug Bounty discussions can be hard regardless of whether it's in a or not but if a doubt gets involved it's and it ends up even harder so in this case the Dow participants didn't have any information about the bug at all and the conversation kind of went into a

direction where there was name calling like the the the Bounty Hunter was called greedy uh and eventually some people even suggested like lowering the Bounty that was already agreed to um and I feel like the main like takeaway here is that is two things like make sure everything is set up well before someone reports a bounty so that you don't need to fall back on this kind of system where someone has to go to your forums where it's super difficult to agree on anything and the second thing is communicating with white hands is a PR problem like you need to be aware of your image around this because yeah

derailing discussions on the public forum it doesn't look good um okay so this one is even uh a little bit older um there was this white head found a bug reported it but the protocol didn't really respond within uh a day I believe so they were like ah I really got to get this money save and they tried a white head heck now we all know that that this can go really well but in this case it went wrong because they were frr uh and uh some money was lost uh and I

think here it's really important if you want to be doing or execute a white attack it's really important to be aligned with the team somehow so either you've communicated with them or in the best case scenario it's them executing the white attack not you you're just helping uh and you kind of only do this in the last case scenario uh or um for example the situations covered by the what at Safe Harbor agreement okay this is another fun one that came up this year this bounty platform um that uh was blockchain enabled and uh let me see

uh they put the the titles of vulnerability reports and their severity on chain um which is not great because that kind of reveals a lot of information about vulnerabilities in systems that have a lot of impact um as learned don't do this um Beyond these I wanted to point out that there's a lot of untold stories uh for both sides of the equations for bounty hunters and projects so what H bounty hunters encounter a lot of the time is unnecessarily unnecessary delays because protocols might not care too much about

paying out when they already fixed the bug you also have the the fix and ghost happens a lot fortunately platforms like immuni can take action like uh kicking people off a platform uh but yeah it doesn't always work and my my favorite one this happened to me once is um the security budget was tight so they didn't have money to pay out the book Bounty uh great reason uh this is an example just I picked it from Twitter from a couple like last week uh where someone uh like reported B and then like a week after you go in hey guys have you had a time to look at this and then okay we had

time to look at it and then it just takes long um a lot of the time conversely there's also lots of problems for protocols that you're probably not aware of uh there's like this fire hose of people that just want to make money uh by doing little work so there's this thing called back bounties it's kind of insane people just report seemingly random things hey you're not following the best practice and then saying can I please as the money um and as a protocol like you have to deal with this and it's such a Time sync and of course like the llm

revolution uh people uh and the problem here is llms can make really good sounding reports that are actually bogus in the end so it's like there's a lot of time drain from the project perspective and unfortunately in the communications between legitimate bounty hunters and projects it can sometimes lead to some friction because the pro like protocols can be so used to grifters that they kind of go into this the conversation in a semi adversarial manner or expecting the the white hat to be somewhat adversarial um and this is kind of unfortunate of course like uh people get banned if they do back

bounties or if they use uh llms but it's also something to be aware of like it's good to know from both sides um that everybody's kind of used to people uh doing things and and making the process that much harder uh that we can all like maybe uh be nice to each other uh anyways I I can of like bu bound this still even though all these things happen uh so I wanted to end with the statement that bug mounties are great um that's it for me uh is the next version okay uh let me quickly see oh thank

you okay so next up is Valyrian from quen uh and he's going to talk about transient storage one to hi I'm Valerian Kal I work at

cramp and today I will answer this question is trans storage a transient Trend this is the plan for today uh so let's start the story of transion storage or t storage started six years ago with EIP 1153 it was then introduced to the evm with the Denon upgrade earlier this year and as of today you can use it in Viper and solidity using op codes or the dedicated keyword tangent it's cheaper than persistent

storage each slot is identified by a bite 32 identifier and you can keep in mind that it has two Scopes first scope it's at the level of the contract because only the contract can access its own transion storage and you need a dedicated view function to make it accessible to other contract second scope is the level of the transaction because trans storage only exists until the end of the transaction and at the end of the transaction it is set back to zero about the use cases the EIP initially uh suggested six use cases including transient reur guards tokens

with persistent balances but transient approvals and tokens where you can pay a fee to unlock the token transfers until the end of the transactions but what about the usage in practice so you can search for this on GitHub and browse the results you will see that most of the results are clients or Dev tools trying to support the Denon upgrade and you will also see that actors such as Unis swap V4 or Balan Serv V3 are using it for Flash accounting and I listed other use cases below as an adoption summary most of the

projects start using it with transient reentrance guards then there is a common pattern for more complex use cases where you use uh transion cont text trans context it's a set of transient storage variables that are used together in a consistent way most of the code bases also use um dedicated libraries to manage their transient slots uh and here is O transion slot do library as an example and the adoption has been postponed in some cases for instance in one case um the code base the rest of the code base was not ready

for the solidity compiler version 0824 let's move on to the security considerations first when you want to check if in a function the CI pattern is enforced consider the persistent storage but also the trans storage the second one is when you target an evm Network make sure that the trans storage is fully and correctly implemented and for this the tool evm D diff is very useful then Beware of the concurrency between different slots especially when you mix uh inheritance and delegate calls because you can have

some slot collisions or storage slot shifts the last consideration is for the concurrency on the same slot and here you can think about scenarios involving account abstraction multi Sig multics and basically it's if the same transon slot can be used by multiple use cases or for multiple actors then there is a risk of unexpected Behavior or of denial of service let's move on to the design patterns the first one is transient readon Rance guards so sometimes by Design you cannot avoid to expose some

areas of your of your code to read only rances and this pattern consists in temporar looking um related view functions before and after an arraya so in this example this contract has a storage variable a a view function get a and a function that is exposed to read only entrance C I use the arrow to delimitate um the start and the end of this sensitive area uh for this um pattern you give an ID to the view function here for2 you use a modifier and um in the at the start of the exposed reeny area you will lock the

view function with a dedicated function and you will unlock it at the end of the area the second one I think is the most important is to safely manage the life cycle of your transient context so the rule number one is use single purpose slots in other words make sure that the same SL is not used for separate um use cases and the second one is to avoid parallel executions for concurrent actors on the same slots and here is a suggestion with a SoDo code if you have a transion context TC and Ador Bob uh first make sure that the cor context is not already locked or

in use then you lock it for Bob you sanitize all the slots of the Tren context you initialize it then the context is active and ready to be used but only for Bob when you finish you clear the slots and you unlock it from Bob and the last uh pattern I will present you today is trans transaction level counters so with this you are able to make sure that a function Can U cannot be called more than n times per transactions or M times per transaction per user or any more complex

Logic the advantages is that it's cheaper than using persistent storage and also it can prevent some hacks for instance if a mean function uh is used in the transaction that redeem function in a repeated amount of time but it has also some disadvantages because it can limit or even break the composability of your protocol in that transaction think about account abstraction and once again thinking about account abstraction maybe some transaction batchers could abuse the system and create a denial of service in the advantage and this is the answer to the question

so no we are not is a trans storage is not a transion trend it's we are in a healthy early adoption phase and transion storage is here to stay it's well documented useful supported by most of the networks and Dev tools uh the main Builders are already using it and the security knowledge uh exist but still has room for improvement I added some resources if you want to learn more about this topic and that's it for today thank [Applause]

you you want to say something cool okay uh that was a last talk for this session and also the last session which I think is why can I give my mic to him does it work let's try uh can you turn it off and then a little bit of logistics oh there's a mic Co thanks everyone okay F first of all uh this is a pleasure for you to come here so um I have to first I guess I was asked by many of you why and how DSS created so

first of all it has been a while but there are sort of two reason in My Mind One actually this is what I love doing is connecting domains actually this is what I did in Academia sort of trying to understand how to connect and here it's about connecting between the developers and the security researcher which I think they are both good but they can be better together that's one reason the second reason is purely selfish I actually want to learn about this domain so I thank you actually for teaching me I have to pay you I'll try so thank you very much for teaching me and hopefully this domain actually will grow more and understand we had today and yesterday about many talks so that's about uh DSS about you I really I hope you enjoy we

are in the next day hopefully we going to publish a um a survey please answer because we want to improve whether it will go next year to Banos SES or some other place we need to improve and we want to improve I think we already have some ideas and we messed out in some things but we really want your help so please it doesn't take much it takes five minutes please uh uh help us to improve so now I have to go today thank you part so first of all actually one thing which is very surprising we held it actually three times we held it in Stanford how many of you have been in Stanford probably not very much oh few one two three great so Stanford is an amazing place was amazing place was amazing to

start also maybe it's surprising you but it for us it was the cheaper because I'm academic venue was for free but uh uh Stanford was very difficult to one of the things which is and actually then we had it in France and France was amazing place but I think the staff here are the best we have so please give them thank you I think they are all in the back there is B so all of them please thank you the staff the people really amazing I don't know what you think and maybe you'll see it in the survey but we really really feel we have been taken care of we feel like the AV is working we feel like a lot of things so thank you that's the first T the second T and

that's also surprising to me is the speakers this year the speakers this year are totally amazing both for the talks and the work please give them big thanks and not promotional things are very good I mean really really am proud of people we had this three years the first year then the second year people say it started being promotional here I see it's going back so that's great so thank you all please thank them okay thank you thank you all and and try to think of something new in this field and we also have the webinar so you don't actually have to to go to next year and the webinar is not very selective we are trying try to learn about this domain anything which is useful we have Nathan from the ethereum funds please submit and we'll make it

and it's not very selective we actually want to hear we heard about things like a a lot of big protocol talking about it a are V4 balancer V3 so all of it a lot of protocol and if you are doing something interesting in this domain and you want to use us we will love it so please thanks to speaker the second thing is the steering committee they're not listed here here but please thank them here many of them are still here some couldn't make it basically what happened all the papers had reviewers they have about three three reviewers and they help us and we rank them we did almost like an academic conference so which basically we try to have it's not really per review but we try to make this

content which is unique and new and we want things to be original and I think we did well actually we didn't check so thanks the steering committee uh then and then I probably will forget so we have all these people all these companies these are the best companies in web three these are the companies that supported us and they supported us without getting anything well they got some free tickets but many of you got free tickets so let's see them so Electric Capital it's a VC film some of them are here it's they based in the Bay Area in New York they are VC film for basically developers they're developer friendly they for example support

companies like immuni they are they are fori they are basically building things for developers they also do the developer study how many of you are familiar with the developer study few are okay so they are doing some things about understanding this domain so thanks them uh and then we have Quant stamp we see them in the in the um in the talk later they actually one of the first security company they have been around and they actually did a lot of things thanks them and then of course a needs no introduction here but it's good to have such a protocol actually from day one uh

uh helping DSS with content and everything so thanks them then we have abos it's a newcomer it's a layer to we have seen them they actually contributed uh leure they contributed they also building the move formal verifier they are building the move language so thank them uh we have Sigma Prime also almost from the beginning that's a security company Med I don't know if he he R but thank them we have hexen also coming new security company tell thanks them uh we have Stellar we had uh the speaker talking about storage they're

building St Oran they're building the r implementation thanks them uh we have aan le of course very famous in this face also coming from TK them open Zeppelin uh is a security company build the libraries and everything thanks them fand actually a new security company building fazer we heard about their talk tenderly building the infrastructure also diding a workshop thank them Lio also contri sh from day one liquid staking need no introduction but still thank them uh starware we seen the last talk bu building Layer Two Zero knowledge thanks

them uh van is actually building we seen iron lock maybe still in the workshop sort of building the the network of security we have seen ASA talk this morning thank them by the way these guys I don't know if you know they're also one of the earlier one in crypto they did the first amm in bankor so they're actually coming from this field thank them please and then we have spear beat they created a lot of contest they're doing bu bout they're doing Cantina they're doing now a lot of things they're doing community so thanks them TR of bit again need not introduction but they are also with us from the first one thank them I don't know if Joseline here Dan is not here uh we have daab yanis he's a

TKS also a company doing static analysis and security thank them trash block uh again newk car thanks them ethereum France supporting us for the second time thank them and ethereum is not here but also they're supporting us for the second time thank them immuni again supporting us again thanks them a back Bounty platform Civic uh also a security space company space thanks them a rare skill uh is actually providing excellent education in this field and actually holding a a workshop tomorrow they're basically doing things about zero knowledge so please thanks

them uh Sherlock we had Jack talk they are doing backb platform and thanks them Community auditing and a symmetric research is actually very interesting they came very late how many of you know about a symmetric research so a few of you thanks so sematic research is a is a new company actually started from Solana foundation and you've seen them actually they have found one of the most interesting bug in this place so please check them it's a very small team but very prestigious very interesting so thanks them I don't think they are here but they wanted to support us they I guess they incubated in the job cap so now I inan the most pleasure part is to invite all the people that help us here to come up front please the volunteers

the V which organized this this event urri which is actually without him I'll be lost Fel which came in the last moment and save us for everything thanks you and all the volunteers and I think Rajiv was here but maybe I haven't seen Rajiv now he's not around no okay so maybe just uh first maybe we go up we go we go up no no I don't know if we can manage last time we did manage are you right something it's going out it's going so noine so maybe I don't want to embarrass you but maybe just say few words about

you everybody no everybody we yeah yeah uh okay I want to not not to talk about me but to thank everyone for being here uh it's a pleasure having you uh discussing security topics defi topics like you know security is very very important in in in the web three domain and without security we are totally wrecked so I'm glad that we are organizing this and that you are attending and participating in this insightful discussion so thank you for being here also with us from the beginning actually from the stand so uh yeah it's

a pleasure to be part of this event again third time seeing this grow since Stanford since first year has been amazing participation has been growing community's been building active so it's so great to see this growing being part of this and also thank the team secum and also spear bid which I'm jsr at so yeah thank you and let's keep securing ethereum [Applause] so I've been with uh DSS for the third year now um but this year was a bit

different it was pretty far away from uh the previous locations we didn't have many local connections and that's why we had to rely a lot on the community and on you the volunteers which did a tremendous job uh so thank you for making this happen [Applause] this all the and one year yeah I'm almost since April so I have been at DSS both from the attendee side and now from the organizing team side so I'm I have seen both sides I'm really happy and excited to see everyone here and actually having really really high quality uh talks and

people and I want to thank everyone who Beed with us all those months and uh it's not only this team it's also all this team for making that happen thank you [Applause] so hello thank you everyone for being with us um this is actually my first time in this Summit and I'm really proud and happy to be here thank you everyone for having us thank you hi everyone H thank you for coming thank you for caring about security it's good to see all these people all these faces that by the time we're getting known by like each of us and I I would

like to see you again next year glad to be to see you here and be here thanks uh hi everyone uh thanks for coming uh it's was uh this was actually my first web event so uh I don't know what I was doing so uh yeah hope I didn't do any mistakes so yeah [Applause] I just want to thank you all for being the heroes in the space and uh making it safer for the rest of us great to work with a uh fantastic organizing team and the production team

it's it's a great honor thank you uh first time at DSS uh thank you for organizing a fantastic event V and mully and also thank you for everyone on participating and being very friendly uh looking forward to be here to next year also thank you hi so it's my first time as well and I make all of the rewards my own thanks for the opportunity and thanks for being here hi everyone Hi everyone uh just wanted to quickly say thank you for coming and um you know had a great time and looking forward to next year hello everyone thank you all for for coming and uh it's awesome to see

year by year how the best practices are improving how tools are improving and um how entire security ecosystem is evolving and improving thank you so it's my first time as well and thank you for like giving me the opportunity URI M and V and I believe uh I've learned a lot and if there's any mistake just I'm sorry for that but yeah I will improve than thank you so much for joining uh hello this is my first time I'm really happy to be happy to be attending this event and I hope that all of us are glad and will still be there next year to help us out in any way you

need us thank you thank you thank you the speakers and enjoy the rest of the event or going home thank you very much for coming [Applause] everyone have aink after yeah we have a happy hour with halborn that starts in 20 minutes or so follow us and see the information on the telegram group we would like to see you there thank you so much thank you

the [Music] [Music] [Music]