Developing secure protocols: The Power of simplicity and good design. by Valentin Quelquejay

Transcript

hi hi everyone um thank you very much I'm super happy to be here in Dubai and talk about something that I feel is uh very important which is Simplicity I think this is something that we don't uh talk about enough so I propose that we just start by maybe saying what simplest is so I just copy pasted the definition from the Cambridge Dictionary so what's Simplicity well it's the fact that something is easy to understand or do so now you might actually ask yourself the question why the heck this talk uh well so Simplicity is actually critical for building uh robust systems that's something we've known for a long

time and I feel that sometime there is a misconception that um Cutting Edge engineering uh is incompatible with simplicity and actually that's quite the opposite I feel so uh the beauty of softw engineering is actually to uh solve complex problem with Simple Solutions not the opposite you don't believe it well maybe you actually believe this guy uh which said that Simplicity is the ultimate sophistication I think that's really true so now why simplis in blockchain engineering well uh simplifying means less I mean I mean decreasing

engineering time decreasing cost decreasing cognitive Lads both for developers and people that are going to review your codes um and thus decreasing the likelihood of bug and increasing security which is of course extremely important in blockchain protocols as Einstein said keep it simple as simple as possible but not simpler so if you had to just remember one sentence from this talk it would be stop over engineering that's it but I guess we have to extend a bit so let's see where uh does complexity come

from well there I just put a bunch of IDs it's definitely not extensive that I grouped in a bunch of categories uh so it can come from the mindset so the way you approach your protocol right the design uh of course the development practices and then external factors such as like inter interaction with like other systems um something really interesting that we observe in pretty much all software uh that have been developed is that the complexity naturally increases over time so we really have to tackle this problem early if you look at uh so here I just pled like the number of lines of codes um in Sal C so the

solidity compiler and I think we can clearly see that like it follows an exponential Trend so actually it's it it goes in line with like the fact that as software age they tend to be more complex there are like several types of complexity so there is uh actually essential complexity which is the complexity that you can't avoid because this is what uh actually makes like brings value to your customer and your product U but at the same time there is also other type of complexity that is detrimental to your product and this is the complexity that we want to avoid so you have like accidental complexity and

inci incidental complexity and those kind of complexity actually arise from your design decisions and this is what we want to drastically reduce something interesting that of course uh complexity is observed throughout the whole engineering chain so from design to execution and we should try to tackle it at basically every stage I would like to particularly focus on ux because as an engineer myself I know that sometimes ux is really something we actually Overlook but the truth is that when you're actually building um customer facing

products ux is extremely important so for instance I've been lately reviewing uh some wallets and um it turns that like if you're building a wallet but your customers um don't have access to all the information that they need for instance when they're signing a transaction it's a clear red flag and this is often time a ux problem so be mindful of your ux and complexity is about Loop because why because when it increases it's harder to write good specs it becomes harder to write good documentation same for the codes often

time it comes with like more interactions more dependencies and then the complexity increases even more so we really have to tackle it early to break the loop now if we want to optimize something we have to have like kis right like metrics to quantify it it turns out that like it's quite hard to um quantify complexity so we have a bunch of objective metrics that we can use so number of like the code or like the catic code complexity which is something that's often used in the software industry so it's like the number of uh linearly independent paths in your in your program but there are also

subjective metrics and I feel these subjective metrics are often like even more important so basically if you're are building something but you can't explain the design easily to someone else and it actually happened to me so I know it probably means that like your design is not simple enough or you don't fully understand it um so how to simplify well again uh there are a bunch of points uh but I would like to focus on two points mainly because I think they they are the basis of everything the first one being focus on what's relevant that's extremely important the second one being make simp simplifying your code a priority within the team if

you don't do that you're going to end up with a complex product so a big principle is you aren't going to need it I feel this one is very important so don't write code that you don't need actually it sounds very simple but when I'm reviewing code I very frequently actually reviewing and reading code that's not even like needed in a protocol meaning either it could be completely avoided or just like simplified by a lot um and that might be the first and most most important principle uh a second one is like write code that's easy to change and more

importantly based on what you know now because no one can predict the future uh otherwise we would all be rich and we wouldn't work anymore um so write code based on what you need and you know now last over think that's good but don't over engineer meaning don't write code that is too generic uh just write codes that's generic generic enough for what you need right now and maybe later you'll tweak it if if unit I like this nightman from a guy uh which is uh so John gal and it's funny enough a doctor that focused for many

years on system design and Resident design and basically this statement summarizes the fact that like all the complex system that work properly have actually evolved from simple systems um so you can't build if you start building a complex system from scratch it will probably uh fail at some point so Simplicity requires design because people do not naturally build simple stems we actually like complexity as humans um so what's a good design well it's something that you can easily explain something that you can draw and write about if you can't draw your

design it probably means it's not that simple uh it's something that do not always reinvent the wheel but only when need it and it's something more importantly that's driven by global decision not local decisions so here there is this is something that the NASA uh wrote so they studied uh they did an amazing study about um flight software complexity because of course this is Mission critical and that's what they say engineer and scientists often don't realize the downstream complexity entailed by their local decisions meaning that like you really have to think about the design and work with all the team if you want to end up with like

a simple product it's not that Engineers want to build a complex product it's just that like they're all working on their own component and just don't realize the overall complexity that like they're uh building together so I guess if you can answer that question it probably means that like you're on the right track if you can explain to a 5-year-old children on your design it probably means it's already like quite nice from a a simplistic perspective so I just wanted to illustrate this talk with like a quick example of a not so great design so I don't know if you know that product uh but this is one of the biggest failure of like Silicon

Valley so this startup called Jero raised like hundreds of millions of dollars to build um a juer and it turns out that they ended up with this machine that's supposed to take take a bag of vegges and just press it to um make jeice it turns out that like people realized that instead of buying this $400 machine they could just take the bag and press it with their own end and they would end up with the same joice so yeah design is all about tradeoffs um no uh requirements is really bad because then you don't have a good design but too many requirements is also bad because you might end up with

like a product that's too complex so you have to find this thin line between between the two so I just here's an example right so if I write this requirement an easy to clean device that efficiently extract juice with minimal effort I might as an engineer end up with this but now assume I write that I was going to read it because it's too long but uh I end up with this and it's a useless product so now what's a good design well you can illustrate that with like a sticky not for instance this is a good product very simple uh solves a problem helps me to remember important stuff and

it does it right maybe something that you're more uh used to uh Unis swap I think it's a good example of a great defi protocol very simple code few contracts clear um separation between between them great documentation just just great example uh yeah if you're building ay you should you should take inspiration so write draw put your design on a sheet of of paper and if you cannot do it it's probably too complex and you can simplify something also really important make sure that you perfectly and I want to stress the perfectly uh understand

all the system that you interact with otherwise you might end up in a in a bad Loop it's also better save to save guard Than to Assume meaning that like when you interact with external systems you should um Implement as many preventive measur as needed because if an external system is compromised you want to avoid the repercussions on your own system and uh lastly simp still require uh thinking um so there's an example right uh finding duplicates in a solid array so I think this is a fun example uh on the right you have like the naive

solution just uh two nested for Loops other N squared um complexity and on the left you have like a much uh more elegant and simple solution which uses the ordering natural ordering of addresses um so sometimes let's say the most simple solution can require a bit of creativity I like this guy uh and I think he stated like pretty much everything so yeah simple can be harder uh than complex and you have to work to end up with like The Simple Solution make your code readable that's uh of course extremely important uh

because at some points people some people are going to review your codes and uh we are all humans so to do a great work we have to exactly understand what you um want to express and it's much easier to review code that's readable uh so be consistent follow conventions if you're doing something in one place do it in every place uh follow the standards uh it makes your code a lot more secure this is a bad example I don't know if you know the usdt contract but basically their approv function is not uh rc20 compliance and uh a lot of devs have to

actually cvent that and that's annoying write good documentation I know no one likes to write documentation but it is extremely extremely important um right comments but good comments explain why you did something not what the code is doing what the code is doing everyone can infer it just read the code why it's much harder finally of course we also don't like that as devs but test your codes um unless you've tried it you don't know that it works um and use all the tools at your disposal meaning fuzzing andine unit tests uh symbolic execution if you

want uh yeah all the best on all the B on whist and finally if you're a cool security researcher and want to work in an amazing team of incredible security researchers just feel free to ping me uh and I it will be a pleasure to connect thank you very much all right thank you so much