 Good afternoon. I'm Stefan Bayer. I'm the CEO and founder of Groupronics, where I spin off of a large cyber security company. And one of the many things we do is audit smart contracts and focus on cyber security in the blockchain space. So in this talk, I just want to go over our personal experience of auditing smart contracts and how it relates to open source and how we think open source can make smart contracts and blockchain in general much safer or secure. So one of the questions I'm often asked is are blockchains secure? So if you do move a lot of money around with blockchains, that's a sensible question to ask. And my answer usually is yes, blockchains are secure in that the underlying cryptography has been sound. It's worked for a while. The mathematics have not been broken. So blockchains themselves are secure, but the digital assets we represent on them usually are not. So this may sound strange. The cryptography is secure. Why do we have a problem with securing these digital assets? So just to prove my point, there's some facts. So in 2018, there were 1.7 billion of digital assets stolen or lost from blockchains. Depending on which report you read, you get different numbers, but we can generally agree that there's an issue, that money does disappear. And another interesting fact is that there are two groups that have recently been identified that are behind most of the attacks. So this is interesting in that it just shows that it's a business model. It's become very lucrative to break smart contracts and get digital assets and steal Bitcoin tokens, whatever. So it's lucrative enough for big groups to be set up. So why is this? If the cryptography is secure, why is it that smart contracts or digital assets are not? So there's three things, really. First of all, the digital assets are usually represented in a smart contract somehow. Whether you tokenize art, move around Bitcoin, or move around Ethereum, or have a token, there's usually a smart contract involved at some point. And these are incredibly difficult to get right. So I'll talk a bit about this in a minute. But other concerns are that there's a lot of off-chain code involved. Smart contracts are only a small part of a typical blockchain application. You need to interact with them through an API or through a website. And that code shares the same security concerns with any other software. And finally, the humans involved. So every cyber security analyst will tell you that the weakest link in all cyber security is the user. And this is because humans, they lose their parts where they have social engineering attacks, they might lose their keys. So they're generally really bad for cyber security. But these last two, off-chain code and humans, they're not unique to blockchain. That's in all software. So let's focus on the smart contract issue. So a smart contract is often described with this metaphor here of a drink machine. And I don't think it's a very bad metaphor. But basically it means there's a contract between myself and the company selling drinks. And that contract says, I pay $1 or whatever and out comes a can. And this is automated by the smart contract in the form of a drink machine. So really a smart contract is an automation tool of some form of agreement. Possibly a legal agreement, but you know, might just be an informal agreement. So in a blockchain context, smart contracts are written in code. They're just computer programs. But they usually represent some form of agreement and with terms and conditions. And they're deployed and executed on the blockchain, which makes them immutable, which is an important property. And they're sort of autonomous in that you might have to interact with them through an API. But usually the terms are programmed in there and they're not modifiable from the outside. And there are certain events that trigger the execution. And just an interesting fact, they usually in a public blockchain require some gas to execute, which is just a small payment for making sure there's no denial of service type scenario. But basically it's just code. Here's an example contract, a very simple smart contract for Ethereum written in solidity. All these structures are recognizable from other programming languages. Basically what this does, it just stores a hash value of some document or anything really on the blockchain together with a timestamp. So this can be used to replace sort of a notary service, proof of existence of a contract or a document. It's very simple smart contract, but it's actually sort of an easy but useful hello world example. But anyway, why are smart contracts a security issue? Well, first of all, if we're talking about a public blockchain, they're publicly accessible. You want the public to be able to interact with a smart contract when everyone can see the smart contract. They usually hold some value. Blockchains are typically used to represent anything of value. Could be cryptocurrency, but it doesn't have to be. It can be a property, anything. But generally it represents value, and it moves value around. So next, they're immutable, which means, well, it's a very important property for the smart contract, because the only reason they work is that the terms cannot be modified. But it also means that once deployed, a smart contract cannot be fixed. So if you discover a bug after it's been deployed, you just cannot fix it. And the only option you have is to redeploy the contract, make a new one. So these properties together are very useful, but that sort of makes smart contracts an ideal target for cybercriminals. Something that is publicly accessible, is valuable, and cannot be fixed, that's a very good target. So there's a list of some well-known incidents, and there are many more, but these are just sort of important events. Back in 2016, there was a DAO attack. It's interesting to read up on if you're interested, or if you've not heard of it. But it sort of showed us, made us rethink what smart contracts can do and how they should be used, because there was a very obvious vulnerability that lost a lot of money. Then at the end of 2017, there was a parody multi-stake hack, or bug, whatever you want to call it. And it basically meant that a lot of money was frozen on the blockchain and cannot be retrieved. And that's interesting because it was a very important company parody that provided this code and had this happen. So it's not just a small smart contract someone written at home and got it wrong. This is a big incident. And at the end of 2018, a project called Spank Chain lost 40K, which is not a lot of money. But I put this up here because it's exactly the same vulnerability as a 2016 DAO attack. So this just shows that in two and a half years since the first big incident, we've not really learned much. The reason there was less money lost was because there was less money to be stolen. But then just recently, there was a very interesting incident. And we actually had to postpone the Ethereum Constantinople update because of an issue with how that would affect already deployed smart contracts. So there were a number of smart contracts that were considered safe, but that would not have been after the update. That's interesting because you may deploy a contract that you think is secure, but then the actual protocol has a change or is updated, and then it's not. So that's very worrying. So this is our experience of one year of auditing smart contracts the last year. So we've audited 22 projects. There are fairly large projects, including a lot of smart contracts. They included simple tokens and ITOs, but also bigger projects such as investment funds. We did a big STO platform prediction market. And there's a huge variety of contracts there. But anyway, these are the statistics that came out of these audits. Minor issues here, these are really small mistakes where you don't follow best practices. They're probably not a security issue, but they might be in the future as the protocol changes. Like the type of thing that would have been affected by the 2019 Constantinople update if it had gone ahead as planned would have probably been identified as a minor issue. Major issues are big mistakes that are exploitable, but we probably haven't figured out the way how to exploit it yet. And critical mistakes are definitely exploitable. Someone will lose money, and we usually demonstrate this, how we can exploit this type of issue. So these numbers, what do they show us? Well, I like to think they show that we are pretty good at finding these issues. But apart from this, it also shows that smart contracts are incredibly difficult to get right. So these were important projects. Some of them were of less quality, some of them were of good quality. But within the 22 projects audited in 2018, there was not a single flawless project. So it was not a single project, but we didn't find at least minor issues. So that's very important to consider. So what's the solution to this? Well, first of all, it's essential to get a smart contract audit. And I'm not just saying this because I'm a smart contract auditor, and I live from this, but it's really essential. You need some external entity, which is independent, to look at your code in this space. And it needs to be, probably need to get two or three different audits. And it needs to be someone that doesn't know the code bus yet and has a certain procedure and methodology to it. So this is not cheap, but compared to the marketing budget of a lot of blockchain projects, it's actually minor. And it's very good marketing to get a good audit report as well. So highly recommendable. But then obviously, the next solution, and this being here, is to get community support. And you do that by using free open-source software and following the whole model. So the first thing you can do is, as in legal contracts, there's no point writing smart contracts on scratch. So there's templates out there, template libraries that you can reuse. You know, the same way Loja's work, they hardly ever write their contracts on scratch and why should smart contract programmers do that. So you get a lot of community-ordered code for free, which is already out there, which, you know, it's been audited by a very large, active community. And you will find most common functionality already covered. So for a typical project nowadays, you might only have to write 10% of the code and the rest is just using a big library. A good example of this is Open Zeppelin, a very good project. Just listed up here with the link. And then the next step, of course, is to open-source your own code. Now, this is, you know, being here, we're all in favor of open-source code, I suppose. But in blockchain space, it's really a no-brainer because we are placing trust into protocols and smart contracts, removing trusted third parties. So we obviously want that protocol or that smart contract to be open. And it's the only way to prove the correct behavior of a contract and get community validation. And, you know, if you take this step further, you can actually offer bounties. And that's a common way of finding bugs in smart contracts. You offer a bounty program where you get the community to audit your code and to do that, you incentivize them. And you actually pay them for bugs discovered. And there are ways to do that on the blockchain through smart contracts as well in a transparent way. For example, Solidified, which is one platform to do that. And so a bit of a disclaimer, I do a lot of work for them, so that's why I list them here. But I generally believe they're a good platform. So as I already said, it's not just a good idea to open smart contracts. If we are working on a public blockchain, I think it should be imperative. Smart contracts must be open source. Not just for the security, but, you know, if you want users to interact with your smart contract on a public blockchain, they must be able to verify the terms of the contract. It would be like having a legal contract with someone who hasn't read the contract. That doesn't make sense at all. And going a step further, I also think audit reports must be made public. Why? Well, because not everyone is a smart contract expert and knows how to program. And, you know, you want the security validation that you get of a third party, you want that to be transparent, and you want to demonstrate the correctness of the contract to non-expert users. So, yeah, I was just showing the 10-minute sign, but I'm actually finished. Yeah, questions? Yeah, well, the question is, what's about tools that we use for smart contract auditing? And what we mainly, well, all these 22 projects were done for Ethereum-based smart contracts, which is where we find most work. You know, we try to do others, but it's mainly Ethereum that comes in. And there's a methodology to it, a process. So first of all, you know, we just try to get a hang of the code, and then we just run it through it. But then we actually run a number of tools. So there's static code analysis. You know, there's a tool called Slither, which opens us and then we use. There's MyThrill, which is also a commonly used tool. We use both of them. We are sometimes experimenting with more complex tools, like fast testing, but I'm not sure of the usefulness in this space yet. And then obviously we go into the next step, where we have sort of a checklist of things we look for and look for a list of known security vulnerabilities. And the final step is to actually run exploits, and then we generally get up a test network and deploy the contracts. And then we're just using the tools. If it's a truffle project, which is a framework often used, then it's very easy to use that tool chain to get a test network up locally and run some tests. Yeah. Okay, so the question is what's my view on making smart contracts easier to develop? And yeah, you're right. Obviously that might put me out of business, but yeah, joking aside, I think there is a lot of scope for improving smart contract development. And right now you have to be a programmer and you have to be a fairly good programmer at a relatively low level. And there are a number of projects working on things like this, but there's no way yet of sort of a legal contract to be translated into a smart contract easily. And there's also no way of writing smart contracts at a very high level. Simple script language. So yeah, obviously that would be very important. And I know there are a number of projects working on this. Questions? Any other? Nope. Well, thank you very much, Stefan. Okay. Thank you.