 So, garaftinun. Iliya, this year, I started the first underhanded solidity code contest. And the goal was to write code that looked innocent on the surface, but actually concealed a sinister purpose. The reason that I started this was to encourage deeper thought about smart contract coding practices and good code. And to help highlight potentially issues with unobvious features in solidity and smart contract programming. So, in an attempt to capture the current zeitgeist, the theme was token sales. And participants were challenged to write a contract that was in some way involved with token sales and looked innocent, but had some advantage for the person running the token sale. And ideally, the sinister purpose should be ignored by an auditor, or if it was discovered, then easily excusable or explainable as an innocent mistake. So, I have here the three winners of the contest this year. We have Joao, who came in third. Richard, who came in second. And Martin, who came in first. And so, I'd like to start our discussion about smart contract security by asking each of the panellists to describe their winning entry and what they think is novel about it. So, would you like to start? Sure. Well, my entry is a proposal for a Dutch auction crowd sale. So, in this model, the sale starts with a really high price per token that decreases continually as the time passes. So, buyers can enter the sale in whatever time they feel the price is fair. The sale ends when either the time finishes or the cap is reached. So, the thing is, I made use of a feature of Solidity that is that anyone can forcibly send error to a contract without triggering code execution. So, in that scenario, the sale owners could sneak in some error during the sale to inflate the token price making the Dutch auction earlier. So, if you couple that with, for example, a mintable token that is a token that you only mint the amount of token that was bought, you can really inflate the token price because you put money on the auction but you don't mint tokens. So, you're raising valuation of the token artificially regardless of marketing interest. And another detail is you can kind of use this as an influencer because if people are watching the sale and they see that it's reaching the cap really fast they might want to get in earlier than they would if in normal conditions. So, it's a kind of effective way to manipulate market in your favor using this little feature. Great. And Richard, would you describe your submission? Okay, testing. There we go. So, very similar. I actually didn't know about the Suicide Bug which allowed you to get money into a contract without code execution. But it basically uses the same idea which is there was a... So, the basic idea of the contract is you have a crowd sale and the runner, yeah, the issuer of the token gets one ether the first week, two ether the second week, four next week, so on and so on. The idea being that if they're not doing what you expect you can kind of yank your money back from them. It comes down to using this.balance. So, again, as long as the contract is executing as you expect, this.balance can never be more than the amount you received unlike the Suicide Method, which again I didn't know about but I have more clever solutions now if I was new at that. Basically, you compute the address the contract is going to live at before you deploy it, send ether to it and now you deploy the contract and now the contract actually is breaking the invariant that this.balance is strictly less than the amount it thinks it has. Great. And finally, Massim. So, in my entry I'm going to start by describing the bug. My entry is based on ABI encoding and how Solidity handles ABI decoding in runtime. Maybe everyone doesn't know that actual the EVM and the code in a contract doesn't really have a notion of methods. That's an invention on top of the EVM. So, on the fly some bytecode determines what method is called and what the parameters are and this is encoded by ABI. And certain types of parameters such as dynamic length arrays have a length and that length is not enforced by the decoder. So, it's possible I noticed to specify a very, very large length and make this value overflow. And that's what I kind of designed my entry around. And it was a bit difficult because I had to make sure that during a loop I can't loop against the size but still use the size to somehow give a kick back to the attacker. And in the end it became a kind of a round table where you can round table dow-like thing which you can try to get a seat on this round table and submit multiple bits and thus get the dynamic arrays in there. And what I think was pretty good about that entry is that this exploit is basically not possible to exploit using standard tools. You need to generate your own ABI your little bytes of data in order to exploit this and I think it would be very difficult for solidity contract developer or auditor without deep insight into how the EVM functions to actually find the vulnerability. So, first of all then a question for any of the panellists who'd like to answer which is what should smart contract auditors be looking for in order to try and detect these sort of underhanded tricks? I mean, and I think in the case of our entries if you see this stop balance anywhere it should be I mean it doesn't mean it's wrong but it's certainly a red flag that you're accessing data that may or may not be what you expect it to be. To complement on these there are a few things that tip me off one example is random numbers because it's usually pretty hard to generate random numbers and that kind of indicates that it's a point of failure. External calls are also a kind of security edge because you're calling external contracts so it's the kind of thing that I start looking after when I start looking at a contract. Yeah, I would like to add to that that what you really kind of should be looking for or one of the things is are these assumptions and they're mainly implicit assumptions that are made and it's easy to gloss over that and not notice it but really try to investigate what are the implicit assumptions here and in your cases I guess the implicit assumption is that the balance is zero at the entry or at the exit and start to like make these assumptions explicit and then see can I violate this assumption in any way shape or form. And just to add my own note do you some caution is required there in this if you made the assumption that the balance is zero and then you coded in an assertion the balance is zero then now an attacker has a mechanism by which they can actually just disable your contracts by sending some funds to it. Exactly, so I didn't mean that you should assert that thing necessarily but instead question is this the valid assumption that can be made or can this be exploited by an attacker? So next question again for any of you is what sort of improvements would you like to see to tooling and to languages and other infrastructure pieces in order to make it easier to detect these issues and help prevent them from happening in the first place. So on the tooling front I was at the excuse me at the breakout session earlier and saw some presentation about oyente and about Securify and for a long time I had this feeling that there are these tools which does analysis on bytecode and either detects vulnerabilities or provides some kind of analysis on the bytecode and they're on the kind of fringes but they're not right now in the toolset of most depth developers and that's what I think should be added so that as part of your development process you can get some aid by these tools which operates preferably on bytecode which would also help to protect against failures embedded within the solidity and in the step from source code to bytecode. Alright so you'd say more maturity in the tools we're already building and easier integration? Yes, easier integration into the developer pipeline of these tools. Yeah Anyone else? I mean I would yeah, that's basically what I'd say it's really important that we have better testing tools as well like being able to run a huge suite of test cases against both expected behavior and unexpected behavior if you feed bad data in do you still get a result and now you've corrupted something or like I just think we need more and again I think the tools are there I think it's just they're not easy to use it's not easy to make a test suite and just run through them you you see all these contracts they have about three test cases and it's testing if I send money to this another like this thing does it work? Yes, it's passed and so three test cases should not be sufficient to validate that this contract you're sending millions of dollars to is working and yeah it's a go ahead and just in addition to that I would like to see some way to test in large scale because most projects when it tests some behavior they use like the minimum the viable number of players in the contract to test but if a contract work like with 10 transactions will it work with 10,000 or a million and there's no way to test that there is but there's no no one doing that right now so I would like to see some some work on that all right and if you each could give one piece of advice to somebody writing a smart contract on something to look out for or something to be careful about what would it be? Um I would I would give you advice that sometimes the code work as intended but the mechanisms behind it are not so sometimes it's not about the codes about the way you design your contract about how interact people interact you don't consider that might be a malicious player interacting with it that someone is like not bad behavior and it's kind of easy to oversight that and just like because it passes the test it works but you have to account for like bad people right I mean I again would just mimic the same thing I mean formal verification everyone thinks is this magic bullet but there's still again the game theory you have to think about I mean we've heard about minor front running this is a great example of the type of things that the code is doing exactly what you expected to do there's nothing being lied about about what's happening it's just people who have weird connections to what's going to happen have too much say and can tweak what you expected to game theoretically or mechanism design wise work. Yes and my top recommendations would be know the EVM in detail and keep it's simple don't build like very large inheritance models because just try to keep it simple and much easier to audit last one dropped out alright so I'd like to to see are there questions from the audience for the panellists if you raise your hand and shout it out I'll repeat the questions so everyone can hear nobody has any questions about smart contract security Makoto I've seen like many companies or individuals does like code auditing but there's not much standard if you want to say like if we gonna have code auditing standard or something what kind of stuff should be on the standard list so effectively you're asking how would you recommend people go about auditing code is there is there a best practice for that is that right yes best practices for auditors and audits so I'll say there's been some work in that direction I think mainly done by consensus they've put together best practices guide but as I mean in general it's the field is not yet mature it's taken a lot of years to even get kind of like a rough web application security guidelines going and it's still evolving and this is the same thing here new things get added as hacks happen and so yeah there's I don't know it's it's going to continue to evolve there is one but it's not it's not all complete and one other thing I I I agree we need something like that we also need some I I would like the idea that auditing should be a fairly public type thing I've done many audits and often time I'll say like oh well you're you're can be exploited if character who owns this address does this thing and often I hear the response like oh that's the lead developer he won't ever do that to us and that's not accounting for him a being malicious him or her or them being hacked and their computers private key being stolen so I I too often hear in response to a completely valid audit well that won't happen and that's you're losing some of the value of blockchain so well we're talking about audits at a very high level would you audit like how do you go from here's a big chunk of code to to here's a finished audit report I would I mean usually to be fair most most audits I feel aren't actually large amounts of code like the Dow looked way larger than anything I've needed audit before that was like a lot of code for what I was doing but even with one issue or thing that actually makes this describing this process a little bit easier is usually Wack ton of contracts that are all inheriting for each other using each other so it makes it easy to kind of break it down and and yeah I usually just start at the top go through it and kind of like how you brows wikipedia you hit like some weird class you're like I don't want to mean and so you jump with that file and you go through that and it is that you start popping the stack and get up and you have to go over a few times before yeah that's a good point the first thing you do is really understand what the code is doing trying to audit code that you're kind of like well I think it kind of does this you really need to understand the assumptions the rest the code is making I mean going back I guess to a previous thing another like thing I often see is let's say you're counting the number of elements inside a mapping I often see you know plus plus and then set but this isn't or and other direction minus minus and then set to zero and you set the same thing twice you now think the mapping has two items in it and so it's important to kind of be able to trace back and see well what code paths can get here to even do this maybe they're guarding at somewhere else maybe they're not maybe they should be checking like gas efficiency may or may it come to play so I don't know fairly answered the question what was seemed like good start do you have anything to I imagine now that that sounds extremely time consuming to do it this way but really get to know the code read it read it read it read it until you know it's forward some backwards and during that and try to have this aggressive mindset where you know that there are flaws in it you just need to find them cool other questions from the audience shout and I'll repeat oh no we have a microphone hi so we heard from Piper yesterday and for solidity and Python as well are you guys or anyone else looking into how we know if we can trust those packages especially as the standard library might be replicated with different package sets obviously today in the development world we just hope the code works and then we realize it it doesn't which may not be as big of a deal when it's not solidity well that's an interesting question and just will to add there's also the question that if you can we trust the standard because a lot of contract interact with tokens for example and no one accounts for a malicious token that can implement this standard but can modify some some way that now exploits the other contract so it's it's not sure if I'm answering a question but it's kind of a a a a a bad I'm sorry it's it's it's hard to really trust everyone what Martin said you have to be aggressive you have to think that anything can break any time you have that think that anyone is malicious anyone is bad and it's kind of go this way don't trust anyone is anyone thinking about putting in that package management system the concept of this package has been audited and give some kind of of of marking of what company audited at and of course is Piper here? I I mean my perspective at least maybe I'm not supposed to have an opinion since I'm running the panel but is that it's definitely true that systems like NPM are unsuitable here you know you need a lot better control over the code you're running but I think step one and as I understand it to PM implements it is you specify exact versions of the code cryptographically hashed so you know you're getting I don't know if any any of you know whether sort of metadata about auditing is is in scope or not whether metadata for whether a code has been audited and who it's been audited by is is in scope for a package management system I don't know what level of metadata is in so I guess the question is ask Piper or the answer rather thanks just over there I was wondering if you guys are contract languages and if so what would they be we interested in any smart contract languages other than Solidity is that correct yeah yes definitely I did look a bit into serpent contracts way back did in order of the BTC relay but it's right now Solidity is the one which most contracts are written in but I think it'll be actually refreshing change when serpents hits the road properly or Viper Oh sorry Viper yeah yeah I had a fascinating chat with the lead developer Viper today I think it shows a lot of promise I'd like to see more smart contract programming languages I there are things I like about Solidity and things I don't I have a mental laundry list of what my perfect programming language would look like and the reason I don't write it and other languages are going to have a bit to catch up with Solidity before it's before they're sort of at the same level in terms of tooling maturity but I don't think like Solidity is continued domination is in any way assured right and so I'm working on my own like a little language but more as a side project than anything um the Solidity is by far the most mature and it's all those other things on top of it that you really and like syntax highlighting like writing a syntax highlighter is not a fun thing but it's something that you kind of want and that's something you just have to write if you're doing your own like random stuff I I I think another cool approach is to have languages which are less capable basically like Babbage which I'm and I don't know the details of this but I I think that Babbage is a lot more restricted in a greater safety about the you know potential post states after the execution great unfortunately that's all we have time for so thank you very much to my distinguished panellists thank you Up next we have another panel on formal verification moderated by Rito Trinkla