 Then I'm going to jump over to our next speaker who has already been mentioned in this presentation actually is from Holland boss Spitters is coming up on the floor. Now he's from Department of Computer Science at Oldham University and it's going to be talking about smart contracts and formal verification from blockchain. So as Claudio said, so we just recently set up a blockchain research center here with generous ground from the Concordium Foundation. And as part of this, we're doing formal verification and design of smart contract languages. So I would like to tell you a bit about this and the motivation behind doing this. So blockchains. So one of the basic things they provide, I mean, that there's a precise definition. So an append only log that's unchangeable, but very importantly, what they provide is trust. Trust in a system that because everyone can participate in checking, we have security cryptography built in so that those are very important aspects of the trust. But also understanding through open implementations, almost all the implementations of blockchains are open because if you have a closed implementation, people won't trust it because they think you would build in a back door. Scientific refereeing, that's an important process and mathematical proofs, so cryptographic proofs. So all those things contribute to having a whole system that people can actually trust. So currently, last time I checked, there was something like 5,000 different cryptocurrencies. And I can tell you only a handful of those are actually adhering to those principles, to all those principles. But those are the principles we try for. We really want to make something that people can trust. So why do we want to do formal verification? And Claudio mentioned very briefly what it is. So giving a mathematical proof that our software actually satisfies a specification. So the internet broke five years ago. And just to remind you about this Heartbleed bug, so this was a bug in TLS. That's the protocol that's doing all the communication on the internet. So TLS is basically the lock in your internet browser. What happened there is best explained by the XKCD webcomic. And there are many things in life that are best explained by this comic. So what happened there in the protocol was you would ask the server, please give me back birds in four letters. Indeed, what the server would do was actually send you back this information. And now there's this strange thing in the protocol that you're both sending a string, a request, and you're sending the length of the request. So now make things, well, let's experiment a bit. And let's just ask for head with 500 letters. And then the server just obliges. So it looks up head and sends the 500 letters connected to that. And this allows you and anyone to read out this memory from the server. And this would contain passwords, all kinds of private information, a master key. So the internet was really completely broken and it was extremely hard to fix this. And so this led to the realization that actually we need much better software practices. There are a number of standards for how good software is. There's one standard, the EAL, which goes from one to seven plus. So one is just very basic unit testing. And the highest level, you actually do formal verification where you prove that your software actually meets its specification. Now one of the things that happens in TLS is we use this cryptographic library. In this case, for example, elliptic curves. So elliptic curves, I give you an artist impression here in practice. What you're using is elliptic curves over finite fields so you cannot actually draw the picture. So this is one of the more advanced Bachelor courses we're teaching here at Orish University. So what we need to do is to teach the computer to actually understand this mathematics that we're teaching our students. So it's quite advanced mathematics. And then we need to spell it out all the way down to the logical axioms because we want to make sure that there are absolutely no mistakes in that process. Once we've done that, so this is already a quite complicated task. We only have the mathematical algorithm, but now we need to refine it to an efficient implementation. So we also want to make sure we want to have a formal proof that the compiler is actually correct. So this is a lot of work and we actually want to extend the work that's there. So Diego will be speaking after me and we're looking for a PhD student to help us in that process. So what the cryptographers are doing, they're writing mathematical proofs. But writing proofs is hard and it's just a tedious task. So people make small mistakes in that, they're off by one hour. And computers, as in any tedious task, we can ask the computer to help us fill in these proofs. And there's now an emerging field of computer-aided cryptography where we combine crypto, programming language research, and formal verification. So now to come back to the TLS story. There's a lot of work by a number of groups. I want to just highlight the work by Microsoft-Inrea. They have a joint lab and this joint lab was actually one of the examples also for the Concordium Center where we have a collaboration between what's happening at the university and what's happening in the company. So there's now a completely formal verification of the TLS protocol. There's a new standard, of course, because the old standard was broken. And if you're using Firefox or Chrome, you're actually using these formally verified libraries. So there's been a lot of progress in these five years. So the technology actually became a lot better. This also means that if you get an accident like this in something that's as important as your banking software or the internet in general, then you might also be liable for it because you haven't actually done the rigorous process of making secure software. So what they actually do is they prove the correctness of the CN assembly implementations of those libraries and prove the security against a precise attacker model. So now why am I mentioning this bug in TLS? Because there's something very similar going on in the blockchain space. There we had enormous accidents. One very famous is this distributed funding organization. So the idea would be to have something like the industry funds but then actually have it on the blockchain and have it fully done there. So people could make proposals and vote on proposals and then if the majority of people thought, well, this is a good idea, then you would actually be paid out. The problem was that the way this organization was programmed they thought they understood what they were doing but the semantics of the underlying programming language was so subtle that actually the rules were slightly different and in this way they got hacked for a third of the money they had for $50 million. And this is a program that's only about a thousandth line of code. So it's very small and still there was such an enormous bug in it that actually allowed you to empty out the whole organization if you want. Another one that came up or was published recently, it came up about two years ago was a bug in a cryptographic paper. So this was done by high quality researchers. It went through scientific review process so they've been extremely careful. Still, there was a very subtle bug in this and this allowed you to print money and we hope it hasn't been exploited but we cannot be sure. So there's a very... And all these things are things that we actually have the technology to avoid by doing formal verification. So what we want to have is a blockchain with the quality of TLS or maybe even better. So you saw this picture before. So this is what the blockchain stack actually looks like and we're doing verification of the whole stack. So I want to highlight one thing that actually my PhD student, Cern Allen Thompson, is working on. So this is the verification of the consensus protocol and we now have a proof that the concordium consensus protocol is actually functionally correct. But the next thing what we want to do is to prove that it's also secure and there we need to do, as I showed you before, what we're doing here is reducing everything to the ordinary logic but because of this cryptographic aspects there are all kinds of new reasoning principles that come in. So this is reasoning about probabilities, reasoning about an attacker and so we need to have a very precise attacker model for reasoning about distributed systems. So there are all kinds of new reasoning principles that come in. So there's a lot of work to be done there. Fortunately, we have some things to start out with. Then I want to switch or continue with smart contracts. Claudia already highlighted this. So the first generation of blockchains, so we can say this is Bitcoin which is purely a cryptocurrency. The second generation was the realization that the underlying technology of Bitcoin is actually the blockchain and we can just put a general purpose programming language on top of this and these are then called smart contracts. So a smart contract is the digital analog of a legal contract. So one example is here where you can ensure your house on the blockchain. So if your house burned down you automatically get paid out. Here are some similarities and some differences between ordinary contracts and smart contracts. So the specification of an ordinary contract would be in natural language and legalese and smart contracts would just be code. Identity and consent would be a signature or digital signature. Dispute resolution would be judges and for smart contractors could be done in a decentralized manner. A nullification is done by judges. Perhaps it could be done on the blockchain with governance and payment and ESCO are just built in into the blockchain. Potential applications of smart contracts are making new tokens. We don't really need to design a new blockchain each time we want to build a new cryptocurrency. We can just implement the token on the blockchain. Voting, ESCO, marketplaces, insurance, supply chain management, there are a number of examples there. And also replacement for DNS. That's something that's actually in use. So what's happening now? Because so this DAO example, so this is a very critical example that just shows that it's extremely hard to write search contracts in basically JavaScript. So JavaScript is the programming language they used for Ethereum. And then you just make mistakes and these mistakes can be avoided by using a more mature, more modern programming language. So a lot of projects, the Tesla project, Cardano project, the Concordian project, Zillica project, they're all moving towards new programming language. Typically those would be functional programming languages. And there those are much easier to understand, much easier to reason about, much easier to analyze. So you could, for instance, compute how much gas you actually need to run up a search contract as opposed to just paying it. And they have a very clear meaning. So you can actually, it's actually much easier to understand what you're doing. And so in this way you can avoid big accidents like this. There's a number of very simple invariants you could have written down for this distributed organization. If you would have just proved those, the 50 million would still be there. So what we're building in my group is a verification framework for the smart contracts. And this is both looking at the compilers, the interpreters for smart contracts, looking at verifying individual contracts. So we now have a re-implementation of the DAO in the Oak language, and we're proving properties about it. And in this way you can make sure that a very big class of accidents doesn't happen. So this was just a wrap-up of some of the things, some of the research we have going on in the Concordium Blockchain Center. And I'd like to emphasize some of the tools we're using. So this is computer-aided cryptography and modern smart contract language design. So we're taking a lot of ideas from programming languages. And what is very important is that we have a very clear meaning, very clear semantics, and languages that are easy to analyze. Thank you. Ask a question that might be absolutely only for my own benefit here. Yes. Depending on the audience. Who in this audience feel that you can explain the difference between Bitcoin and Ethereum to your little bit slow art at a family dinner? Hands up. Who can feel that they can do this? Okay. You get to answer. Nobody can answer you. You're always going to pick you. No, please. So as I tried to say, so Bitcoin is just money, whereas Ethereum allows you to have, so you have a big ledger, and then you can write any contract that you would write down with the help of your lawyer on top of that blockchain, and then you could carry it out as just a programming language. So it's really the difference between money and a world computer as the way it's marketing. So it's a very big difference in functionality. And you could use Ethereum to write contracts for other coins, for instance. So there are currently many coins running on top of Ethereum. You have a really super smart ant. So I'm going to actually probe a little bit more into this. Can you use some examples of the difference here? What differentiations would you have? I had a list on the slide. So you could have an insurance to have nice weather today. So you would write a contract saying, well, if the weather is good today, if the weather is bad today, then I actually get paid an amount of money. So this is a very simple example. Another one would be the name coin that I mentioned. So this is a replacement for DNS. DNS is just the connection between the URL you have in your browser and the IP address. And so this is basically some public log where you just connect names to addresses. So this is a very typical application that you can write on a blockchain. This is not something you can write in Bitcoin because there's no programming language there, but this is something you can easily write in a smart contract language. It's 10 lines of code, basically. So that's a very simple example, but that's one that's actually in use. And if some great article comes to mind, then you think that I should know that we could share on social media for people who are trying to understand the subject. Please send it to me, to the network that I have. Because I think this is important that people actually try to understand this, and that's also why it's a transition for us today. So thank you very much to Bas. Thank you very much.