Smart Contracts Secure Software Development Lifecycle

Transcript

welcome to today's session about smart contract secure development the crypto valley association was founded in 2017 to further blockchain adoption in switzerland and focus on the swiss crypto valley in the meantime in the last five years we have grown into a global community of blockchain based experts including six working groups today we're here with the cybersecurity working group and our mission is to increase trust in blockchain-based solutions by sharing the know-how that we have as experts and allow companies and people worldwide to build that know-how and

build smart and secure solutions thanks to the team who we have here we have added yet another building block around more contract secure development and without further ado i would like to hand over to emily thank you very much marcus and thank you everyone for joining um so my name is emilia and i'll be your moderator tonight so before introducing the panelists i will quickly introduce myself i'm the head of sales of chain security we are a tier one blockchain cyber security company and we focus mostly on smart contract audits especially for the large and complex d5 projects you might know some of our long-term clients like maker

dao compound curvier and so on um so i think i'm not going to surprise anyone by saying that there is a lot of risk and a lot of money at stake in d5 as you can read in this amazing paper we just published um there is 21 billion usd uh that have been uh caused in damages by attacks in the d5 space so this is huge and it's of tremendous importance to make more secure code and to basically create those guidelines and this is why we're here today what's noteworthy is that chain security as an auditing firm we come at the end of the development process

and although you know you can trust your auditor to identify most vulnerabilities in your code you cannot expect them to radically transform low quality code with a poorly designed architecture into a d5 piece of art and this is where today's discussion comes in there's a huge need in the defy space for standards for the secure development of smart contracts and this is what our awesome panelists are going to be talking about and have been working on this past month so the paper uh has actually been released a few minutes ago i think the link is in the chat you can also find it on the website of the crypto valley association so feel free to give it a read it's extremely well written and

it's extremely useful if you're thinking of developing a d5 application or web 3d application in general um so we will give you an overview of that paper and then afterwards we'll have a long q and a where we will answer all your questions so before i introduce the panelists and kick off the event i'd like to run a quick survey of the audience i'm going to ask you three questions and i'm going to ask you to raise your hand virtually if this applies to you so my first question i'd like to ask you to raise your hand if you are an i.t professional so if you are a researcher developer technical project manager so if you're an i.t professional um

uh-huh and i don't know how to see who raises their hands i need to click on participants out here all right so we have nine hands that are raised out of uh 39 attendees 10 hands nine someone doesn't know which category they are all right so we we do have quite a lot of it professionals um could you raise your hand if you work in the blockchain or dlt space also 11 12 people working the dlt space okay very cool and then third and last question could you raise your hand if you are nit professional working in the dlt space so if you are

typically a web 3 developer or all right ok ok good so we have a very focused audience we have 11 people who are i.t professionals in the web 3 space in the blockchain space so that's i think that's that's very good and i hope it's going to be very useful for you guys so as you can see we also have a lot of people who are non-technical like me so um feel free to ask your questions even if these are non-technical questions you think this is an easy question or stupid question or whatever please ask it because maybe someone else is wondering the same thing and they're not gonna dare to ask the question um all right so thanks for participating in

the survey you can already start dropping actually your questions in there and i think there is a difference between the chat and the q a is that right nikki um yes so you can see on the bottom left there is the chat and the q a please ask your questions in the q a because in the chat we might miss them and you can start dropping your questions now and we'll get to them as at the end of the presentation all right so enough with the technicalities uh i'm now going to introduce you to our brilliant panelists so we have agnian marek who's a senior researcher at dfinity with a focus on formal verification agnin got his phd

from eth zurich and his thesis was titled formal verification of fault tolerance systems before working at dfinity you worked at digital assets on the design implementation and verification of distributed commit protocol and that makes you a true expert of the topic of today so thank you so much for joining and welcome to you next we have sebastian banister from kwan stamp for information kwon stamp is also an editing firm like chain security but rest assured we're very friendly competitors and i'm glad to have him joined today um sebastian you are a senior research engineer and quantum managing director in germany you wrote

your phd at the technical university of munich in the field of cyber security but more precisely it was titled characterizing the strength of software obfuscation against automated attacks thank you for sharing your expertise with us today sebastian thank you for the intro and last but not least we have tilo waghorn the cyber security consultant for swisscom tilo you have done cyber security research both in the private sector from major banks like freddy swiss but also in the academic sector at tth zurich where you wrote your phd thesis in the field of cybersecurity and namely around ddos attack prevention and rbac and abac policies which are

actually some of the key topics of today you will see t load is actually also a charitable side to you as you recently co-founded a non-profit platform to help smes make it through the covet 19 crisis thank you for joining us today tilo thanks for the introduction so tila i will give you the floor to give an overview of the paper but before i do that i'd like to quickly remind the audience you are encouraged to write all your questions in the zoom q a and not the zoom chats you can write it already now and we'll get to it at the end of the presentation this being said tilo the floor is yours thanks so can i get quickly an information if

you can see all my screen perfect okay thanks a lot uh emily for introduct for the introduction and uh marcus for the opportunity to work in such a great team so i'm very happy to present to you today our work um about smart contract secure development life cycle which was done with my awesome co-authors um sebastian ognian who were both here and also duncan and peter which couldn't be here today but um i'm very happy to present you now the the result of uh one year's work um it's done in the security working group like marcus mentioned in the beginning and uh it was a lot of fun

next to our work and our professional life and yeah i think it's a very interesting paper especially if you are into secure development and you're a security engineer as you heard in the beginning that there are some i.t professionals here and you're interested in like how to improve smart smart contract development and make it more secure maybe quickly like emily already mentioned it the motivation behind this paper is as you can see for example in um in in on this slow mist website uh you see that there nowadays like last week there was

already 25 billion dollars of money which was lost due to to hacks and different blockchains or public ledger technologies and um the the reason for that is that as you all know the blockchain's got more and more traction and the prices went up over the years and it gets more and more interesting for hackers to attack these kinds of um smart contract environments and try to um extract money from it and um the the advantage of the hackers at the moment is that it's a very new industry a very new

environment it's very it's very fast moving and innovative but for that it's also a bit immature so there are not as established development procedures as we have it in in more established software development areas and for that it also leads to more bugs which the hackers can and vulnerabilities which the hacker can then use for in this work we want to do a high like a high level overview we don't go too much into technical details and the question we ask ourselves is okay how can we develop smart contracts in a more secure way so how we went through the whole development life cycle and try to understand um where uh in the

smart contract development life cycle can we add some best practices for example to to make the product the smart contract in the end more secure a well-known picture of well-known graphics of this development lifecycle for software is given here for example as you can see it's an iterative process so it starts with the initial phase where you plan what kind of software you want to develop and from there you define requirements your software should fulfill in the end then you you make a design and uh after you made the design you you implement it at least that's what

best practices and um after implementation you you or even during implementation you should do testing to verify that the functionality you implemented the software you implemented actually works as intended on some examples and with these tests you you can do evaluations you make more complicated tests system tests and from then on you go again in the cycle maybe you identified some some problems some things didn't work as planned and then you readjust your planning you maybe add new requirements and that the cycle begins again until you have developed a functioning product and you can deploy it or give it to your

your customers but even after you gave it or deployed it to your customers it doesn't mean that the product is completely finished we all know that there are updates uh which we have to install to ensure security uh regularly for the browser or for other things and there there's already a key difference um with smart contracts because once they are deployed it's very difficult to upgrade them or to change them so what we did we started looking at this normal software development life cycle a smart contracts are also software and looked at each of the stages and and try to understand a bit better how can we give best practices

for example in the first stage where we looked into the setting and framework and we provided a new framework it's a as you can see it's a list so it's not important that you see the details the details are in the paper but we we developed a framework which is similar for example as the nist framework uh where there are different areas different categories uh like the data model or the platform you are developing on and there's a set of questions you can ask yourself in the beginning of the project um what does this platform i'm using like what what is how is time measured there or um what how is data stored in this platform and depending on on the answers of this question you already get

hints and requirements how your smart contract has to be developed or what's important to to keep in mind and after you went through this this framework um the next thing is uh you did you define a design of your contract so normally um you start to define requirements um so we gave some standard requirements in smart contracts which are usually um commonly looked at and you look into access control for example you you define who can access what in your smart contracts and also with smart contracts there are new challenges there are new threats therefore usually you you can do a

threat modeling and and look okay what kind of uh for example malicious uh smart contracts could interact with my smart contract and uh in the next stage you go into the the implementation phase uh i hope you can actually see that because i have my my screen here so there's the implementation phase and there um we talk about common pitfalls you you can have during uh during the implementation and um we look into how to do uh reproducible builds and what are best practice resources so like what kind of smart contracts can you leverage which are already built which may be already audited which you can be sure that they are

working well and you can add them into your implementation cycle lastly you look into quality insurance so there are experts from font stamp and and a chain security come in so usually first you do testing you you try out so there is also interesting i mean you don't want to do tests in a in a productive environment you don't want to do tests on the blockchain already so you want to do it maybe offline and then you can use formal methods like static static analyzers which are developed and which are also used by these auditors and you can make a proper

audit before you deploy your smart contract to to be sure that you don't miss any any clear vulnerabilities and also to give the users of your smart contracts or your customers later the confidence by publishing the audit uh that the product you produce is actually um secure against vulnerabilities lastly then you deploy the contracts and now with the blowing of smart contracts uh you might have depending on the platform you're using you might have problems to to change the contrast afterwards or to make updates so what you can do you can at least monitor it and you can get alerts if something's

going wrong and react to it much faster it's then also very helpful to define incident response plans before like to define okay in case something goes wrong how do we react what do we do like maybe we do we do a hard fork what are the options we have actually to react as fast as possible and to avoid that you have this huge hex which we mentioned in the beginning and lastly i mean some platforms also allowed allow you actually to upgrade smart contracts so this is also something which you could keep in mind in the beginning to be sure that even if something goes wrong you can fix it afterward and with this um with this short introduction i hope i

could make you excited about reading this paper and this work and we were very happy that you're publishing it today and yeah i would if i would like to give back to emily and start maybe the q a session thanks a lot thanks a lot that was a great summary um of course you know there's so much more that we're gonna dig into um just a reminder if someone just you know joined you can ask all your questions in the q a and we'll get to them as soon as we can before we move to the q a i actually had some some questions i wanted to ask so in the paper you mentioned that um

dlt platforms themselves often have properties that are complicated and poorly understood maybe i'm i'm going to ask this question to to augment what are these these properties and how could developers become more aware of you know those fundamental properties of dlts that they're building on [Music] yes so i guess you know you could ask so like what is kind of the difference between regular programming and programming against the dlt a blockchain or anything like that um so in general blockchains and blps are fairly complicated systems so writing an application against one

is often more difficult than writing an application against just a centralized database or something like that you know like generally how you write a web application or have a maybe a database in the background and some kind of web server and you know maybe some javascript from the front end whereas here you have a whole distributed system usually that your your application is running against your smart contract um so i think there isn't you know um a very simple answer in terms of you know these are the three things that you need to look at but what we did try to do in the paper is collect a list of questions that help

you understand your platform better that can help you inform you about things that you need to do with your smart contract things you need to take into account when programming when actually not just programming but even when designing your smart contract even when um coming up with requirements you know it could be the case that for some reason you know you might want to choose ethereum because the most popular platform you might want to choose a different platform for a different reason um and there there is i think a helpful systematic approach that somehow we try to condense this into this list of questions that can then help you answer

um basically what can i even um what can i even actually achieve on this platform and what do i need to pay particular attention to so examples i think people already mentioned some of the examples in his intro but would be something like well do i need any kind of confidentiality of my data for example if i do then what does this platform provide me what are the trust assumptions of the platform are there any concurrency issues with the platform or um are they how do i do authentication how do how do i do authorization can i upgrade things and so on and so forth so i think it's a bit too it would be a bit too long to go into the list of detailed

questions but these are the kind of things that you try to capture all right thank you yeah so the platform really does influence the the security so again i think it was not just the security but i think the idea is a little bit it can also influence what you can actually get out of your smart contract so there's this interplay between um you know normally you would come up with an idea of what you want to build but what the platform provides can actually shape what you are able to achieve at least especially if you want security yes thank you thanks a lot um i also had a question for for sebastian so in web 3 um does security only mean

that you should write proper code are there other steps that must be taken by smart contract developers to to really reach this this golden standard thanks for the question yeah i think uh one thing which is sort of underestimated is good technical requirements so in my opinion if you don't have good technical requirements and you go live with a smart contract or a platform basically you you have something like code is law uh right because like you cannot clearly claim after a hack well i did not intend

for that to happen because you didn't have any documentation right so if you don't write good documentation you're in a pretty bad place when it comes to what might happen after a hack right what you could do so good documentation also helps auditors like us have a more effective outcome from an engagement and it also helps uh maintainability and extendability of the platform yeah yeah we have this uh this joke poster in our office you know what to do

the guy who developed it is gone it's really important yeah i agree and for auditors it's really important for other people to understand your code if you don't understand the intentions then yeah for sure totally yeah yeah probably agree all right thanks a lot sebastian um you know you said uh something really interesting that i'm not sure i understand you said that in the context of smart contracts threat actors can be divided into two types malicious smart contracts and humans interacting with smart contracts can you tell us a bit more about this difference sure

so i think from the spread noticing perspective usually one looks into more like internal threads or one different red actors which are like script kiddies or like nation state actors which are the most difficult to defend against but in the smart contract environment somehow it gets a bit more interesting because the the contract is published so everybody can see um uh what the source code is for example and uh also you the smart contracts can interact not only with the users but with other smart contracts so in case you're using for example a smart

contract which has a vulnerability uh you you might be hacked not because your code is bad but because the dependency is is uh you have a bad dependency or you you allow interactions with smart contracts which you didn't foresee and which are used to then deplete you from your money so i think a lot of maybe sebastian knows more about it but in the security audits i saw uh one has to be very much one has to be aware on the interfaces between smart contracts and uh what can interact with your smart contracts and i think some of the hacks actually use these kind of vulnerabilities a lot and

that makes threat modeling a bit different than we are maybe used to when we do normal software development where the only one who can interact with the software the web application is maybe a user okay and how do you think developers can protect themselves again because you can't have the entire defy space audited and know for sure that there are no vulnerabilities is there any way to protect yourself against that i mean one thing you can do you can do a risk analysis you can you can check okay what what dependencies do i have on other smart contracts and how from which one which ones i know that

i'm depending on and then check for example like how how long do they exist uh have their win how critical are they and uh the the other thing is you can look at all the interfaces like you can restrict access to your smart contracts and and try to to limit that that the smart contracts who can interact are really the ones you intend to i think there is also like requirements are very important you have to be very clear in the beginning what should actually interact with your smart contract and to be able to foresee that that nothing that no malicious smart contract can interact to it so i think they're

yeah it's it's it's a very vile a very wide field so maybe i would be interested what the auditors say to that yeah so that's sebastian raise your hand so if you want to add something for free yeah so i think uh this um situation where you have like this this permissionless composability right in d5 where uh it's really hard to restrict other contracts from interacting with with your contract or you can basically interact with anything uh like like tilo said it's really important to do an analysis and for that you also need good documentation but there's also this principle of like which is used in other places but like the principle itself is like zero trust right so you're not you

shouldn't be trusting any contract that you're interacting with uh that it will behave the way you want it to right and this is one of the main reasons for many of the hacks right you we've seen a lot of d5 aggregators which rely on many uh different platforms to maximize their strategies and the hacks were due to the fact that they were assuming that if you call a withdrawal function the right amount is going to be withdrawn right um they didn't have any check on the return values of the withdrawal function for instance to see if the amount is too low maybe uh revert right so those kind of things like you should always check those kind of return values uh in

in like any contract even if you think it's gonna be totally fine 99 comma 9 of the time because like that 0.1 is gonna be the one that gets you all right thank you a stern warning um so we have already some questions from the audience thanks a lot guys for participating we have six questions feel free to ask more we can get through all of this uh quite easily um uh yeah great thank you so first one from jessica what were the specific hack scenarios that were used to validate or test the robustness of your life cycle considerations

i can read it again so you have more time to think about it what were the specific hack scenarios that were used to validate or test the robustness of your life cycle considerations ah sebastian go for it oh okay you wanna take it maybe oh sorry i didn't see uh yeah i i was go ahead i can i can add it yeah i just wanted to say like from my perspective we were developing this uh in general so like for pretty much any hack i think like um those those really famous hacks um like the dow hack which was due to reentrancy um and and really like the the most

common ones right which have to do with access control which have to do with um overflows underflows and so on we have them in mind but like we believe like what we wrote here i think is pretty much agnostic for what type of problem you may have so if you follow this methodology you should be covered for all problems okay yeah that's pretty much what i wanted to say i think you know in terms of validation i guess it's kind of been so it is a relatively standard software development life cycle that applies not only to smart contracts but also to other kinds of software um i you know i guess from our experience of auditing smart contracts or in my hand

like in my case verifying smart contracts um following the methodology like this is tremendously helpful of course there is no hard guarantee but you know like sebastian mentioned many of these things hopefully would have been called had such a methodology been followed all right thanks a lot so um our next question is from nana i'm a viper fan and i find quite little material on best practices when it comes to viper smart contracts what material could you recommend here i think again sebastian wants to go

so like indeed there's so little material when it comes to viper and though the the resource that i find myself using pretty much all the time are just the viper docks because uh they're like the most comprehensive one that is out there they do have like best practices embedded in there and in addition to that one thing which i find useful is to look at some of the more famous um d5 platforms that use uh viper with like curve uh the curve uh decentralized exchange and also the urine protocol right which which have a few

uh smart contracts which are fairly complex implemented in vipre they're really nicely commented they have the documentation so i think like those are some some pretty good resources we have from anonymous attendee what's more important gas optimization or readability i see that this makes you laugh boot onion and and sebastian onion you wanna you wanna get this one um yeah well i guess since we're you know um here trying to give guidelines

for secure development this uh secure uh like life cycle um i guess we would go for the readability i think on all three of our sites but you know obviously i guess at some point it might make sense to to optimize as much as you can but you know i guess actually things like like formal methods that might come into handy try and prove equivalence of things and so on but that that's pretty um you know it's pretty advanced stuff so i would say when in doubt go for readability are they always a trade-off do you always have to choose one or the other or is is there some way to maybe um i mean often you know if you can make

the code more concise um you and simpler it's better for both so you can't have a win-win situation but i guess in some scenarios you do kind of have to choose okay okay yeah if i may just add one thing there i guess it depends if you have freedom to change the api right because if you can change sort of like the api and the architecture you can code something more efficient but sometimes like after you deployed something and and maybe you're upgrading some stuff in the background and you cannot have that freedom anymore it's pretty difficult also if you have like stuff in storage already which is

like had a certain layout you cannot just change the layout anymore if you're upgrading so yeah that's pretty tough all right our next question from alessandro uh thank you for your presentation can you do a simple example of a smart contract monitor what can i do when something goes wrong after the deployment it's through that oh yeah i guess it it really depends on the

platform it also depends on what kind of provisions you have done for this case before deployment so if your contract is immutable has no kill switch and you know you're running on on a public decentralized platform there is not very much you can do you know there is obviously trade off like if you do have a kill switch then there are trust issues involved who can um actually trigger such a thing and so on so there is the perfect answer but those are we cover some of the things in the paper so um not in great detail but we do touch upon

yeah maybe to give like an example i'm not sure what what the the quest the the person is referring to with an example but kwon stein has a smart contract monitoring service which basically notifies you via email sms api whatever you want and it can programmatically pause your contract in case there's a hack right so for instance if you have a token and you notice that there's some kind of massive burning or minting that could be caused by a bug it can just automatically pause the contract and this refers to the the provisions that that augie was referring to before deployment right you should

have some functions which are only accessible by the owner or governance which can sort of pause the the functions calling the functions give you some time to figure out what happened and maybe uh take an action plan yeah i mean also i think uh an unknown monitor is probably from open zeppelin also i'm not sure which one you use but uh i think it's called defender and you can just monitor people function and see or or um yeah i mean i guess there is no end to what you can actually monitor in your instance most of the smart contracts are public

the question is how do you react and as the best explained i think that's the most important part to think about it beforehand well if you do have a kill switch or if your smart contract is possible does that mean that you increase centralization or or do you think that possibility could be considered as a not so centralized method i think it's definitely more centralized if you have those kind of functions but if you give the power to a multi-sig wallet where you have like

i don't know m out of n users of that multisig can trigger the action then it again becomes less centralized because there's not just one person who can who can perform the action okay so that's good oh well talking about again centralization and efficiency again from nana one final question upgradeability bane or boon i don't know what vayner boone means but i assume it means good or bad so should smart contracts be upgradable for example dfinity blockchain you can

upgrade smart contracts or there is a possibility i guess you know in ethereum it's it's also kind of possible through pointers more or less so upgrading your data i think the question is sim or i think that the trade-off is similar to what we just discussed with the kill switch or like it introduces some form of centralization um possibly even bigger right depending on whether you can control how you can upgrade your smart contracts if you can upgrade in an arbitrary way and you know there's a small number of people who can trigger that that that that can uh you know be i have an even greater effect than just the kill switch this just stops the so actually one interesting thing i

think we had dfinity right now is we're trying to come up with or we will provide uh smart contract writers with a library for a dow that kind of controls the smart contract including the the upgrade the upgrade process so um you know you can have a decentralized process in a way and that that's kind of similar to you know many other decent private solutions that allow to do upgrades but i think like i said i think it's a you know obviously it can be very useful um depending i think also in the context of things like in web 3 where you're trying to build bigger applications um on the blockchain you know it's i think if you move if you manage to

move that direction i don't think it's really um it's really practical to stay with with just immutable contracts and things that will never change so i think if the implications do become more complex we will see more of uh we'll go more than direction of upgrades i think thank you more comments on upgradability or should we move on to the next question i just just had one thing which is like uh traditionally everyone believes like a contract is immutable so it comes often as a shock to newcomers to this space to hear that contracts can actually change and indeed like i think traditionally on ethereum

this was not something that was thought about in the beginning but then people found ways around it and if you're thinking when you talk about a contract right that should not change once it's deployed right so if people would sort of like put their trust into this they would put their trust in at the moment when they deposit their funds if it becomes if it changes then maybe they don't trust it anymore so i am a big fan of immutable but i do see the big need of upgradeability but for you it's bane or maybe boon whatever whatever it is whichever it is all right thank you very much um so that

question is answered all right so alessandro is asking so i didn't quite understand are you testing only smart contracts code before deployment on the blockchain or also smart contracts that have already been deployed on the blockchain so it's testing before or after deployment kilo we haven't heard you in a while actually i wanted to see so we were mainly looking at testing uh before deployment so especially if you have immutable contracts um testing after uh uh at least i don't see really a use case where when you deployed an immutable contract that you

tested afterwards maybe there are use cases i'm not aware of but um so so in this paper we we assume the testing happens before um and and and rigorous testing should happen before you deploy it from our perspective because after you deploy it the testing is basically a big bouncy and you know if it's not good your friends disappear that's the that's the testing that's yeah one could say actually a bounty would be um yeah would be testing after deployment yeah um thank you for that question from rm not depending on third party libraries does that include more established

libraries example open zeppelin so before sebastian you were saying that you shouldn't trust anything so does that mean you shouldn't trust those libraries that have been tried and true or where do you think is the limit there oh so i was referring to something slightly different um like if you're talking about libraries in the sense of something that you can import while you're developing and you just like compile it together like the open zeppelin libraries that is fine right like as long as that code is audited and it's safe like i think open zeppelin libraries are pretty safe i was referring to actually things which

are deployed and you're just referring to them using an address like you're pointing to something which is deployed it could be just a proxy which is pointing to some other logic that can be upgraded so at that point you cannot really trust that address which you're pointing because it might even change its behavior so you should always verify what you're getting back from that deployed contract because like this composability uh which i was referring to happens after deploying like at runtime right not while you're deploying the while you're developing the smart contracts so i'll just add one consideration there so with

dependencies i think one thing to consider are also reproducibility of builds so if you do have dependencies and they have to be audited like what sebastian said but you actually also have to make sure that you keep them available for as long as your smart contract lives at least the current version if you want people to be able to reproduce your builds your contracts and actually make sure that what's deployed it actually corresponds to the source code and they also think the paper actually gives us best practices that you you should use them uh for your before your builds

um maybe that was not clear in the presentation would say also um i mean it's true that those libraries have been audited have been used and used and so on but it's sometimes we we have already changed security we have already found some some you know some issues in in those libraries and of course as soon as you find it you submit it to open zipline and they have this very quick you know um response to it um and now also what what makes it so secure right so maybe when it just comes out wait a little bit but if it's been around for some years probably you know a lot of auditors have been looking at it um but it's always a big question i mean in terms of scoping

audits um whether we have to other you know the libraries or the dependencies and so on so it's always a kind of tricky but sometimes it's actually worth it to um to actually go that far so thank you very much rm for you for your question um sorry sometimes i'm looking down but my dog is being all crazy next to me since from ds are you evaluating to integrate confidential computing technology in smart contracts to implement security level so it's mentioned in the paper it's not a we don't dive very deep into it but

one of the design guidelines is some privacy and for privacy as you know like most of the smart contracts are public and this might might be a problem because you you might handle sensitive data and you want to protect protective data and there are ideas out there so there are these zero knowledge proof protocols trusted execution environments and they they help with privacy um but i think there is still a lot to do in the in the future there so it's touched upon um and i think it's a very interesting i didn't quite understand what was meant

by security levels so if this is like the standard uh security level framework or something like that so if yeah whoever asked that if they can if they can explain bit then you can answer that part too yeah so diaz if you want to re-uh explain your question a bit more and give a bit more details about what what you'd like us to answer exactly and then we can come back to it very soon actually because there's only one more question after that um feel free to ask more questions we have 11 minutes left and one question left i also have my questions but it's always better if it comes from from the audience and it's things that actually

interests you so from evo hello eva once in production is there any solution or tool to monitor the security issues so i think this is what you mentioned sebastian and also open zeppelin has their solution um and so then you can potentially trigger a possibility artillery or even saying a hard fork could be the solution i mean it was in the past but i guess it's not the preferred solution i actually don't see do you see a possibility for a hack being big enough to trigger a hard fork that's that seems very

hack yeah was bigger than yeah yeah but i mean at the time it wasn't that much compared to what we have now i mean in the big d5 protocols we have north of 10 billions easy and yeah for a heck of the same size we would never go back in time right so it's kind of kind of funny to think what would be the threshold now to trigger that i don't think it's gonna happen anymore yeah there's the the market cap for some blockchains is too high i think at the time probably it was way lower so all right so thank you eve for your question is there more that we want to

say on monitoring all right um so i had a question for you tilo so in the paper you mentioned that access control is often a vector of and you mentioned role based access control rbac and attribute based access control abac can you tell us a bit about these two models and how we can choose what's best for our web 3 application sure um i mean it's a protection mechanism in the end so role-based access control means that you define

roles and these roles have then permissions assigned to them so that's more abstract what role base access control tries to do and you assign to each user you assign rows so for example a managing role in smart contracts i guess these roles are different but you would give a manager role or engineering role and then each of these roads has a set of permission assigned like they can execute certain functions and this was used since several decades now as a as a very good framework because it has a very it's very easy to analyze and to audit because you can look at these roads and say yeah who who is assigned to which roads and it doesn't make sense and then there's the more refined version which

abec the attribute based and there you don't really give rows anymore but you look at the user attributes and what and the attributes what the user wants to access for example a user wants to access a database at five in the morning then the user should be for example an administrator or should have should come from a certain location and you can use you can define then rules and say okay if this user um logs in for example from switzerland he's allowed to access these accounts so it's a much more refined and it's also more difficult than to to audit because these roots

uh very complicated and they are similar like firewall routes maybe like from firewall routes you know this this kind of schema from a usability perspective of course attribute based is is more flexible and role based is usually less flexible but easier to to look at i'm not sure what the autism people say to that if it makes makes it easier to audit a a smart contract uh with abec or with rbac and and if you see a trend going in some direction what do you think sebastian i do see there's a big trend um which is being used right now and that

is using nfts as a way to gain access to certain airdrops or communities even like discord channels and so on right so uh people are using something that they have in their wallet right not a password not a not a um whatever token well it's a token it's sort of different right so i i don't know like i think this would fall into sort of um attribute based access control because there's no centralized database where like it says like okay

this user has this token right it's it's just something that is being checked when the user tries to call a function of the smart contract so this is being used a lot right now and i really like the fact that we're switching from passwords to something else and we have one more question in the q a from alfie are there any efforts being undertaken toward effectively achieving a level of confidentiality in an otherwise public i think there's actually on go ahead and

select it yeah i know just just wanted to say like uh tilo touched upon that with um mentioning zero knowledge proofs uh so there are like um a few up and coming blockchains that are using that but maybe not necessarily for privacy one one chain that i have heard about is the secret network which actually uses tes and their claim is that everything is basically confidential so you cannot see amounts in someone's wallet or the amounts in transactions which is is pretty good but the dependence on

such hardware makes it uh slightly prohibitive for it to be to reach a super high level of decentralization as ethereum or dfinity or other blockchains right which are not do do not require such specialized hardware well actually one of the things that we are considering a dfinity and we are planning to transport our trusted execution environments so that where the nodes running the um running the code would basically have to run it so we would have evidence that they're running it inside of such an environment um of course this does push you know the thrust somewhat

to the hardware manufacturer it would be one step towards providing confidentiality i guess both so with a trusted execution environment um you could get the confidentiality of both the code and the the data um whereas guess with zero knowledge proofs you would mostly go in the direction of data but of course it's you have to well i guess normally there's some kind of trusted setup with zero knowledge proofs you know i think that the thrust is not shifted to the hardware manufacturer i guess for serial knowledge i mean i'm not an expert there but i could imagine it takes more computational power or you

so you do the transaction if you want to do it privately um it's it's not as simple anymore as as if you do it uh openly and these zero knowledge proofs usually add some some computation and if your computation costs gas maybe people are less willing to pay for this private right i guess that's also the reason why dfinity is going with trusted execution rhymes because you can have basically regular programs and they will execute almost as fast as as they do without one whereas with zero knowledge proofs the prices are or the computational cost is very high and yeah the privacy aspect is something

that that they touch upon in the section three design guidelines you can see there's a section on privacy talking about trusted trusted execution environments and dkp's so there's a there's a bit to read in there i really invite all of you you know attendees to to read that paper it reads really well very clear and it really gives a lot of the info we discussed today and even more um so we have only two minutes uh to until the end of that panel so what i'd like to do maybe is to just ask each of you a closing statement you know something that people should remember something that you know maybe something actionable or

something that developers can use or should remember as they leave this panel um who wants to start drum roll maybe um i i can say something um as i'm gonna remove that question so um as chain security we there's a lot of demand i mean sebastian at constant i'm sure you see the same thing there is so much demand for smart contract audits and all the auditors are completely backed up um they don't have availability for month and month so as you are thinking about your life cycle there um

think about the audit as the last stage of that cycle and plan it as you're planning the rest of your development so that you get a chance to have a nod it's when when you're done because then people come to us and they want to know another next week but we're available next year and that doesn't matter that doesn't help so this this would be my advice for all developers out there if you're thinking of developing something think about getting booking your smart contract other right away actually that's a good tip i think we even mentioned it that you should plan in advance to do your audits and i think i i can add to that and i i would for me like since i'm more theoretical

guy i would be happy that in the future like more formal verification uh is possible for smart contracts so usually formula verification takes a long time and smart contracts are limited in in the development lifecycle when they are deployed but i hope like maybe static analyzers or other formalization tools are getting more and more available and they are already available and i hope in the future that's that's going to increase and help one thing that i wanted to say was as opposed to like i know this space is is really young and it moves fast but as opposed to web 2 where the model is move

fast and break things here you should like try to move carefully maybe slowly and grow things right and build it like uh carefully because any mistake could lead to massive losses of funds so like the dow hack was just two lines of code switched around and most hacks are just one line of code right so yeah move slower yeah um i think from my side the actionable thing to do with read the paper but otherwise i agree with everything that was said i think you know they're the standard methodologies do

apply to smart contracts but um i think the challenges are even larger just because the extremely hostile um complicated and adversarial environment that they operate thank you very much so that's all the time we have for today thank you so much for the attendees and also to the awesome panelists and the writers of that paper which is really good which was really missing in the space so i hope now that we're going to see better quality of code in the future d5 protocols that are being developed thanks a lot and um see you soon at the next panel bye

thank you thank you bye bye