 I'd like to present to you a proposal for a smart contract programming language, which is radically different from everything we've seen so far. The main drawback is that it's still just a proposal. The main goal here is not necessarily to create a programming language which makes it easy to write smart contracts, but more a programming language which makes it possible to write smart contracts which are easy to understand. So let's take a look at how smart contracts are written nowadays in a language called Solidity. Yeah, we have, as an example here, a smart contract that does some kind of crowdfunding. It's simplified, so some aspects are missing. And so it starts with a mapping that stores the balances of the participants. So participants can send ether to the smart contract and it just registers who contributed it how much. And then there's a Boolean flag called locked, which can be set to true when the function lock is called. So this function lock usually probably needs some more checking so that not everyone can call it, but yeah, there is a way, so the flag is initially set to false and there is a way to set it to true at some point in the lifetime of the smart contract. And while the smart contract is still unlocked, you can send money to it using this function called fund. And your contribution will be registered. And still while this contract is unlocked, you can also call withdraw if you change your mind and say, oh yeah, I don't wanna contribute money there. And it will just, yeah, send you back everything you contributed. And now because this would not be useful like that, there's of course more code below, which is a little complicated, but yeah, I mean, we saw that everything works. I can send my money there and I can also withdraw for some time until the point where someone locks the smart contract and then the money is there. But it turns out if you take a deeper look at the stuff that does something complicated there, there is a tiny line of code that says locked equals false. So it turns out there actually is a way to unlock the smart contract at a later point in time, which means people could actually withdraw their money even though the contract has been locked before. Okay, is that kind of clear? So and the problem here is of course that anywhere in the smart contract you can hide this tiny line that says locked equals false. And then somehow, yeah, so if you want to find out whether it is possible to only lock the smart contract once and not unlock it later, you have to analyze the full thing and find every occurrence of the word locked inside the smart contract. And I would say that this is a general problem of any text-based programming language that variables can be referenced just by stating their name from anywhere. I mean, that's not 100% true for all programming language, but I guess the idea is there in all text-based programming languages. And the problem why this is weird is people, when people deal with abstract concepts like programming languages, they are still able to understand it because there's some kind of analogy to the real world. And I would say this referencing kind of breaks the analogy for us. So I don't know, imagine walking the streets of Cancun and shouting Vitalik butchering and Vitalik pops up next to you. That's weird, right? That doesn't really work in the real world. Why should it work in programming languages? So and the problem is you don't see, there's no visible connection between the declaration of something and the referencing something. There are tools that do that. So in most IDEs when you click on a name, it highlights where this is referenced, where this is used, or you can right-click and say find usages and something like that. But yeah, why do we need these tools? Why don't we actually fix the programming languages? And so other things people usually do is enforce modularity of software or encapsulation, which kind of helps limit the consequences of that problem, but it doesn't eliminate the problem. And yeah, this is one problem of text-based programming languages and another problem of text-based programming languages is that they always, oh yeah, they always have to use a certain natural language. And I'm not talking about syntactic elements. Here like for loop, you have this English word for there or function, the English word function. I'm talking about the names of identifiers. So variables and functions always have to have a name. And this name is always a word in a certain natural language. And if you're not too proficient in that language, it's hard for you to understand the software. And the humans all speak different languages and the way this is solved is that most people agree to use English. But yeah, this kind of makes it hard for people who are not that good in English. And so imagine you're such a person, you don't just speak English very well, and then software or a smart contract will look like this to you. This is an actual language. So bonus points for anyone who can find out which language it is. And even more bonus points for someone who can tell me what the smart contract does. I already heard, yes, it's Gaelic. So, and what does it do? Oh yeah, sorry, I forgot. Of course, you can't say what it does without actually seeing some functions. So here's some more code. Does that help? Yeah, I guess you get the point. So when I explain Ethereum to people, I often use the analogy of a soda vending machine, for example. So imagine you have a soda vending machine that is somewhere in the public, anyone can walk up to it and buy soda from it. Anyone can go there and use it. And even more so, this soda vending machine is made out of glass. And this means everyone, which is common for soda machines, you can see whether there are actually still drinks inside before interacting with it. But even more, you can also, because it's fully made out of glass, you can even see whether there is still change in the inside the machine. So you see whether it makes sense to pay with large coins or small coins and so on. And you can even try to find out how it works. Because you can see every part that moves. It's a little difficult probably, but it's possible in principle. And this is unprecedented in software. And we have a kind of similar thing with open source because you can actually see how software is written, but that doesn't help you if some software runs on a server and you actually don't know whether that software was compiled from this host code. But with Ethereum, you actually can be sure about that. I think I'm running a little bit late, so let me try to speed up. And I would like to use this machine analogy and extend it into a programming language. Okay, this is a Babbage smart contract. It's very simple. So you always have these dashed lines which are basically the casing of the machine and you can only manipulate it from outside of these dashed lines. And what you can do is you can send ether inside that machine. We all know that ether is a liquid that flows through pipes. So you can pour ether inside that pipe. It will follow the direction of the arrow or it will also always flow downwards. And then it enters this gadget here which is a so-called splitter and it moves half of the ether that enters the gadget to the left and the other half to the right because the setting is 50-50. And then ether continues flowing in that pipe and at the end, the ether that comes out to the left side is sent to this address and the ether that comes out of the right side is sent to that address. Quite simple contracts concept. Doesn't do much, unfortunately. So let's take a look at a more complicated example. We can add a lever to this splitter which allows that account here on the right to modify the splitting ratio. Currently it's set to 25.74 but at any point in time this person behind the account on the right side can modify this ratio. Okay, still not very useful. Let's take a look at a little more complicated example. People have been to DEF CON 1. Might recognize this again. So I did a live coding session there back then and I wrote a smart contract which does exactly the same thing as this Babbage machine here. Okay, there are two sides. The left side can only be used by this account and the right side can only be used by that account. So there's a, I call it seller and buyer. I know I use the English language again but the difference here is that the fact that this address is called seller is not an inherent part of the language. It's basically just a comment and you could have comments in different languages at the same time. So both seller and buyer can send ether into this ether tank and both sides of the tank can hold up to 10 ether and they can also press this abort button which opens the valve here and lets the ether flow out of the tank and send it back to the person that put it in. And the interesting thing now is that as soon as, so these things on the top here are floating switches. They are currently off but as soon as both parties send the full 10 ether into the tank, the floating switch activates and opens the valve here at the bottom. And if both valves are open at the same time which means if both seller and buyer deposit 10 ether then the combined 20 ether will flow into the bottom tank. And at that point, it's visually clear I would say at that point if the ether is in the bottom tank there's no, this abort button doesn't have any function anymore. And this is something which is very easy to see in this visual, using the visual programming language but it's probably quite hard to see in a text-based programming language. Another thing you can easily see in this diagram is that the upper part is fully symmetric with regards to seller and buyer. And only the lower part is asymmetric. This is also something you can't really see in text-based programming languages. Okay, let's continue, how does it work? So we have two other buttons that operate the bottom tank. The buyer can release the payment to the seller and the seller can refund the buyer which moves the ether into a splitter and moves half of the ether back to the seller and half of it back to the buyer. Okay, that's how the smart contract works. What's the idea behind? This is an ISCRO smart contract. So the seller sells something, has to put up a deposit and when the ether flows into the lower tank then the seller sends the item to the buyer and when the buyer receives the item she presses the release payment button which pays the seller and if the item does not arrive they have to kind of come to an agreement and one of the outcomes of the agreement might be that the seller just refunds the buyer which results in the seller retrieving the deposit again and the buyer also retrieving the deposit again. Okay, yeah, so as I said this is for now just a common concept. Unfortunately, there's not much more than this talk here but I welcome everyone to join the discussion. We have a Google group here and if you have any ideas about more gadgets please propose that in this discussion group and oh yeah, of course I mean the idea is of course also to have a graphical IDE where you can select these gadgets and snap them together and connect them and of course you can also create smart contracts which have very complicated pipes running all across the screen. The language doesn't prevent you from doing that but you immediately see that it looks really, really messy if you do that and so you're encouraged to create machines that look simple and are easy to explain. Okay, that's about it, thanks for your attention.