The Security Trilemma - @Mudit__Gupta at @ETHDubaiConf

ETHDubai 2022 · March 2022 · 28:21

Mudit Gupta examines trade-offs between product usefulness, security costs, and risk. He outlines a smart contract security checklist covering simple code, documentation, testing, static analysis, fuzzing, formal verification, peer review, and audits, then discusses bridge risks and security budgets.

Speakers

Topics

From ETHDubai 2022, hosted by DeFi Dubai.

Transcript

uh happy to be here folks so the topic uh the main topic is the security trilemma today uh what we're talking about uh for a bit uh and then there are a bunch of other things i'll be talking about i'll be talking about just a checklist for your smart contract security like when you are building smart contracts like what you should do to make sure your contracts are secure um and then a bunch of similar things like this so let me first start by who i am actually uh that's a linux command who am i um i'm currently the chief information security officer at polygon and uh i am also a technical partner at delta blockchain fund doing due diligence

there on the side i am advisor to projects like sushi swap so help them with anything technical anything security related and helping the community as much as i can uh now back to the topic the security trilemma so i've defined this as a drive like triangular relationship between the usefulness uh the cost the usefulness of the product actually cost of the security measures the budget basically spent on security and the risk that the person or the product guy is willing to take with their product these three things go hand in hand and if you move one pillar the others automatically just move

so understanding the problem usefulness firstly let me just define what usefulness is so it's basically just a combination of features that a product has and how easy it is to use so from usefulness i basically means like what you can do with that software uh what you can do with that product uh a basic calculator might just give you like one plus two a scientific calculator will give you more functions like sign costs and stuff um so that's your usefulness and then there is ease of use so uh oftentimes you will see better products won't succeed just because they are very hard to use if someone can't use your feature doesn't matter that the feature exists so user experience is actually quite important

security can hamper user experience in many ways a typical good example would be the captures i'm sure everyone hate captures but they are necessary almost unnecessary for most things now that is just uh like a trade-off most products have accepted to take they'll add captchas in exchange of those a little less usefulness of the product then like how to increase your usefulness um basically the best way is to add features the more features your product has the more useful it is but there is another thing you can do is just make your product easier to use especially in d5 you might have seen

like a lot of projects or products launched which were too complex but then easier versions of those projects launched and they just took off a good example can be bank or um and guinea swap so i'm sure unit swap is or was different from bank or even in v1 but the base concept was the same but bangkok never really got much attention especially in the v1 version just because like it was relatively complex to use they tied everything to the bank or token and stuff while you need to have just made it all open and rest is history so that's one example then in terms of the trade-offs when you add any feature to any product

you are basically increasing the attack surface if you increase the attack surface you are increasing your risk you are taking on more risk and you are also increasing your security budget if you want to maintain the same level of security like if you want to get one feature audited it might take you i don't know six months wait time and if you want to get two features audited it would take you any year um so definitely uh hampers all of your things hampers your budget hampers your timelines and everything usefulness is obviously important if your application is useful is not useful there's no point going forward i mean that that's the base requirement for any product it needs to be useful so that one pillar is super important

usefulness cost is obviously another super important parameter especially the product guys will agree if you end up spending all of your budget on one thing the product would just suck you have to manage your budget very carefully and you have to like make sure you are not just spending everything on security while not having a actually usable product risk is another thing you need to manage very carefully like if you don't manage risk properly and have nine nodes you might end up losing 650 million dollars and not realize for a week that happened so you have to be very careful about what risks do you accept and that's basically the trilemma you have to adjust these three parameters and find the right balance for you

uh one thing i'll tell about all the trilomas is you can't solve a trilemma by a by their definition you can only optimize for it so the next time you see any marketing materials stating they have solved the trilemma you can assume it's full of in most cases why you can't solve it so i'll mathematically prove this the reason is the things that are present in trilemma they are measured on a scale they are not a check mark that you just take off so security is not just a check mark you check of this is secure or not it's always a scale of like how secure it is how safe it is cost is not a check mark like if you don't just check mark of one dollar it's costly uh it's always

relative it's always a scale um and same as usefulness like something very basic is also useful and something super complex is also useful so it's it's just a scale um so you can't just like solve a scale you can just take mark that off you have to find the right balance for everything um and that by definition uh you basically optimize the trilemma so how do you actually try uh optimize the trilemma so now this depends a lot on uh the product itself i can give you some pointers so one thing is usually extremes are bad um so you want to be somewhere in the middle you don't want to spend all of your budget on security you don't want the product to be not useful at all and you also don't want to take on all of the rest in the world

in most scenarios but obviously there are certain things where uh like being extreme is fine so for example if you are bitcoin then having a product that is not very useful that spends like energy of multiple countries on security and that like takes no risk is probably a good electrolymer situation then if you are building an mvp product then you can obviously go super high on risk if there is like no monetary value to it you are just building something for one people call it testing and production so in those sort of things yeah you can take on super high risk uh for cost people don't really spend much money on uh like these

mvps type of things all of the focus goes into the usefulness of the product in that case so for those sort of products yeah it's good to like focus everything towards usefulness but for most products that go live in production yeah you have to just find the right balance it depends on it depends on productive product but there is always a good balance the third thing i'll add is you need to adapt over time a lot of times i've seen a lot of projects that just uh mold themselves in a shape at the start of the project and then they never change so i'll tell you like even i've seen projects that just allocate a fixed budget to security and five years later when the project is ten years uh when it's when the project is

ten times more complex the security budget is still the same people i don't know why but don't adapt over time change is super important evolution is super important so uh doesn't matter if you have struck the perfect balance you need to keep tweaking it over time and like you might have to tweak it depending on external parameters not just your own product but external parameters can also affect the right balance that you should be having [Music] this is basically like what i had for the trilemma now i have a bunch of other things but before that i'll get into chilling today's video is sponsored by raid shadow audience well not really but the two things i'll mention here is one delta blockchain

fund keep an eye on it i'll be dropping a few useful small d5 tools for it the mvp sort of projects which are good on usefulness uh but yeah i'll make sure they are relatively secure um and then the second polygon i'm currently building the best security team so uh like if you are interested in security just reach out to me i'm hiring aggressively now uh this one pointers for writing secure smart contracts this is basically something i was working for an internal list in polygon just like creating some guidelines and uh security stuff i'll probably make the whole thing open source eventually once it's ready but just to give you some highlights

uh the first thing i'll say is you should first understand how to like what defy actually has uh to actually write smart contracts you need to understand the best practices the best practices are called best practices practices for a reason you should understand the common pitfalls like if you see someone falling in a ditch you should not be walking to the same ditch um just avoid repeating the same mistakes and you'll be golden in most scenarios another thing i like a lot is doing capture the flag events um so if you are even remotely interested in smart contract security and you are a developer would definitely highly recommend to do ctfs that would allow you to learn a lot about different

attack vectors that would allow you to think in a in a manner that the like bad guys think uh in a manner that they exploit testing and that way you would be able to like sort of front run their thoughts and keep your product safe the third one which honestly i feel like is the super important it's the most important bit in smart contract security keep it simple you don't want to go crazy with optimizations on all unless you are maybe transmission in most scenarios you would just want to in more scenarios the trade-off for like saving a few bits of gas for making your code non-readable it's just not worth it start with a as easy to read code as simple as

possible doesn't matter if it's not super optimized optimizations can be added later just make sure you have something very simple that is safe and sound another thing is have proper documentation and specification i'll tell you like even the tier 1 d5 projects they are super lacking in documentation and almost nobody no one has proper specifications someone who comes from uh like a traditional development environment when you spend like a good chunk of your development time just writing a documentation and specifications even before the development starts it's just a weird thing it's good to be building fast but you have to be

like especially when you're dealing with such large amounts of money you have to be building proper i don't think rushing projects to be the first one to do this or do that make sense especially in d5 the first movers advantage i feel like is overrated um i don't think like probably none of the projects that just launched first has actually maintained lead in the space um it's almost always the second project which is more polished um that takes over um like even like lending borrowing platform always taking over compound in like amms uni swap took over uh bangkok so she would be taking over uniswap very soon um and so on so people who launched later uh sort of uh

usually get to do the better job reuse safe code so no need to reinvent your wheels uh there's always there are already enough erc20 tokens out there i don't want any of you to be writing your own one to save two gas um so just reuse code and then these are some checklist that i tell people one is aim for 100 test coverage if there is any reason you can't get 100 uh if the there is a branch that is impossible to reach try to reason with it why it's unable why you are not able to cover it add a code comment to it for the future days for auditors and all that hey this is the scenario that we cannot test uh then you add a comment like this is fine this

is perfectly safe this can never happen in production or you add a comment like this is very complex to do or they should never happen in production but there is a chance it might happen so focus more on this bit maybe so even those comments can be very helpful for any reviewer any auditor use a static analyzer uh like i like trail of bits tools a lot so a slater is my favorite one uh there is metrics as well you can use both but in practice like even if you have one of them uh you're good most of the rules they share are the same then use a property testing thing you can either go for formal verification go for a tool like satoru or you can go for a fuzzer like echidna from trailer bits the

difference is basically with formal verifier you will have guarantees that uh the property you are testing maybe you are saying that x should always be less than five a formal verified would give you a mathematical proof that uh there is no code path possible where x can be greater than five so uh you would be like hundred percent certain in that case uh on the other hand a fuzzer would just keep trying random inputs uh to sort of you can customize the inputs but let's just say you it would keep trying random inputs and see like in any scenario in any path of the input does the value like breach your condition does it become greater than x so you will never get absolute security with the fuzzer you

would get probabilistic security like the longer you run the fuzzer the high like higher chance that there is no bug so yeah the in theory formal verifies um obviously look good the big gotcha with them is it's very hard to formally verify complex things uh when there are too many code parts it's just not possible to do it with a formal verifier so you have to fall back to a fuzzer and further fuzzers are also usually easier to use so uh my recommendation would be for simpler things or some or things that are super important super critical go with a formal verifier like satoru for things that

are like maybe too complex that are like integration of yarn curve and i don't know what not some wheat economics and all all in one function um that thing you just can't do with a formal verifier so go with the fuzzer or just try random inputs let it be run let it running let it run for multiple months or something and uh hopefully you it won't find anything but fuzzers have actually find issues i remember i think it was consensus diligent solidity fuzz or something that found an issue after three months of just continuous buzzing so it can take a while but like even that single bug can be quite useful the last bit obviously get peer reviews and audits i know it's hard to find audit slots right now

for any of the good firms so you just have to ask your friends to do semi audits for you but that also works oh yeah so i was collecting topics about this talk at 4 am today so what should i talk about this was the tv don't tell the organizers my slide wasn't ready till now uh so i'll just rapid fire answer some questions um i got from uh my like twitter tweet or whatever uh something [Music] oh yeah so this is something i just talked about there are certain things that uh harm the ux in terms of security capture is the most i think relatable experience everyone hates capture but they are

super important uh other things like uh slippage protection can be one thing in amms like most of the people don't realize what slippage protection is doing but it helps you from being sandwiched in most scenarios and all but it also can lead to some like failure of transactions or trades when the prices are moving very fast the asset is very volatile it's dumping fast faster than titan or something so yeah can users trust d5 if they can only review the smart contract it really depends on the smart contract if the smart contract does not depend on an external factor it's a self-contained smart contract then yes you can just trust the smart contract a good example would actually be

junior's v2 code base uh assuming like it is decentralized there is not much like uni can do to rug your stuff while there are certain code bases where the owners or the dows can actually like upgrade the contracts or whatever and steal all of those things so in those things you can't just depend on the smart contract you also have to depend on the dow itself or the people controlling that power so will you post a recording or will there be a live stream probably should have answered this first but uh yeah i think there is a live stream going on uh is deflationary base asset so yeah like a lot of folks would disagree with me uh but i would say like deflationary assets for a platform that wants to be

get that wants to get used is a bad thing um i don't think uh you should be like promote like deflation basically promotes users just to hold tokens we want users to actually spend their tokens build cool so i don't think deflationary model is a good bit the only gotcha there is ethereum is not deflationary not even any two it might become deflationary if it gets a lot of usage if it gets usage more than it can possibly sustain then it becomes deflationary so it becomes a self balancing model where like the system actually wants to slow down growth so that uh the nodes and all can keep up or the gas prices don't like go crazy and all so if it's being used a lot uh then it becomes reflationary but if it's not

being used a lot then it would remain inflationary and uh it would be promoting use of the token so that model fits but if there is a lot of d5 tokens just launch and say like we are deflationary from day zero even if you don't use it most of them are ponzi's so what audit really accomplishes so everyone has to understand audit does not guarantee anything especially code audits financial audits are a completely different beast you can verify things mathematically but when you are doing code audits you just can't verify things uh you can only sort of do peer review in some sense uh you can like again it's not a check mark it's a scale you can move towards a good

quality scale but you can never just say like this is audited this is safe that can never happen um so now about the bridges and all uh yeah so in d5 like this is something i was just talking uh about someone uh a lot of hacks sort of just happen in clusters so people just figure out a new attack vector or a new attack surface and most of the products protocols that are using that like attack vector surface just get exploited so uh when the uh like flash loans came in power i think bzx was the first one that got wrecked uh like all of the attacks just immediately become flash loan based and that was all of the hype because you know that was

the latest attack vector people hadn't realized that ditch yet and were just falling in it again again again these days uh bridges are the new hype uh wormhole uh the iranian thing and everything so bridges are the new attack vectors that is what the attackers are targeting right now so uh bridges should remain careful but they should make sure the code is safe but that's the latest thing in this space right now so yeah everyone's going after bridges so principles that developers should consider again like the checklist i give that is good the balance you need to find out in this space that is good it really depends on product to product

i don't think there's any general advice apart from what i've already talked but just think about your product think about how much like what balance you might want to find there and go with it so vitalik's multi-chain and cross-chain thing um i agree with him on some bits um so one is the future is multi-chain i agree with him uh if you find 8 maxi or even btc maxis they are just either lying to themselves or i don't know what they are doing but um i can guarantee you the future is a multi-chain you like if just imagine if a car if cars were created in the 19th century and we only had one brand creating cars that won't happen like you'd have

specializations in different demand in different spaces so it might be that uh like it might be the best one for d5 uh solana might be the best one for uh i don't know coins and other chains for other things so there might be like different use cases um but uh there will be multiple chains uh no events or on is great uh solana is doing great stuff but this was just a joke um so yeah next thing uh [Music] well that's a comment so i'll pass that uh i didn't get time to edit it properly so apologies for that how protocols is valued at 10 million should have bug bounties uh yeah i mean with that i'll say in this space i think we really need a company like zerodium

so if someone is from traditional security field uh zeriodium is basically a company that buys zero day exploits so if someone finds a bug in like facebook and they can access facebook just log into anyone's account and they go to facebook directly they might offer them like 100k bounty uh what the the zero like this uh dave group or this security researcher can do is reach out to z rhodium instead and sell the zero to zero dm uh all all of this is legal i don't know how but it is zero dm would likely pay them in millions and then zero dm would with their lawyers and all negotiated with facebook and um i don't know what get probably even more for that bug um or just maybe selling doc in the in

the black market so in any case companies like zero dm that can guarantee you fair market value for any bugs would be great in this space i personally i have reported a lot of bugs in fact like once i reported a critical bug in a year one chain i got a bug bounty of 250 dollars even though the stake was like tens of billions of dollars i wasn't even angry about it because for me like i wasn't doing it for the money i was just doing it for fun for education and all so it really depends on the motivation of the person um i think from that incident i learned a lot more than what money could have like made me or like me earned me or whatever

um so i won't i don't want to put exact numbers for different types of bounties but yeah i do think there should be some intermediary who like guarantees fair market value for bounties uh deflationary base asset i think we've already talked talked about this and the security culture yeah like 90 of the projects launching uh data present right now honestly i think won't exist five years later uh people are very bad at optimizing that trilemma everyone is just going for that usefulness people don't care about risk people don't care about security there is no budget for security uh projects are launching without peer reviews without any audits

um i know like projects that have like billions in tbrs and have no audits so it's scary like those projects i feel like uh won't survive long term i might be wrong hopefully i'm wrong but uh yeah that's uh how it looked like and that's uh all i had uh on the agenda uh but i'll open it up to any questions if anyone has yeah let's get to questions um i was taking some notes so follow best practices reuse safe code keep it stupid simple right mind the ditches previously visited by others ronan monitor your bridges all right so do we have any other questions that

oh here right here hi thank you for that talk so the blockchain is moving very fast in terms of innovation do you think security is also moving as fast as blockchain or are we uh barely scratching the surface as an industry thank you um so with security unfortunately it always lags behind development because it really happens that someone's develops a security product for something that doesn't exist yet it always happens that a product launches and people realize it's not safe so people start working on like how to make that secure and stuff so even in blockchain space since we are growing so fast security is lagging it's lagging

more than the traditional world with the development on the uh like uh you won't get new completely new primitives every day in the traditional world so you don't need new security tools every day in the traditional world um so even though security lags behind the latest up there it's still fine a good example would be anti viruses you will see they keep updating every day they have now added behavioral analysis but you know they only update the database when they actually like see the bug the viruses are the latest ones at least are always one step ahead um so yeah in the blockchain space it's even more like focused in the sense that uh we keep dropping new protocols new primitives and whatnot every day uh the security space just can't keep up uh so

it's a tough situation uh but over time i think it is getting better here hi here hey so you mentioned about the budget problem and then obviously in the web to world we've been seeing that also like you know security is considered to be a cost center you know we don't get the kind of reward and then so what kind of typical budget would you recommend for companies and if you categorize let's say bootstrapped early stage versus growth stage versus mature do you have any ballpark number or percentage or any any suggestions issue so uh putting a number again is very hard depends on the product it depends on the range you optimize for uh like in general um i say like 10 of your

engineering budget at least 10 percent of your engineering budget should go towards security um so that would include like audits and all um this is the like uh fingerprint like the number we use in the traditional world especially like if you're building any project at least in the iteration world 10 is the standard accepted amount in the d5 world if you're just starting up you don't have a lot of money to burn on security and all 10 percent is fine but as the project may choose um i feel like more of the engineering engineering budget should move to security because like smart contracts are not upgradable what are you going to do with all of that engineering budget when your product project is already like there should definitely be a research budget a super high research budget so

you get to know about your next like what you will be building next but you should be spending a lot on maintenance and security as well while the project is live let's get moody a big round of applause thank you guys [Applause] you