Writing Robust Code by Bryant Eisenbach & Kirill Pimenov (Devcon4)

so we are gonna give you a little bit of an overview of what good projects do in the space in order to plan and ensure their success their success so let's address the elf in the room everyone says smart contracts are insecure there doesn't seem to be anything changing about it like like what can be done is it just something we have to live with or is it something that can be fixed so I think it is possible the design robust and secure software and I think that this comic actually points it out a little bit unintentionally so we built we trust machines we trust airplanes elevators all sorts of machines that are actually run by software the safety critical parts are run by software every day and those those machines are designed such that there's there's very little things that go wrong that you hear about I mean you might hear about an airplane crash once a year you imagine them out of time that airplanes actually fly around the globe that's pretty amazing so we have to ask ourselves like how how do we get that kind of security into our applications no I just want to go down on this nope I [Music] have to do it manually yeah so we have to we have to learn like more from these industries how they make things so good so most of what I what I'd like to talk about is just how not to take shortcuts how to plan ahead how to make sure that you you have everything all your ducks in a row so so the secret is is that the weakest link and designing software is actually humans it's all of you guys so you have to figure out how to make yourselves mitigate against any risks so the only the best way to do that is by having lots of layers of testing not just single types of testing have really good documentation so other people can understand what you're trying to do and get multiple people to review your code tests and assumptions and a regular basis not just during an audit so testing is the only true way to actually detect inker behavior in software I think a good quote is that like you know software - test is just paperwork basically at the end of day so multiple layers of testing ensure that you don't have any single one critical vulnerability that goes all the way through and I like to illustrate that with blocka Swiss cheese so the bigger the box Swiss cheese you have the less likely you have that a little bubble ends up making its way all the way through so if you have a big big huge chunk of Swiss cheese you can you can never see through it but if you have one thin slice representing one layer of testing or just one person writing the thing you're very likely to have lots of holes so documentation testing all helps help you get through that and again hitting on security audits a lot of people like to say security audits with gold standard for security and in space and that's just plain wrong you have to have a lot done before you get to that point or else you're never going to be successful that process you're gonna have a lot of you're gonna have a lot of outcomes from the audit you're gonna have to do a lot to fix all the outcomes that the auditors brought up and since you guys are innovating in the space so often you're going to have to redo this audit over and over again pay a lot of money to get that into there it's way more cost-effective for you to build into in this process into how you guys approach smart contract development and and you you make security auditing one small part of how you ensure the overall development process is secure so I from aerospace we kind of had this like ancient view of how things get done and we used to use this be model of software development it's like way before agile and waterfall and all these other buzzwords but I actually kind of like it because it has this neat little iterative process as you go kind of moving forward so you end up always at a place you want to end up but you you always are looking back and make sure you're solid on your foundation before you move next to the next step so the first part is just having a really good design spec understanding with the customers or or you know the business leaders of your company or anyone who has like the solid idea like what it is you're actually doing and you'll always be constantly coming back to this and making sure that you have very solid firm idea and grasp on what you're actually doing if you don't have this you end up in a position where you're constantly iterating and you you you sort of lose focus of actually what you were trying to do in the first place and if you don't have that real focus it's really hard to make a determination of is this decision I'm making the right decision am I going in the right direction so from there you sort of take your design spec and it should be a the design spec itself should be like human readable something you can show somebody else who's non-technical an agent understand and get your project it's kind of like a white paper almost so you take that and the next step you go is the architecture so that is the you know the really solid underpinnings of your project you start to design like what kinds of contracts am I gonna have how it's gonna interact with all the other components in my application and how you know what names I want to give everything and and that really gives you a solid foundation for the next step which is designing requirements so you can go you know ray off the deep end with this like we did in aerospace it took us months to actually get requirement specs through the door or you can just use this as a process to say like hey what are the technical things we need to do in each one of our pieces to make sure they're like to the degree we want and you can write this in like a comet field at the top of each smart contract however you want to keep track of it just make it clear and make it easy to understand like how that links back to your idea so you have a clear view of traceability all throughout your application so from there once you have your requirements you're at the bottom of this V cycle here you start the code do you just do the thing you have all this solid underpinning of understanding of what well you're actually building behind you and you can iterate on that as you discover new things in code and you you know identify things you want to change about your design but because you have this solid traceability down the left side of the V you always understand like well I just want to update this one thing and then you can analyze the change impact that has you could say oh well this little piece gets changed and I update this other piece everything's fine the really cool thing is that because you've gotten requirements and architecture down on paper you know what you're calling everything you know what everything's supposed to do you can do testing in parallel you can you can get a whole separate team on board and have them work in parallel on you know test different Velma processes and have them start writing tests that link to each requirements everything you want to do so you can kind of save some time and effort from that by having two teams working in parallel instead of waiting for the code to be done before you write tests usually the tests come out better when you don't have the tester the person designing the verification going back to the code to say like hey what does this do it actually makes your documentation more improved because they're looking at that to design the tests instead of your code and you make sure you build it like a stronger project out of the gate so the really cool thing is that as you go up the V on the right hand side this is how you know you're getting closer and closer to done you can actually design a schedule around this so so once you're at that bottom point you're doing code and testing you sort of iterate in this very short loop between requirements code and testing updating anything on the left-hand side as needed and until you finish testing you get all greens on your huge test suite from there you move integration you kind of integrate with the rest of the application whether it be you know the front end or any sort of Damons you guys written or networks or you know plows for frame Ericsson and anything you guys imagine that kind of exists outside of the hypercritical design you're doing with the smart contracts and this works for anything not even just smart contracts but hypercritical smart contracts are hyper critical so that's why I point them out once you're at that point and you may have some iteration in this cycle tool back to your architecture because you made some fundamental misunderstandings of how the tech would work you're basically done at this point you're ready to go to demo and test and release so you create your demo you you probably want to show off on a test and then start bumping it up as you grow more and more confident under what what you've made until you're you know pushing on the main to main net and starting to work with real user fonts so the important part you got a cert small here you got to grow that as you grow confidence and make sure that you're able to cover any losses that happen so like the recent spank chain hack I actually like the pointed I was a really cool thing that they didn't over exceed their ability to pay for any any issues that arise I don't think they planned for it but I think now that they see that they understand that like you know this is all new technology bad things gonna happen but as long as I keep that expectation below my risk level I'll be fine so once you get through that and everything goes well on your demos and everything's happy you're sort of in this release cycle and now you let it that sit out there in the world and you just you know gather use your feedback and you may be working on the next iteration of the design but you're also maintaining that code watching things out there in the world and understanding you know what you want to do next and how you're gonna support what you did and it's very important to sports what you did I think in this space there's this idea that you know once you release about the main that it's all mutable you can't change in any way there's nothing I can do about it after that point that's false there are things you can do in order to respond to react to events it may not be with that smart contract itself but having an accurate plan beforehand of what you're going to do I following any sort of hack like you know build a whole new token contract and poured all the token balances over just have a really good plan of how you're gonna handle most situation that you think will arise and then you get Lambos of course so a little bit requirements so this this was pain for me for like five years but there's a lot of truth in this defining good requirements is really an art and it helps your testers your your implementers your coders everyone to understand what the process is very succinctly and very well so there's five aspects of good requirements they are smart quote unquote so specific means each requirement decides a very specific logical functionality and it should be unique to what is describing measurable means that it should be quantitatively measurable ie the you know the the token shall be transferable only if the balance meets or exceeds this amount blah blah blah they should be attainable I describe functionality that the software can actually implement not something like the economics of the platform or some sort of loose UX experience that's desired it should be really tightly coupled to something that's achievable and practice relevant kind of describes that same thing not describing extraneous functionality is very it's all very core to the application and isn't kind of outside the realm of what you can do with the software and time-bound is last it basically describes things that are like very specific in time they shouldn't be like oh well eventually it's going to do this or you know at some time it should be like X seconds or Y seconds or weeks or months or whatever you should have very tight requirements around time to make it easier to understand so traceability is another thing I think a lot of people haven't had a lot of exposure to so the idea is is if you go through this process and yeah it's a little bit more upfront work you can actually use some really cool things to get a really good picture of whether or not you're done and that's pretty cool so if you have the requirements you kind of link them to these numbers I had an idea to you know like hatch the requirement tax to have a unique ID hash so you can tell when things change you can do it any way you want you basically link your requirement to you know a specific identifier you might use like a like a NAT spec comment link in your code be like hey this implements requirement number one or something like that and the same thing in your test case you you know use Nats textile comments in your test cases and then once you have all these things in place we can build tools that link it all together and you can get a really full picture of your entire application linking all the way back to the specification the human readable thing that you guys all agreed on before you started the project by using tools like this and you can you can identify holes in the approach you can look for places that things weren't implemented correctly or missing and make sure that you guys are like truly done with your application before you're ready for the next step if you bring this to an auditor your honor it would be like half the cost no joke when I was shopping around for audits all the auditors were really prai's that I was doing this in my application okay so I'm Creole and I will be more pragmatic part of this talk pragmatic enough that you will feel like a motivational speaker not some sort of the engineer and this first thing I'm going to talk to you about is test-driven development because everyone knows that you probably should be doing the ads no one understands why like I was like I asked and people to earn because I need 100% coverage or something like that the actual answer is that your tests a code and you need to verify that your test code is working as you expect them to do and you I'm not suggesting you writing tests for your tests right so the only way you verify that you test check something and it's not like one equals one in the end is that you write tests first and they fail and then they fail your ad code and then they pass and that means that your tests are actually checking the behavior which you just implemented in your program also I promise to be problematic no one is going to do that all the time this is like true of rust where engineering no one is writing tests first so what I'm suggesting for the existing systems systems weren't written right now by you and you have to write tests for it just try to break your test by modifying your code just introduce miles sounds small error and make sure you test go read if it happens yeah this test is useful this test is testing what it's supposed to and there is no subtool syntactic mistakes in there another like being more to the solidity testing i recommend testing solidity in javascript because then small syntactic misunderstandings between you in solidity won't get in a place so you basically won't repeat the same error on your testing side of the code oh yeah and actually the major truth is that you are not designing just the system which is deployed on chain or like the web app you are deploying to accompany it but the system includes you and it includes the way you deliver things and so on and this is the info front blockchain gravy really wonderful project which accumulates the post-mortems of failed and hacked blockchain related projects and as you see how other projects haven't been hacked through the unchain things at all it is all poor operational security it's either your servers hacked or your cloud credentials hijacked or your keys are compromised or something at that and good operational security is a part of a security of a system you delivering you know this this is the thing like you all know what needs to be done you're just not doing that because it requires you to change your habits to the second factor just get a hardware token if it is too expensive for you just get the Kryptonite on your smartphone it is almost as good for zero price hardware wallets air-gapped sonic devices yes please please do that website based wallets bad idea never just if it is a production-related key never to type it in any website this is like instant compromise just assume that we've seen even the best online wallets being compromised by really really expensive attacks you are not protected from that just use something else real keys to conduct damage like to your investors or to someone mmm use the test net all the time like your production keys stay safe if they are not on the screen when someone else is looking that's the rule just you wouldn't believe how frequently I see compromises from these like probably everything ends up fine and you investors a trust for few guys but why push your luck and just don't ever forget that many mass uses the same key and every network yes general hygiene like do it like you know you not need to use password manager you don't need to reuse passwords still like everyone has them let's just make push and change it full disk encryption just is a must you don't want to have your project compromised just because you forgot your laptop on the train firewalls like everyone knows the list just figure out the way you can incorporate those security habits in your day-to-day life I promise you I will be motivational speaker yeah you know what needs to be done I know can do it please do it another thing sit down with your DevOps or operations engineers and come up with a list of security improvements there they probably also know what needs to be done but they also overload it with day to day tasks so they never improved your security but we need know what needs to be done so please go in and figure out do you need passwords for SSH properly you don't change that are you build machines are secure are your secrets for builds are protected and they won't leak to any third party pull request offer to your repository that's a surprisingly frequent thing I see well yeah if easier MongoDB port is closed from the external world that's like the most frequent source of hacks in the last year yeah this thing problems happen you just need to be able to recover from it and have a back-up plan the thing is that when hits the fan you will be under stress and you want to be able to react in time the smartest way so the only thing I can recommend is come up with a recovery plan before things happen have a really it will be stupid it will be obvious checklist you will feel like am I in the five grade again I'm writing down obvious things trust me you will really thank you later when it times come to unpack that checklist and go step by step and ensure who is responsible for what what is the effect that the parts of your system do you need to notify your partners what are the channel for those notifications and so on obvious things have it have it ready it will save you day yeah yes so I think just like all in summary you guys are all really smart people just write down more things on paper share them with each other that'll make your things all the more secure that all of these recommendations involve writing things down thanks to those folks we got 10 minutes for questions just raise your hand we got this down hey so essentially first slide is the return of waterfall a little bit at least it feels like that and I get it for airspace if you're building rockets and planes where people can die or people can lose all of their money for sure you shouldn't throw on the wall and see what sticks or what's what gets hacked but in reality it's it's also a little bit more nuanced right it's not a plane or something super agile where you can can afford to make mistakes so I'd like to know how do you how do you know which mindset to apply because in that first example if the first time users actually see this is at the very top right of the V you potentially have lost a lot of time where users could have told you what's not working that is a great point I think like just getting more user feedback in terms of the cycles so that's about doing smaller demos trying to figure out things ahead of time like getting practical feedback about the market right that you're intending and operate in I think so in response to the V thing like like nobody said you couldn't use V and agile at waterfall and agile together like everyone's like oh man that's that's the thing you can't do but like you can like I chose like kind of a short cycle that you're you're always constantly building towards a goal and you know waterfall or V is is like the long-term push like the idea from start to finish you know we're building protocols that like once you build you probably won't want to spend you know the ninety percent of the time you spent testing and do that over again for one small change so it like it really pays to get things right ahead of time so just building that into your process I I think is really helpful and you can still use agile for everyday you know everyday use that that keeps people moving in a specific direction this is more project management stuff to make sure that like when you're at the end of the process you know you cross your eyes not your T's and all the technical things but you're you're totally right you have to have the feature set identified and validated by the market you're ten operated can also I meet a little bit because I believe what waterfall typically emits like they don't do that is they never get the feedback loop on pre-production stage of things but it can be done and it works perfectly like you can show like I don't know sketches of your interface to the end users and get feedbacks or something like that and this is what all agile is about we find your hypothesis earlier so if you can incorporate those feedback loops in whatever is large planning really complicated process the more agile you would yet even if it looks a little bit like waterfall yeah we understand that it has stages and they go one after another when when you're at the lambo stage that's that's the end release that's every what everyone's been waiting for that's when real people's money enters the equation so you know I will absolutely stay on the side of you know handling my clients money and my users money as effectively as possible so this is the best way I know to do that but again absolutely you have to get that feedback along the way or you're building the wrong thing you're not doing the right thing and to begin with yes thank you for the presentation guys we talked about TDD and testing and I wanted to know where would you recommend testing with JavaScript their solidity is it more like you like like he was saying just never use solidity tests they're I think they're a terrible idea you're trying to use the thing you're using to release as you know like real live code and developing in that same framework which was never designed to actually do testing there meant there is some caveats to that sometimes there's just something that's not possible like a library it's really hard to test the library without like some sort of you know infrastructure around that but use that and then do it in JavaScript test where it has a more more feature full test testing infrastructure or use Python I hope people writing tests in solidity where you have a team of people working on a contract and you right like you know people are focusing on a function and you want to pass it so well you can write this without that it's okay thank you there's always nuance yeah couple behind I was hoping could you clarify or the tools around traceability or their repos that are open-source you think apples I'm working on some particular tools I have like a BIM plug-in that like will help you like what I was talking about with the hashing thing so that's really useful once you very greed upon your list of requirements you know they should never change the hash should never change and if you use that hash and like you have a really big codebase and you start putting like you know a trek hash this does blah blah blah a part of that requirement and and then like further down the line you've sort of forgotten everything you've ever done behind the scenes and someone's like oh well this requirement is wrong we validated with the market those are bad assumption we need to change these features now you're like okay what do I have to go update super easy I now go change of the hash and see where all the places where the old hash were in place that now are mismatched with the new hash pretty cool so I'm working on a tool like that but there's no real tool tool set in the market so if you're interested to come talk to me hey guys thanks I'm a bit curious you've provided some very awesome technical points one thing that I'm very curious about is how do you actually develop a kind of company culture of appreciating the importance of these sorts of things both from like the technical standpoint and perhaps the non-technical people in your team like basic thing I like to encourage and like I see really helpful in encouraging that is use robots as as long as you can like no one like when you go in into the pull request and you said no this is just not testing this requirement or something like that you're not like you enforcing it by hand and people start arguing with you but no one will ever argue with robot because that's sort of stupid and this is how you basically put the baseline on any culture of a culture of tests on the culture of code style and so on just use the robots to the like maximum extent after that probably just talking with people like explaining why you're doing that in before will help like they will not they will agree and then we will feel bad if we will try to like push you away from your various and I think at the end of the day it's it's either gonna come from a cultural shift before a problem happens or after so I think a lot of people in the space look at the problems that happen and think like oh those people were stupid they didn't think ahead of time no they just weren't aware of it they weren't thinking along those lines and they've bathed drastically changed how they've approached the problem and we should learn from them because you're gonna repeat the same mistakes if you don't take that seriously