Smart Contract Security: Solidity Exploits & EVM Deployed Code Updates

[00:00:00]hello and welcome everyone i'm peter robinson and this is the ethereum engineering group meetup so today i'm the one who's going to give the talk and it's all about security so smart contract security and solidity security so a tiny little bit about me um about 30 years experience developing products of which i did 13 years at rsa doing cryptography and that sort of stuff and five years at consensus working on blockchain things and with that i'll share my slides okay so can people see some slides i'm getting some thumbs that's good thank you all right so i didn't do all of this by myself i've had help and it's nothing like being able to say run slides past people and have them go they're good they're bad and i don't know that i've got all the names joanne your name should be there because didn't you you've pointed something you did all right joanne's name's there as well um so yeah there's probably a few other people who i didn't get back and edit the names in so anyway um so sorry about that and thank you everyone so today i'm going to give a um sure we can have a transcript so um all right so um today i'm going to go and give some overall context and then we're going to talk about the ethereum client the um evm um abi and solidity and then talk about high-level things to consider um dive and then we're going to dive into solidity and work out some of the issues related to that and then we're going to work on some complex stuff and also some tools that are out there and so by the end of this talk i'm actually going to go over a really interesting thing and that is how to change the byte code of a deployed contract and this is without actually i'm using proxies this is actually the deployed code at a certain address how to change that code and i didn't think it was possible before i started working on this talk but i now know it is so you might notice the dark forest background and so the dark forest was a term introduced by a sci-fi order author and i'm not going to even try and say the name but i i believe it's something like yui uh she shen but that's probably completely wrong so anyway they're a science fiction author and they had some world where as soon as you identified um someone else's location then there were these super predator things that would come along and kill them and so dan robinson and georges costanzanopolis they brought the term to the crypto space to identify the adversarial environment of the ethereum mempool and so what that was all about was that once you you say here's a transaction that could earn some money then other people see that and they say hey and they grab that and they get in front of you and they front run your transaction so i'm going to reuse that term in a slightly different way because if you've got a weakness in your contract then you should expect people and bots that are created by these people to find weaknesses and exploit it so um you know ethereum is a dark forest and so um you should you know watch out when you're working on stuff and so yeah so we're going to journey through this dark forest and hopefully survive so some context um so there are two subtly different but maybe the interrelated things and there's smart contract security and then there's solidity security so smart contract security is security where it's really defined by the properties of the evm whereas solidity security it's really you're writing that smart contract in the solidity programming language and so maybe there are some overlays on top of that and so you know what does a contract actually have so it's got some code um storage balance and nonce and you know generally the code can't be updated so i am going to tell you how to update the code later on but in most situations that's just not going to happen so you're worried about the storage and balance and the nonce unexpectedly changing in ways that you would prefer they didn't and um that includes self-destruct which is obviously a really special condition where you essentially wipe out everything and remove the whole contract so that's a rather undesirable state change potentially and um then another one is um that you've also got the possibility of the whole contract getting stuck and so what that means is that the contract you know suddenly can't be used anymore and um if you have the have the contract so it can't be used then that's also going to be really annoying and not what you want so when you're thinking about um blockchain um you invariably you know you really you've got to be thinking about the whole application you're writing and so invariably you've got a set of contracts um you know it's not normally just one single contract it's a set of contracts that call each other maybe you've got some off chain node that talks to those contracts that might might use infuria or some other gateway service to talk to the blockchain you're going to have some admin that's going to use metamask to fire some transactions in you're also going to have users that are going to have metamask or maybe some other wallet and they're going to interact with some website and that website's going to have linkage so that then you can open up metamask to submit some transaction for some on-chain activity so that's a pretty typical sort of application and um you know so the thing to think about is that the smart contracts are just part of these larger applications and these attackers often target other bits of the application they don't necessarily target your smart contracts and also as i was saying you know you've got to think that these smart contracts aren't just by themselves um they're typically um you know like in a group so you've got to look at the whole group of contracts and also you've got to analyze them separately so um you know you've got to think about the whole context and you've also got to think about um the users so um with a recent attack it was really about um social very complex social engineering i mean it was about bad devops as well um but it was also about really really clever um social engineering of the administrators and so you know you really got to think that it's more the security of your application is more than that just the contracts um so you know when you're looking at your threat modeling and i encourage everyone to do threat modeling of their application you need to look at your attack surfaces and obviously this the smart contracts are going to be a really big public attack surface but there are others and so don't ignore them otherwise you know you will be hacked and it won't be by your smart contracts it'll be by other things so saying all of that now let's actually look at those contracts and so when we think of smart contract security really we're overlaying a few different things all together so you've got your ethereum client which is the software that runs the ethereum node you've got the evm which is something that executes inside of that soft software you've got the abi which defines how you interface with the overall program and the solidity programming language itself and so you really need to understand all of these things to be able to do good smart contract security and so what does the ethereum client software give you well really you've got two different types of calls you can have so you can have eth call rpc method and that's typically used for view calls and so what you're doing there is you execute the contract on a local node and you get a value back so you're not including that in the that that call in a block and so you can't change state so even if you you called something that could change state those state updates aren't going to be become part of the blockchain simply because you're just executing on a local node if you use on the other hand eth center or transaction rpc method then you are giving yourself the opportunity so you submit a transaction it gets included in a block and then it gets executed and so the um the evm you know will either commit or discard those updates then depending on what the last op code that executes is so if the last op code is stop return or self-destruct you will update the state but if it's revert or invalid then you're not and so it really comes down to you know how this how the code executes but i think it's really important to understand that you know just at a very high level you um just the ethereum client software can say whether these states are going to be applied or not just based on which methods you call so normally you're going to call each raw trend central transaction to update the state and call when you're doing a view call but it's useful to understand those two then you've got the evm so the ethereum virtual machine and so this is defined by the yellow paper and so the yellow paper has been updated quite regularly and so when you have forks um in ethereum you'll find that often part of it is to update the evm maybe the gas costing or something along those lines and so all of the byte codes are talked about described in the yellow paper and so with the evm every single contract starts at offset zero and so it doesn't matter what functions you've got what you've got what language it's written in as far as the evm is concerned everything starts at zero and it just goes through and executes each individual instruction one at a time and so then yeah so you've got to think that whether it be a view call or a transaction you're doing a cross-contract call or it's an unique code segment that's what's happening and um so the other thing that the evm is giving you is things like return and so for instance with an init code fragment um you're copying the code that you're going to return to offset to a certain offset and then you then the return code is used to say well data at this offset and this length should be taken as the return value and then the evm when it's the init code it uses that returned information as the contract code and so that's down to the evm the abi is something which is completely separate to the evm and it defines how contracts of any programming language should communicate with each other and so it um so it's strongly typed and so that means and it's defined at compilation time so what that means is that you have functions that um in your contracts and they define um you know what what parameters they're going to have so the abi doesn't support the idea of having some dynamic parameters going into a function it just doesn't support that and so the abi defines how functions are called and so it talks about say the four byte function selector so that's essentially the truncated hash of the function signature and it then has the parameters so all the parameters are done as 32 byte blocks in in the overall overall call data and so um you know for instance you've got that 20 byte address and it's stuffed in with 12 bytes padding and you can have arrays and anything that you can think of that you have as um parameters to a function they are encoded using the abi and so it really comes down to you know you can read the abi spec to understand how all that encoding occurs and so the abi isn't just used when you're calling functions it's also used in return values so say if you've got say you're returning a uint256 and an address that will be abi encoded also when you've got reverts or panics happening you will get the actual function selector followed by the function parameters are encoded as a return in that case so you have panic unit 256 or error string and you can also with recent solidity versions have your own custom um different error messages as well event parameters are also encoded using abi encoding and then we've got solidity so it is a language which compiles down to evm byte code that can be executed in the evm so it's not just that it compiles to bytecode but it's byte code that is designed to start it off set zero has a init code that will return the code to be executed at runtime and follows all of the other rules of the evm and it also follows the api encoding rules so it knows about function selectors and it decodes parameters based on that abi code abi specification and so solidity has actually a lot of extra features that are not part of the evm so often people think of stuff as being just part of the smart contract and as joanne pointed out there is actually a lot more and really understanding so understanding the difference between what the evm supplies and what the smart contract supplies rather the solidity compiler supplies is really important so you know when you think of payable and the enforcement of payable it is really down to um the people who created the solidity compiler um noticing that keyword and then saying all right well the value of this transaction if it's not zero then we should fail because this function is non-payable and then there's a whole stack of things you can see there that are things that exist in solidity but don't exist in the evm and so to really understand what the evm specifically gives you and have a look at their youtube video that i've got a link to there and so all of these features and some of them are really security features like payable certainly isn't say the revert chaining across um or across contracts um things like that are certainly security features and when you're using solidity you are assuming that the compiler creators um created it without bugs and you know that's probably the case but um you know it may the compiler hasn't been you know fully verified and so there may be bugs in the solidity compiler itself and as well the in solidity you can dive into assembler code and a lot of my examples i'm going to have later on do dive into assembler code and so once you're in assembly you can do anything anything the evm can do you can do and so um so you know given that you can dive into assembler code from solidity then maybe smart contract security and solidity security are the same thing and i don't know what do people think is that a fair comment well there i mean there are obviously other smart contract languages like viper for example i guess true that is true but is viper security the same as solidity security in the same smart contract security have we got down to the same thing or i guess the evm is the fundamental right so so there's also a huge uh trend at the moment which is building secure languages to deal with security features so that that has not made it yet to the smart contracts world but there are some people designing secure languages yeah yep that's true so i guess at that point you would have a separation but yeah all right so what about security so here we are we haven't actually talked about security yet so let's talk about security and my top level advice before i talk about security is have as little in your contract as possible you know if you could get away with one line of code that you know just stores one you win 256 and gets it then maybe that's what you should do so it's going to be cheaper it's going to be simpler there'll be less to go wrong and it'll be harder for people to hack so less is more when it comes to smart contracts top level thought so some high level things to consider let's talk about upgrade and so there's the proxy pattern and then there's the pattern where you have data separated from your business logic as ways of upgrading but the proxy pattern's a really good one and i think quite commonly used so upgrade it's a good thing because you know let's face it coda has bugs and you might come across a bug and you want to upgrade your logic and so that's good also you might think hey i want to add a new feature to my code but of course when you upgrade you can inadvertently introduce some errors and so that could be either in the data used for the upgrade or the code itself that you're upgrading so someone could have been using a contract for years that was nice and solid and now you upgrade it and now you've suddenly made your user vulnerable so that's a that's a big thing as well some people they'll look at the code and they'll say well this code can be upgraded so you could add in some attack method like withdraw all coins and you know that's not a good thing i i wanted to not be able to have people just steal all the money and so the other thing is well who gets to do this upgrade who who chooses what group of people or single person and what security procedures do they use and can they be hacked so say if you need three out of four people to do stuff but they all have their password stored in text plain text somewhere on their computer or on google drive or i don't know somewhere and they get hacked some malicious person could do the upgrade and maybe they could um put in the withdrawal or coins things or even if you trust people running the thing if you don't trust them to be secure it's a big issue so upgrade is a top level really hard thing to think through and um so nomad recently did an upgrade and they've got hacked for 150 million and um hermes is going to talk a bit about that so he's doing a cross-chain security talk in the coming weeks and yeah not going into the details and not even fully understanding all the details because ms is the one who's really hammering home on this but the end of the day it's an upgrade issue and so you know upgrading is something that needs to be not done lightly and you know done extremely carefully another thing to think about is pausing freezing and banning and so pausing is the ability to pause a contract in case of an emergency so for instance in the nomad contract if they have had a pause feature at the right spot when they you know maybe they noticed 20 million disappear and they go oh my god they could have hit pause and stop the other 130 million going out the door so you know that would have been a good thing and so um before i talk about pause a bit more you've got to think you've got these in solidity you've got something called modifiers and so the idea is you define a modifier and then you say you define a function that uses the modifier say a mod which takes a uint256 and so that effectively means you've got um that function and it's now surrounded by this modifier code so that you know some code executes before the main functions typical code does and some code executes after and so it's good for if you've got a lot of functions that need the same type of modification like require owner recalls this authorized or message center equals owner or something like that so in the context of pausing you um if you look at open zeppelin they've got a plausibility contract and the idea is you inherit from that and you get this modifier and so essentially it says well if i'm not paused then let's just keep on executing and so at a cost of just 2100 gas um you're able to um you know add that capability to your contract and so or to a specific function in your contracts and so you could just add that and then you then have the ability to pause um freezing and banning are a slightly different thing so say there's someone who um you decide a person non gratis so say for instance um the recipient of that 150 million dollars that has been stolen maybe you think that they should be banned or maybe um and so banning would be to stop them using your service stop them from depositing or withdrawing frozen would be that they can deposit but they can't withdraw and so um you know the you could use that to control the dresses that you decide are no longer able to use your contract and that could be particularly important if say you had a law enforcement agency telling you look you know this belong this address is related to some north korean hacker group and you know they're just not allowed to use your service anymore and so that would be a way of doing that and again you're going to be say dealing with every time you're reading a value it's going to cost you 2100 gas and say if you've got two addresses in some sort of transaction then that's going to be 4200 so it's going to cost a bit of gas but then it would give you the ability to freeze or ban addresses okay so what about front running so um i'm um borrowing this code from a guy called yet rodrigo and so i've sort of boiled it down a little bit but have a look at this code and um so the idea is that you deploy the contract and then anyone can send money to the contract and then anyone later on can call the underscore transfer method to get the um the balance of the contract sent back to them and um and so yeah you can just um have money sent to you so someone deposits money then anyone on the planet can call this and get the money back does anyone know what's wrong with this contract what's the issue is the issue that there's likely all right the tradition why don't you go well it's more likely that if you call this someone will front run you put an extra an extra tip on the gas and will will execute the transaction before you exactly right exactly right i'm sure that's what you're going to say too david yeah i was just going to say because it's unprotected right there's not anyone can send it which means anyone else can send it if they see that you're trying to send to it exactly and that's what these general i think how the general purpose front runners work is they'll look at a transaction that's being executed and um they will just try and execute the same thing with their own message sender and then look at what the outcome is is the is the um the balance of the message sender now suddenly higher okay it's worthwhile sending or if they send that transaction is there any of the other available functions on that contract available that they could call it and then their balance would be higher so if that's what it's all about is determining is there any transaction they could do that's being executed or secondary transaction they also look for cross-contract calls as well so say this resulted in a cross-contract call they would also look at them to work out is there a way of message sender becoming more wealthy and so how you can prevent front-running attacks is using commit reveal schemes so essentially um you commit to some action and you tie it to message sender and then the the contract stores that commitment and then to execute the action you reveal your secret and so you know you can imagine you could have say claiming a bounty proposing the purchase or sale of something or even that simple example we've just had and so um i haven't tried to i've compiled this code but i haven't actually run it so um there may be a bug but my how i can imagine you doing it is you would have a register function and so you would register to say that you want to with do a withdrawal and um you put in a commitment and then um from then on you've got one day to um to do it to do the withdrawal before someone else can come in and propose another commitment and so um yeah so you propose the commitment and then the transfer you notice in that line there and it's got commitment equals of the encoded secret comma message sender and because you're hashing in message sender it really is going to link it to you the message center and there's no way that someone else is going to be able to um front run you on that but maybe you know you don't want to hold it up for one day between when you submit the register transaction and transfer because that might be um you'll limit that so the other way you could do it is allow everyone to put their commitments in in parallel and so in that case what you do is you put your commitment in and it goes into a map so of all the possible addresses and then you say well for you have you got the right secret and i i would speculate that a front runner would not be able to work this out not a robotic front runner if there was a human involved they could sit down look at the code work it out and do it but surely there are i mean unless there was lots and lots of money involved in this no one i think is going to have enough time to invest in trying to write a specific front runner for this so a generic front runner i don't think would be able to do that um does that look good do people understand what that code is doing i guess is probably the bigger question yes he's reboot david you look you're staring intently you've got your video on so i can see that you're staring intently does it look yeah we'll look at it later on pete can i ask a question yeah sure uh so can you just just drill into this a bit more can you explain how somebody would use but generate the secret and use the secret to to work this contract ah yeah sure barry um so what you would do is offline you would generate um secret so secret's got to be a byte 32 so 32 bytes to 56 bits i generate a random number um you'll you notice that we're using encode packed so that means that message sender which is a 20 byte address is going to be encoded as a 32 byte um value with you know zero field so you would create that 64 byte blob which will be what you'll get when you go abi and code packed and then you would do the kick act 256 and work out the commitment first and so you'd submit the commitment first and then um you'd just be able to submit the secret and it should just work so when you say work out for commitment what do you mean oh you would calculate the um hash so kick at 256 of that 64 byte value being the secret concatenated with the message.sender address yeah okay so the commitment is actually just a concatenation of the secret and your address yeah and hashed dashed yet yeah and the hash is the important thing because it's the output of it is a bytes32 and because there's no way that anyone is going to be able to find a collision so find another um secret message sender combination that will collide with it um not not with a kick act 256 it's um yes it's very secure algorithm so it should be good i'm just curious that you said that a human might be able to work this out and i don't see how a human could yeah how they could is um if i was sitting there i go oh this is how the algorithm works so then i would then have um i would then register my own commitment so i'd calculate my own i'd have obviously a different message sender because i've got a different eoa and i could come up with a different secret because that doesn't matter and then i would calculate a commitment and then i would put that commitment in and then i would call transfer and because the only guard here is that require statement it's whoever gets in first for the calling transfer oh i see so it's right you're just great you're creating your own commitment okay yeah yeah and that's the thing that is the difference so that previous example which i've now got on the screen hopefully you'll see in a few seconds this previous one there was only one person you know so one person got to call register and then one then they got to call transfer and no one else could call register unless it was timestamp was greater than timeout and timeout is set to now plus one day so essentially even if you know you register and you plan to call transfer but then you don't you've only got one day and then someone else could come along and register cool thanks pete yeah okay another way of handling the front running is batch auctions and so the idea is that um so rather than having individual orders go in and then people saying hey there's an order going on here i'll try and get in early and then manipulate the price um if everyone goes in at the same time or if everyone's orders go in for one whole day and then you process the matter batch and you essentially get the average price then there's no time incentive to front run because it doesn't matter whether you jump in first or jump in last as long as you're within the time period everyone's going to pay the same price and so that's another way around it okay another high-level thing to think about is checking the deployed configuration and so um cello optics um that's actually another cross-chain protocol it actually had a it wasn't a hack they just had a a incident where their whole system went into what's called recovery mode and so the whole thing stopped working and there's a big saga related to someone being fired for a misdemeanor and then 15 minutes later the whole thing's stopping but it turned out it wasn't james preswitch the person who was fired um who did it it was someone else um so um yeah but so the bigger question is so what on earth happened you know so the recovery mode should have been controlled by a multi-sig but it was only an eoa so it was only a single externally owned account was the controlling address for this recovery mode thing and not a multi-sig and then there's this recovery mode time lock that supposedly gives people enough time to go oh no i don't like what's being proposed i'm exiting my money i'm you know taking my cricket back and going home but it was only set to one second so you you know so you had should have been multi-sig should have been i don't know a day and instead it was one year away and it was one second so what you really what i think this is telling us all is that even if you've got these great intentions you really do need to check the configuration of the deployed project to make sure that you know someone hasn't deployed the whole brilliant system you've got in a really bad configuration and as well if the idea was that this time lock was going to give people enough time to react then maybe they should have had a same minimum value in the contract which said look that must be at least i don't know one day you know and one second is just not a possible value and i think that that would have been a good thing okay so we've talked about high-level stuff now let's talk about solidity um first one is a really simple one sort of and that is you should use the latest version of the compiler i know this is really obvious but um you know like defects are fixed all the time in soul c so you know check the release notes and like these older versions you know they're going to generate issues that might cause have a bug in it and if some attacker looks at that bug and says i could exploit that in your code then they might be able to work out some way of leveraging the bug fix on your code so you should wherever possible use the latest version of the compiler and so you can use this pragma which is link it to a very specific version and um that way you know your you you might say right we've tested it with 8.0 you know 0.815 and so we want to deploy it with that version because that's what we've tested it could be fair enough another way is you use that little up arrow and that means i want to be between that value and the next release major release version so 0.9 and so you can think that what's going to happen is they're going to be bug fixes between 0.815 and 0.9 that you know you will be able to take into account and be able to use so obviously you've got to be using that later compiler as well but it means that you're saying my my contract is compatible with those versions um and so i guess what it means is though your code will fail when 0.91 comes out towards 0.90 but that's probably a good thing because what it'll tell you to trigger you to do is have a look at your code and say oh maybe i should be using this new security feature and putting you know implementing that in the code and that's a good thing and so i've heard this advice which is you know don't use the latest version of the compiler because you know there might be some undiscovered bug and i don't think that's a good idea i think that um you know the um if there's some brand new feature that's come out maybe don't be the first person to use it maybe wait a few versions but if there's if you're only using older features then you know chances are they're going to have bug fixes in them so um for those features so i reckon you should use the latest version and not like the second latest obviously you shouldn't be using the test version you know the latest build um but um you know if you're using that little up hat thing you're not going to be using that you've got to specify them if you want to use them okay next part function visibility so in solidity you can have external public internal and private so external and public you can call them from outside so whether it be a transaction a view call or a cross-contract call you can also have in public and internal you can have a contract that inherits another contract can call an internal function and um similarly if you're within the same contract you can call public internal or private so you've got these these visibility things to try and control who can call what and so in non-trivial contracts though you'll find that you start including an awful lot of other interfaces and other contracts it's very typical and so it's really easy to miss some external function that you just don't even know about you know like here i've got my contracts b and f and b's got c d and e and in c somewhere you've got i bet you didn't even know about me function and so you know that is quite a common thing and so if you go use sole c and go dash dash hashes you'll get the list of function signatures and function selectors and so that'll tell you all of the public and external functions that are available in your contract and so you should audit that list and go oh i didn't even know about that i wonder what that function does and you know maybe change or remove those functions um so i think that is something that i've actually seen people have problems with where they've deployed something that with a function that shouldn't have been public that was okay access control so you can limit um who can call external and public functions um but uh or rather this is to limit who can call the external and public functions by essentially having a require statement so you could have say message center equals some authorized party like owner or maybe you've got a map of authorized addresses and as long as you're within authorized then you know you're good and so authorized would be a mapping from address to boolean in that case and so the thing to remember is you don't need to do this sort of require statement if it's a view call because all the data in the blockchain's public so there's no reason why um you know you need to be trying to limit scope because anyone can read the stuff so you only need to be putting in these require statements if it's a transaction function um and in fact this sort of lack of you know like access control was exploited say in the parity wallet hack in 2017.

[00:41:34]now i'm simplifying the code a little bit but essentially they had init wallet owner and um someone was able to call that and then um get the whole thing to self-destruct and so that locked up 513 000 eth which is an awful lot of money these days okay let's talk about full back and receive so if um someone transfers ether so essentially you've got a transaction with no call data then you'll get the receive function will get called and so notice that it doesn't have function receive it's just you've just got receive and fallback and no need to have the function identify and so it'll get called if um you're just sending value if um receive doesn't exist and you've got a payable fullback then that'll get called and so you can have fullback without payable and it'll get called if there's any call data or there's no receive um and if you have bytes input then you can even try and understand what you've been called with and um so there was an old ethos that people had that if someone sends you eth then possibly by mistake then accept it you know say thank you and then um you know but i think it's probably not a good good ethos to have because if you don't plan to manage eth in your contract then maybe you shouldn't have any payable functions and you know that includes receive and fallback you know you shouldn't you should be trying to make sure that you don't have to worry about that all right let's talk about reentrancy so reentrancy is where you know you have a call from an externally owned account which and you have a contract which maybe calls another contract and then eventually it loops around and the code that you have ends up calling back into its own code and so um there was even a reentrancy hack the dow attack back in 2016. and so it can be for a value transfer or a function call and so if you look at this code here you've got um we've got some shares and then you call the withdraw function and then you're you're going and you're sending the share to message sender and um and that's how much you're sending and then if it's successful then you say all right let's update the state so someone who hasn't put in a comment before who's on the call let's see ah joanne joanne what's wrong with this um i don't think my brain's thinking quick yeah it's too cold in melbourne there is a reentrancy problem so i guess i guess that should help because you're not setting it to zero until after yeah when you do the call the call can start the code in the contract just transferring to and so it could come back in because you're only then setting the shares to zero after exactly that is exactly what the problem is and um yes so the call is a cross-contract call and it gives it hands over all remaining gas and then um the receive function is going to be called and it can call back into withdrawal and so that user message center could go and then drain lots of money out of the fund so and how you should do it is as per what joanne was just saying that you should work out what the share is and then you should set their share to zero so you do the state update first and then you do the transfer the external interaction and so this is really the check effects interactions pattern and so you do your requires whatever checks you're going to do right at the start and then you update your state variables and then you do your interactions with external contracts another way you can do things is use what's called reentrancy guard and so i'm open zeppelin i've got a new example contract that you can use that does it and essentially you put this modifier non-re-entrant around your code and so um it stops uh it allows you to make sure that there's only one instance of the code running and you can't run you know call back into it so you can imagine here i'll just go here so if this is put on a function it's going to go required not entered and you know it might be not entered initially then you set it to entered and then finally you set it to not entered when you exit and so that means that you can't you know call through that non-re-entrant twice and if you um think about the gas being used and the gas being refunded then you end up having i think it's 2300 gas there in total is used so it's not too expensive but it's a way of doing it um if you can't do that checker check mod um state effects paradigm another thing you could do is limit the gas supplied and so with each call down from one contract to another you only pass on 63 64 of the remaining gas available and so even if you say started with 10 million gas for a a um an initial transaction then you know you're going to be maybe only being able to do 500 um times through assuming you want to end up with say 3200 gas at the end and you can also like restrict it by say specifying the amount of gas to be passed in for some function call and so you could use this sort of code to work out how much gas a function is using so gas left is um just calls down to an evm op code and it tells you how much gas is remaining and then you call that function and it's going to say tell you how much it's used and so you know you see you could quite finely work that out but the thing to think about is that opcode prices change i mean for that matter the thing you're calling could change as well and so if you finally you know work out how much gas it's going to cost and then say some things like this s door change happens where storing stuff costs more then you know you might you're going to break your code and so you do need to be very careful with limiting the amount of gas you're actually passing through all right modifiers so i've already talked a little bit about them but modifiers was where you essentially insert your code from your function between two parts of modifier and so the thing is that modifiers are often defined in far away places some they can obviously be defined in the contract you're using but sometimes they're defined in something that you've inherited or something that's like 10 levels of inheritance away and so you don't necessarily come top of mind what that modifier is actually doing and that's a bit dangerous the other thing is that um you know so you can have the modifier have code before and after and i know of there's the there was that um reentrancy guard was an example where they did have code after but generally people aren't expecting that code after because most usually it's just require blood so um yeah be a bit careful about that um you also want to be careful that you're only doing checks and you're not doing lots of code in a modifier and so here we're you know just using two maps to say you know should the require statement go through or not and as you can see you can have more than one modifier um and you don't want to be doing something like this so we've got um is eligible here and we've got registry and dot is a voter and you're passing in message sender so calling out to another contract is not what people are expecting to happen in a modifier and that's you know like you're handing control away and potentially um you know could have reentrancy issues as well so that seems like not the right thing to do okay value transfer we've already talked a little bit about this but um so there's a few different ways of doing value transfer so we've got you know the dot transfer and dot send and um dot send returns a boolean to say whether it's passed or not whether it failed or not transfer doesn't return anything and then you've got call and call you um it's like a normal function call and so you find out you can have a boolean and you get to pass as much gas as you like so you can have it could have arbitrarily complicated code in the receive method whereas if it's um transfer and send they've only got 2 300. so the 2300 helps to stop reentrancy but it also limits the scope of those functions so what about this let's have a look at this code ah yes all right so barry are you still available yep still here okay barry this is a harder one i thought great thanks a lot have a look at this code what is wrong how is this code broken you know what what how can you know what problem does this code have okay so richest is a payable okay so the constructor is payable so you could pay the contract yeah um become richest so if the value sent is less than the most sent then complain revert otherwise ah transfers other uh transfer that amount from richest yeah so yeah yeah so it's transferring the amount that was there previously so you'd put in someone would deploy and put in one each and then because you wanted to be big name yourself and say i am the richest um then you barry would put in two weeks just and you would get that one if that yeah okay so it gets returned to the previous richest yeah actually now that yeah the two eighth gets returned to the previous previous richest that's true yes yeah that's how it is and then the new richest becomes um whoever set the the fonts in the value well it looks good to me yeah i there's nothing that jumps out yeah and so um an attacker could um set this up to point at a contract and so when the transfer goes through you could revert and so you know here you are you've gone and designed this lovely game and now um the um the person who's um decided to become the richest and they don't like this game anymore they break the whole contract simply by every time transfer is called reverting so um so they don't actually make any money they just um frustrate the contract and so this is you know one of those things where you've allowed someone to make the state of the contract broken which is quite frustrating so for something as simple as this it doesn't matter but it was something like your automatic market maker or something and they were able to lock up the whole contract that would be super frustrating and so how you can get around that bug or that security issue is the withdrawal pattern and so the the constructor is the same become richest is pretty much the same um and you but now you have some pending list rules so you become the richest you've got a pending withdrawal and then you can withdraw yourself and so if you did that attack where you reverted on transfer all you would be doing is stopping yourself from withdrawing your money but you wouldn't stop the contract from operating so it's a simple pattern that stops that sort of attack okay mappings oh no patricia go ahead are you going to say something no just a little a little a little tip from the old days of solidity development it's always better to let the user withdraw their funds in the instead of you sending them yeah very true very true okay mappings so um mappings are um you know the like say you went to uint256 it's a way of you know mapping one key and values and so how that's actually set up by the evm is you have these storage slots and the values are stored in cacac 256 of the storage key dot the storage slot number so that is so say um the um say the map is the second variable in the contract then it's going to be in storage slot one and so that's the storage slot number and so you work out the kick 256 of the storage key dot that slot number and that's what the value is and that's where you get to store it and so you don't actually store anything at that storage slot one you only get to store it um based on that equation there and so imagine you've got this code here and i'll give everyone a few sec to think it or look at it but working through from the top you've got an array and it's an array of mappings and then you allocate a whole set of new maps by pushing on to the array some new mappings and then you've got right map which takes which map do we want to talk to the key and the value and then read map you to say which map you want to use and the key and then you've got this arrays maps function where you delete the whole array and so the thing to think about is calling delete on that array will delete the array but it can't delete the mappings because it doesn't know where those variables are stored because it doesn't there's the keys that are used are not kept anywhere you're not storing the keys you're only storing the actual values in a map makes it cheaper but it means you don't have those keys and so imagine we have this sequence you call allocate to allocate one new map and then you call right map and what you do is you write um the um with a key value key of two and the value of five and then you call arrays and maps to get rid of all the maps and then you allocate and you allocate one map again and now i called read zero comma two so i read that value that was written originally and despite having gone delete on that array i will get 5 returned from read map and that's because the map value has in fact not been deleted okay integers so in integers the uh are the n solidity integers are um are integers so the numbers are integers and they're not floating point or anything which i think is obvious but um it's important to realize that 3 divided by 2 is just 1 and not 1.5 and so if you have something like this where you're paying out equally then if holdings isn't divisible by number owners then you're going to have money left at the end and that's not good and so you could imagine if you've got some voting like this you will walk through walk it through you count the votes and then you go for all the people who voted um we'll see if they're voted for and if they have will add the number of votes and then you want to return true or false depending on whether votes for is more than half of the number of votes and so if you have it just like that you can have a problem because the number of votes even if no one votes you'll still end up being true and so that that's not good um and um so that that's not what you really want to do you don't want to be returning true even if um no one votes and then you might have like this where you've got all right well what we'll do is we'll just do greater than and again that's not going to work too well for you because say if you've got six people in total you were hoping that it would be three or more people voting to get the right number so essentially you just need to do that which is not hard but it's just something to think through and sometimes has unexpected consequences another part of integers to think through is underflow and overflow and so essentially for if it's a uint 8 255 plus 1 is going to cause the problem and so by default um everything now is checked and so if you do do that sort of addition you're going to have to have a panic thrown so it'll be a revert in a panic and this could leave your your contract unusable because if every time you execute a function it causes a panic you're not going to be able to use it anymore so you could put unchecked around it um and in that case are you going to be returning zero because 255 plus one is 256 which is zero and again that could have have some problems too so you do need to think about that tx origins another one so what's this code um doing okay so who hasn't talked darren rogan are you on the are you able to talk yeah i can talk all right darren what do you reckon tx origin equals message sender could be doing for us it's trying to ensure that the person sending the transaction is the starter of the transaction flow exactly exactly right so given the tx origin is going to be an eoa that means that message center is going to have to be an eoa as well because there's no way of looping from a contract to an eoa so that's essentially saying this must be an eoa you can also imagine though you had this code where you had your transfer to and you're saying well the tx origin has to be owner so if you look have a think about that that's actually got a big problem and um because you're um so this is your user wallet and you're wanting to transfer some amount and the issue that you're going to have is that you could have an attack wallet between your user wallet and your real wallet if you could persuade the user to do a transaction send some east to this attack wallet then it can it will get it in the receive and then what it can do is it can call tx wallet so that user wallet and um then call it to um to essentially execute the transfer because it's looking at tx origin and not message sender so essentially you're um you're masquerading as the user and inserting yourself in the middle of the actual call flow so you're able to but that could be have a valid uses yes to do gaseous transactions for example would that be a case um to tran so somebody could do a cheaper operation and you sort of use this uh as the as the funder of a more complex scenario so let's say i wanted to mint something i could just do like an easy one before would that be a valid usage of this sort of almost like a proxy yeah you could but you would then in that case though would you be you would you could be trying to do something like that but in that case you're gonna have to be very careful with um exactly what's happening in transfer too to make sure that and maybe what you would do in that case is oops sorry yep maybe in that case what you'd do is you would make sure that message sender was a known proxy so you'd say if message center is a known proxy yeah i'd have it in a miracle tree and make sure it's in the miracle tree first just something like that yeah okay all right dropped to one hour i'm going to keep on going got a few people health few dogs hoping here all right um just a stick all right the puppies i think are going to go outside so let's not worry about them all right so reverting so in solidity there is a whole stack of different ways of causing reverting and so one is obviously revert bracket string and then you can revert with the custom error um you can require a condition require condition and provide a string to be returned or you can have an assert and um so the actual so the local the revert op code but what you actually get for return data is quite different and so um your you'll get error string if it's a revert or revert condition and um if it's an assert you'll get a panic with a panic code of one and see asserts are used with static analysis tools um and so the thing to think about with reverting oh yeah so you've got these panic codes and so it's worthwhile knowing what those panic codes is are so that you can try and decode them and understand um yeah what's um going on with your code because sometimes you get these panics and it's quite confusing you can also have error called but without any parameters and that can happen for a whole range of reasons and one of them is that if you call a contract address where there is actually no code so invariably that's because your contract address isn't really a contract address at all it's just you know an incorrect address um if you try and call receive some ether and the receive function isn't payable or the fallback function isn't payable um and if again you try and send ether to a public or external function and it's not payable if there's not enough call data supplied so if you've say got one byte but not say four bytes so not enough for a function selector and not enough for the parameters then again that'll get called um another thing to understand is about error propagation so if there's something happens in contract c you know it can cascade the whole way through and revert the whole transaction and it typically does but it doesn't have to and so you can um so if you call transfer um you know that'll fail and that'll cascade if you go new for a contract again that'll fail if you um do a normal function call that'll fail and call cause the cascading reverb if on the other hand you do a lower level type of call where you capture the success or failure and the return code then you can work out what you're going to do from that point so you could catch it or you could discard it and that could mean that contract c's function call could revert that contract b and a might not and so you know they might do different things depending on that you've also got this try catch style um feature since uh in recent versions of solidity and you know you can see that you know you're catching it if um an error happens or a panic happens but if there's some other low level error so essentially there is no return code at all you're not catching that in fact you're just absorbing it and keeping on going as if nothing's happening and so that's actually um pretty bad because now you're not even reporting the error to anyone and so you've got to be careful when you're analyzing code to make sure that um reverts are being cascaded back and handled correctly okay timestamp manipulation so um proof of work um you know block block creators so miners they can specify the um the the block creation time within about a 15 second window and um you know so that and when you're looking at your code you know you can have block.timestamp and be doing stuff based on that and so um you know you could imagine that someone could manipulate the timestamp and miner could manipulate that timestamp to change the effects of your code in once we're at proof of stake in another couple of months time another three months time or so um actually it's not three months it's only two it's real soon um then um you know all this time stamp manipulation is gonna pretty much go out the window and it's not going to be able to be manipulated and so you know you've got to be really careful then with time stamps and another thing you've got to be careful about is um if you say all right i want some action to happen in some time window then you wouldn't want to limit that time window so there was some gambling game and the idea was that after something had happened you then had some winning period that you had to claim your prize and um the attacker they just um filled all of the blocks in that period of um for win period so that no one else could submit a transaction and in that way they won because no one else was able to submit a counter transaction so that was done back in 2016 or 17 something like that so i don't think it would be necessarily possible now because there are the blocks are bigger and the gas prices are more so it would seem unlikely um but that was done um at one point all right so i've talked about easy stuff now let's talk about complex stuff so storage collisions part one so they're um there's a proxy contract pattern um which i talked about in the advanced security talk some time ago and the link's there and so you use delegate call and call code to have say contract b operating in the context of a different contract and so what you can then do is you can be upgrading the contract um or you can be um so you can have two contracts upgradeable but the thing to think about is that you've got the proxy contract and the contract being proxied so the contract that's actually got the code in it and so the storage slots are in the proxy contract and most of the code is in that code that's being proxied and so the issue that you can have is though that you can have a collision between the proxy contract and the contract being proxied and so for instance save contract a has val 1 and val 2 and contract b the one that you're using delegate call to has b val and address then they're at the actual same locations and so contract b is going to interpret vowel 1 and similarly contract a will be interpreting b val and so that would then potentially lead to issues as well as if you're doing upgrades you've got this sort of overwrite thing where you've got version one of a contract in version two and so if you insert an extra variable then suddenly the very the storage locations are going to be interpreted differently and so that's another storage clash and these storage clash things are real so this is um days ago like literally a week or two ago there was um this admin proxy and it was using storage location um xero and that was well storage slot zero and that was um the proxy admin was that storage slot and that was then also available in the proxied contract and they some hacker was able to essentially change what proxy admin was and then steal all the money so having two storage slots at the same location is wrong obviously and um if they have used the um used the open zeppelin proxy they would have not had this problem um there are also and there's also another type of storage collision and this one is more of a malicious type and so if you look at this code here we've got a map and you've got um so because it's public there'll be a getter on that map and you'll be able to get a value based on a key we've also got set val which sets up a key you know given a key and a value it sets the value of in the map we've also got set val 1 and get val and they use this get you in 256 slot and that dives into a bit of assembler there and so what that's doing is it's actually setting the storage slot for um that particular variable and which is um that return value r there so r is being returned at a certain storage slot specified by the parameter and so what you do is you abi en code and kicac the key value comma the storage slot and once you've done that then you know you've got exactly the value that the storage slot being used by the map for that key and so setval1 essentially stores that vowel into that storage slot which is essentially setting that value and getval does it the other way around it calculates the storage slot and then returns the value and so you know so map so the map can be accessed um by map and set val but it can also be accessed by get getval and setval1 and so what this is showing is that if you just searched for map and usages of that map variable and say all right i fully understand where that maps being accessed and you didn't like um and you didn't notice this um set val1 code here then you wouldn't notice that someone was able to overwrite map values and um this obviously can be used for anything um and this is just showing that you can access any location that a contract has um whether you know whatever data type it is and so it would obviously only be being used for malicious purposes doing something like this but it's worth noting yeah and which is and so that just says what i've just said okay so now is the exciting bit how to change the byte code of a deployed contract okay so there's this thing called create2 which is um you want to create a contract at a known address and the contract depends on so the contract address depends on the address of the creator so message.sender the bytecode of the contract the parameters supplied to the constructor and a salt value supplied by the creator so it allows you to say deploy the same contract with the same parameters many times just with different salt values and you'll get a whole host of different addresses and so the use case was that you wanted to be able to predict the address of a contract and so you could have all these off-chain interactions and then if there was some dispute you would then deploy the contract afterwards and say all right here's the contract and now let's settle the dispute that's the use case and so what the code looks like is something like this where you've got contract d is the contract to be created and it's got a constructor that takes no parameters and it has a self-destruct where it sends the eth of the contract to the owner and create um it uses just a salt of 0x1 but you know that should be some obviously 256 bits sold but um uses that salt and it deploys the contract and then predict address is um calculates what the address should be and so the address of d will be the address of predict address and so that's um how you can deploy a contract using create2 and um so you could use that though and so um and all the things we've learned today so you could have this overwrite soul which deploys using create2 a contract called choice and in choices init code it could actually say hey what should actually be deployed and so it could talk to a contract called loader and the loader could return to it the contract code to be deployed and it could choice could then say hey this is what should be deployed and so it could choose to deploy say code one or code two so let's see what that code looks like so we'll have a interface where we've got get and we've got withdrawal and so get just returns you went 256 and so for instance get can return 1 or it could return 2 for code 2.

[01:18:11]and in both cases it's just going to return the when you self-destruct the um contract it returns the um value the the balance to the current address of the contract and then that loader um has two constants and um the little lines there they're the rest of the code but in font like one one size font or two two point font or something just in case you want to later on copy and paste the code um okay and so you have set choice so you can choose which one you want obviously you could have had set code which could have set the actual bytes to be returned and then you've got getcode which will return the bytes memory so the actual bytecode to use okay and then choice which is obviously the interesting one so it's got a constructor and it knows the address of the loader contract and so it's it gets the loader contract and then it says to loader get code so give me the code that i want to use and that's going to put it into a memory object and then what you do is data pointer is so you can see on the right hand side there's some really small code there and so i've left that there so that people can grab it later um from the slides but it's some boilerplate plate code that gives you the pointer to the actual not the data within a byte so bytes have got the length of the bytes followed by the actual data within the bytes and so that'll give you the actual pointer to the data itself and then you work out what the length is so we've got the offset in memory and we've got the length of that bytes and then copy does a low level copy of um from mem offset to and then the offset that you're copying to is location zero and then length which is just the length and so that's doing a low level evm like copying of data the final one is assembly return zero comma len so return and zero is the offset of the code to be returned so so the idea is in in a init code when you return you return the offset and the length of the code that's going to become or the data that's going to become the code of the contract and so what you're saying here is all right i've copied it to offset zero so now let's just return that length um and in fact i guess i could have simplified all of this and got rid of that copy mem offset zero and just gone return mem offset comma len didn't think of that anyway um would have been less code and so that will then return the code to the um the contract and so you can imagine now choice isn't going to be the choice contract it's going to be code 1 or code 2.

[01:21:30]and overwrite so it is similar to that other code that we had where you're just deploying choice with a certain salt value and you can even work out the predicted address as well so the loader could have had a function set code bytes you know which would have let it set up anything it liked um and the constructor so it returned before the actual returned out of the unit code fragment before the overall constructor was finished and so um you know that's a bit of a problem in itself because there could have been all sorts of variables being initialized um and so that didn't happen so block explorers are gonna look at the source code and go oh that's not what's been deployed and so they'll detect it so if you were going to be a tricky hacker you would want that initial version of choice to match the actual codes that you initially deployed and just have the ability to change it over so the the big thing to do though which maybe i've gone over quite lightly is you need to do that withdraw function because the withdrawal function self-destructs so it removes the contract from storage so so let's work through this through again we call we deploy using two choice loads up and gets code one or code two the next thing that um you know then you use the contract and then overwrite then calls um withdraw and withdraw then um self-destructs the contract and then you can call create2 again and meanwhile you could have changed loader to change the value to be returned so does that make sense to people getting sort of head nod sort of yeah makes sense i mean i can if i was brave i'd live do it but anyway so so pete if a contractor's had self-destruct called on it then you can recreate it using create too that's right yeah but but it's got to have been um so you've got to have done it at i mean you've got to have created the first contract using create 2 2 otherwise you're not going to be otherwise you might be able to get the same address yeah yeah [Music] yeah exactly so you can go and um yeah change the code around yeah it's mind-blowing it is it is after all these years of using solidity and evm and ethereum and now we can change the code um not what we expected so is this a problem so just to be clear i was just trying to ask that question so if i was to look at a contract and i see a self-destruct in there is there any way to detect that it was created using create2 or is this just a risk that you have with every um self-destruct contract that's a yeah that's a good question um no i don't think there is a way actually yes there is a way you'd look at a block explorer and that is going to tell you that information i am almost certain um though trying to tell your users just look at the block explorer and if you look at this part here if it says if it's got create and two at the end then look to see if there's a self-destruct op code in the middle of it um yeah it starts to get a bit confusing but i think the big thing is you're going to audit the code and if you see some some assembler code in the in in the constructor of a contract i'd start to get a bit worried i think that that's probably the the big thing especially something that's going return um in the code because that's definitely going to be strange um so look if some attacker could sneak some code in um like that then you know i think they could rather than going to all these extreme lengths they could just do simpler stuff you know surely there's simpler attacks they could do like send all the money to me or something you know surely um also all the storage is going to be lost when you call self-destruct so sure if it's just got eighth value then you're good but if you've got any storage locations all of them are going to be wiped out so it's only going to be very certain attack cases that this could be used for ethereum foundation know about it in fact if you look closely at create2 there is um this text here um so yeah and so as a final thing if you're thinking hey well i could upgrade my contract using this i don't think so i don't think it's a good way of doing it you lose all your storage so you know doesn't sound like a good idea okay can you transfer value to this contract so you know so this contract is essentially this contract so receive don't give me any ease i don't want it so is it possible to do that and you know confuse things and the answer of course is yes you go self-destruct and with an address and you the the value is transferred there directly there is no call to receive it just goes there directly so um it is possible to bypass and of course with create2 you know what the address is going to be before the contract is created so again you could send eth there and there's even something called force feeding attack so if a contract is doing stuff based on its balance then you know you can force the balance to be something that the person is not expecting and that might cause something funny to happen so you should have your your accounting for how much money you've got separate to the actual balance you shouldn't have the two of them intermixed okay heading towards the end obscure functionality who wants to volunteer what on earth this code is doing what is it telling us what's going on we've got a boolean doing a function call yeah all right everyone is just going no that's just not possible unfortunately it is um so there's this using keyword where you can say i'm using some other library for say you went 256 or blue or whatever or star star meaning everything and then you can just say all right boo and then there's some function and then you have some logic and i find that super confusing all right who has heard of function types before and so the idea here is you've got a function and it's funk to use and so that that functor uses the function and it's a private and it's of that type and so the idea is that you can change the storage location func to use to say oh well now we want to use func one or func two and func one and two can be different functions doing different things and so rather than in call func having if choices one do this else do this you can just call funk to use and it will call that function directly and so i don't again this is some really obscure functionality that i know i've never did hadn't heard of before i did this talk um and then yeah all right so here's another piece of obscure code now what was oh yes this one here is really really hard so i know we're up to one and a half hours so everyone's brain is in meltdown for some really hard code but you've got a constructor we've got some secret number and the owner and then if you can guess that secret number uh and then it's payable so yes when you deploy it you put some money in and so every time you get you try and guess you try and guess what that secret number is so as we all know that secret number is public because it's um just on the blockchain so you can just read the state and so you think all right i'm going to put in an eth and try and get that prize so you check you check the prize to see if you've won and if n is right then you transfer your money and otherwise not so forgetting the fact that it should be withdraw and not a transfer um can anyone see or guess what the problem is it's hard to see what the problem is here but can you guess what the problem is is it something to do with the fact that you've got that kill down the bottom and so you're going to self-destruct that contract and then do something different or something construct it yeah with a different value again no this is fair this is far worse this one and this one you can't see the problem and so in remix though you can so you in um what is it the um unicode you've got right to left over right and left to right override and so in fact this is what the code what the text really looks like so we were seeing this when it was displayed but what it really looks like is this which is pretty scary so that means that n and p are reversed and so you would be there um saying all right so you're passing in your address who to be paid and um you're thinking you're passing in n the value that your guess and in fact invariably you're going to be wrong because your address isn't going to be you know the number and so people could be just keeping on guessing and never getting it right and going but why am i right and it's because you've flipped the um the variables around which is i don't understand okay so if you open up that in a normal ide you see this and so you're passing in an n that's what you think that's what you're seeing so when you look at this that's what you're seeing however when you um actually pass it in though um and what's really going on is that and if you look at the um so it's nnp rather than pnn and so the variables get flipped around and it all comes down to so that when the when your ide is displaying it it's displaying it including the text and direction overrides um whereas in remix it's kindly saying we don't think that you really need those text override but that's pretty deliberate right oh yeah yeah this is malicious code this is the and this is also um yeah this is being silly um but still it's a thing it's a possibility um it's a stack overflow attack because it's hidden characters you see it all the time yeah it's crazy so the characters that just affect the comment they don't affect the actual parameters yeah they affect the actual parameters here we've got we're seeing we're viewing we see when we look at it with our eyes we're seeing p comma n because that's how it's being displayed on the screen to us by the ide but the actual compiler is seeing n comma p correct oh hang on so that that right to left over right is that talking to the ide or the compiler i think it's it's talking to the ide the display i think i think if you open it opened it in just a normal text editor you'd see this yes you would if it was a simple text editor um yeah so barry using notepad or vi or something um rather than i'm not sure what xcode would do um i i don't know but as someone i think it's darren or someone said that you know someone's going to be malicious doing this and this is um yeah that would be pretty strange so my summary on the obscure functionality is it's really obscure and i reckon that it'd be really good if some of this was deprecated or something or maybe you could have special ways of enabling some of this obscure functionality because if it's obscure then people will come across it not understand it and then you know there's going to be bugs in the code because they're not going to be able to interpret it correctly or fix bugs in it so yeah i reckon it'd be good if some of that was removed from the language okay security tools soul c compiler so the sol sulci compiler has been improved massively over the last seven years or so six or seven years six years and um there's in fact you there's this registry of issues um with you know security issues in in um smart contracts and these days the vast majority of those issues are actually being resolved and though you know you'll be getting either fatal errors or warnings if you um if you have them in your code so what that really tells you is you shouldn't just muck around and not get rid of compiler warnings i mean pretty obvious um they've also got something called an smt checker i have not used this but it should be able to according to the documentation find a set of reasonably simple simplistic issues but um yeah and there are a stack of other tools too i have not used any of these either and in fact you could imagine someone could spend a whole talk working through these um these different tools and maybe some new tools and so which are free which are web services which support recent versions of solidity and which is the best i have no idea um and within consensus we've got a group of people who are called the tsa trustworthy smart contracts team um so david pierce and joanne arathio frank and milad and um yeah so they're working on a actual language thing that will allow us to um i've even got i should should use their words the tsc team are developing techniques and tools to deploy higher foot assurance bug free smart contracts and so they've even got a paper that's been accepted into a really top-level conference and they've got an archive paper and so they're working on a way of writing contracts in daphne so you should hopefully be able to have more trust in them to not have bugs okay in summary so smart contract um development is super complex and like this is just your start at the start of your journey through this dark forest and um you know application security is a lot more than just um smart contract security and so you know sure the contracts are a very public part of the attack surface but there's a whole lot of other stuff as well and you shouldn't ignore it because a lot of the recent really big hundreds of millions of dollar hacks have been on the non-contract bits but there have also been bits that have been on the contracts as well there's a lot of links of a lot of different information there are a stack of talks coming up so hadathio is going to be talking in a week's time about the ethereum reference tests and so what they are how they work and why hermes in two weeks time is talking about um cross chain security and really going to be looking at some of those recent attacks as well and trying to pick them apart and have how they really happened and what does it really mean um paul ashley is going to talk about decentralized identity we're going to have the chief scientist of chain alice's on and then going forward we've got a few phd students lachlan and minh thing talking about their phds there is um social stuff like the um we've got a youtube channel if you're watching this on youtube we've got um a meetup that um this is on that you can freely join um there's a slack workspace um use that invitation link the code that i've written today most of it is in that ethereum engineering group samples under the security folder and there's also a formal message reading group as well that you can attend and go to the slack um to um talk to people there about joining that group and that is all folks and i can see we've got a lot of chat which i have just not um been looking at so i wonder if there are any questions that weren't resolved in there and um [Music] all right um yeah okay anyway i don't think there's anything any questions in there are there any questions we're at 1 hour 40 minutes maybe just post them in the youtube when it's done all right look thank you everyone for coming along and um have a great week and i guess we all look forward to haraffio's talk next week so talk later everyone bye-bye thanks thank you so much thanks pete that was awesome thank you thanks thanks thanks peter