 Alright, so welcome, on this lecture we're going to cover Uroboros proof of stake. We're going to start from the origins of the protocol and then take it to Uroboros Prouse, which we present this here, and then to the next evolution of the protocol, which is Uroboros Genesis. Let me start with the concept of a robust transaction ledger, which is the problem that Bitcoin protocol solves. So the formalization of the problem was itself like an interesting question, which was something that we tackled a few years ago already now. This was work that was with Juan Caray and Nicos Leonardo's. That was the first formal definition of the objective of a robust transaction ledger. Now this work, which you can find it here, basically set out a crisp model and an objective that a ledger protocol has to meet. And after that work, there was a number of other papers that took that model and improved it in a number of ways, and I'll just mention a few of them that came out of the years afterwards. Mainly the definitions were further refined. Partial synchrony was considered, and finally there was a composable definition that was presented just in the summer last year at crypto. So what does it take to realize the ledger? So realizing the ledger is something that, as you can expect, it can be achieved by Bitcoin. Bitcoin itself, the Bitcoin protocol, was the inspiration for defining this problem. Nevertheless, this solution also, I should say, came out, in retrospectively, somewhat unexpected. The problem itself was never considered in this setting. The problem of consensus or the problem of having a ledger of that type that Bitcoin solves. So you might actually, if you look at the theoretical results in the distributed systems literature, you might even consider that result as impossible given though that we knew that the barrier without using some type of public infrastructure was one third of the number of parties that might be malicious and Bitcoin was achieving that with a threshold that was going close to 50%. So despite this remarkable feature of the protocol to provide us consensus in this setting, there are significant scalability and energy efficiency disadvantages that the protocol has. So the clear question came to be, once we have this and we understand the problem that the protocol solves, is it possible to realize it in a more efficient way without fundamentally compromising any of the basic assumptions and the features of the objective that the protocol tries to solve? So proof of stake was an idea that early on by the Bitcoin community was considered as an alternative and in the Bitcoin forum were many discussions about how it might be feasible to use that in place of proof of work, which is in the case of Bitcoin. So a little bit of background about what is proof of stake. Now if you look at the way that the blockchain protocol works in Bitcoin, it's a little bit like an election. So what happens is that the next entity that is going to produce the block that is going to be added to the blockchain is elected and in some sense is elected with probability proportional to its hashing power. So basically the more hashing power you have, the more chances you have of being elected and produce the next block. Now collisions so to speak may occur, the system is decentralized, there is no coordination between the parties that are running the protocol and the protocol itself is designed to be able to absorb such collisions, to absorb such momentary, temporary disagreements between the parties. So all of that is fundamentally based on this concept of proof of work. So modifying this is what proof of stake is about. So using stake, which is a virtual resource instead of hashing power, which is a physical resource is at the core of the POS idea. So while in POW and proof of work, we're going to have the set of stakeholders being the miners in some sense, this will be substituted by those that have stake, which is reported in the ledger. Once we have this, then we have to come up with a randomized process that is capable of emulating basically the same election idea that naturally comes in the proof of work domain. So this idea proved to be very powerful and motivated a number of people to propose a lot of protocols for implementing the proof of stake concept. So there are two fundamental approaches here that you can consider proof of stake. The one is a proof of stake blockchain, where basically what you try to do is think in the same way that the Bitcoin blockchain works and use proof of stake in a way that does not jeopardize any of the features that the proof of work protocol provides. An example of these protocols is Uroboros, the protocol I'll be talking about today, Snow White Next and a number of others. The other approach is based on classical bidding for tolerant protocols, which can somehow be upgraded to operate in the POS setting. And an example of that is Algorand. So both approaches are POS, since what is important here is that participation in the protocol is based on your stake, as that stake is reported in the ledger. So POS didn't come without its controversy. There was an early folklore idea that was discussed among many people that were working in the Bitcoin space that POS blockchains are fundamentally impossible to work. And the main deficiencies or vulnerabilities that people were pointing at, where it can be pointed, can be summarized in these costless simulation vulnerability that the POS has intrinsically and the ability of attackers to mount what's called long range attacks. Let me just explain in a bit more detail what are those. So a costless simulation basically suggests that in the absence of proof of work, proof of stake, after all, is a proof of a virtual resource. There is nothing that prevents you from doing this over and over, perhaps in parallel multiple times. So a fundamental difference between a proof of work based blockchain and a POS based blockchain is the fact that in the proof of work case, all parties they have to commit to a certain protocol execution and advance that execution using their proof of work algorithm. That's not the case in POS. And it's not the case because it's really costless or nearly costless to execute the POS protocol. Thus, in principle, the adversary has really literally nothing at stake and is capable of advancing multiple different executions of the protocol so that it finds one that is the most favorable. And that could lead to what has been called like a long range attack. So basically in a long range attack you have a victim node that tries to distinguish between two alternative histories which are furnished by the network without having access to recent information. And recent information here is key. I mean, if you are constantly online, you have a good understanding about what is communicated in the network. Nevertheless, imagine that you join the network after a big hiatus or basically you're just a new node that doesn't have any other information about what was going on. And in that case, you face the bootstrapping problem. How are you able to synchronize with the right blockchain without having any recent information? So just to understand how this comes like in practice. So here is just a visual depiction of this bootstrapping from Genesis problem where you have the Genesis block, let's say, you have a new party. And the new party now tries to find what is the right history. He doesn't have any information about the protocol until at least the, for instance, you can even say the Genesis block. And now you have the honest parties which are providing this blockchain that you see at the top and then you have the adversary that is providing the blockchain at the bottom. So what we want is that the new party, presumably honest, would like to join the top version of the history. The only information the new party has is the Genesis block and he's faced with that decision. So how does this work in the proof of work world? So what happens in the proof of work world is that what you can prove is that the main chain, the chain that is maintained by the honest parties, is going to have the most blocks. Or to be more precise is gonna have an aggregate difficulty, which is higher than the alternative chain. So basically, the adversarial version will be substantially shorter, counting difficulty as length, and that will enable the party to just connect to the correct blockchain. So this is a very powerful idea and you see in some sense, realize intrinsically on the fact that this is a long blockchain represents aggregate proof of work and the resources of the honest parties are assumed to be in a strict majority. So basically, the majority of the housing power is with the parties that follow the protocol, while the adversary is in the minority of the housing power. Clearly, this argument would not work if things were otherwise, and there was an adversary that has the majority of housing power. So this setting suggests the following model for understanding how blocks and protocols operate, which we call dynamic availability. So dynamic availability is a setting where we analyze a blockchain protocol that suggests an environment that parties will join and live at will. There is a number of offline and online parties that dynamically change over time. They may lose clock synchronization. They may lose their network connection and there will be no a priori knowledge of the participation at any given time. So the blockchain setting is dynamic availability is what people would like these protocols to work on. So we have to see how proof of work compares to proof of stake with respect to dynamic availability. So let's see, compare for example, the Bitcoin protocol with a POS blockchain or a POS BFT protocol. Now, in terms of setup assumptions, there is a first difference. Bitcoin protocol uses a common random string, as it is frequently called in the cryptographic literature, or basically the Genesis block contains a random string, and that is common and shared by all the parties that run the protocol. On the other hand, in the case of a POS blockchain or a POS BFT protocol, what we assume as a starting point is a public directory. So in both cases, this is a shared assumption and the difference lies on the fact that the common random string is basically can just be a string in the sky, something that is random and predictable till the moment it appears and everybody agrees on that. Whereas a public directory basically it is what it is. It's basically a set of keys that have been accumulated and they provide the root of trust of the system. So this is a fundamental difference between POW and POS and this is something that is going to remain. So this is like something that typifies, let's say, the proof-of-work concept and the POS concept. Nevertheless, in both cases this is a setup assumption and as long as we are capable of somehow ensuring that this setup assumption is there, then the whole protocol is going to be hopefully safe after that. Long-range attacks, though. How do they deal with long-range attacks? So in the case of Bitcoin and the proof-of-work-based blockchain, the longest-chain rule is sufficient for the same reason I told you. So basically a party that is bootstrapping from Genesis and potentially faces a long-range attack will just follow the blockchain that has the biggest number of blocks or the highest difficulty and it can be shown that it connects to the right blockchain. Unfortunately, what happens in the POS domain things are not as simple. So there are a number of assumptions that people have used to deal with long-range attacks and you will see that many of them are not quite satisfactory. Mostly is that the longest-chain rule, for example, that is used in POS blockchain, is not sufficient and what is frequently assumed by these papers, essentially all POS papers in one way or another, is what we can call a local moving checkpoint. So essentially the parties are assumed to not diverge to any alternative blockchain compared to the history they have. So they have basically a recent block that they trust and they just remain that. Perhaps that's a block that has naturally evolved because they are online all the time or it's a block that they heard from another node. In a sense, that requirement means that if you are not online all the time you will have no way of having such recent information at the local checkpoint and thus someone will have to provide you that. And that would be basically an assumption that when you're initialized in such a POS blockchain you will have to get some trusted information. Now this is fundamentally different from the POW setting, at least in all these previous protocols. Another requirement is to have key evolving signatures which is something that doesn't exist in POW but it is something that we know cryptographically how to design. If we look at the same question at the POS BFT case we also want key evolving signatures but now a different requirement comes up. What happens in the BFT case is essentially that the nodes that are running the protocol agree on all blocks. That means that you do not have forks because every time that you produce a block there is sufficient agreement about that so you do not have to resolve such type of collisions or disagreements that we were having to deal with in the blockchain setting. Nevertheless, in order to run such protocols you will have to have a good understanding of what is the level of participation. So this points to these deficiencies that you see are described in this slide. So while dynamic availability is feasible in the POW setting using only the Genesis block in the POS blockchain setting rejoining parties would need a somewhat recent block whereas in the POS BFT setting parties will need to know participation level at all times in history. And these are both strong requirements that hurt this general setting of dynamic availability that a POW proof of work based blockchain like Bitcoin works. So in summary, POS blockchain so far they need to have additional advice to do this bootstrapping from Genesis information the longest chain rule in itself is insufficient while POS BFT, the level of actual participation needs to be known throughout. So and the reason as I mentioned is that these BFT protocols they have to rely on these counting decisions that need accurate estimates of participation. So all this is the motivation for the new version of the Uroboros protocols that we call Uroboros Genesis. So the new version of the protocol is exactly dealing with this problem of dynamic availability and the intention is to see whether it is feasible to produce a POS blockchain that is capable of natively working in the same setting as Bitcoin. So the Uroboros Genesis protocol is a new milestone in the line of Uroboros POS based blockchains the protocol is based on Uroboros PROS that will be presented in Eurocrypt 2018 and the Uroboros protocol which was presented in 2017 at crypto. The main novel feature is that we design a new chain selection rule that enables parties to bootstrap from Genesis. So let's take a step back and see how the Uroboros protocol works. So the protocol was designed together with a formal proof that realized the functionality of robust transaction ledger and that's one of the fundamental distinctions that was put in place in the design of the protocol. So we designed the protocol together with a proof that the protocol is capable of realizing a distributed ledger. The proof strategy involves properties of the underlying blockchain data structure and these are properties that are shared with the Bitcoin proof of work analysis. Common prefix, chain quality and chain growth these are the fundamental properties that previous work has identified as the important building blocks for arguing security for blockchain protocols. The analysis pairs the honest parties against an adversary that controls a malicious coalition of parties that is in the minority in terms of stake and furthermore the adversary has complete network dominance in the sense that it's capable of delaying messages and acting after all the honest parties. One of the things that is done for the network is that messages are eventually delivered. So there is an upper bound in the delay of the network which is not known to the participants that within which parties will actually receive messages so it's not possible to stifle information from being propagated in the network. So the design of Uroboros protocols was this structured stage approach that comes as follows. First, the protocol is an initial analysis is performed in a setting where state is static so it's basically like we freeze the stake of everyone and we see how the protocol works. Then we use randomness, a randomness source which you can think otherwise unspecified like a randomness beacon that at regular intervals emits a unpredictable value and we show how we can basically bootstrap the protocol the stage one protocol that is static stake to a setting where stake is allowed to move and evolve over time. And then finally at stage three we show how it's possible to remove the assumption of the beacon and using cryptography or some type of cryptographic implementation show how the protocol itself can emulate the beacon. So here's an example of the static stake segment or how it might advance. So what you see here is a sequence of blocks that are produced in time starting from the leftmost side where we have a genesis block let's say that's B0 that you see on the left side of this of the screen and then moving on the time moves forward to the right. What happens is that every moment in time every heartbeat of the protocol there is a certain party that is identified and is capable of producing one of the blocks. So that assumption is happening for most of the moments in the protocol but there will be also moments by design that will also be silent. For example, this is what you see in the fourth in the fourth time moment in that sequence in that time window here. What happens when you are elected to produce a block then you issue a block using essentially just a digital signature and that is distributed to the other parties that are running the protocol. Now that block is connected to the previous block that an entity knows. If there are points in time which in the protocol model we call them slots so if there are slots where nobody is elected then this by definition is going to be a silent slot but there might be also slots where multiple parties are elected at the same time. The election process itself is based on a randomized process which initially it is seeded by the Genesis block. So this is how the first segment of the protocol let's say advance and if you also want to think about it this is the first few moments of protocol execution. Conflicts are bound to occur and the protocol uses a simple longest chain rule to choose what is the correct history. So once we have this in place here is how the evolving stage of the protocol will take place which uses a randomness beacon that regularly emits unpredictable values. So what you have is a sequence of blocks that are produced in the static setting where basically state is assumed to be frozen and then what happens is that the beacon value is emerged and in some sense refreshes the randomness that will produce the next segment. Now what happens is that during that time the stake that is assumed to provide the safety of the protocol is assumed to be frozen but the real stake is not assumed to be frozen and it's possible to flow arbitrarily between the participants. What we do is that when we are about to go to the onset of the next stage of the protocol which in our technology is called an epoch the protocol looks at the stake as it has evolved in the first epoch and then creates the stake that will provide the safety of the second epoch and this is what happens and now you go into that recursively in an indefinite cycle. There is another basically state called a distribution that has evolved from the first epoch guaranteeing the safety of the second epoch and the protocol advances in this fashion. When we are ready for the next epoch again we look at the ledger, collect the stakeholders produce the next randomness value and so forth. Finally, in some cryptographic fashion we need to show how the beacon itself can be implemented. So let's take a dive a bit deeper and see how the security analysis works. If you look at the protocol execution as I described it you can think of a string that we call a characteristic string. Every heartbeat, every moment in time can be assigned one of three values. Zero means if the parties that follow the protocol own that slot. One is when the adversarial coalition controls that slot and the next signed bottom means that nobody controls that slot. So this is a type of a random sequence that is produced based on this election process that the protocol is utilizing. So let's see how a possible protocol execution can go. What happens is that little graphs like the one that I'm presenting here and we call them forks naturally emerge from such characteristic strings. So let's examine how this comes to be. So here on the left we have the genesis block and that's in a sense the root of this tree-like graph. What happened at time one? There was an honest party that produced block one. Now observe that the next is silent and now let's examine what happens when the next honest party is activated which is at slot number five. So the adversary served block three to that honest party and thus the honest party at slot five abandoned the block that was produced by party one and adopted and extended a different one. That happens because the adversary enjoying network dominance and delivering blocks in advance is capable of delivering its own blockchain which extends from slot three, the genesis block, to the party at slot five. Let's see what happened at seven. Here is another honest party at seven that is served by the adversary block number six. That block number six extends one and thus the chain extended by party five is abandoned. Party eight, observe here what happens. Here is a situation where you have honest parties at five and seven but party eight chooses to extend the block one. What happened here is that the adversary could exploit network delay and have party eight receive the block produced by party one without seeing the blocks produced by parties five and seven. So here is a situation where network delay puts the adversary at an advantage. Finally, as the adversary moves on we have an extension of the block from party eight by an adversarial party at position 12 and finally adversary serves block 12 to the honest party that extends it at slot 14. What happens now in this picture is the following. We've managed to take a protocol execution and substitute it with this tree-like graph. This tree-like graph emerges naturally from the randomized process that produces the characteristic string. The nice feature of this is that we can study now the properties of these discrete structures in order to understand the security of the protocol. How can we show eventually that the protocol converges to a single history? Because this is what is the fundamental question. So drawing from Bitcoin analysis what happens is that random walks play a fundamental role. A one-dimensional random walk actually is what you can find at the core of the security analysis of Bitcoin. So this random walk you can think of it as follows. Imagine that there are the bad guys and the good guys. Every time that the bad guys find a proof of work you can imagine that there is this random walk advancing upwards. Let's say they're equal at the beginning starting for instance from the Genesis block and then the parties that follow the adversary the adversarial coalition will advance this proof of work upwards with a certain probability which is how much they can find the proof of work. At the same time the good guys will pull the random walk downwards whenever hopefully they produce a block. It turns out that this is not quite the case. What happens is that indeed there is a pool of this random walk downwards every time almost every time the honest parties find a proof of work. The reason that this probability is gamma and not equal to alpha which the probability that honest parties found the proof of work is the fact that honest parties pay the price of being decentralized. And here this paying the price of being decentralized you can see by the fact that gamma is approximately alpha minus alpha square is the probability of two or more honest parties colliding around the same time and producing a block together. So we cannot use these moments if you want. Still, if we make the assumption and that's the fundamental assumption that is done in papers that analyze the security of Bitcoin is that if gamma is strictly bigger than beta this random walk is going to get a strong pool downwards and the honest parties will win. So here is an inspiration from the analysis of Bitcoin. So now the question is can we apply this logic to the POS setting? Unfortunately, winning a block for the honest parties does not necessarily constitute a move to the left in the random walk and the main reason actually is what we cited at the beginning, costless simulation. So the adversary may reuse an opportunity to issue a block in multiple paths of the fork exactly because this costs him nothing. So you can have bad situations like the one demonstrated in this graph below and that's like a pathological execution of the protocol where basically see what happens. The adversary just owns three out of the total eight blocks which are shown here and still is capable in producing a situation that completely forks the blockchain despite the fact that he is in the minority in terms of ownership of slots. What happens is the reason of costless simulation slot three and four can be used in two separate blockchains without the adversary actually having to pay twice for that and that's the fundamental issue of how costless simulation comes here and spoils the analysis or if you want the proof logic that was used in the case of Bitcoin. Nevertheless, what we've shown is that it's possible to overcome that. But we need a more complex analysis. The complex analysis that we did in the Ouroboros lines of papers uses the following features and studies these graph structures that represent the protocol execution. There are three important quantities that are relevant when you study a protocol execution like this one. Every path that you see in the execution will have these quantities measured. The first one we call it gap. The gap is we look at a certain path in the execution and we say how far it is from the leading one. That's the gap concept. The reserve concept on the other hand says if we look at a certain path how many slots are still at the full control of the adversary and the adversary might use them to advance that path forward. In that particular case for the top path you see there is three slots. And finally, if you see you subtract gap from reserve to say what is the reach of that specific path. So that path here has reach minus one which represents the fact that it's a bit too short by one to win over the leading path. So if we are in such a situation and you are an honest node that follows longest chain rule you will not be able to fool by the adversary and adopt the top branch. You will follow using longest chain rule the branch that was extended by player at slot nine. A similar situation happens with the lowest branch. And then at the end if we look at the whole execution we look at two concepts. The first one we call it reach which is the maximum reach across all times and the other we call it margin which basically says what is the second best disjoint reach? What we would like is that the margin is always below zero. That would be a setting like in this particular one that the adversary will not be able to fool an honest party that tries to connect in this protocol execution and any honest party that connects in that particular execution is going to go and extend the block that was produced by the party at slot nine. So reach and margin are the two fundamental quantities that are interesting when we analyze these protocol executions and we can show that the adversary will win if and only if the margin which is the second best disjoint reach of a certain protocol execution is at least zero. What is interesting now is that these two quantities together define a random walk which is even though more complex than the random walk we analyzed in the case of Bitcoin it still has some good features that we can exploit to prove security. So here's how the random walk is defined. So it's a two-dimensional random walk and what happens is the following reach and margin when the adversary wins a slot they advance forward so basically both of the quantities they go plus one. So that's like the standard one-dimensional behavior the adversary wins a slot or wins a block then things are towards its favor. On the other hand when the adversary loses a slot things are more nuanced. The one-dimensional behavior would suggest that would just go minus one so what you see in the third branch here of this equation but that's not what happens in fact reach and margin decrements only in one of the possible cases but what happens is that first of all reach will never drop below zero and that's by definition but what happens very interestingly from the adversarial point of view is that the adversary can prevent the margin from going negative by sacrificing reach. So essentially what happens is that the adversary can make margin stick to zero by using the quota if you want that he has accumulated in terms of reach. This completely describes the random walk and here is a picture of it. So what you see in this picture is how now the probabilistic process that the characteristics thing suggests in the protocol will induce a random walk in this reach and margin quantities. What happens is that the adversary wins when you go when he gets a slot and when the adversary wins you see a move of the random walk towards the upper right of this diagram that's the beta moves that you see here and now you see what happens with the gamma moves. The gamma moves is when basically the honest part is win a slot and this gamma is a similar parameter to the one we've seen in the Bitcoin analysis. Now when you are in the upper right and you get a gamma transition what happens is that initially you can follow the same one-dimensional behavior. So beta goes upwards to the right and gamma pulls leftmost to the bottom. Nevertheless, when we have the situation that margin hits zero it's possible for the adversary to prevent the margin from going zero and as we saw in the previous slide sacrifice reach to maintain the margin to being on zero. So somehow the adversary has a little pull to prevent this random walk from escaping to minus infinity as it happened before. But nevertheless what we have still be able to show is that despite the fact that this random walk is more complex than the one that happens in Bitcoin we can still prove that the random walk will escape to minus infinity in the case of margin and that means that the longest saying rule is going to enable the parties to converge to the same protocol history. So this gives you the picture of what was happening before Uroboros Genesis was suggested. The new chain selection rule takes this idea of longest chain and deals with long range attacks. So all the analysis which we've seen so far essentially deals with short range concerns. And up to this case this analysis completely covers us. Nevertheless, for long range comparisons where chains diverge let's say from more than K blocks where K is the security parameters we have to use a different rule to select the right chain. And here is the novel chain selection rule which I will explain to you with this diagram that we have designed for Uroboros Genesis. So when you have going back to this bootstrapping from Genesis question which is the fundamental question that a node that joins the network would like to resolve you're dealing with the choice as you see on the right you have two chains that you have to deal and they are forking at a certain point. Now if this fork is kind of recent that's like a short range attack if you want or a disagreement between nodes that was just produced naturally because of network conditions then the longest chain rule will apply. On the other hand, if the fork is bigger than K blocks the following plenitude type of rule is used. We go to the moment where the chains diverge and then shortly thereafter we isolate a certain region of blocks and we see in this region which is defined in the time domain which of the two chains is more dense and that's the plenitude rule. The party is going to follow the chain that is denser in the time domain despite the fact that that chain might have a multitude number of blocks later on. So this is how the plenitude rule works. So what is interesting about this is that this rule is still quite simple to implement. It's still a quite simple rule and enhances the longest chain rule in a way that is still quite easy to program. So what's the intuition? The intuition and what we prove in the protocol is that if the majority of parties follow the protocol then at any sufficiently long time segment the corresponding chain of the honest parties will be denser especially after a fork. So adversarial blockchains will be shortly after the divergence point will exhibit a less dense block distribution and we can use that rule to determine what is the right blockchain to connect to. So going back and remembering the picture I showed you before about what was happening before POW and POS what Uroboros Genesis does changes the way that a POS protocol can operate in a dynamic availability environment and does a way with the requirement that you need to know a recent block in order to connect to the right history of the protocol. So here is the biggest advance that the Uroboros Genesis protocol offers and for the first time we can say now that POS blockchains can operate in the same dynamic availability setting that we know the Bitcoin proof of work base blockchain to operate. So this was a very quick overview of Uroboros Genesis there is more to come in Uroboros Research and I'll just mention very quickly some of the research streams that you'll be hearing soon and following up the work that we're doing now importantly the incentive structure and delegation and stake pools of the protocol is a work that we'll be releasing soon sidechain software updates and ecosystem sustainability is another important research direction that is also coming up smart contacts and domain specific languages for these POS blockchains a permissioned version of the Uroboros blockchain is also underway and finally looking at how POS blockchains can be scalable in the most general term of more general term of scalable sense is something that is also on our plate so with this thank you for your attention and I look forward to telling you more about our research in a coming video