 So we are going to 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 to 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 the amount 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, that didn't work. I have to do it manually Yeah, so we have to we have to learn like more from these industries how how they make things so good so Most of what I would what I'd like to talk about is just how not to take shortcuts how to plan ahead how to make sure that You have everything All your ducks in a row so So the secret is is that the weakest link in 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 detract incorrect behavior in software I Think a good quote is that like you know Software minus test is just paperwork basically at the end 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 Block of Swiss cheese, so the bigger the block of 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 are the gold standard for security in a 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 gonna be successful that process. You're gonna have a lot of You're gonna have a lot of Outcomes from the audit and 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 have this like ancient view of how things get done And we used to use this V model of software developments like way before agile 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 making 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 a 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 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 and they should 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 going to have how it's going to 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 comment 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 You just do the thing You have all this solid underpinning of understanding of what what 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 can 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 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 development 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 test 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 a very short loop between requirements code and testing Updivating 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 at the front end or any sort of daemons You guys are in or networks or you know placer frame Eric's any 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 not even just smart contracts, but Hypercritical smart contracts are hypercritical. So that's why I point them out Once you're at that point and you may have some iteration in this cycle to go 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 the test net 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 tech main net and Starting to work with real user funds So this is the important part you got to start small here You got to grow that as you grow confidence and make sure that you're able to cover any losses that happened So like the recent spank chain hack. I actually like to point it out It 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 plan for it But I think now that they see that they understand that like you know This is all new technology that things can 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 sit out there in the world And you just you know gather user 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 going to support what you did and it's very important to support what you did I think in the space there's this idea that you know once you release it out the main net It's all immutable. You can't change it anyway. 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 following any sort of hack like You know build a whole new token contract and put all the token balances over just have a really good plan of how you're going to Handle most situations that you think will arise And then you get Lambos of course So a little bit of our requirements, so This this was pain for me for like five years, but there's 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 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 that 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. I either you know the the token shall be transferable only if the balance means 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 in practice Relevant kind of describes that same thing Not describing strain is functionality is very it's all very quarterly application and isn't kind of outside the realm of what you can Do with the software? And time bound is the 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 hash the requirement to actually 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 to link in your code be like hey This implements requirement number one or something like that and same thing in your test case You know use NAT spec style 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 agree it 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 are 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 audit would be like half the cost no joke When I was shopping around for audits all the auditors were really surprised that I was doing this in my application Okay, so I'm Kirill and I will be more pragmatic part of this talk Pragmatic enough that you will feel like I'm 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 that No one understands why because like I ask and people to 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 test, 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 you add code and then they pass and that means that your tests are actually checking the behavior which you just implement into your program Also, I promise to be problematic. No one is going to do that all the time This is like true of first-ware 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 smiles or some small error and make sure your tests go red if it happens Yeah, this test is useful. This test is testing what it's supposed to and there is no subtle syntactic mistakes in there Another like being more to the solidity testing I recommend testing her solidity in JavaScript because then small Syntactic misunderstandings between you and solidity won't get in the place So you basically want to repeat the same error on your testing side of the code. Oh Yeah, and The actually the major truth is that you are not designing just the system which is deployed on chain or like the web app You're deploying to a campanite, but the system includes you and it includes the Way you deliver things and so on and this is the info from blockchain graveyard really wonderful project which accumulates the postmortems of failed and hacked Blockchain related projects and as you see half of the projects haven't been hacked through their own chain 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 like that and Good operational security is a part of a security of a system you're 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 gap signing devices Yes, please please do that Website-based wallets bad idea never just if it is a production related key never 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 demos like to your investors or to someone 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 this like Probably everything ends up fine and you investors are trustworthy guys But why push your luck and just don't ever forget that metamask uses the same key and every network yes General hygiene like do it like you know, you need to use password manager You don't need to reuse passwords still like everyone has them. It's just make a push and change it Full disc 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 least Just figure out the way you can incorporate those security habits and your day-to-day life. I Promise you I will be motivational speaker. Yeah, you know what needs to be done. I know you 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're also Overloaded with a day-to-day tasks, so they never improved your security, but they need know what needs to be done So please go in and figure out. Do you need passwords for SSH? Probably 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 requests? Offer to your repository. That's a surprisingly frequent thing. I see And yeah, if is your MongoDB port is closed from the external world that's like the most frequent source of hacks in the last year I believe Yeah this thing Problems happen You just need to be able to recover from it and have a backup plan The thing is that when shit hits the fan you will be under stress And you won't be able to react and 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 5th 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 all those things have it have it ready? It will save you day Yeah, yeah, so I think just like all in summary you guys are all really smarter 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 a lot folks. We got 10 minutes for questions Just raise your hand Hey, so essentially the first slide is the return of waterfall a little bit At least it feels like that and 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 Shit 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 in 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 that's a great point I think like just getting more user feedback in terms of the cycle 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 a V and agile or waterfall and agile together like Everyone's like oh man, that's that's a thing you can't do But like you can like agile is like kind of a short cycle that you're you're always constantly building towards a goal and You know waterfall or V 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 90% 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 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 nod 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 intending to operate in Can I also admit a little bit because I believe what waterfall typically amidst 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 you 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 Keep on hypothesis earlier. So if you can incorporate those feedback loops in whatever is large planning really Complicated process the more agile you will get even if it looks a little bit like lot waterfall Yeah, we understand that it has stages and they go one after another when you 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 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 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 versus solidity is it more like you Like like you was saying just never use solidity tests there. I think they're a terrible idea You're trying to use the thing you're using to release as as you know, like real live code And developing that same framework, which was never designed to actually do testing There 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 tests where it has a more more featureful tests Testing infrastructure or use Python Yeah, I heard people are writing tests in solidity where you have a team of people working on a contract and you want to write like, you know people are focusing on a function and you want to pass it over It's okay. Thank you. There's always new ones. Yeah couple I was hoping could you clarify or are the tools around traceability or their repos that are open source you think have I'm working on some particular tools. I have like a Vim plugin that like will help you like What I was talking about with the hashing thing. So that's really useful Once you've agreed 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 code base And you start putting like, you know at rec 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 is a 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 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. There's no real tool tool set in the market. So if you're interested come talk to me Hey guys, thanks I'm a bit curious. You've you've provide 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 in the like I see really Helpful in encouraging that is use robots as long as you can like no one like when you go in and to the pull request And you said no, this is just not testing this requirement or something like that You're not like you're 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 values 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 this space look at the problems that happen and think like all 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 they've 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