 Once upon a time there was a king, his kingdom was big and he ruled upon it with great strength and justice, so that all his people loved him. But what he loved the most were his three daughters, the princesses. And one day the king felt the death was imminent, so he decided to sit down and divide his kingdom in three perfectly equal parts. Then he wrote a testament, made copies of it and handed one copy to each one of his daughters. He kept one copy for himself and then the four of them they went to the notary office. And once the notary has put his seal on each of the copies, the king felt relieved. He knew that he could spend the rest of his days in peace because if at any moment after his death someone tried to forge a false testament trying to change his will, the notary would grant the authenticity of the first original copy, the one that he wrote. But these days didn't last long because not much time later he received an anonymous message saying that the notary and his youngest daughter were conspiring because they were in love. They wanted to forge a new testament that would give all the lands to her, stealing them from her sisters. And the notary would grant that this fake document would be the original. The king could have the notary captured, tortured and killed, but he didn't do that. It would be very difficult to substitute him and even if he could substitute him how could he know that the loyalty of this new man would be forever? The king quickly understood that the problem here was the need to trust a single person for such a job. Unable to find a solution, the king published an announcement promising a huge reward to the one who could solve the problem of granting the authenticity of a document without trusting anyone. He received many engineers, inventors, wizards, alchemists to the castle and he discarded each and every one solution because they were weak because trust was still a basic block. Right before the king began losing hope, a young boy introduced himself. He said that he knew a machine so perfect, so unstoppable, so incorruptible that trust was not even a problem. He said that this machine could solve any problem as far as the problem could be expressed in the language of the machine. Okay, said the king. So what's the name of the machine? The young boy said Ethereum. The king said Ethereum. You bunch of hipsters. So show me this Ethereum machine, said the king. I can't, said the boy. The machine is everywhere. The machine is nowhere. Oh my god, said the king. So tell me how it works. The young boy took a deep breath and started talking. Ladies and gentlemen, bonjour. My name is Luca Marchesini and I work at CASEL where I contribute to the construction of probably one of the most awesome on-premise back and up there and I'm here because my team helped me prepare this talk and while I was doing my slide and rehearsing, they kept up the pace, providing good code to the repository. And I'm here today to tell you what the young boy said to the king. I'm here to explain a little bit Ethereum and it turns out that the best way to understand Ethereum is as a generalization of Bitcoin. So let's talk about Bitcoin. Bitcoin is nothing more than a bank and a bank is nothing more than a system that helps us keep track of the state of a set of accounts and it does so by maintaining a ledger of transactions which is nothing more than a log of transactions. And the interesting thing here is that by keeping the log, we can compute the balance of each account at any moment in history, right? And Bitcoin is exactly the same thing. It's a ledger. It maintains a list of transactions but the difference is that Bitcoin doesn't rely on a single centralized entity. It's not one server or one cluster. It's decentralized and trustless. Bitcoin relies on a network of computers that work together keeping up this service without trusting each other. So how could this possibly work? First because every piece of information in Bitcoin is public. Every node that joins the network and anyone can do that. Anyone can join the network. Every node gets a full copy of the whole ledger which today is about 100 gigabytes. I think probably more. And this allows every node to verify all the information in the ledger. It's the duty. Every node has to verify everything. Transactions are signed so nobody can send a transaction to the network on behalf of anyone else because nobody can fake cryptography. And in addition to this, every transaction must comply to a set of rules which we will call the consensus mechanism of Bitcoin. And if a node tries to submit a transaction to the network and this transaction goes against consensus, the transaction is simply rejected. And in order to synchronize themselves, nodes do not just stack transactions one upon the other. They group them in blocks. And blocks here behave pretty much like Git commits in the sense that they are linked together. They form a chain. That's why we say that Bitcoin is a block chain. And the way they are linked together is that each block contains in its header the hash of the previous block. And Git works exactly the same. The only difference is that in Git, a commit can reference many parents. And in Bitcoin, in a blockchain, every block can reference one and only one parent. But the interesting thing here is that by being chained in this way makes the blockchain immutable because if you wanted to alter the content of one block, we would need to reconstitute all the subsequent blocks because all the hashes would change, right? And this is theoretically possible. But in Bitcoin, this is extremely expensive because the algorithm artificially makes expensive the process of building a block, which we call mining. So the name of the game here is that playing by the rules is more profitable than cheating. It's a game theory thing. So I will not discuss more here about Bitcoin. First, because we just have half an hour and if you want to talk about Ethereum, we just don't have enough time. And also because many of these concepts are extremely well covered by Andreas Antonopoulos, which is the most prominent Bitcoin evangelist out there and probably one of the best speaker I've ever seen. So there's this masterclass that he gives at the University College in London, where he explains the consensus mechanism that underpins Bitcoin in an awesome way. So if you want to fill the gaps, just go for it. It's a one and a half hour video. It definitely worth the effort. Did everybody get the QR code? Okay. I hope maybe we can put a link in the video for the YouTubers. So if you're not familiar with the technology behind Bitcoin, I ask you to have a little bit of faith. Just stay with me. Bitcoin is actually a thing. The market cap is just huge. It's insane. It's decentralized. It's trustless. It's immutable. It's secure and it works. From now on, let's generalize. We said that Bitcoin is a ledger, right? What's a ledger? In the end of the day, the ledger is just a state machine, which is a system that provides a function that, given a state and an event, which we call a transaction here for consistency. Given these two things, the state transition function allows us to compute this subsequent state, the next. And so on. Every time there's a new transaction, we get a new state, right? And this state transition function in Bitcoin is hard-coded. Whenever you run a node, you run a software, and this state transition function, which contains all the rules of the consensus mechanism, is hard-coded in the software, which is perfectly okay because Bitcoin just has one purpose, being a bank. Nothing more, nothing less. But what if he could make S programmable? That's pretty much what Alan Turing did when he invented, guess what, computers? Well, we would get Ethereum, which defines itself as a Turing-complete virtual machine running on a decentralized, distributed network. In Ethereum, what we would persist, it's the list of transactions. We persist them in the blockchain. And we keep the latest states in memory. In the fashion that in order to change the state, we have to submit a transaction. There's no other way to change the state, right? And every transaction is persisted. So let's go back to the problem of the king, the notary problem. Do you remember the problem? Yes, you do remember. Okay, let's take a look at this piece of code that I just got on GitHub. There's many of them, credits on the bottom right corner. The core thing here is this function, register proof, that the king may call, providing the hash of the testament, right? And this hash would be used as the key for an associative array that would be associated to a metadata structure containing the address of the king. MSG.Sender contains the address of the account that called the method, the now timestamp, and a comment that the king may have passed to the function. So we create a new entry to this associative array. Of course, before we checked that the entry doesn't exist yet. And here is where we declare the metadata structure. And everything is wrapped in a class, in a very object-oriented fashion. But instead we don't call it a class, we call it a contract. And that's the way, that's the vocabulary of solidity, which is the high-level, strongly typed, object-oriented language that compiles to byte code that the Ethereum virtual machine can understand. Awesome. So we have a bit of code. What do we do now? Well, just the classic things that we do when we write code. We compile it, we load it in memory, and then we execute it. Just like on a computer. Let's see how it works in Ethereum. Okay, not very exciting. This is just a compilation step. Works as usual. You have a compiler. It's called Sol-C. And it generates byte code that we want to load in memory. And loading things in memory boils down to changing the state of this memory. And we said that to change the state, we need to submit a transaction. And that's exactly what we do. We take the byte code. We create a transaction that wraps it. Of course, we have a full tool chain to do that. And when we send the transaction to the network and the transaction is approved by the network, we get an address for the byte code that we just deployed. Just like when we load the program in memory, we get an address in memory so that we can tell the processor, hey, go read at that address, take n bytes, read these bytes as instruction, and execute them. And to do that, we do the same thing. We create a transaction containing the address that we just got, the name of the method that we want to execute on the contract, and the arguments. And what happens here is exactly what we just said before. Nodes in the network receive the transaction, and they have to run this state transition function against the transaction in order to compute the new state. But our transaction is a method call. So all the nodes that receive the transaction in order to validate it, they have to run our code, which leads us to say that in Ethereum, nodes do not share the computation load, like on a cluster. Ethereum is not a cluster. Ethereum runs in a trustless environment so that nodes do not share the computation. They replicate it because they have to verify that every other node said the truth. And performance here is not the aim. Security is the aim. In addition to this, for a transaction to happen, it must be included in a block. And we said that building a block is expensive in terms of computation, in terms of energy, and in terms of time. In Ethereum, building a block and having the block accepted by the network takes, on average, 17 and a half seconds, which is not fast. You don't want to deploy on Ethereum an image processing task. Awesome. We deployed a small piece of code. So how do we interact with it? How do we let other people, non-nerd people, we don't want to send emails saying, this is the address. Build the transaction. We need a UI. And this UI, just like classical server, client server paradigm, has to communicate with the backend. But the backend here is the blockchain. How do we make this possible? It's extremely easy. The Ethereum Core Developer Network provides a set of libraries. And I pick the web free.js, which is the JavaScript library that I'm familiar with. And it just provides all the API that enables any layer to communicate with the blockchain. And we just made a DAP where the D stands for decentralized. Let's go back to the contract now. Does this make sense to everybody? I hope so. We can dive a little bit more on what happens with contracts. This is the notary contract once again, and it inherits from another class called owned. Why is that? Let's take a look at owned. It has a public member called owner, which is an address. And owner contains the address of the account that called the constructor. MSG.Sender is that address. And this is reliable information because MSG.Sender is an environment variable provided by the Ethereum machine that reads the address of the sender of the transaction, which is signed. So it's reliable. And passes through the MSG.Sender to make it available for the code. And in this concrete case, the constructor is automatically called by the transaction that deploys the contract. So deploying a contract means actually creating an instance of this class that we just declared so that we can deploy many times the same contract because we are actually deploying instances of the contract. So here, the owner of the contract is the account that deployed the contract. Why do we want to do that? Because we want to restrict some execution of some methods to the owner only. And we do that by declaring a modifier. A modifier is just like a function that wraps another function, like the process of corifying a function. And what we do here is just we add an instruction, a check, that throws if the sender is not the owner. And then if everything is okay, we execute the rest of the function code, which is represented by this placeholder here. So let's see this modifier applied somewhere. This is another contract called mortal that inherits from owner. So it inherits all the modifiers as well. And here we apply the modifier, only owner, to the function kill so that the self destruct function is executed only if the owner has called the kill method. Okay, what is the self destruct? What's the point of self destructing a contract? This is because in Ethereum, we are pretty different. It's a pretty different environment than a Linux box. Contracts that we may think about as processes in a Linux box. They are meant to be autonomous entities. When you deploy a contract, it's not yours, unless you tell it so. The Ethereum virtual machine will not try to stop anything. The Ethereum virtual machine will not provide signals or kill comments to stop contracts. They are meant to run forever. And the Ethereum virtual machine is something that you can't stop it. It has no on-off switch button. It's a network. So you have to force everybody that participates in the network to shut down their computer, which is not easy. So unless we tell them so, contracts are going to run forever. So what happens here when we self destruct a contract is that we send a new transaction that unloads what we previously loaded. It deploys the contract so that when we call that address, the machine throws an exception. And the other funny thing that happens is that all the money that the contract owned is sent to that address that we pass as an argument to the self destruct function. Did I just say money? Did I just say funds? Yes, I did. In Ethereum, we have a cryptocurrency just like Bitcoin. It's exactly the same. It's called Ether, not Bitcoin. And the funny thing here is that contracts can own money, just like humans. In Ethereum, contracts are really first class citizens, just like us. Now, let's check this function that we previously ignored in the notary contract. You can see it inherits from owned and mortal. But there's this piece of code that we didn't take into account before. It's an anonymous function that every contract can implement. And we call it the fallback function. Because it's a fallback when someone tries to call a method that doesn't exist on the contract. And also, it's executed whenever someone sends money to the contract. So this implementation here, it's pretty honest because the notary contract isn't meant to manage any money. So the author here just made the function throw so that when someone tries to send by mistake some Ether to the contract, the function throws and the Ether is sent back to the sender. The exciting thing here is that we are dealing with a system where money and the rules that allow money to flow, they live in the same system, which is different from real life. Let's explain that with a concrete example. Imagine that the king wants to buy a TV set from a merchant. He goes to the website, checks the cart out, sends the money. And once the merchant has the money, he has the choice. It's a moral choice. Either he sends the merchandise to the king, either he runs away with the money. He goes against the law. The king can leverage the law because he can try to get refunded and get his money back. But in the meanwhile, the merchant has fled with this money. This is how real life works. Imagine that we can put a middleman contract between the two. When the king checks the order out, he can send the money to the contract instead to send them directly to the merchant. And then the contract would hold the money in escrow and notify the merchant that there's a payment pending for him. If the merchant wants his money, he must send the merchandise. And once the shipping is complete, the king and the shipping company can sign together a transaction to notify the contract that the shipping is done. The contract can then unlock the money and let it available for the merchant to withdraw the money. And everybody's happy. Our story is close to its end. Right now, we're running out of time. We can say that the king is happy because he solved this problem. The notary is sad because he and all the notaries in the world, they had lost their job, which is something that always happens whenever we introduce a new disruptive technology. Philosophers and thinkers in the kingdom are now wondering if the humanity will be able to deal with such a perfect, unstoppable machine as it gains more and more power. But the king sleeps like a child. He's unaware of what's going on. He doesn't know that somewhere in the suburbs of his kingdom, in a very well hidden garage, a group of hackers are trying to code a contract that once deployed, it will enable for perfectly democratic decision-taking. The king doesn't know that the age of monarchy is probably over. He doesn't know that the age of democracy is probably coming. But this, ladies and gentlemen, is another story. Thank you very much. I have a lot of questions. I was right away. Okay, that was great. I have lots of questions. Where should we start? In the king and merchant scenario, how do you ensure that the king and the delivery guy don't conspire against the merchant? Very good question. I've asked it myself. Well, of course, the use case that I described is pretty simplified. People that actually work on these kind of things have figured out many scenarios, but one thing, I'm probably very naive here, but one thing we could do is that if the shipping company wants to get paid, they are forced to be honest with the king and properly sign the transaction that the delivery has been done well so that the contract can unblock the funds for the merchant and for the delivery company. So if they don't do that, they don't get their money, right? Okay. Another one on the more technical side, I guess. If you can write any program and anyone can execute it, and everyone executed it, isn't that a very easy way to spread malware? Yes, of course. I never thought about that, but yeah, you can deploy malware on Ethereum and you can tell people to use that. We are entering, we are overlapping a little bit with a non-archist realm. So it's pretty much up to you. You have to be careful. There's a lot of hacks in the Ethereum world. There's been a lot of hacks this year. There's a lot of companies that claim that they were an online wallet and then instead of managing your funds, they just send all the funds to their address. And this is something that you just can't revert. So you really, yes. Everybody can deploy everything. And it's up to each and every one of us to be aware of what we do. You talked about the hacks. Obviously earlier in the year, Purity's wallet was hacked. And there were millions stolen over, I think there were three hacks, if I remember rightly. Yes. Parity, multi-signition. Parity, sorry, not purity. How should we, if we were going to use this, defend ourselves so we don't become victims because that was just a one-line book, if I remember rightly. I actually previously, when I first wrote the first draft of this talk, I wanted to talk about the parity multi-signature hack because it's a very good example of how fragile this environment is right now. Because of course, when you deploy, what happens is that someone hacked three very rich wallets and then everybody can see everything. So they were seeing that they were being hacked and all the other people that used that wallet, they couldn't do anything. And what happened is that a group of hackers, a white hack, a white hat hackers, they hacked systematically all the other wallets and transferred the funds to more secure wallets. This is because you can't stop contracts on Ethereum. If you deploy a bug, it's going to be there. So updating a contract is kind of an open issue right now in Ethereum. There are solutions being proposed which involve the use of libraries, which I wanted to discuss but I couldn't. But I think that the best way we can protect ourselves from these kind of flaws is to test more, to enable ourselves to automatically test contract in a more extensive way. And we know that object-oriented programming is not the best paradigm to do that. Functional programming enables for automatically generated tests. I don't know if you've ever heard of it. But there's clearly a lack here and I believe that the lack will be filled by the tool chain that will improve itself more and more and bugs will be almost automatically spotted by the tool chain. I hope so. I have three more questions linked to this. One that I was wondering was, if the contracts run forever, how do you avoid DDoSing? So could you not just spawn loads of those contracts? Yes. This is another thing that I wanted to talk about and that didn't fit the... No, but it's okay. It's perfect. Actually, to avoid DDoS and avoid flooding of the network, Ethereum introduced the concept of gas, which is basically a measure for the computing resources that you're going to use. So when you send a transaction that triggers the execution of a method, you have to declare two things. First, how much gas do you want to allocate? Which means how many instructions are allowed to be executed by this call? So if you execute less, it's okay. If you execute more, the program fails, the execution fails. And the second thing you have to specify is how much money you want to pay your gas for. This is important because if you pay less money per gas, your transaction is going to be cheap, but miners will not... We are going to be likely to deprioritize your transaction in favor of more expensive transactions. So if you pay a lot of money for your transaction, you're going to be sure that the transaction is going to be taken into account quickly. The thing is that no transaction gets lost. So at a certain point, every transaction is executed. But by introducing this gas concept, you just can't flood the network. If you want to execute huge pieces of code, it's going to be very expensive for you. And it's going to be finite always. You mentioned a moment ago that maybe an object-oriented language isn't the best choice in some ways for this. Other languages? I mean, this is all running on a VM, right? So could you have other languages that target this that are object-oriented? Somebody asked, could you have a mutable language that you use instead of something that's stateful? Well, Vitalik Buterin, which is the inventor of Ethereum, is proposing alternatives to solidity. And there's also this new company that I wanted to talk about that I couldn't, which is called Eternity, that addresses this problem of using object-oriented languages for very critical pieces of code. And they really, they're, they propose to write smart contracts in a functional, fully functional language. It's on its early stages, so I don't really know if they are going to succeed. But I think this is the good path to go. I think this is the safest. If you want to extensively test your code, it's better to do it in a functional fashion, which is more difficult probably to code. And it prevents you from storing state. I don't know. Yes, you have to see how it evolves. Yeah, you have to balance the in and out. Two final questions, both a bit more practical. One, how do you debug and test these contracts if we wanted to go out and make our own now? Just like Bitcoin, you have an offline blockchain that you can run on your own laptop. And then you have a test net that you can use to deploy your contracts and then let your testing team send transaction and see what happens. And the test net gets, I think it gets reset every now and then. And money doesn't mean anything down there, so you can open an account on the test net and get as much ether you want. I'm not sure what I say, but there are means to test it. But we know that testing depends on us, so we are not perfect. And then the final question and probably the most important one, should we all be going out and buying Ether? Should we all be going out and buying Bitcoins? What do you think about the ICOs? Let's explain what ICOs are. In Ethereum, it's trivial to create new cryptocurrencies. You can find on the Ethereum homepage, there's a documentation section and it's like 20 lines of codes that you can deploy and you have your own cryptocurrency. You just have to put a name on it and it's yours. And then you just have to convince other people that they have to buy it because it's great. So, ICOs is a practice that got massively adopted this year as a fundraising method from startups that work on the blockchain. And huge amounts of money have been raised because this company, they issue their own crypto token and this crypto token will be used later when the company will provide services. It will be used to pay the services. So, investors, they buy tokens. It's like a crowd sale. They buy tokens for later to use and they get the tokens, they trade them and they don't get shares of the company. The company gets all the money and you don't get to be a shareholder. You just have tokens. You're just a trader. So, I think it's very complex to express my opinion right now here. I promise that I'll write an article on this and I will tweet it. But the TLDR of this article right now, the only thing I can say is, it's up to you what you want to invest in these kind of things. Thank you very much, Léka.