 So, how many of you would consider yourself, you know, insolidity is my contract like, you know, you're starting with it. You're not, you know, it's the first time to it, you're just getting started, you have coded a few things, but, you know, you're still pretty new. Okay, so I would figure that everybody else considers themselves to be intermediate or advanced level of security. So, I don't know how much, what I'm going to say, perhaps I've already, you already know about it. So, we could have more of a dialogue, and you could, and you could have, we're going to have room at the end of the session for some questions. That's for mostly also why Gonzalo from Diligence is here, because they work on security on their everyday basis. So, if there's a question that I'm not able to address, he'll for sure be able to at least help me figure it out a way to solve it. So, how many of you are from, have taken any class or anything in, for Ethereum, or how many of you take courses, or do you teach yourself? How many of you take courses? How many of you learn yourself? Most of you. All right, that's good. All right. How many of you learn, like, from Github or Ripple from people? That's mostly where people learn from? Yeah? If not, where do you usually, if you want to learn about Ethereum, where do you go to? Read the docs. Oh, sorry? Read the docs. You read the specs, the docs, yes? That's a common one. All right. And just our curiosity, because we're always about how many people here's consensus? Sorry. Yeah, we're always, we're always there. All right. So, let's see if we can get started, because honestly, the women's schools have, actually, that will give us a little bit more time of, you know, to work on this. So, considering that most of the audience is advanced or intermediate, I'll try to go, maybe, a little bit fast about some of the topics. Also, I don't know how well some of the code will be able to be needed on the back, so we'll see how that goes. So, we have more time for questions and answers, or, like, concerns about how to address for focus security, and maybe consult with the thing to tell you a little bit more about, you know, how audits are conducted for smart contracts. All right. So, let me go back to, first of all, welcome. So, I'll introduce myself, then I'll let Gonzalo introduce himself. So, my name is Carlos. I got involved in the blockchain space in 2014. I had my startup at that time, and basically I was just, you know, trying to, I was just using Bitcoin blockchain to stamp documents. Because my startup were having a lot of documentation, and using DocuSign didn't seem like something a startup would do. So, I started with it, but to be honest, I didn't really got, like, it didn't excited me that much. Then, I ran into Ethereum, and that for me was really up to my mind, and it made me get into the space. And little by little, I've been doing things in the space until I joined Consensus, I think, about a year and almost two years, perhaps. And I work in the educational arm. I'll tell you a little bit more about it later, but also in this session, I want to introduce you to Gonzalo. Okay, yeah, I can, okay, yes. I'm going to introduce myself real quickly. We've been, I'm aware of Consensus, we mostly do security audits, but we also do security tools. Mostly automated analysis tools that will report back to any philosophy code you might have. I don't know that my story of getting into Ethereum is exciting enough right now. But yeah, I've been hacking for most of my life, and I found Ethereum a while ago, late 2016. I've been breaking smart phone back several seasons, and yeah, I'm here to answer any questions that you might have in the end, or throughout the session, from a point to stop, Carlos, I guess. Yeah, if you have any smart phone right now that needs auditing, please come to me, and you can be here, and we can get you hooked up. So, as probably everyone here knows, there are Consensus, you know, we're pretty broad and we do a lot of different things. And without that, in that, there's also the educational arm. That's Consensus Academy, and basically, on one side, we try to get developers skilled and ready to be able to build using Ethereum technology. And we're also trying to get business leaders, managers, and, you know, lawyers, and all the non-technical people to understand the technology enough to identify business opportunities. It is as important as that we have really strong developers community, that we also have traction in the business, and that companies understand how to use it, because probably not necessarily your cases, but if you're in the blockchain education space, and for whatever reason you work with enterprises, 90% of the ideas you hear that they want to use blockchain for is honestly not a good use case. So, it's very important that they understand when this technology is relevant, and what is it good for. And I think it's part of our commitment and our value to the ecosystem also to help that happen. And a little bit that's what we try to do in the academy. Since everybody here is kind of intermediate level, I'm just going to say that we have trainings online, like central, developers actually, it's a cohort that is going to start on October 30th. We have this code, but if you're also looking to get into the space, like looking for a job, you might be interested in certifications. Those are certifications that are issued by consensus. There's smart contract developer at CDC. And if you're a developer, basically it's smart contract and apps. Smart contract developer is just smart contracts. And EBP is Ethereum Business Professional. In case you're interested or anything you're looking for a job, those could be things that you might be interested in. And also like I've said, we have here Gonzalo from Diligence. And Diligence, basically what they help you with, and correct me if I explain it wrong as all of these, is they help developers, startups, companies, and basically anyone who has a smart contract to feel safer when they are in the mainnet that they will not make the news because somebody had them. I guess that's one way to put it. And luckily, in consensus there, you know, the people that have really looked into this, and I would say that probably one of the brightest minds in this aspect is in this team. So you can feel very confident to approach them if you have anything with regards to security. All right. So we're going to go a little bit about some code recommendations. We're going to talk a little bit about some of the common attacks that you might run into and some of simple ways or a little bit of simple ways to address it. And I guess most of you have made a, if you're curious, you have already made, especially if you're familiar with this, but we're going to see how the attack of the bell happened. And so you can understand how it run and we're going to run the code. So you can kind of see what actually, what is the problem or what happened there as one of the most renowned attacks that happened in space. So as, this is going to be otherwise, you know, I'll bore you to that. Basically, when you're, something important that you understand is that the smart contract at the end is code. And it is compiled to by code, which is what the Ethereum virtual machine understands and runs. And ideally we're trying to make that code as secure as possible. And if you really, really want to get into the security level understanding, honestly some people are actually, especially for gas optimization, they actually work at the bytecode level. So they understand the bytecodes and they actually, at the end, they work with the bytecode. So if you're really into this, eventually the next step or the next frontier for you is to actually be able to get, to understand what's happening at the bytecode level and actually try to optimize there. For security, not necessarily is the only thing or the most important thing, but it is important that for gas that you consider because sometimes there's, at that level, like even just like rearranging things on the smart contract you're helping. So the important thing that I want to get started for the people that are new is that at the end, a contract in the Ethereum is just another account that is created by a transaction and basically the code is stored there. So as there's two types of accounts, you have externally owned, basically managed by the private key that as a user you hold and basically you are the one who holds and make the decisions. However, the contract accounts are governed and ruled by the code. So they only will do what the code says. That's it, that's why you cannot change, you cannot, you can trust a code that is there because you know that you will only do what it says it does. And you could also trust the fact that it has its ups and downs that no one can change it. One funny story, not funny story, but one of the things when we're like working with the people we're training them and how to get their first smart contracts, everybody, or not everybody, most of the students forget to get the function to get the money out of the contract. You would not, you don't believe how many people forget that because everyone's used to, that the money just ends in the bank. You know, that's the mindset of changing the mindset of how this works. It's actually more challenging that people expect. So you have no idea how many contracts are out there that have either locked or somebody forgot to make the function to get the money out. So it's important that, and we'll see that when you actually try to run here, the fell fast, which is kind of something we heard a lot with web development and agile and everything, done necessarily is the approach for a smart contract. It's actually, I don't know the opposite, but it's important that you are careful what you do and what you don't do. So everything just from the point of view of execution is, the code is just taken by the IBM from the state, from the account. The input data comes in a different section. All that is run based on whatever the function says. And then at the end of the state, the account, the either the storage or whatever information that is there, it's updated. You know, that's the logic of it. And the important thing is that if something goes wrong, you know, then you know that the state is reverting. And that's important because we're going to see one of the attacks and basically that's what you enforce to happen so that whatever function you're trying to run never ends or never gets to the finalization period. So it's always regarded and then you kind of have a denial of service kind of a thing. As you know, from those of you, this is for the new people. Smart contract has different spaces or different scope for variables on what we use, what we do with them and how to use them, how to store them. And from the point of view of the space on storage, everybody knows that that's very expensive on the mainnet. You know, you need to optimize as much as you can for that. So there's like the temporary memory that's the memory of this tag that basically you can have variables that you will only be using while your code is running. But then they will not be there. They will not be stored. They will not be saved. And there, of course, whatever you need to import them which is state variables should be, unless you allocate memory to it, should be on the permanent memory of this, so that you store there and you don't lose that information. Probably the only cases where you want to have something that is usually memory you want to store is if you have a very big array and you know you cannot look through it infinitely because you have the gas limitation. So you may want to store the last position of the array so the next time you run it, you don't start from zero because otherwise you'll never look through the entire array. So those are kind of things that you may want to think about when you're coding and that information that you're going to need for the whatever next call you make with that contract should be in the storage or in the permanent memory. Otherwise, you know, for example, in the case of the array, you'll never look through the entire array because you'll start from when you initialize it in one and it will just go until you run out of gas. So it's very important to take those into account. And as you know, Ethereum has a balance model, not as a UTXL as a Bitcoin. So basically, you know, it's much simpler for a lot of different things and getting like your balance and everything. It's a simpler process. It's just basically a field, a data field in the structure rather than a compilation of all the Bitcoin addresses and everything and adding them up and all that. So it's very simple to use and simplifies a lot of things. However, you know, it does not allow serialization, like a lot of transactions in parallel like the UTX model does. So it has its pros and cons. So basically that's why it's important that, you know, you need transactions. You have to make sure that the previous transaction has finished to get it started. Otherwise, you know, you're not going to have it. You're just not going to have it. All right. So let's talk a little bit about the quick intro that I just wanted to make sure that we get some basic concepts out there. So as I was saying, it's very important that you have to understand that the code here, like in this environment, there's a high pose of failure. And not only from the point of view of security, which we all know, but for everything. If for whatever reason, you know, you need to update or change the code of the smart contract. If you have not really thought about how do you migrate data or how you're going to manage data from the beginning, it could be a very big pain to make that change. So thinking about, it's very hard sometimes when you're thinking about what your smart contract will do because sometimes you don't even know if things are going to evolve, how you actually what all you're going to need in the future. So it's very important that you really, really take your time to think what your smart contract might be doing. And also, maybe if you want to start small and then growing. Because if not, you know, you may run into some problem that the change could make you get into a lot of trouble or like even into like issues with potential users that you have because you have to stop or something. The fact that they're immutable is good because we have trust and you have that, but it also implies a challenge that you cannot, you know, I'll just try this. If it doesn't work, I'll just fix it or you know, I'll just try to fix this at a run time, but that's not possible. The important thing that I was saying, you fail fast is not the approach. And you need to think very carefully how you're going to manage this. Then I guess this is what we have for services that are immutable and they might be there. I mean, I would say like, you know, the doubt thing happened, you know, and you wanted to make a mistake. So it's very important that you are aware of this and you're not afraid to be open to testing it with others, to have it there, use external party services to audit your code for example, like for example diligence or anything to run tools that you have there, formal verification, you know, it's still happening. You know, some people, there's new tools. How is it, Ellie? I think it's a new tool for formal verification out there. There are a few of the tools out there that are coming. Still is an ongoing thing, like everything in the space. Yes. Do you have any, any, do you have any sort of thoughts on MagCorp for like testing and auditing and verification? I have, like, you should use diligence as tools instead of drill bits. We have the equivalent of landing order in the Queen Nun. Oh, really? We're close to the tool, I don't know. Are there any diligence in public? Yeah, so if you go to diligence.census.net or retax.io which enables the suite of tools that have come out of those, right? There's also like a symbolic engine tool, a static analysis tool that they fuzzer. They both, they all work in tandem just like they do in the drill bits ecosystem, but it's basically the same thing they're called. It's symbolic engines. So you should use them. I didn't know that the A-levels had a happy set. Yeah. Mixtex is easier to use. So for people that are just starting developing smart contracts, if you are using, like, any tool at all, I think you should be using Mixtex would be on the line, but. And being is also working on that, so. Plugging is coming through. It's also about the same in writing, or the both Python that both use, like... If you have more questions, you can ask me. And I guess, I don't know if other tool does it, but one of the things that Mixtex scans life, so actually it will help you, like, if some new vulnerability is identified and added to the SWF. This, yeah. They will let you know. What is it used on the upstream? Where does it check for the new vulnerabilities that are compounded? There's a registry of all the data access, so they check about that. If a new thing makes it to that list, they add it, and then you'll go directly to that. All right. All right. And they use also, like, I'll let you so that we'll be able to scan what's already in the main. SWC GitHub, the repo that holds all of the identified vulnerability should pop up in Google. All right. Another important thing, and I usually run into this, you know, you need to make your code or try to keep your code as simple as possible. And usually it's, for example, it's good to start with baby steps in a lot of things. For example, there is this person that we're trying to forget. It was more of a permission. But while in New York, real estate is a big thing, and there's a lot of permission and documents that go back and forth between a lot of different parties, so they were trying to say, oh, let's use blockchain for this. It makes perfect sense, and it kind of does. However, basically what we said is, like, yeah, but don't start with trying to get the whole work thrill on smart contracts or everything about your blockchain, because, you know, it changes a lot. It can change something. So right now I'm starting just by, you know, figuring out a way how to stamp or how to make sure that someone can verify that the document is valid and nobody has to change it. But, you know, don't try to get the workflow yet until you really get it tested and you know that it works and you know that it's not going to change, because if you want to get, you know, governmental board, you really want to, you don't know what they're going to request to you in advance. So first, have it running, get it there, and then, you know, figure it out what becomes actually transaction on repetitive that doesn't change, and then try to go from there. So it's important that you also take those into account. Important thing is, as you guys know, a lot of the things we do is import contracts or use contracts that exist out there. And they're safe. There are some that are safe and you can trust, because the people that are behind them, however, not necessarily everything out there is safe. So it's very important that if you're working with an external contract, you really pay attention to it and you really understand what it does and how, you know, all of the dependencies and other contracts that you use, especially, you know, sometimes you import one contract and it imports a lot, it imports on everything. So you really have to check everything that it's related to your contract because you never know if there's something that not necessarily is a, you know, with a bad intention, but, you know, maybe there's some vulnerability to some of the contract that, you know, that person was just not really that diligent with it and just, you know, forgot to check something or to change something or just did a very, some common mistake. So it's very important that you take into account that. Yes. Or the compiler could be different at this time. Exactly. I think it's, I think later we will also mention that. On the compiler, you know, it changes and everything, especially because, you know, I mean, so literally it's still when there's no one. Yeah. Right. So it's important that you take into account everything there. And, um, so now let's get a little bit more about those recommendations about the code and a few things. So some codes that we're going to see, you know, like basic mistakes that people made is you know, how is it executed? There's, it's important in the order of how things happen. So the last thing that you want to, that you want to do in the code is to send money. You first need to make all the change, all first check all the conditions. It's very important that you first check conditions so that you know that everything's correct. That's, you know, normal programming. Then affect all the state variables that need to be changed because, and this is what we're going to see, re-entrance attack happens when, you know, I first send you the money and then I change your balance. In that, in that small period of time a fallback function kicks in and, you know, gets all the, all the, all the hacking. And so it's very important that you always try to remember prior to, to live, to do everything that implies an external thing of your contract for the last. Everything that is internal to your contract should happen first. And it's very important that you always make that, you know, your everyday when abroad. Your everyday, you know, like, don't forget to do that. That's what I'm trying to say. Then you also think, another interesting thing is that if you have a fallback function that you check that, you know, whatever it's coming in when it's called that it doesn't have any strange data on it. So you get out that small require there just to make sure that, you know, there's nothing strange coming in to your contract for the fallback. Important, as there was mentioned, you know, changes happen in Solidity very often. Like, new words get deprecated and it's impossible to know exactly what will happen in the future. But as much as you can, try to work with the most reliable and up-to-date version of everything because they're introducing changes quite often but those changes are really important and as much as possible, try to always work with the most latest and most stable version of whatever is out there especially with the code. And just like he was saying, it's very important that you fix the compiler to a specific version. Even if you could put like anything from here and above, usually that would work but it's better if you fix it and you leave it fixed so that you never get the chance that's on word deprecated or something could be done in a different way because you never know every time you fix something you broke something somewhere else so you never know what other back door will be open when we close one. So it's very important that you always at least as much as possible try to know what you're facing and of course the picture of challenges that you might be running into. So we're just going to explain a little bit based on that like the re-entrancy attack. I know that this I don't let me see how well in you guys see this but I'm just going to quickly show two smart two simple smart contracts just to show like the malicious and the vulnerable contract there's there's nothing really complicated here for those of you also knew I don't think you're going to have any issues understanding it but basically this is just a contract that just gets money and you know it will give you back one ether at a time that's that's all it does that's nothing they're just two functions well that's basically the deposit that it will just get money one ether or more yes yeah good idea, thank you probably better so basically just get one ether or more that's it nothing else just for the purpose of the exercise there's the function that takes the money out and this is what we're saying the issue that we have here is that your first kind of sending the money and then you're affecting the variable the state so my balance is like oh okay I'm going to give you five so I first give you five and then I go and write it down on the ledger that's the issue that basically this contract has and then you just have you know a function just to get balance so that's what you know the vulnerable contract has this is the re-enterance you know then the malicious contract honestly the only thing I'm having is as probably you'll know or most of you probably know you can inherit as an object or in the programming language basically what I'm saying is just I'm just creating the I'm just inheriting everything from the contract and I'm just passing it the address of the contract that I want to attack because I have that with the address and you know you can import it there really depends on how you do it basically there and then you just have everything and the important thing here that is where it is if you see I have a fallback function and the fallback function is just checking if the contract has one has one one ether or more that's if it does it just asks it calls the function it will call again that's what the fallback function is doing here rather than being just an empty thing where you are just you know just have it there just in case or whatever something consider something I have actually a piece of code that will run when this function is called and basically this structure is similar just have it there so because the internet connection was a little bit bad I just don't want to take any risks so here's basically this is the code of the same code I'm not really going to make it that big because honestly you've seen the code trust me it's the same thing and so basically I have the two contracts employed right everybody knows Remix here I figured yes I know there's some people there's you so basically all I'm going to do is like let's say this per die over here it's going to 10 here right so I deposit to the world contract right so if we get the balance positive you got it balance all right oh yeah I don't know if it could be much bigger but it has 10 1099 that's what it has right if you get if I get check the balance of the malicious contract it just has 22 so the only thing that right now if I just want to get it out I just I need it the first with the contract the first thing that I need to do is that I need to get this malicious contract in the mapping in the in the contract that I want to attack right so the first transaction that actually happened is with this contract deposited one ETH in the vulnerable contract so that it is in the in the making of people that could withdraw money because if you read the code you could see that you know if you're there that's the only thing that the previous that happened there right so now the only thing I I have to do I know that this is the attacker's address I'm just going to withdraw and if you see it takes some time because it's just it's just running and if we just check this balance here you see now it doesn't have 10 you just have the 99999 because I took all the 10 ETH out if I just check this contract here you see it doesn't have 22 32 but the code says only to take one and then get the money why? because what's happening is that at the time that they send me the money in the in the malicious contract the fallback function kicks in so it calls the function again so the function sends another money calls the function again and it just stays there until the condition is out which is when you don't have one ETH that's why I'm there so that's the ETH attack and something similar to this is what happened with the Dow and it's something that it's not really hard to avoid it's just as we were explaining before it's just a matter of how you affect everything so whatever you're doing externally to your contract should always be the last thing that the function should do after any basically before any after another kind of a common attack how many of you are familiar with the ETH or a general attack so I'm going to go into more into it basically there's how many of you are familiar with the MSG.Sender construction or keyword so MSG.Sender basically just gives you the address of whoever is whether that's a contract or a person you get so as you guys know what happens a lot in this space is that you actually have some person that sends something to a contract and that contract may call someone so for whatever reason the third contract or the second contract in this equation wants to know because you are going to send money and you don't want to send it back to the to the first contract so potential reasons for that you use TX Origin so you know which is the address that started the whole transaction itself right so that's handy in that case so if you're being withdraw or like taking money out it would be handy so you don't have to pay for whatever reason anyone who's in the middle right or like or have a lot of transactions happening for everything that is in the middle however it also could work to impersonate someone and what happens is that let's say what's your name Felipe Felipe so let's say I want to to impersonate him so what I would figured out and let's say your name is? JC JC so the contract he wants to really track with is JC so what happens is that I figured out a way to trick him to think that I put whatever it looks like it or something and he thinks it's wallet or exchange or whatever thing I just figured out a way to trick him so he will send a transaction to me and what I will do is then then I will send it to JC right but because he uses TX origin then he's going to think that it's actually him who's getting the money for whatever reason depending on how the code is I would be able to perhaps go funds because still he's just going to refund the TX origin address but I might be able to break something or to maybe get it in the fallback function or do something there that you know I don't want that thing is not really accounting for now that's that's the hard thing here where your code is hoping is that people could be really clever and figured out how to attack it so that's why it's important that's simple so that's a little bit about the TX origin you can use it but you have to be careful for what you use it so that you are not really opening the door for someone to if they manage to make this trick to try to do something to your code or to take advantage of anything that is in your contract and so sorry so another thing that could happen is similar which is kind of a denial of service kind of a thing I don't know that's the best name of it basically what happens is similar let's say this is an example of let's say I have a magazine and you subscribe to it and you pay me monthly or for whatever you pay me on a recurring basis but I also have in my function that refund fees for something I'll refund everybody I'm shutting it down I'm refunding everybody because I'm changing the code to a new code people just for them to be happy I'll just give them because I'm going to change the smart contract and have a new one I don't know whatever you know you can figure it out so in this case it's really hard to find a specific one but let's say that I have a function where I look through the array of all my the people that have been subscribed and to refund everyone so basically what I could do here is that I could get rather than someone's like an externally owned what happens is that when this person is like okay I'll give you back your fee and I pop your address out what I actually do is that here I have a pullback and just get it there so that this function never finishes because I just keep the track I'm not earning money out of it I'm not really doing the only thing I'm doing is just to break your system there's not necessarily any economical gain for me but I just find a way to break your system I think that happens is basically that so because it will not happen or I could put a condition for example like one equals zero that's false it will always be false require one equals zero that's always false so it's going to give back an error so this thing is going to revert so you're never going to be able to pop my address out of the array and you're never going to be able to look through the entire array I didn't get any money I didn't got you know maybe cause you a lot of pain with your users because of course if you don't have any other functions any other way to refund the users you're not going to be able to refund them right so this is why I would say it's very important that you have to think about all the things that could go wrong and again it's as simple as first take that address out affect everything internally in your contract then do whatever you do that could not necessarily solve everything but probably will help you a lot so how do you face this vulnerabilities like I said there's the SWC director list which you know there you could go it's very it's you have examples of code there you have examples of solutions there so definitely a resort that you should check and that you should pay a visit every now and then because it's outdated but there's also called design patterns there's things that you know people try to put in place so that you kind of if you implement those in your code you're I'm not going to say you're bullet proof but at least you know that you're prepared to face some of the most common things that until somebody more smart or smarter comes in and finds another backdoor you're going to be able to at least protect yourself better so I'm just not going to go through all of them this is quite simple and even you know so for you might be obvious we have it for a reason it's very important that you try to take advantage of the modifiers and have permission to who could do what because if not if you just have it public or if you have it or you didn't put private or you didn't have anything anyone could execute something and again sometimes people forget how different it is to work for you guys like second nature now but for other developers that are more used to on premises or all the kind of things it's a shift in their mindset so it's very important that you also forget don't forget about these kind of things so take advantage of the modifiers to use them as who has permission to do what on your contract then kind of what we're saying it's very important that you know you do who can explain the difference between require for conditions when to use one yes it's about spending on the gas or not one difference is that assert will take all the gas that you have there require will give you back in case of failure will give you back the remaining gas yeah that's true yes assert should never occur at one time that's true so usually you first use require and you leave assert for how it happens like whatever is really extreme or everything should you know the 1% thing that might happen that could break or something important you can think about I'll add to that like the reason for you to use assert is assertive variance things that you never want to happen right so like if you let's say if you don't want the balance of your smart contract to ever be one the way you designed it should never be below one either the way assert is implemented in solidity is that it actually uses a different outcode right as opposed to the outcode has the reverse instruction now what this allows is that when you use like formal verification tools be like from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from that some of the people that have made ICOs or something like something something that they have or something they had like a search like if the transaction is over 10% of the volume stop it. So what's the benefit of burning the gas for a search or is it due to the extremity of it you want to there may be like a game theory or an incentive behind that but I think that the way they're used today most please that they should never be treated so like that's why we've heard is better right like in the beginning but if they the ICO that actually returns the remaining gas to the user it didn't exist right to the guy who paid for the transaction that didn't exist so this is all you have. When the revert ICO came into existence it doesn't make much sense to use this unless you want to and these are again these are meant to be invariants stuff that will not happen effort by specification so you're basically you're basically specifying here you're basically translating intent into solidity. It's like you're saying this should never happen and if it does I want everything to stop and that's when those automated tools that I said helped you verify that your assumptions were wrong. So I'm sure we do want to certain like there should be this remaining I think it should be above this limit. I know that like I said in some ICO contracts my contract some of the changes they did to the AC20 was that if there were two transactions that were like about 5% of the total token supply or a few things like very strange things that should not happen on a legal normal basis to have that stopped. So one example of this is maybe more confusing than it is not I don't know you tell me but like one good example of like the revert versus a certain discussion is Safe Math by Opens Up. You guys know what Safe Math is. The library that actually checks that there are overflows and underflows and whatnot do not happen right it's a safe way to do math and basically it was implemented with asserts and what this meant in Opens Up it had was that if it's an assert it should never happen. So your code should already make sure that overflows do not happen. However people were not using it though. People were using it to protect themselves from opens up and it's intent right. So Opens Up in Green World Safe Math is referred as opposed to asserts because now it's a safeguard. Now it's supposed to protect you at runtime as opposed to never happen. I don't know if this is confusing or not but I'm having to talk to you later in this sense about this. I can talk to you all about why you do more than the other but it sounds like the only actual technical difference between the two is one of them which you have to guess rather than the other. It sounds like that's the only actual difference in terms of what it does. Is that correct? Yeah that's the only actual difference. Yeah. Yeah. Is there a gas difference to that? Are there any slides from Opens Up? I don't know. I think they all stop execution so they have no problem. Yeah. Mark statements all you do is require statements used to report off code so like they actually return gas to reply. There was a bit how you put in like a message. Yeah. Oh yeah you could put that as well. Yes. This case where there is not existing but yeah you could put like a not something whatever condition you just want to know and just put it out there. Yeah this might be like earlier code at the beginning to require statements didn't even allow you to put messages and now they both used to report off code and they still didn't meet the event before stopping execution so that it's not even notified. But it's important that I mean that you always try to make sure either with a require, with if statements or assert depending on you know kind of a thing that you always check for behavior of your contract. You always test that because at the end that's the most important thing that your contract behaves as you expect that it will behave. Then well like I said basically this is just all the tech and tech interaction which is just you know everything internal then external and basically you know update every requirements, state variables and then whatever goes external or payment and all that. That will save you a lot of trouble and it's very simple to actually remember so don't forget it will save you a lot of time. Then there's also time where you may want your contract to stop running. Like for example like I will say you know this guy's from the ICO they figured out that you know they're being hacked, they managed to stop. There's no such thing but you know they never know something else will come and they know I want to stop. I want my contract for a time to stop. So you could have those and they're not that difficult just you know a Boolean thing variable. Basically that only specific person with the permissioning to do it will open or close that door and have it there so that you just make sure but you could have this emergency stop in case something happened you know you're finding out that oh somebody's figuring out a way to take money out you know not happening. It's happening right now as I see the money going down I want to stop this or something. It's very important that you consider all those kinds of things and like I said this is just like thinking from the beginning it's like do I want it, do I don't want it. You know it's very important that you stop to think about your contract what features you want to have in your contract because once it's out there you know it's pretty not that simple to make changes to it. And sorry do you then add in like the stock flags throughout your code like do you check against that or like? Yeah basically I cannot turn this and but basically if you see at the end it's like emergency withdrawal in this specific case what you just have is like yeah your contract has to be stopped and for whatever reason like somebody's taking the money out it's not safe so you tell like hey it's not safe I need to take the money out I'm allowed to do that. So you stop it and then you take all the funds out you know so yes you put it there and under the circumstances that you stopped you check that that variable is stopped or like if it is before any payments you may want to check that it is it really whether you do it or not it will depend on you know how credible it is or how important it is but you could always have plaques that could allow you to stop something or even to put timers or things. Here's the stop go no go but you could also have a timer for example so that something doesn't happen you know 5% of you cannot withdraw or 5% if not in 24 hours kind of a thing you know for example you could have something there for that. You usually have like a modifier like not stopped that you can throw at different functions that you want to make sure that you only call this function that it's not stopped. It usually opens up and it has like very standard libraries to do this or just contract safety in there from their framework. I'm talking a lot about opens up and if you guys don't know If you search for opens up in Google they have a bunch of stuff including their framework which is not they have an OS and they have like the normal like solid reframing that just has a lot of reusable components that you can try to plug in. Then you know like all variable contracts although kind of thing basically what you have there is just you have proxy contract that is the only thing is just being connecting you between data and the logic of the contract sometimes. So in this example for basically what you just have here is that you know you have what's called the latest version of the contract that you want to use for whatever thing that you're running or for whatever process is there that you want to have and basically this contract the only thing that it does is just holding the data. Right and so basically if you needed to change because you change the logic of a contract you deploy the new version of a contract let's say in that new version you added the stock for example right for whatever reason. So you would come here you would update the you'll tell it now whatever thing that happens you have to interact with this new contract that I deploy so you kind of give it the new address point to rather than it's like I was working with this contract now you tell it now this other contract. So that contract that for whatever reason you no longer want to use you know you can disable it you can self destruct it or you can just leave it there whatever you want to do but now the important thing and this is kind of a way also that you kind of a split a little bit of like the data and maybe the logic, the business logic of your application and have that. So it's called the same pattern of internal storage in case you want to go to the degree value because honestly it has a lot more things but just to make it readable we kind of short it a little bit. Another and this is more about like a recommendation things is like you guys know like I said the storage is important everything is by 32 word and all that. So even if it doesn't seem like a big difference or like something that you would say like the ordering how do you order your state variables matter because if you're able to pack them in 32s in back to 32s and everything you make a more optimal use of space and it actually reduces gas consumption. So another recommendation there is you know when you have your state variables and you have everything there you know for whatever reason you figure it out how to better arrange them. It could be important depending on a lot of the circumstances of what your defined contract does or what you're doing if it's a contract factory or different things out there. It could be a good optimization to consider. So you always pack variables into like little blocks of 32 bits? Yeah for example here you have a 16, 16, 32 and 16 what will happen is that basically you're not going to there's going to be empty spaces in the middle because the word is 32 so it's 32 and it's 16 now I need to put 32 oh I don't have space so I use another space in the stack. Oh now I got 16 so there's going to be empty spaces so if you put 16, 16 they're going to be better packed. Well this may look dumb but the way this little new compiler works by reading from top to bottom like whatever happens you'll always read stuff from top to bottom and the reason why is so this way it would read 16 bytes and it would attribute it to a storage slot and then the way it works this way is exactly because there are storage slots that can't be used right so this would be storage slot number zero and now it tries to write to the second slot because obviously if each slot is 32 bytes these 32 bytes won't fit in the first slot now if you do it like this this little compiler will put this in the first part of the 32 bytes in the zero slot right and then it still has like another 16 bytes addressable bytes and then it takes these just like puts them in front of BAA I was thinking this, I think the C compiler actually does like actual C does like packing optimization I don't even know what it's called I don't even know what it's called What do you mean? Yeah this impacts it up so like actually like solidity has like everything is 32 bytes Right, exactly, that's it Does that work for you? If you put this in C you'll kind of like Is there any mention of the whole C compiler? Sure This gets complicated fast I am not complicated but like this gets tricky fast and the reason why is that is because solidity has inheritance right and each of these slots they are shared in between contracts so like if solidity, if there are not like if there isn't like a clear ruling a clear rule as to how solidity does that type backing and then right now it's from top to bottom maybe like a better solution could we discuss even though like this it's just a spec to do this right like you can do it a million ways but like this is how it does and like if you inherit from this contract the layout storage at the inherited contract will be exactly the same right so like solidity like just like randomly affects stuff in different places when you inherit this from another contract or when you exit storage like for any reason you wouldn't be able to map it to where at least different variables are I guess we have this we can also talk about this over years and I'm interested in getting into it What's the difference between transaction costs and execution costs? We're going to have to correct me if I'm wrong but basically the transaction for example like sending one E is 21 that's the cost of the transaction but it's not the gas cost it's far more than one so like transaction costs at least like 21,000 gas because like that's the main contender this might I don't know this might be wrong in the sense that this may be I may have written this and what I meant here it was that by execution I mean like when it has been executed at least once first I don't know Yeah it doesn't make much sense to talk about execution costs if you're just deploying