Les Amis d’Ethereum France #17 — Sécurité et audit de smart contracts

As I was saying, we're a non-profit organization (under the 1901 French law). We organize events like this one, so monthly Meetups. We also organize the big conference called CC, which you may or may not have attended. Historically, it was in Paris last year; next year it's happening in Brussels in July. We publish content on our blog, efrance.

com, including translations of technical articles. You can find us on various channels: Twitter, our Meetup page, our Discord server where we gather our community, and our YouTube channel where this Meetup is streamed live and where we share all our historical Meetups. So there's some great content there too. The content of all our conferences is also available there, so you can see all that content there. And again, this Meetup will be published there.

You can become a member of our association for the modest sum of €10, which helps cover expenses, but more generally, supports us and allows you to participate in the association's activities. You'll be able to organize Meetups, write content, and you'll have... A token, so a sol token, which will allow you to have voting rights in our association, in our general assembly which will take place in January. Well, a quick word to finish: we're also going to organize a Meetup in January which should be about Layer 2 and another in February which should be about taxation and DAs, and other topics, but I'll hand it over to the speakers right away. Thanks again, and good evening everyone.

It's a pleasure to be here. Thanks again to etum France for inviting us to this 17th edition on a topic that is particularly close to our hearts: the security and auditing of Smart Contracts. This is a topic we hear a lot about in Web 3. So, my goal is to give you a fairly comprehensive overview in a few minutes of what security is, the state of the art, where we are now. Then you'll have four exceptional speakers who will delve a little deeper into the subject, each with a different perspective on security in Web 3.

So, I'm telling you, we hear about it very often, unfortunately rarely well, or not often enough. In any case, the first thing to mention is the difference between security in Web 2.0 and Web 3.0. It differs in something quite clear.

In Web 2.0, we often hear about data leaks, often about the theft of personal data. There are credit card thefts, which are particularly problematic, but generally, we're more likely to have personal data stolen, like names, addresses, etc. It's problematic, but it does n't have the same impact as if we were directly robbed of our money, thankfully. And from the hacker's point of view, once this data has been stolen, they can't monetize it as easily as they'd like.

Generally, it involves a transition to the Dark Web—oh, sorry, it involves an auction, at least on the Dark Web, in a way, from what I know (I'm not an expert). And in order to monetize the data that has just been stolen, the hacker who has it can use a different method. Stolen and therefore able to make a little money in Web 3 is quite different. You connect to a smart contract, you hack it, and you steal millions of euros worth of cryptocurrency. So the path is much shorter and much more attractive for hackers who are generally very experienced thanks to their experience with Web 2.

And then some, as we see in recent cases, are young kids who come out of nowhere, who are 16 years old, and who steal millions because they're just little geniuses. So this difference comes down to three main points. The first is that the code in Web 3 is immutable. We'll leave aside everything related to upgrades and that kind of thing to try to keep things simple, but I'll take the same example as with Web 2. Tomorrow you manage to hack your bank, you add 30 to your bank account.

Well, the bank realizes, "Do you have its database?", removes €3, and you spend a quarter of your salary. In Web 3, if you manage to exploit a vulnerability, the code is modifiable. There's no one behind it who can control the database and then fix it and move on. That's the first point.

The second points are quite related. We're in a very immature industry. The beginning of Defi was in 2016, I think, and the explosion of Defi was in 2020, so it's really very young. We're in a young industry that still has relatively few processes compared to Web 2, where things have been falling into place for 20 years now. There are relatively few experts, relatively little training, and a structure that's not very present, so we don't have an industry as flourishing as we can have in Web 2, and hopefully soon with fewer hazards.

So, with the third point, there's a lack of credibility, which is what I mean by that. The thing is, many Web 2.0 experts, who have all the skills to bring real added value and secure the protocols we use in ADF (Advanced Digital Finance) today, do n't take Web 3.0 cryptography seriously. They're generally quite hesitant to get into it and they take it as a joke.

I've spoken with Web 2.0 experts who say, "Well, I'm passionate about what's happening in Web 3.0, I do a little bit of it, but when I talk about it with people around me, they make fun of me. We laugh, we don't take it seriously." So, that's security in Web 3.

0, and concretely, encryption. How does that translate? Well, it's not a pretty sight. Red as blood: 7.5 billion dollars worth of cryptocurrencies have been stolen since we've had the figures.

Overall, since 2016, probably more, but at least that's the minimum, and in 2023 alone, it's... 1.3 billion dollars, so, uh, you have a little graph here that's not pretty to look at either, uh, it's the value of the hacks that took place each month. Well, there are months when hackers take a break in October, and then there are months in November where, well, we would have preferred not to leave our LMIS, you know? And so, once again, this goes with the first two points I just mentioned: the lack of credibility.

People are thinking, "Well, tomorrow, if we want the democratization of the game, if we want everyone to be able to invest their money and benefit from the advantages we all believe in, it's complicated to tell them, 'Well, there's a one in ten chance that at the end of the year, either you've made more than 20%, or you've lost all your money.' So, this is a subject on which, well, we listeners and Pen testers of Web 3—the term doesn't exist, but we'll formulate it like this—" We're working to try and make this industry a bit more secure. Specifically, we've seen the numbers of hacks and how they happen. I wo n't go into detail about each of the main attack vectors that the DIA (Digital Infrastructure for the Environment) generally suffers from, but what's interesting to see is that the first one isn't unique to Web 3.0; it's an infrastructural attack vector.

It's when someone steals a private key, like they might steal a bank password, for example. However, most of the others are quite close to Web 3.0. I'm thinking of reentrancy, which we all know about, manipulation of ORAC (Operational Access Control), and so on. As you can see, the number of attacks is frightening, and the amount of money involved is not pretty.

So, in all of this, Soleditors, why are we talking to you about this tonight? We're a French-speaking community of passionate professionals, amateurs, and those interested in Web 3.0 security. We were created thanks to... in France, I would say...

following... At the C and Security Summit in August and July last year, we met a French community. We met up, and at the end of the conference, we thought, " Well, it's a shame we don't know where to talk now." There are places dedicated to SC, dedicated to dev, sorry, dedicated to crypto in general, like DEF, but there wasn't one for the purely security side. So we created a Discord server.

We're now 110 members. We've been doing monthly meetups for three months now, and we're sticking with it and would like to continue it in the coming year. And among the notable events, we went to Dev Connect. There were almost twenty of us, I think, in Istanbul. So far, it's been really great to be able to get together, talk about CQ using Web 3.

0, have some cocktails—you know, all the things you can do at conferences in general. Listening to talks from time to time is good too, and we're planning to do it again here in 2024 in Brussels. Well, if some of you are planning to go, we'll have the opportunity to see each other again. So, I'll give the floor to the four speakers for whom you're here tonight, to introduce them very well, because they'll have the opportunity to introduce themselves later. So, Lilian, right after, will present a transition from Web 3 because he himself experienced it.

Sergi will go into a bit more detail about what white hating is. White hating, sorry, and it's what we call an ethical hacker in Web 3. Berao has even formulated his own protocol framework, sorry, to have good practices for a secure protocol definition. And Merlin, let's not pretend otherwise, who, having experienced it, has a very, very secure protocol, but not very pleasant to audit when you're an auditor because you don't find much. But he'll tell you how he got there.

So, thank you all. Good evening everyone. So, what I'm going to try to present to you is a I'm going to explain the different impacts and differences between Web 2.0 and Web 3.0 cybersecurity, considering a career path that goes from Web 2.

0 tester to Smart Contract auditor to Web 3.0 auditor. A " P tester," for those who don't know, is someone with a very technical background who tries to find vulnerabilities in an information system. An information system can be a simple IP address, a connected device, a connected camera, a car—it can be really anything. And that's what I did for two years at Talès at the beginning of my career, so to speak.

It was on the Red Team side of cybersecurity. In cybersecurity, we have the Red Team side, where we put ourselves in the attacker's shoes and try to find security flaws. Then we have the Blue Team side, which is the defense side of cybersecurity. So, I spent two years at Talès, then I went to Airabus for six months in a SoC. It's the Security Operations Center, so basically that's where all the defensive side of cybersecurity takes place.

I only did 6 months because I didn't really like it, and then my last web 2 opportunity, well, my last web 2 job, was as a VOC analyst, so in the Vulnerability Operations Center, where we managed everything related to vulnerability management. That is to say, we would look for the vulnerability at the client's and then we would accompany them to, uh, catch it, to fix, basically, the security flaws they might have at their place. And since, uh, June-July, I switched from the web 2 world to the web 3 world, uh, to do Smart Contract auditing 100%. 100% sorry, so the first question we can ask ourselves is, what are the differences in stakes? What are the differences in terms of the stakes of a vulnerability or a hack in Web 2 and Web 3?

Well, we talked about this a little bit just before, but basically, the biggest difference is that we have a Web 2 system where money is external to the system, and we have a Web 3 ecosystem where money is an integral part of the system. In Web 3, every time we make a transaction—I don't think I'm telling you anything new—there are tokens in each transaction. These tokens are worth money, and so it's directly the money that can be impacted. Therefore, we arrive at a stake that is lower in Web 2 than in Web 3. The first victim of a Web 2 hack will be the brand image of a company; it won't be its customers' money, but it will be the brand image, because...

well, why? Simply because... When a Web 2.0 company gets hacked, well, in terms of customer trust, it will impact the company. Consequently, fewer customers will come knocking to buy the products.

Whereas in Web 3.0, well, it's immediate—well, it happens very quickly. As we explained earlier, the money gets hacked, we connect to the contract, the money is taken, it happens in a few transactions, in a few minutes the money is gone, and that's the end of the protocol. In Web 3.0, there are few or no second chances.

Once you get hacked, there's little chance the protocol will recover. Whereas in Web 2.0, since the impact is less and the stakes are lower, the company has a better chance of recovering from a hack by investing money to regain... The trust of its customers, basically, so we have a system where, well, what will suffer the most is the integrity and confidentiality of the company's user data, versus a system where it's the users' money, the money from the protocols, that will be the first target. So we can see directly that the stakes are different, and what will reinforce this even more is that we have an M2 system where companies make the most money from reselling data, and therefore companies work very hard to authenticate their customers and to know what they are doing at each stage of the process.

This means that, during an attack, the possibility—the percentage chance—of identifying an attacker, since we have worked very hard to authenticate each person who connects to our system at each stage of the process, we have a better chance of catching, so to speak, finding out who hacked our system, whereas in Web 3, which is a system based on Semi-anonymity or deanonymity, well, it's very complicated. We can see it in the recent KYB swap Act. If we see that an attacker does things well, in the end, it's kind of them who can set their own rules. Once we've said that, we quickly understand that we have different stakes, and therefore, we have different... well, it's going to be two different jobs, almost, between a Web 2 security expert and a Web 3 security expert.

Why? Because we're going to have a firefighter image. That is to say, what happens, basically, to explain this slide a bit, we have to ask ourselves the question: what happens when something goes wrong in Web 2 versus what happens when something goes wrong in Web 3? Well, quite simply, in Web 2, we call... what happens when...

when we call a Web security expert? It's when we can no longer... Connecting to the network is when there's a problem in the system, whereas with Web 3, we're much more focused on prevention and not on patching. How can we find solutions in Web 2? And so, to come back to the point, once we understand that it's a different job, basically, to have the role of a web security expert in Web 2 versus Web 3, we can ask ourselves why it works this way.

To begin to answer that, we have to consider the stakes directly. We've seen that the stakes are much lower when we have a hack in Web 2 compared to when we have a hack in Web 3, simply because in Web 2, we have a system that can be stopped at any moment. So what happens when we have a security vulnerability in Web 2? We stop the system, we develop a patch, we apply it, and it continues as before. What happens when we have data that has just been compromised?

We just experienced a REM watch, and the company's data is no longer accessible. We're going to try to back up all that data, apply the backup, and then the system will continue. So we can see directly—and this is where I'll come back to— that the overall impact of a vulnerability or a hack is low, and the cost of repair is also low. And so we come to the broad definition of security, or rather, security in Web 2.0, which is often defined as security by obscurity.

Basically, what happens in companies most of the time is a central component: data security. Basically, everything where all the customer data is located, where the servers are very old, running for a very long time with very old versions of Windows and Java. These are things I've really seen, especially in industry and in the military. Basically, with all the old systems, we have very old machines with very old versions that have been running for a very long time, surrounded by an onion-like layer of security. Security measures, some newer, some older, some not, all aim to hide the core of the system, where all customer data resides.

This leads us to the well-known cybersecurity argument you see circulating a lot on LinkedIn right now: that a company's cybersecurity budget in Web 2.0 is very low, even though we're increasingly moving towards democratized cybersecurity. A large company's cybersecurity budget is often much lower before than after. Okay, now that we've seen this, now that we understand these different challenges and impacts, we can ask ourselves the same question for Web 3.0: why is there so much more focus on prevention?

The first element of the answer, which we just mentioned, is that everything that happens on the blockchain is vulnerable—that is, vulnerable—as soon as we do something on it. With blockchain, you can't go back. That is to say, if you have data, or rather a smart track, that gets hacked, you can't just say, "Okay, wait, let's go back to a week before it was hacked and continue as before." So, to try and understand this, we come to this tweet that made me smile, from Patrick Collins. If you don't know him, go follow him on Twitter; you'll learn a lot about security.

The point is that smart tracks should be considered hardware. For those who do n't know what hardware is, to take a simple example, hardware is your phone, and software is an application on your phone. So, basically, the hardware development loop compared to the software development loop is completely different. In software, we're no longer talking about the famous Marber phrase, "moving fast and breaking things," where we try to go fast to gain market share because when we have a low impact... In terms of security vulnerabilities, if we're not afraid, or hardly afraid, of a cybersecurity vulnerability, we might think we'll try to move as fast as possible to gain the largest market share and, consequently, make the most money.

When we have low unact and low resolution costs, we can afford to move quickly and unbreakable things. However, the hardware development loop is completely different today. If your phone explodes in your pocket, if a car catches fire, or a plane falls from the sky, it's not the same at all. What will happen is that we'll stop all production, we'll recall all the products that have already been sold. Therefore, the impact isn't low, and the resolution cost is n't low either.

Okay, so what needs to happen is that it has to work on the first try. And here the parallel with blockchain is obvious: what needs to happen is that as soon as it's deployed on the... Blockchain has to work on the first try, okay, so once we've identified, basically, why the focus, we come to the definition, which is totally different. In Web 2, it was security by obscurity; in Web 3, it's going to be more about security by design because, well, it has to work on the first try. And for that, I refer you to, to give you some very telling examples, you have Uniswap, which is the best known on Ethereum, which was really a research paper.

Basically, it was already something that had been thought of even before the language in which it was developed, namely SolidWorks, existed. You have Chainlink, which, every time the Chainlink protocol wants to implement new features, creates research papers, does tests, thinks about what could go wrong before even starting to write code. So we clearly see this security by design, and basically what happens. I refer you here to the Zencing roadmap. Zcing, which is also a protocol, or any mature Web 3 protocol in terms of cybersecurity, basically aims to build trust in a product that can then be deployed.

Based on this trust, we'll try to create a community, and then, based on this community, we'll try to create decentralization. Even though at the beginning of the protocol we might say, " Well, we're in Web 3, so we'll focus everything on decentralization," decentralization, for most projects that prioritize security, will really be the last piece of the puzzle before considering anything else. Meanwhile, we'll implement security by design, by default. Once we've seen the different challenges and impacts that a vulnerability can have in Web 2 versus Web 3, we'll focus a little on the knowledge required in Web 2 versus Web 3. What you need to understand is that in penetration testing today, there's a huge amount of knowledge required in Web 2.

I mean, as a web penetration tester... 2. There's a huge amount of knowledge to acquire on Web 2.0. There are, well, first of all, the different types of operating systems: Windows, Linux, Android, basically everything you can find as a different OS.

There are all the programming languages: C, C++, Java, PHP, and so on. Plus, there's more and more cloud computing, more and more IOOI, and so on. So, where I'm going to come in is that, logically, the best pain testers are those we know the most about. But today, either those we know the most about, or those who have a very strong specialty. But today, with everything we have access to on the internet, for me, the best pain testers are those who know a little bit about many things.

So, for me, the good definition of a good Web 2.0 pain tester is someone who has a little knowledge in many areas and who knows how to do good research or build a good database. This is in contrast to Web 3.0, or the current state of the market. The fact that it 's quite young, as we mentioned earlier, means there are few auditors, few Smart auditors with truly strong specializations.

However, in the coming years, I think there will be teams with auditors, each with their own specialty. But today, the market dynamics mean that a good auditor is someone with extensive knowledge in a few specific areas—well, for me, there are four areas today: Solidity, IVM, finance, and EVM. Why? Because with Solidity, you'll be auditing code, so you need to have knowledge of Solidity. Most Smart Contacts today are written in Solidity and IVM because the code you'll be auditing will run on EVM, on the Virtual Machine.

You need to have knowledge of finance because everything related to Smart RAC mostly involves money, loans, liquid options, and so on. You need to have a minimum of knowledge in math, know what a market maker is, and know about cryptography. But what I'm going to come back to is that, for those who want to get started, having a lot of knowledge in a few places makes the learning curve or the production margin much higher than for a good Web 2.0 pain tester. The phrase "a little knowledge in many places" is key.

Because as a pain tester, if you spend the next six months learning all the possible attacks on PHP, which is a web language, and then in your next pain test you're testing a website created in React, which is a JavaScript language, it's like starting from scratch. Having a lot of knowledge in a few places makes learning much more enjoyable. So, if you have some knowledge of finance, some knowledge of math, and you're curious about what's happening on Ethereum, then just start learning and get into it. Once we've seen the different aspects of the Smart Contract UDI and their impacts, we can ask ourselves: what are the differences in the process between a penetration test, specifically between vulnerability scanning in Web 2 and Web 3? The process of a penetration test can really vary depending on what you're going to test, but most of the time it remains these nine steps.

That is to say, we'll have a first step with a reconnaissance phase, or to give you a very clear example, am I pentesting an IP address or am I testing a car, a connected car? Secondly, there's a mapping phase, then enumeration, and finally a vulnerability search phase. It will simply be: is my IP address connected to Windows 7 or Windows Server 2016? Depending on whether it's Windows XP, Windows 7, or Windows Server 2016, we'll search for known vulnerabilities on that type of system and try to exploit them. I'm going to perform privilege escalation, meaning that if I manage to gain remote access control with a regular user, I'll try to escalate my privileges to gain administrator access, for example, to perform maintenance, propagation, and lateral movement.

I'll clean up my tracks by going through the logs and trying to hide what I've done. The most important step is presenting the report, which means what I found in this test, what vulnerabilities I discovered that someone with malicious intent could exploit. I'll simply present this to the person who asked me to perform this penetration test. In terms of tools, penetration testing is similar to the definition I gave earlier for Web 2.0.

The market's maturity means there are now a huge number of tools for performing penetration tests on just about anything. So, we come back to the same definition: knowing that a tool exists is cool, but knowing how to use it today... well, there are tons of tutorials online. Again, as I was saying earlier, the market maturity means that a lot of people have already made tutorials on how to run these tools on Web 3.0.

For me, it's a bit simplified today. The steps of UD SM Track... well, that's just my opinion, but for me, there's a big understanding phase. What's good about Web 3.0 is that we're always auditing a different protocol that does different things.

So there's a big learning phase, understanding what we're going to audit. Then there's a logical compromise phase: we try to find vulnerabilities, security flaws in the SMART device we're auditing. We generate a report and give it to the protocol. We audited the code, and we're going to check how it was able to fix the vulnerabilities we identified. We'll especially verify that Ben, in fixing the vulnerabilities we found, didn't introduce new ones.

Basically, the code used to patch the vulnerabilities we found does n't introduce new security vulnerabilities. In terms of tools, we're auditing code, so we need to visualize this code, be able to test it, and be able to search for vulnerabilities similar to the code we're auditing. So, for me, the main tools are, in quotes, Visual Studio Fundry and Solodit, which is a database of known vulnerabilities. Of course, there are others depending on what you want to do, what you're auditing, or how you want to audit it, but today, these are the three main tools. In conclusion, I think you understand that security by design versus security by obscurity makes it a much more complex ecosystem.

" Security, in quotes," is what we talked about just before the maturity of the Web 2.0 ecosystem. Well, we still have some steps to take, in quotes, to make it a truly secure ecosystem. But in any case, security by design far beats security by obscurity. Thank you for listening.

So, I'm going to talk to you about white hat activity in Web 3.0, and we'll see how we can save millions. So, I've been an independent Smart Contract auditor for about a year. Before that, I was a developer for eight years, and I'm also developing a tool, a kind of web app called Upgrade Hub, which I'll talk about a little later. I'm also interested in zero- knowledge technologies.

As we've already mentioned, the specific characteristics of smart contracts include the fact that once deployed, they are difficult to change. So, if we want to make modifications or correct things, there are patterns to implement, but it's a bit more complicated. The code is public; anyone can read it. It's completely transparent, which makes it easy for people who want to study exploits. Also, the interactions we can have with smart contracts are all public; the transactions are public.

Furthermore, one of the features of blockchain is that all contracts can interoperate with each other. So, we see that this creates dependencies that we can't necessarily control. This, too, increases the attack surface for smart contracts. So, before going into more detail about the security aspects, let's take a brief detour. Let's see what MeV is.

What does the acronym MeV stand for? It's one of the four options here. Okay, there was a little catch there. Actually, there are two since the merge. It's called Maximum Extractable Value (MEV).

It corresponds to all the rewards that are publicly accessible on Ethereum. So, anyone can execute a transaction and take that reward. There are activities that specialize in this. For example, there are people who specialize in arbitrage on decentralized exchanges, and others who specialize in collecting liquidation rewards, or taking public trades and profiting from them by positioning themselves before and after. So, these are called " sandwiches."

And what's the connection with security? It's what we can call generalized bots. These bots copy public transactions before they're even executed and replace certain variables, for example, with... The funds that are being diverted are intended for this purpose, and this allows, in fact, for—well, this is what often happens, by the way— attackers who aren't sophisticated enough will get thwarted and seize the funds they're trying to steal. We see that in this ecosystem, there are very sophisticated players who are capable of acting on transactions that haven't even been executed yet, and thus potentially saving funds.

This is the case with a security company, let's say Deud BlocSec, which has the infrastructure and quite powerful monitoring tools to be able to save funds. For example, we see from an excerpt of an article here that they allowed Sadle Finance, for instance, to save approximately 4 million. And another player, a fairly well-known participant, regularly manages to save funds as well. Whiteat actions, the tools that are used, so, how to say, to study what's happening on the chain and thus identify potential vulnerabilities that need to be addressed. There's, of course, the Block Explorer, which I think is quite well- known.

So, for example, it's for scanning and all that. And if we take the example of the vulnerability that historically led to the biggest reward, the Bug Buoy, which was $100 million, it could have simply been spotted on an ether scan by anyone looking through the variables. They would have realized there was a vulnerability because a variable was malformed. So, this brings us back to the fact that it's not just the code that needs to be examined, but also the entire configuration of the smart contracts when they are deployed. It's important to have complete coverage of what we deploy.

Okay, I'm going a bit far here. So, this is an advertisement for the tool I'm developing. It's a tool that allows you to visualize code changes made to contracts of a certain type— contracts that are modifiable. It's quite useful when you're trying to see the changes being made and whether there are potentially any vulnerable changes. And this is another tool that's very useful, especially for analyzing hacks that have occurred.

These are transaction tracers. I've included the three most popular ones here, and it looks like this. I won't go into detail about what's here, but basically, you can see the flow of a transaction and therefore study it afterward. Regarding disclosure, if we ever come across a vulnerability that puts user funds at risk, what do we do? Do we take action?

To ensure the security of user funds more quickly, do we notify the protocol so that they can take control and act? Do we check the vulnerability on what's called a TestNet, a test version of the chain? Or can we publicly alert users on Twitter? The last two options might seem a bit far-fetched, but sometimes people do this. The drawback with the last two...

oh yes, well, I can give the answer then. Of course, it's notifying the protocol; they are the ones best placed to take the necessary actions. But, as I was saying, the last two actions are things that may have been seen, and the problem is that simply disclosing the vulnerabilities to the general public puts even more risk than the funds themselves. Option A is possible if we are... How can we tell if we're truly competent and competitive, as we saw with the players in the first part?

But it's still a risk; we're exposing ourselves to a significant legal risk, and it's ethically questionable. So, it's really best to stick to option 2 regarding disclosure. In general, companies operating on blockchains have bug bounty programs on ImmunFi, for example, or through dedicated email addresses. If not, then it's a matter of potentially finding their contact information on Discord or Telegram and trying to warn them privately, knowing that you have to be very careful because there's a lot of anonymity in this field, so you're not guaranteed to be talking to the right people on Discord and Telegram. So, you have to make sure you're talking to the right people.

Regarding the report, when you report a vulnerability, there are several sections, or rather, several... Elements of response to provide the vulnerability scenario, so just writing what happens that makes the contracts vulnerable, the severity, so we need to, how to say, try not to be too alarmist, we need to try to describe coherently what can happen under what conditions so as not to, how to say, overreact, but if there really is a real impact, it still needs to be described correctly. And a specificity of the Web 3 domain is that we can create a proof of concept that is actually secure because we will copy the state of the chain at a given moment, we will fork it, and so we will be able to execute a script on a copied state of the chain without making the vulnerability information public. There is an alliance of Whiteat and the protocol that was created to secure the ecosystem; it was created quite recently, in October if I'm not mistaken, and so there are really many major players in the system who are collaborating and who They can be contacted via telgram, and in a situation where we don't know what to do, they provide support and act as trusted intermediaries to resolve problems we might face. So, what systems do the protocols have at their disposal to act once they are aware of a hack?

Well, here's a list I found on OpenZeplin, but essentially, the functionality to be able to pause smart contracts, which will be used quite often. There's also the ability for an administrator to withdraw funds, often. And I think the last four options are much less common and much more technical. So, for example, adding, or rather putting on lists that exclude a certain actor from interacting with the contract, rate limiters (to limit the speed at which an actor can interact with the contracts), time locks to delay the use of a contract, and as we saw in the first section, front-running. Well, that's...

It's quite technical, so in conclusion, we can say that a lot of progress has been made to truly standardize this approach, but there's still a lot to do, and we haven't even addressed the, how shall I say, the Black Hat side—that is, the really malicious hackers who, unfortunately, are still very much incentivized to act the way they do because, in fact, they'll siphon off funds, and then often there are arrangements, and so, well, that creates bad incentives for the system, and I hope that we'll manage to find a way to reduce the hacks, as we've seen, which are still predominant in this ecosystem. So, I'm going to present a framework that will allow you to best secure your decentralized protocol if you decide to embark on this adventure. Well, I'm a security researcher, so in In Web 3, uh, I went to engineering school before, and since September I've been working in it full-time. So I mainly do contests on CodeArena and private audits, and sometimes bug fixes as well. So why did I decide to create this framework?

Well, it comes from the fact that when I started, it was a bit of a mess, how can I say it, with all the solutions available in this environment. So, you might think at first that it's difficult to find the best solutions for our protocol in this field—also knowing the order in which to do things to be most optimized and knowing what to prioritize based on our budget. These are important questions, and when you arrive in this field, it's complicated to answer them. You need a few months in this field to start getting an idea of ​​how it works. Well, you should know that deploying smart contracts, at least if you're serious, is very expensive.

It's very expensive because, let's imagine we take a classic Web 2.0 project, typically a SAS (Simplified Application Service). Normally, in entrepreneurship school, they'll tell you that you have to develop the product as quickly as possible, make it available to users, create an MVP (Minimum Viable Product), gather feedback, and try to improve it even if the product isn't completely finished. That's not a big deal. But when we're talking about a DAP (Data Access Platform), well, then you obviously have to fully develop the product, at least a functional V1 (Version 1), test, test, test the product a lot, audit it externally and internally, and have a Bunti program.

So all of that costs a lot of money, and that's why it's important to know how to start. Anyway, we can see security as layers of cheese. Each layer we add is a layer of security. Each layer is, of course, porous, and the goal is to know which way to put them, in which order, and to add as many as possible, always depending on the budget, and which ones to prioritize. Budget so that in the end an attack has the least possible chance of reaching us.

Okay, let's start directly. Okay, uh, we'll start with gas optimization. Uh, it's not really security, but it's good to do it, and if we want to do it, well, we have to do it at the beginning. It's something quite controversial because it can potentially, uh, lessen the security of the protocol. We're going to try to make optimizations that can be at the expense of security.

There are many who are against that. Uh, you can do that if you deploy on Ethereum. If it's not on Ethereum, frankly, that's a bit limited. Uh, and if you have a lot of resources, because obviously that's not what we want to prioritize. Prioritizing if we don't have a lot of money, it's not gas optimization that we want to prioritize.

What's most optimized, I think, is the solo editors. So here we have two, certainly one of the two best from Code Arena. So if you contact these guys on Twitter, they'll give you... Beautiful, beautiful, beautiful Gass optimization, certainly not too expensive. The prices I'm going to give below are approximate, and they're for my lines of code, let's say...

so, let's say between $2,000 and $10,000 for my lines of code. $10,000 might be a bit expensive, but you can get away with it for not too much. In any case, then there's the consulting part. Well, it's highly recommended to do the consulting part because, let's imagine you have a little money, you'll want to immediately go and find star auditors who will cost a lot, and then it could be a shame to find bugs that call into question the design of your protocol, because you will have paid $200,000, $200,000, $150,000, and you'll have to re-audit it because there would have been... There are major changes that will need to be made, so the Consulting part allows you to spend a little less money depending on the solution you choose, obviously, and to get initial feedback on your protocol design.

So, I've identified three solutions in this area: there's the solo reviewer, not the most well- known in this field, but it will cost you a lot; there are what I call traditional security firms, the most well-known in this context—there are many of them, this is where there are the most players, but it will be Sigma Prime; then there are what I call audit TR firms, so Trail of Beit, OpenZepin, and Consensus Due Diligence. These will also be very expensive, but in terms of branding for your protocol, it's very strong, and they will inevitably go a little further than the other solutions. So, if you have the resources and good connections, you can afford to go see them, and you'll also be supporting open source in this regard. So, this middle ground is great because it develops a lot of everything in Open Source. Then, well, it's really not essential, but we can do fusing and formal verification.

Fing is good to do in the development phase. Format verification is also good if you have the skills, but doing it right after the consulting phase is nice because it allows you to have fixed, fairly clean code. The design is normally fixed at that point, and to have... yeah, yeah, yeah, well, I realize there are terms that maybe people don't know. So, yeah, fusing and formal verification are two approaches to do pretty much the same thing.

So what we're going to do is write invariants. We'll first write them in English and then in French, and then we'll code them. So, what is an invariant? Typically, for example, for an ERC20 token, an invariant could be... The sum of all users' balances must equal the total supply.

If the sum of all users' balances is not equal to the total supply, it potentially means someone has created tokens in an unconventional way; in any case, there's definitely a bug somewhere. So, for Fing (Formal Verification), we'll code in a language—it could be a different language—we'll code the invariant, and then for Fing, we'll bombard the program's inputs and check if the variant is valid. This will allow us to know if the variant is broken or not. Formal verification is a bit more complex, but it's basically the same thing. Instead of just spamming all the program's inputs, we'll put the program into a kind of mathematical formula and solve it.

The program will immediately give you a counterexample if there is one, indicating whether the invariant is broken or not. So, it's a somewhat semi-automatic method of security. It's good to have it as a complement, especially Fing, which is now very accessible with lots of tools and is quite simple to do internally. Then there's formal verification, which is a bit newer. The main players in this area are Sertora, the most advanced at least with their proof.

So if you don't have the internal skills to develop what are called specs, you can contact them directly. It will cost you a bit, and potentially there are solo auditors who can write SPs because the routine isn't open source, but it's used by everyone. There might be solo auditors on the market—I do n't know any—who develop and can write specs for you. It will cost you less than going to Sertora. Of course, it will be a little less good.

It will cost less, but yeah, as I said, it's not necessarily the priority. We'll prefer manual reviews if budget allows. Then, what is highly recommended to do, in any case, is... In my opinion, the one with the fewest holes in the cheese slice is the contest, so it's highly recommended to do it, especially if you don't have any confidentiality issues with the code. The main ones in this area are there; there are all the...

So, the main thing is Code Arena, and in terms of price, it will cost between 50,000 and 140,000. Let's say that the more you spend, the more you'll encourage people to use your protocol, and therefore the more secure it will be. So, we highly recommend doing this. I put it here after, but before that, if you have the means, it's a bit complicated what I'm explaining here, but anyway, at the end you'll have a link to my blog article that talks about all this with the different steps, prioritized according to your budget. But if you have the means, before the contest—the contest would be the last step—you can do what I call a decentralized OG.

So, the main VOs, only Spvit and TR Security do this. There, you'll have the best in the field, the best, who will look at your code. So, it's great feedback. It costs a bit, so it's a bit expensive, but doing it, having a contest, can add a layer of security. Plus, which is really quite good, and then of course, a Bouny bug at the end, the convention in the MTI bugs, especially doing it is highly recommended, especially if you start to have a lot of TVL, which is recommended, so it's 10% of the TVL for a critical hit.

A hacker can steal 100 million and will be rewarded conventionally, of course. After that, it can be more, it can be less, but 10% TVL, so $100,000. So you can do it on Imunify Finance or also solo, just with an email address to contact them. So there you go. As we've seen, well, it's to secure 1000 lines, we can only do one contest, so it can earn you a minimum, let's say $50,000, $60,000, and a maximum of $500,000.

So you see that it's a lot of money. So the question is, what do we do for people who do n't necessarily have $50,000, let's say the poor ones? So, $50,000 is still quite a lot. So, for people with less than $50,000, what advice could we give them? Because especially for a protocol that's going to have a lot of TVL, it's not necessarily essential to immediately seek out very expensive audits from people who cost a fortune.

What I would advise for people with less than $50,000 is perhaps to go for a full solo review. Try to find some rising stars, people who might cost a little less, people who are climbing the ranks in this field because they will have a high level of expertise, but their prices won't necessarily be fully adjusted to their level yet. For example, you can see Mille currently ranked 3, 4, or 4/5. He reached number one on the Carena leaderboard, the contest platform. So, if you manage to find someone in a solo review who is climbing like that but hasn't necessarily adjusted their pricing yet, and Well, this will allow you to get very good audits for not very much money.

It's also good, so now it's very expensive, but when he started, he was someone competent, and if you look at the trends in this whole scene, at people who are up-and-coming and starting to make a name for themselves, you can potentially get very good audits for not very much money. So the goal isn't to do just one, but to do three or four as many as possible depending on your budget, and I think you'll be able to have a reasonably good level of security. Then there are the invitationals on COD Arena. Invitationals are smaller competitions where there will typically be three or five people competing, so it's private in a way, and there you can potentially get away with spending less than on a regular account. Well, currently, you have everything you need, so all that's left is to prepare for the worst, so check Bitcode monitors the blockchain, so that was explained a bit in previous presentations.

Establishing procedures, well, basically doing everything necessary so that in case of a hack, you know how to react as best as possible. Because once you get hacked, I think it's a bit of a panic, and it's hard to think clearly for some protocols. So yeah, having all that close at hand allows you to react as best as possible once you've been hacked, if it ever happens—hoping it doesn't. So yeah, on my website, bero.xyz, you can find the complete framework.

You'll really need to go into detail about everything, including the path to take depending on your budget. So potentially, if you want to apply it, feel free to go to my website, bero.xyz. Thank you for your attention. So, I'm Merlin, I'm the co-founder of Morpholabs, and everyone has been talking a bit about security.

So now I'm going to give you a case study of what we do at Morpho. To secure, among other things, the next protocol we're going to launch, called MorpoBlue, and we're going to explain a little bit of everything we've done. So, I've broken it down into four phases. This is the prebuild phase, so this is the phase where we start thinking about what we want to do, what protocol we want to create, what features we're going to add—basically, the whole part where we design the protocol and also what the state of the art is. So, MorpoBlue—I don't know if everyone is aware, but we're a learning protocol.

There's approximately $1.5 billion deposited in the protocol, so we're the largest landing protocol on Ethereum after AV Campaign. And so, well, that's a lot, so we have to do everything we can on security. We've also created what we currently call optimizers. Optimizers are landing protocols that are a top-of-the-line feature of AV Campaign and that allow you to optimize your landing rate.

If you're using AV and Campand for lending and borrowing, you'd be better off using Morpho Optimizers. What we've realized in the two years since we launched these protocols is that creating secure protocols is very, very difficult in the space sector, and we've encountered many limitations. For example, in the space sector, we have very, very large codebases. If you take an app or software like Airbnb, I don't know how many lines of code they have—maybe millions. When I say it's very large, I mean 5,000 lines, but even within 5,000 lines, you can find a good number of bugs.

So that's already a first problem. Then there's the protocols, which try to include lots of features, because you ca n't necessarily upgrade your protocol easily. You ca n't update it, you can't add new features. of features so easily, uh, so everyone tries, for example, on AV you have stable mode, isolation mode, and so on, and in fact, every time you add a feature, it increases the complexity, it increases the load. Having a bug in production, that's another one, another one, I didn't do anything, it's Morpo Blue, oh yeah, yeah, that's it, I heard, it's a bug in production, that's exactly it, but generally it doesn't reappear like that, then it's really empty, uh, so what leads to a lot of bugs in production, so we, since we're on AV Campaign, every time there's a bug on the protocol, the underlying, well, we, ATI, a little bit, so there was, I do n't know, Campaign, which upgraded the oracles, which freed the protocol for a week, uh, because they had forgotten to do tests, quite simply, and it didn't work on one of the tokens, well, the oracle, it caused a revert So it froze everything.

They also had some minor problems not long ago, about a month ago there was a critical issue. They had to take everything down, and so on. We're in the same boat. We have to adapt, we have to pause, and so on, and make sure our protocol is safe. Plus, they're doing upgrades, so we have to keep up with the upgrades, be sure it doesn't break what was done before, and that makes things very, very complicated.

Why? Because it's not trustless, it's not immutable code. And so, when you build on a protocol that isn't immutable, your protocol also has to be immutable to adapt. And generally, that creates systems with quite a lot of risk. So we tried to rethink the landing protocols to make them as resilient and safe as possible.

So, what we decided was that we were going to... Include only what is strictly necessary. Every time you add a feature, you increase the attack surface of your protocol. So, every time you think, "Hey, it would be cool to have stable rates, swap space, or whatever," it's good to ask yourself: if I remove this feature from my protocol, will users still come and use it? Will I still have users if you remove it and you still have your users?

Well, maybe it's a good idea to remove it. It will just lead you to pull your hair out, add complexity to your code, and so on. What we think is to approach protocol creation and design from a very minimalist point of view and really capture the very essence of what you want to do, whether it's lending or trading. Really capture what you want to do and don't add anything extra. In your protocol, that...

so there's also a Frat modeling section. We don't do it in a rigid way; I've put resources at the end, you can go and see them, there are links... we do it more like we've tried to create a culture around debate. So that is to say, whatever future we're discussing, whatever we want to add, we're going to spend a lot of time debating pretty much everything, and so we've tried to create a culture where criticizing something or questioning something is really welcome. And we try never to minimize anyone's concern.

I think that's really important because it allows us, at least from the beginning, to catch anything that could later lead to the creation of bugs during the development of the protocol. It wastes quite a bit of time, especially Morpo Blue, which took almost a year to develop. So a year is still very, very long from a startup point of view, but... On the other hand, it allows you to save a lot of time later when you're doing the audits and so on because you've already thought of a lot of things and a lot of potential vulnerabilities and so forth. Now, let's say we've passed the design phase, you have your specs, your requirements, and so on.

At this point, you say, "Okay, we can start writing the code." So, what we generally do is test in parallel with the code development. Some people want to write the tests upfront or develop the protocol first and then add tests. We do it in parallel. This allows us to catch bugs quite early and sometimes problems that can even call into question the protocol design.

So it's good if you have them upfront so you don't have to reinvent the wheel after a month or two of development. For this, we do unit tests and integration tests. Unit tests are really for testing a specific part, a specific function, its behavior, and so on. Integration tests It's when, for example, you have dependencies on third parties, I don't know, like Indice, DeEx, Oracle, or whatever. In that case, it's good to do tests with this F-Party and see how it works.

I recommend doing it in forks. There are some that mock, so mock, you go, I don't know, Morpo AV plugs into AV, so you create a fake AV that responds fairly well, as if it were a real AV. But it's better to do it in a fork. You fork mainnet and interact as if you were really interacting with AV, and then you'll realize that, in fact, compared to your MOOC, you'll realize that there are many more high-level cases than expected. Also, I didn't mention it, but if you plug in another protocol, you really need to do a complete review of that protocol.

There can be surprises, and it's not necessarily written in the documentation. It's not always easy to see. Regarding the contracts themselves, you really have to spend time on them. We were talking about Fing earlier, but now it's incredibly easy to set up with Fundry and so on. It's not necessarily just for invariants; it can be for all types of tests.

For example, if you have a function that multiplies numbers and you want to know that it gives you the correct result, instead of doing it with 1 x 2, you tell it to take X Y and you check that it gives you the correct result. You multiply your numbers correctly. Now it's super simple to do with Fundry. So there's no excuse; you have to do it. Also, in our development process, we have two teams: the Protocol team and the Launching team.

I'm on the Launching team at Morpholabs. The Protocol team is more research-oriented and will write the protocol, while the Unchain team focuses more on integration, contract review, testing, and so on. What we try to do is... What we try, but what we actually do each time, is if one team writes the code and writes the tests, we have the other team review the contracts. Actually, it's a bit like...

I don't remember who was talking about a RED team... well, the RED team allows us to have an internal team that's kind of on the other side, trying to break the other team's code and also bringing fresh eyes to the codebase and critiquing what the other team is doing. And there's a rule that everyone working on Solidity internally has to review all the contracts. There's no messing around, we review everything, and it's quite important because that way there's no single point of failure where there's one person on the team who knows all the codebases and everything. The knowledge is shared, and so if I come in...

It's great, Glo. Uh, if someone on the team happens to die, we can continue working, everything's fine. So, once we've done our internal reviews and so on, we call on several advisors and VC companies who have security researchers in their firms, so that's cool. What we do with them is, when the code is fairly clean, well, even in the design phase we have several advisors who give us advice, and so on. We also have them there.

So, when we're trying to get feedback more on the security aspect or on design details, we call on them again, and they challenge the code. And in fact, we try to refine certain design choices. Also, during the design phase, we generally develop requirements. We also derive invariants during development, so, yeah, mathematical formulas that shouldn't break. And so...

So, we're going to use these invariants for formal verification. We have formal proof in-house, so Quentin has a knack for that. It's pretty cool because we don't need to pay Corin a fortune; we use their tool, but we don't need... well, we have the internal expertise to do our formal proof of code. Generally, this continues.

The workshop continues even after the contract deployment because it's kind of an endless process where you can always find invariants to test on your codebase. So that's something we still do. And we do something cool: the "end of camp." Every year we do an "end of camp," well, every year, whenever we have a big project launch. So what is an "end of camp"?

We go away for a few weeks. It will get shorter as we grow, but for now, it's a few weeks in France with the whole team. The goal of this... Bot Camp is about making sure everyone shares the vision of the protocol, sharing the vision of the project, and preparing for the launch. Sorry, but also, in fact, we're going to move on to the security side.

We're going to try to break the code for three weeks, break the code and improve the tests, find vulnerabilities, think about all sorts of things, all sorts of ways to break our code. And finally, we can move on to the pre- deployment phase, and what we do there is security audits. So, for example, for Morpo Blue, we did an audit with OpenZEP and Spearbit. The goal here is generally to have fairly long timelines so they have time to go deep into the code, into the math, and they'll have quite a few... The goal is to find the biggest vulnerabilities, to critique the design choices we made, and ideally, we do these security reviews sequentially.

It can take a lot of time, generally for... 3000 lines of code and so on, it can take almost a month, not counting the fixes that need to be done. So if you do it sequentially, that's going to postpone your launch by 3 or 4 months. So it starts to add up. Then, once we've fixed all the bugs, after security, what we did was a comp test.

So, contests are competitions, a kind of human fire contest. You put a lot of people together, and they come and try to break your code to get money. And so, it allows you to incentivize people who are very, very good. The biggest goal is your reward pot. The more, the more very, very good people you have, and you also have to try to choose a slot where there aren't any big contests at the same time because if you You stumble upon Z casing, which is acting like a friend with a billion, 1 million, sorry, 1 million, well, it's a bit annoying if you get a reward of 20k, whatever, anyway, so we've done that, currently we're in this phase where we're fixing the few issues that have been found, and in parallel, what we're doing is, I think we've already talked about this a bit, but we're also working on incident response plans, so what are they?

They're a kind of playbook. You 've identified potential problems that could happen, like you've been hacked, you've run out of funds, your Volt maybe, I don't know, blocked for a certain number of hours, well, in fact, you're going to leverage the flight modeling you've done, or all these cases you've identified, try to think a little bit about what the best response is for that, and well, you make a kind of checklist, to-do list, it's a bit like recipe books, like, well, I don't know how I make my pie, uh, Kich Lauren in less than 15 minutes, and the goal is to be as fast as possible, so it's good to have thought about it beforehand. So, you make these playbooks, and then it's also very good to have the contact information for the authorities. In France, for example, it would be the National Gendarmerie. We also have a partnership with Chainalasis, which is kind of their job.

If you have a hack, you call them, they 'll try to trace the funds, they 'll contact the authorities, and also potentially Centraliz Exchange, to say, "Okay, all those 100 million from the SDT that you just received, you have to free them because it comes from the MORP protocol, it's not cool." And we also have Warroom. Yeah, Warroom, you can prepare your server room on Discord or whatever with your favorite security researchers, and that way, if there's an accident, in a few seconds you send a link and say, " Meet me there," and it's already ready. So, those are the things we can do beforehand. That's...

It does n't protect against ha, however, it can limit the impact and it might also allow you to recover the funds if you act quickly enough. Right now, the code is frozen but not yet deployed, so we're going to do a pre-bug by with Ad finance, which is a bit like Immune F. So we're going to put 100k at risk. That's for the time we have until we deploy. And after deployment, we have the monitoring part, which we've already talked about.

But what we do internally is, for example, the invariants we've already defined. We're going to run boots. Every time a user makes a transaction on Morpo, we'll check that after that transaction, the invariants—sorry, the invariants—aren't broken. If they're broken, there's an alarm, and we take action. And that's it.

We don't have a circuit breaker on MorpoBlue, meaning we don't have a posing system. Why? Because we think the primitive that we What we create must be... the governance must be minimized as much as possible, and the protocol must be immutable. So no posing system, no admin, no...

if you have a market, it will run indefinitely, and no one will be able to change it. So that was more a question of value and vision of what Defy should be. And finally, we will surely put our $500,000 on the morpho Blue Optimizer. Morpho Optimizer, sorry, it's super important; it's already been useful to us on the optimizers. So I recommend that any protocol implement this.

Of course, 10 % of the TVL starts to get expensive when it hits 1.5 billion... that's 150 million. We don't have the cash for that at all. So indeed, I think it would be necessary...

these are perhaps points for improvement: how to incentivize hackers to become White Hats and go on ImmunityFast for... Posting their funding rather than hacking optimizers and, uh, against a ransom of 150 million, uh, so these are questions that I think we can address later during the Q&A session, and then, well, staying internal means staying in sync with crypto Twitter, what's happening in the ecosystem, what the new hacks are, uh, we also recently created what we call Hack School, so every week one of the Morpo developers presents a new hack. Last time it was Ky Swap, by the way, uh, pretty cool, yeah, it's cool, and uh, and so, so the recap, that's a bit of everything we've done, and obviously, well, there are, there are, there are plenty of things we could improve. The budget is still in the hundreds of thousands, uh, we're more in the order of 800,000 than 50,000 in total for 3,000 to 1,500 lines of code, so You really need to have a lot of resources; it's very difficult to secure a protocol in the Defy because even after two audits, vulnerabilities are still found after the competition. So, there you have it.

And just for Morpo Blue, it's 700 lines of code compared to 5000 lines of code. So, to illustrate that it's very difficult to secure protocols because, well, it's open source; everyone can see the vulnerabilities, and we can only do preventative measures. So, we'll see you at the next Therum France Meetup in January, which will focus on Layer 2.