The Security Trilemma

Transcript

behind this is that it's gonna be sort of an improv talk um i know the next couple of slides which is about security trilemma and after that these slides were created by annette rolikova so shout out to her and i have not seen those slides yet so either it's gonna be a super fun talk or a super embarrassing one if it's a fun talk i am say so at polygon i take care of security there um if it becomes embarrassing then i'm at starkware okay so let's get started bonjour uh i'm modit uh and that's bonjour so uh well i've already given a brief intro about me so i'll just move over here quickly i think i'll have a bunch of slides to talk about anyway

let's start with intro into blockchain security so again this is also a surprise for me i was expecting security trilemma but let's just start here so with blockchain security to be honest uh one thing i would like to add here is that it's very two-fold right now there's obviously code audits and everything that i think most of the people most of the companies are now taking care of but the other component that a bunch of companies are ignoring right now is the traditional side so if you notice at the last recent big hacks uh the harmony hack for 100 million they run in hack for 600 million none of them were like really blockchain related they were all just traditional security attacks security exploits key key

compromises and that's one like gripe i have with the blockchain companies right now polygon obviously with me leading the security team we have over 10 people in the team but apart from that there is barely any crypto d5 company which has a dedicated security team they just get code audits done and after that it's god's wish what happens so that's just a quick tip for all the competitors and everyone get an internal security team because only the actual security people will know what needs to be secured you just if you are not into security you won't even know what needs to be secured oh so security element now uh what's that so i've defined this as a

matrix or whatever between product risk and budget so all of these three parameters are interrelated when it comes to security um if you move one the other two will be affected so from product i mean the usefulness of the product the user experience of the product and stuff like that so a good example i give here like if you want to add security to a product a common thing to add is a captcha and everyone knows capture is bad ux so if you add capture security goes up uh product goes down ux goes down so that's one relation then obviously the risk so the third point to capture adding capture or not is the risk you are taking so if you don't add capture

you are taking on a risk it may not never get exploited no bot might ever come but you are taking on that risk so are you willing to take that risk or not is the risk justified or not that's one parameter obviously budget so adding captcha is relatively cheap these days but having a security person in house is definitely expensive having the proper tools is definitely expensive so when you are building a product you have to balance the usefulness features of a product with the budget that you're willing to spend on security versus on other things and then the risk component if like you might take on big risks and it might pay off or you might take small risks

and it might still hurt you back you just have to find the right balance and one thing about security trilemmas or like trilemma in general are they can't really be solved if anyone tells you that they have solved this trilemma they are just lying to you because by definition trilem are just uh they're not like check box that you can take you can check box that it's a product is secure or not it's a sliding scale so you can there can be a product which is less secure there can be a product which is more secure but there is no hundred percent security same with budget uh budget is not like you can't check mark a budget that this is under budget or whatnot it's always a scaling scale you can spend as much money as you want on budget and risk as well you can

take as many risks in your life as you want you just can't like check this that i've sold it it's always a scaling uh scale so while talking about scaling we have this slide but let me talk about security travel a little bit because there was another thing i wanted to touch on so as i said it's not something you can solve you can only optimize so the question is how do you optimize for it uh so there i'll give you three pointers one is avoid the extremes don't ignore any of the pillars try to find the right balance for you the other is that right balance changes over time so don't just do the analysis and everything at the start and just keep it throughout your product's life

cycle keep changing it keep updating it as you get more data as you get more feedback keep adjusting the parameters and eventually you will hit the right balance don't aim for anything perfect as i said you can't solve it you just have to find the right balance in life balance is super important and as long as you do it it should be good um so security scaling now these are slides i've never looked at so uh let me just have a quick read as well um yeah so he's right uh adam has he's super famous for his super long trades uh his threads usually start at 100 tweets and go up to anything but he's basically saying here that uh all of the d5 degen times at least now the yields are low anyway but

in the last year 2020 21 they were super high yields but those products were super insecure so you abed into a product you made good money for the week and the next week you got drugged 100 gone so in general it's a good principle that as security increases the apy that you earn decreases and the underlying principle is again risk here you are just playing with risk do you want to take more risk for higher returns or do you want to take less risk for lower returns so you just have to always target risk adjusted returns some heavy words but yeah like in general as security goes up your returns will go down okay so this is another important point

in this space we all love anons um like everyone appreciates add-ons the thing with being anonymous is that it gives you a chance to just do some very bad things and just come back as a different character we know in the space a bunch of players have changed names come back as different people done similar again and then rinse and repeat uh one common example that comes to mind is sifu so he has changed name thrice now omar michael sifu he's done similar things all times uh like not complete not illegal i would say it's in gray area still but uh that's one problem with crypto and and on accounts that people can just

create an account do whatever they want and don't face consequences which is bad but it doesn't need to be that way like and on accounts can be a good thing as well you don't the only thing we need to understand is even when a person is anon they have their reputation at risk the anon reputation is at risk so someone like buntag from yon he's anon but he has that huge reputation at risk already if he does something bad he'll have to start up from from scratch so at the end it doesn't really matter in return in the sense that do you have the reputation of your original name at risk or do you have the reputation of your pseudoname at risk as long as people understand that they shouldn't be blindly following any new anons they

should only be following trusted anodes then we'll be fine so this is just an interesting even obviously six hours of debugging can save you like five minutes of reading documentation so that's every engineer's uh dream and another thing that reminds me about this is with engineers uh you can like another thing we like to do is we automate things we'll spend six hours in automated automating a thing which usually takes one minute of one minute every month to do it but we'll have to spend those six hours in automating it so that's engineers for you oh ethereum data blocks so i recognize these symbols um so in general there's just one peculiar thing here

the size for timestamp is defined as 256 bit while most of the other numbers are undefined in signs is it just says that these parameters should be integers it doesn't say what can be the lower number lowest number it doesn't say what can be the maximum number except for timestamp which is specified to 256 bits i'm not sure why they specified for two uh specified timestamp to be 256 and not others and why they chose 256 bits versus 64 bit well that's basically because evm is 256 bits and if they just chose made everything 256 bits but it has been a pain point in client development for sure so uh like there have been multiple eips i think the most current one is 19 something from

alex which says that we should be adding limits to all of these constants um it's still under development i don't think it has been completed yet but the goal is if we can say that these numbers can be within the range of uh 0 to x then we can optimize for it we don't need to reserve large memory for these for a timestamp for example which will never in our history in the history of earth cross a 64 bit limit we don't need to have it so big and same with other numbers like uh block number for example it can easily be a 64-bit number or something like that so once we define those limits we can write more optimized code we know the size we can pre-reserve these eyes and so on um so that's one

weird quirk about atdm folks and well audited code uh oh it's a quote from sam so yeah this one is basically saying uh folks are usually safe if you don't change anything if you just for uni swaps code and launch it it's fine but if you change a little bit of things then it can be risky some teams did it properly like sushi almost took over uni uh before went down but uh that was a nice folk uh sushi is still rocking hot but there can be also bad folks in the sense i've seen uh projects like i think it was burger swap what they did was they fought uni but they removed the

requirement from the swap that uh just oversimplifying here but they removed the uh x y equal to k requirement which basically meant uh you can swap one ether and in output you can ask for as much as you want you can ask for ten thousand you can ask for hundred thousand dollars whatever you want you can just ask for it they never verified they just trusted you that you'll ask the honest number which obviously some people didn't and it didn't go well it didn't go too well so folks with minor changes like this this this was just one line of change they just removed that check for some reason uh can be super dangerous so when aping in a fork make sure if it's either a

proper fork or if it has been modified then the changes are not malicious okay our way die okay so this is likely uh hint on celsius and all these centralized exchanges that have gone down so that's the difference between uh c5 and uh d5 uh our way uh everything like all of the dc decentralized protocols uh so are we make a dollar and everything they are working just fine um you can lend on our way you can borrow from our way just fine they didn't stop for even a second while all of the cascading liquidations are happening on the other side uh celsius down by three ac down bad uh block block fire lost a little uh well not a little but yeah so a bunch of

traditional companies are down crypto is not down and one thing i'll add here is that is super interesting so if you look at the liquidations happening or even in 3ac and celsius in the traditional terms usually the creditors will get their money back first and they retail people who invested it will get it later so the creditors are safe retail gets raked this time are we got the money back before the creditors why because our way is based on smart contracts if you don't pay back away it will not only keep your collateral it will charge five percent extra and you can't just tell them i'll send you the money the next day you have to pay it back so this is probably the first time that someone got their money

back before the like uh before the big whales got it like if you had lent money on our way you got your money back before suzu got his money from 3ac and suzu is now suing uh his own company vailava doesn't need to do anything they had to pay back away that's the power of smart contracts reentrancy incident so uh this is going to take time for me to even understand realize what attack vector this one is but in general reentrancy attacks refer to this pattern where uh you can do some action on a smart contract and then you can do the same action again before the effects of previous action have taken place so for example if you uh ave doesn't have this bug let's be clear but

uh if ave had this bug then what you could have done is deposited money in our way then we drew it back and before the withdrawal completed you withdrew it you withdraw it again so you just keep withdrawing it again and again and again and again before the actual withdrawal happens so now you have 10 pending withdrawals none of them has actually happened but since all 10 are pending they'll all verify and you'll get all 10 withdrawal confirmed so you'll get 10 times the money back uh instead of what the one time you were supposed to get back obviously away doesn't have this good luck if you can find something like this and i will let me know but uh this sort of attacks were very common at least in the early days the dao can be a

big example of this the dao hack was re-entering the exploit and a bunch of others are as well cross chain bridges attacked so yeah with bridges obviously uh i mentioned ronin and uh ronin and the other one harmony bridge attack which was which are the two largest attacks in the recent times both bridge attacks both crosston bridges the issue with those uh both of them were like non-blockchain based stuff so the multi-signature bit or centralized multi-signature that's mentioned here both were vulnerable to that so not all bridges are built equal some can be decentralized some can be completely centralized

some can some can tell you they are decentralized but they'll actually be centralized so for example with uh ronin they said they have nine validators but four of them were run by a single entity and the fifth one uh was also controlled by that entity so this single entity indirectly had access to five validators which is enough to do anything you know you have 51 percent uh like access at that point in terms of non-validators so obviously bridges are a pain point and the code also is usually not great the i won't take the name right now but the biggest bridge uh that is live right now in terms of volume they are doing they have had three critical vulnerabilities reported to them luckily

none of them got exploited we are all safe we are happy but it just shows that the code quality is not up to the standard right now it's still improving over time it will get better uh and yeah like uh we just have to wait and watch what happens re-entrance the exploits i mean trust to humans so i think the title might be a bit wrong but um so with humans yeah like i'll refer back to the example of ronan and stuff the way ron and harmony got hacked was not due to a computer issue or a code issue or a logic issue it was a human issue so with i think ron in uh the block released an article they said uh the way ronnie got exploited was uh the

attacker probably from north north korea not confirmed but they sent a job offer very enticing one to an employee of ronan and the employee obviously was very happy to see the job offer they opened the pdf file which was a malicious file and triggered uh some bad things on their computers and so on so just by opening that pdf file by a human mistake they lost access to all of their keys and those 600 million dollars so even if you try to take humans out of the equation they are always part of the equation that's why i'm saying like focusing on traditional security is also important at least in this stage when the humans are still a big part of the equation

okay so here yeah like that's definitely a big advantage of defy and dowse in general uh you can just hand over any protocol to the community and uh you the community can handle it you can kick out a co-team bring a new one and a new co-team with a new vision can handle it sushi i was talking about uh obviously if you remember chef nomi did a very famous thing when so she launched so people kicked chef know me out a new team came in and they carried sushi over sushi flourished under this new team and then uh leadership changed again uh so it's like when you are seeing a team struggling in d5 you can just bring in new leadership if someone sees that

sushi or maker or whatever are not doing good just create a proposal in the forum and say like yeah kick these guys out bring us and bring us in we'll do better if the token holders agree with you that will happen uh this doesn't obviously happen in privately held companies and family offices and stuff like that uh it just follows a tradition but that's the power of d5 like if the even the top guys get lazy at any moment they can be just kicked out by the token holders so that's super nice autism in the chart so love this guy i'm not 100 sure what this means the numbers going up up only that's right and this is a cute meme uh polygons missile should be bigger but

well maybe not so a bunch of layer one guys probably and vcs running after running from these missiles i don't think any of the protocols to be honest is trying to hunt any of these we want to we all want to work in harmony uh well not in harmony but together let's see so uh hopefully we'll all be working together very soon polygon obviously is aiming to scale ethereum there is no competition between ethereum and polygon the upcoming roll-ups would uh again focus on scaling ethereum so that's all great and i think that's the end these are my details slides courtesy to annette and uh thanks i'll guess i'll open it to questions now

[Applause] [Music] yeah i guess this went well so i'm with polygon yeah if anyone has any questions yeah i had a quick question if you don't mind like uh not relate to polygon but more in terms of like cross-chain security and a lot of these like new bridges that are coming up like how do you think we can like tackle security over there so with bridges it really depends i'd say right now there are two types of bridges most common one is multi slash proof of stake bridges and

the other is completely decentralized bridges with the decentralized bridges it's more on the code side uh the code is quite complex right now you need to make sure all of the code is properly uh secure audited and whatnot it's like maybe 10 people really understand what's going on in those bridges so it's hard to secure them code wise but overall they have very minimal human trust on the multisig pos site bridges uh you need to focus a lot more on the traditional security you need to make sure the keys are secure uh all of the keys are in proper hands uh they are properly kept the servers are safe and so on uh it's not an unsolvable problem people just have to find the right talent to do it right now the problem with in general with this space is i'll tell you is

uh there are in very native security people in here so the developers who are building it the executives who are controlling it it's not that they don't want security they just don't know that they have to secure this thing as well so they just can't do it do anything about them so for them the advice is just get a security person in there and they'll figure everything out thank you so i had a very strange question from one of the largest bank who is trying to run smart contracts like they asked me what is an optimal number of security audit i should do so your thoughts on that yeah that's a

very interesting question um i would say it depends on the type of audits you are getting there are stamp factories out there i won't take names but if you get 10 audits from them they are still worthless and then there are super nice good auditors uh even like one audit for them from them is 100 worth it but in general speaking like my philosophy specifically for polygon tools is uh i don't want to depend on external audits i have internal security team and have internal auditors assigned to every project since day zero i want security people to be involved from day zero when the product is being envisioned when it's being architectured not when it's already been created and then you're trying to figure out where to fit security in it should be built with focus on security not

like as a side product yeah i got sick [Applause] you