 Hello. Well, thanks for coming. This talk will be about consensus. As you can just see, reaching the consensus can be quite hard and even if you reach the consensus, you still don't win because some malicious guys like me can break the agreement right after you reach it. So reaching the consensus can be quite hard. Do you agree? So yes or no? Well, it's, as you can see, it's very hard to reach any consensus because most of you don't answer at all. So, okay. This will be mostly about distributed ledger systems and consensus in these systems and we'll try to show you that the consensus algorithms are really critical part of any such system and try to give you a brief overview of a couple of consensus algorithms and as you probably can guess, as time is quite limited and the problem is a little bit hard, it will be a really very brief overview of these algorithms. But we will try our best to explain you some differences between these algorithms and give you at least some basic understanding which algorithms is better to use with one kind of distributed ledger system and which is better to use with some other distributed ledger system type. But let's start from very trivial things. Right. So at the first step, I would like to introduce you to the issue why we need the consensus. This is quite like simple example of transferring money from one person to another person. There is the Alice who is giving a note of $10 to Bob. If Bob received that, 10 pounds, $10, then he hand over the coffee to the Alice. If we move to a central system where we have some central authority like a bank, then the system has some centralized ledger, some one source of truth where the system can verify that the transfer is valid. So if Alice sends $10 to Bob and it's written to the ledger and Bob can hand over the coffee to her. If Alice wants to send $10 to Carol, then the system is quite easily can verify now that Alice does not have enough money on the account. When we move to the era or to the world of the distributed system that this problem start to be quite more difficult as there is multiple verifiers or multiple accountants in the system. And if Alice is capable to inform two sides of the system about sending the money to different persons, each of the accountant has its own ledger while it's sending this information or gossipping this information to all other parties. And at the time, this part of the system can have different knowledge of the account balance than this part of the system. So that could happen that Alice, in fact, spends just $10 for two coffees. And this is why we need to somehow manage the consensus. And as now Weta tell you that what is exactly, what is the detail? Okay. What is consensus, I guess, it's pretty clear. It's basically what you expect. It's some agreement, for example, on some value or that you agree to commit to do something. And so basically that's it. You are, most of you are, I guess, programmers. So I guess you use some kind of agreement on a daily basis, at least if you work with some database which use transactions. And if you use distributed transactions, you use even distributed consensus. So, but let me explain why it's hard to achieve the consensus. It's because besides of possible concurrent request, it's because of the network. As you know, the network is not reliable. So packets can be delayed or even get lost. So or they can be some glitches on the network, split of the network, and many, many other possible things. So basically you never know if the note of the network didn't send a reply or is completely off, or if it sends a reply, it's a reply is. And proper consensus algorithms has to have at least two properties, safety and liveness. Safety means that there are no two, no 40 nodes in a network which agree on different values. So basically that really all nodes agree on the same value. And liveness means that each node gets all the transactions and all the values which was agreed on. So basically that algorithm doesn't get stuck somewhere and it's then they're all removed some part of the network and don't communicate with it and so on. So I hope it's somehow clear. And I have already gave you an example about the database transactions. But we are speaking about distributed ledgers. So let's move to some examples from distributed ledger systems. I hope all of you knows Bitcoin, right? So how do Bitcoin reach consensus? Do you know? So what is the mechanism, how Bitcoin network reach consensus on something? Come. Pardon? Yeah, do you know how it's called? Proof of work. Yeah. So this is actually not the right answer. Almost, right, but not completely precise. This is street from one professor at Cornell University who says that it's terribly wrong. I wouldn't agree completely with that. It's not terribly wrong, but it's not precise. He explained in a couple of follow up tweets why this is not a completely precise answer to say that proof of work or proof of stake is consensus algorithm. But as we are not on a Twitter, we fortunately can go more slowly and explain a little bit more. So let's start from where most easy things and don't worry after a couple of minutes we return back to the Bitcoin and proof of work and we'll explain why it's not completely precise to say that proof of work is mechanism of high Bitcoin reaches the consensus. So we'll start with the kind of standard consensus that is used in distributed systems where we have, that's kind of the distributed databases which is used normally like ETCD for Kubernetes or similar. Those systems are prepared for two kinds of the failures which is crash or connection error when the messages could be delayed, the notes could crash and still the system is able to reach the consensus and proceed with the operations. But there is not prepared for malicious users which are coming and saying like incorrect Bronx which is not, it's not following the protocol itself. The examples of such protocols are the kind of the Paxos or are the most known ones and we can like differentiate them to base groups which is leader based where the systems Alex the leader which is the one note which receives all the communication from the outer words could be handling some, by some, by information of that client can receive to redirect its request or could be just some load balancing and the second one is the leader less where any note in the consensus network can reach the request from the client and proceed with the saving this information and needs to inform about received information to add notes in the network, inform the consensus. Here just for like to overview what such algorithms about I, there is the like two slides about the rough that really just the brief overview. There is like four nodes, there is always defined some leader which receives all the, all the, all the connections from the, all the request from the client. Then there are some nodes which receives the information from the, from the leader and the leader is, has to inform the participant, the other nodes by heartbeat, heartbeat tickets where the participant does have some timeout and when that timeout elapsed and they do not receive the heartbeat packet then they start to the election of the new leader. The system has to have some leader. Here is just the, the shown the leader election phase where two participants tries to be in leader and informs about this. Then as the next step of the rough is this phase where the leader informs about the information coming from the client and saving this information to, to the log. The each node has its own log and but those logs has to be in, in sync, synchronous. It has to be in sync and the, the state at the all, on all nodes has to be the same. So the, the, the, the leader sends this information to, to the participants, to other nodes and they agreed on that, agreed that they receive the information and then that information is committed to the log and the system can go forward. This is the, this is, these algorithms are used in private blockchains which is like blockchains which are normally inside some of the, in the, in the, in the elite of some single operation, single organization where all nodes trust each other and they are, there, there is no malicious like user, the, the, the, the hyper, hyper ledger in, in sort of uses, for example, or after one of the possible consensus algorithm. From this, there is connected two terms which are mentioned here. It's permissioned and permissioned less. This permissioned, permissioned blockchains or hyper ledger, networks are, are, are networks where nodes are, needs to be permitted to join while, while the permission less are mostly public networks where nodes can join to that consensus protocol and they will and nobody control them. Right. Okay. So let's make things a little bit harder. So besides a possible failure on the network, there can be some malicious or misbehaving nodes. This is called Byzantine failure. I already showed you, if you remember at the very beginning when we are trying to reach the agreement who will start the talk, we agreed that under will start and right after out of sudden, I started myself. So I behave like Byzantine fail. It was kind of Byzantine failure because I break the rules and started to behave completely arbitrary and started the talk. So in general Byzantine failure is any, is any, any arbitrary behavior. So you don't have to expect from the node anything. It can behave completely arbitrary. In most of the cases, it's usually considered that the node is malicious and trying to somehow cheat or break the rules and things like that. And probably most of the example is what Ondra already explained to you is double spend problem when one node send to some, one reply to one part of the network and completely opposite reply to other part of the network and try to persuade both sides of the network that this answer and the other part of the network about opposite answer. So how to solve it? It was solved quite long time ago with Byzantine Paxos algorithm and also probably the best known is practical Byzantine Fortorn algorithm by Barbaralisco and it's sketched here. The PBFT algorithm, there is a leader or proposal which propose a value, send it to all nodes, all nodes send replies to all other nodes if they agree and if they get, or if they are prepared to commit this value and if they get a sufficient amount of positive responses, they move to other part, other phase and try to commit the value and again if it receives sufficient amount of positive replies, the value is committed. So it has three phase, prepare, prepare and ensures the ordering of the transactions during one round and prepare and commit phase and ensures proper ordering of the transaction between the views. Views are the states where one node for example can join the network or crash and so on when there are some failures and the topology of network changes. So these three phase together ensures proper order of transactions even if there are failures on the network or misbehaving nodes and if you still want to somehow imagine from probably what you hopefully know, you can imagine as three phase commit, it's quite similar. What is the disadvantage is this, as you can see, a really huge communication over the network. So this PBFT algorithm can be used and it's actually used for example in some hyperledger project, but it's used for either private distributed ledger systems or federated. I will get to federated, maybe I can right now, federated distributed ledger systems. The federated distributed ledger system is that it, here is the centralized example where is just for example one node which decides but federated means that there are a couple of groups which for example vote leader or some node and this node speaks or represents the whole group. In most common cases, these federated distributed ledgers are still to some extent centralized because these nodes are more forms kind of centers and quite often there are also permission because typical case is that anyone can join this but this communication in yellow is somehow protected and in some dedicated for example network. You can imagine like that couple of banks want to create a distributed ledger system so each bank would provide one node for example here and they will trying to reach agreement between the banks so you don't have complete control over the network so you want to be prepared for some arbitrary Byzantine failures but you still can to some extent trust the other nodes inside this network. So I mentioned here also two more algorithms, it's called PTFT. Tendermint is some kind of improvement of PTFT. It replaces the communication here over the network by GOSEP protocol so it reduces the communication a little bit and also improves the PTFT algorithms by introducing some different methods to make it more easy to finish the agreement. I don't think there is some big idea which I can share here behind it so maybe if you want details you can read the paper but it's quite similar to PTFT, just improve it so that Tendermint can be used in early years and it's not limited to some small network and the STALAR protocol I mentioned here because it's exactly what is shown here, it does some federated voting that a couple of nodes elect node who represent them and this node again can elect other node which represents some even bigger group and so on. So this is like parliament democracy, you can imagine it and again this scales quite well and can be used in early huge networks. So that's it and let's move, let's add something a little bit even more difficult. So before moving again to the Bitcoin, there is an example of other threat that the distributed systems need to somehow handle which is named as Sible attack and based on the fact that as you could understand from the previous size all the presented algorithms up to this time have the each node in the system has one vote, one vote and all of them have the same permission for voting. If there will be some malicious user who would be able to spin up multiple nodes it can overhand the network with its own voting rules and in these times of AWS when you can have hundreds of nodes just by one click it's quite possible. So the system needs to somehow handle this threat. This example is for example Alice who just overhand the network and consensus and get just by the majority of the voting. So this is the threat and some basics about the distributed systems and when we come to the Bitcoin again then I would like to show you how Bitcoin handles all of those. Just to be at the same page I will try to briefly go through what's about the Bitcoin consensus or how that particular part works and this is really not the precise thing just for me being able to show you the idea. So the proof of work is some mechanism which works on blockchain which is the data structure where the each block is linked to the previous one by referring it's hash. Hash is the signature of the block. It's calculated from the header and because of this signature it's hard to calculate or hard to change then you can say that the blockchain is immutable because it's defined and how it is with those linking blocks with each other. The block to the block chain is added by process name mining where miner starts with SH 256 hash functions, calculate over the data of the header and he tries to find out such hash that would be following some rules of the network which is for example having five zeros at the start of the hash and then if such hash is found then the such block is valid for being added as the next stop of the blockchain. How the miner can achieve that is to changing the field, let's say normally it's field nouns which is just arbitrarily randomly changing it and trying to with this change calculating the hash from the header and find such hash that would be starting the five zeros. As we are in the distributed world then there are multiple miners and could easily happen that two of them find out the same hash that would be valid for the next block to be added to the blockchain and at the time we say that there is the fork at the blockchain because there is two possibilities where the blockchain can continue. So now we are coming to what Bitcoin uses to manage this which is Nakamoto consensus which is combination of this proof of work which manages the way of adding the blocks to the blockchain with the static rule which is very sad that only the longest chain is valid. So if I get back here in this case there is just like waiting which of this branch will be prolonged at first and that one will be submitted as defined as the valid continuation for the blockchain. So as we define Bitcoin is Byzantine fault tolerance in a way that is pretty hard for malicious user to change anything because needs to have quite a big hash power computing power to change the blocks or to change the blockchain as well as resistance of symbol attack because it's needed not just to have multiple nodes but it needs to have hash power for changes of the blockchain and at that state it needs to have quite like a lot of money to buy some computers to be able with such power to change the blockchain. It said that this consensus as well probabilistic because you never know when if there is some hidden chain which was not known to your part of the network and there is just big probability while adding one next block to another that there won't be any such hidden network because again there would need to be quite a lot of powerful computer machinery behind building such hidden network so there is just increasing probability that blockchain which is now known to the network is really the right one. The Bitcoin uses one more thing or point for the consensus it's defining the time how long the network should how long the network should need for generating next block it's defined it should be 10 minutes and depending on the number of participants in the network this the difficulty of riddle let's say this the rule of the network of five leading zeros at the hash is changing for six or could be reduced. The reason why there is this 10 minutes is that Bitcoin needs to be is different to be synchronized because for not having 10 minutes I need to be faster. There needs to be 10 minutes is enough time for all information about the found block to be produced over the whole network and if there will be last minute there will be a lot of folks and the consensus would not reach to the state time. Now I move to proof of stake which is kind of the improvement for proof of work where when you run the proof of work you need some machinery to reach the consensus of proof of takes tries to put it this need to inside of the network like that you are not buying the computers but you are providing the stake which is a currency inside of the network and you have votes for being able to participate in consensus you need to deposit the currency in the system and based on the size of the currency you have voted based on that. This is the way how to manage this again the civil attack because for reaching the consensus you need to stake your currency and you are again you are not fine with just adding some arbitrary notes you need to provide some real currency for being able to vote. Still there is it's not the consensus because there is still a rule that the longest chain of the blockchain wins. Just briefly there is two ways or two different states like chain base where there is the proof of stake which so the randomly choose the node where we will put the next block to the blockchain based on the weighted size of the deposit and PBF style when the voters just promotes the next block and the next round goes through the PBF style algorithm. It's not exactly consensus algorithm but it's further beyond the blockchain. Yes thanks. So as Ondra said the blockchain is basically synchronous and it's more or less something like linked list and obvious disadvantage is that it's slow and the throughput is quite low. As you may notice we try to use not a blockchain which people in many cases use interchangeably with distributed ledger system but we try to use the name distributed ledger system and it's because of that the blockchain is just one possible data structure used for the distributed ledger. Another one which seems to be pretty good and useful is and quite popular in let's say last year or maybe two is direct acyclic graph. As you can see here it's basically graph where the edges are oriented and there are no cycles in that graph. There are obviously things like not common consensus can't work on the top of such structure because nodes won't be able to choose which is the longest chain because the forking and adding transactions happens so quickly that it would be absurd because they will compute any useful hash so we need other consensus algorithms against quite some of them like hashgraph, Avalanche, Tangle and probably a couple of more. I will briefly speak about two of them hashgraph and Avalanche and I will just mention the main idea behind given algorithm. So the hashgraph is based on two main ideas. It's gossip about gossip and to watch voting. Gossip about gossip is following things. The protocol used gossip protocol to spread information really fast but besides the vote or transactions it includes here not only it but also all it's known state from previous conversations. So for example this node knows that this node vote for this value and when he sent message to this node he includes it into this message. So the node, so this is what the authors call gossip about gossip and virtual voting is that if you remember PBFT algorithm there was a lot of huge communication because each node has to communicate with each other to know how they vote so this is not needed in this case because the information for example how this node voted is included here so this node knows the vote of this one without talking directly to each other. So besides the information is spread really fast over the network it can be really effectively reduced. In reality of course the algorithm is a little bit more complicated but this is let's say the main idea and if you are interested in all the details you can read the paper here. Ovalunch is kind of similar it's again based of gossip protocol and it used the property of this network which is called Metastability it basically says or it's means that the probability that the network would split exactly into halves when one half of the network will vote for yes and the other part of the network will vote for no is extremely low so in a couple of rounds the whole network very quickly converge to yes or no answer and it's done in this way that the node each node send gossip message to couple of randomly selected nodes and ask them how they vote and when they reply they vote according to the majority so in this case the node gets two answers voting for blue and three answers voting for red so this one will vote for red and every node does this and it can be proven that the whole network very quickly converge to some result so again in reality it's a little bit more complicated but this is main idea standing behind this protocol or actually it's a whole family of protocols as you can read in the paper but for probability we will just speak about this one so that's it and now comes practical exercise for you to try how to reach the consensus in reality so we will adjust it we adjusted algorithms suitable for this in literature it's usually called Halopka-Iranic almost consensus algorithm with usually positive social side effects the name is a little bit long but don't worry the algorithm itself is really trivial and it's as follows you should go to this web page scroll down to feedback form and click on this icon remember this icon when we finished or during the rest of the conference you should grab five randomly selected people in the corridors introduce yourself to the man or lady start chatting with them explain them what you remember from this talk what the algorithm is sorry what the consensus is explain them this algorithm and ask them to do all these four points and then continue chatting and this is the positive social side effect that you will learn new people and probably have some good conversation with them and if most of the conference attendees are not Byzantine the actual result should be that we will win the best talk competition so remember this is a homework for you so hopefully it's clear and hopefully we will win to finish with just more seriously and to have some quick summary what we were talking about that is like what was this talk that there is consensus we can differentiate to Byzantine falter and consensus algorithm and non Byzantine falter and algorithms non Byzantine ones is using private networks where the nodes trust each other and it's the that could be rough or paxos then we have Byzantine falter and algorithms which are using permissioned networks which is where node needs to have privilege to join for example Tenderman which is based on practical Byzantine falter and algorithms but with enhancements under this we would federate it federated ones where there is the democratic elections of some nodes which has rights to vote for in the consensus in public networks we have structure where the consensus runs at it's either blockchain where we can say there put the proof of work or proof of stake with some rule how to say which blockchain is valid and the new upcoming direct acyclic graph data structures and at the top of them there are again the family of consensus algorithms and we presented here hashgraph and avalanche just quickly say that for those some of them here like needs again some proof of stake mechanism to manage the civil attack that's they are normally not not resistant for it just as they are that was the fourth summary and last one I understand something at all don't worry we don't understand it either but there are a couple of things I like you should take off from this talk so first one is that the consensus algorithm is really a crucial part of any distributed leisure systems and the choice of such algorithm can impact almost every aspect of the network like performance and security and it's quite rich field there is not only proof of work and proof of stake which are not consensus algorithms but it's quite a rich field there are quite a lot of algorithms and also there are many or several types of possible distributed leisure systems and not every algorithm is suitable for every type of distributed leisure so you have to have at least basic understanding now what are the differences and what is more suitable for what kind of distributed leisure system and one of obvious recommendation if you want to do some programming on some distributed leisure system please take time read the documentation of this network and get familiar with consensus of such network and be sure at least to some extent understand how it's reached so questions, no one so one or could you repeat what was the question what are the concepts so the question is how the network is formed and basically it depends on the type of the distributed leisure as we showed it can be a permission so basically you just have everything under control and it depends on the cable you connect to which machine and federated network you have for example some node where you can connect and this node are the rest of the network is trusted and there are public network which are peer to peer and anyone can join so it depends on the type of distributed leisure does it answer your question it seems to me that these sites for you that don't have to be if you use gossip protocol you at least have to get some information for about other nodes and then you ask more nodes so you can somehow cheat that the first node send you some wrong list of participant and let's say send you his subnet which he controls but I think as the gossip protocol spreads you can easily escape from that anything else so if not here are a couple of links to the papers which we mentioned here so if you want to know any details just follow the links or google or the appropriate paper thank you for coming in the morning and thanks for your attention