 I'll tell you about Roboros, a probably secure proof of stake protocol, and this is joint work with Alex Raster, Bernardo David, and Roman Orlin-Nukov. So you heard in this session a lot about the ledger objective. So the goal is to construct this protocol that realizes this robust transaction ledger. And as you've learned, this was the objective of a paper by Juan Caray, myself, and Leonardo Sintiqiel, where you formalize this definition as an objective, and this gave some follow-up work, which we find the model and definition, some of which we also heard in this session, which now we can say we have finally a simulation-based definition, which is composable. Now once you have an objective, which is cleanly defined as SAT, now you can ask do we know the best way to realize it? So trying to answer that question is the topic of this final talk. So we know that the ledger can be realized by Bitcoin based on all these wonderful previous works which are cited. But we also know from the way the protocol actually works in the real world that it accepts significant scalability and energy efficiency disadvantages. So can't we realize any more efficient way? So it is at this point that an idea that is called proof of stake was circulated in the Bitcoin community as early on as 2011 as a possible way of designing a more efficient ledger. So what's the background behind proof of stake? So as also highlighted in the previous talk, you can think that at the core of Bitcoin's operation is an election process. So the next block is produced in the form of an election, so somehow a minor one of the protocol participants is selected to extend the chain. And this is done with probability proportional to its hashing power and collisions that may occur are supposed to be resolved by following some rule, let's say the longest chain rule or the most difficult chain rule. So proof of stake, the idea behind it is to follow a similar approach but use the amount of stake that an entity has as that is reflected in the ledger and use a randomized process that takes into account that stake to elect the next entity, the next participants who will extend the protocol. So in some sense this respects the fundamental logic behind how these protocols operate because after all in the real world you can use money to buy hashing power and as a result like you increase your probability of being elected by investing more money in the equipment of the system but in this case is somehow cutting out this physical footprint of the protocol and use directly the stake as it is reported in the blockchain itself as the main guidance for how the election process should go to elect the next entity to extend the blockchain. So you can classify all these protocols in this two dimensional space that cover two parameters of interest. So you can think like of the x-axis as showing how performance and energy efficiency scales and on the x-axis we have decentralization. So if you put it here together and you can think like the objective is to have a ledger where we have a centralized database on the one side and you can easily see this is on the upper left corner and then we have Bitcoin which is on the lower right. More decentralized but not energy efficient. And there's a direct way of also implementing a ledger by just composing sequentially a series of business agreement protocols and you can see that this would not be as decentralized as Bitcoin is and it would be less efficient of course than a centralized database which is just has a single point of failure. So a proof of stake protocol at least that's the hope if we can design it would actually fill this much coveted space which is here on the upper right corner because it can be more decentralized than this classical business agreement sequential composition because the stakeholder distribution may shift over time but at the same time the protocol can actually produce one block every heartbeat. And this can be done without actually suffering a penalty for scaling the protocol to a large number of participants. So if that's a protocol like could be designed it could possibly be more decentralized and more efficient than what we have. So this was realized early on when proof of stake was suggested as a possible course of action and very soon enough people realized that there were significant challenges that are specific to designing proof of stake protocols. First one which has been coded as grinding attacks is the fact that the adversary exactly because now the election process becomes a computational protocol which is reflected in the blockchain itself it stops being this idealized process that we can think of in the blockchain protocol like Bitcoin that uses proof of work. So it is possible somehow the parties to use computational power and try to buy the protocol to their advantage and these type of grinding attacks were present in all the protocols that were suggesting proof of stake based blockchains. Another attack which has been considered and has been seen in many cases was the nothing at stake attack that somehow reflected the fact that a stakeholder didn't have to commit to a specific extending a specific blockchain but it could just try multiple ones at the same time. And finally there was this circularity argument that somehow you would use the blockchain to run a protocol to produce randomness but at the same time now the security of that protocol would have to rely on the blockchain. So there is a circularity between the randoms generation and the security of the blockchain that you have somehow to avoid if you hope to prove this protocol secure. So this is where we stand and the question is is it possible to realize the ledger objective by using just a proof of stake discipline. So let's recap. We are in a synchronous setting. Time is divided in rounds which we call them slots and messages are sent through a diffusion mechanism. So basically it is the same model that you've seen in the previous two talks. The adversary is rushing which means that he has the advantage. He can deliver messages and spoof their source, inject messages of its own, reorder messages and send some messages to some parties and refuse some of their salary messages to others. So in this setting this is how the first rendering of our protocol works. So this is the first stage of the protocol where basically let's assume that the stake is static. So we have a fixed set of stakeholders which are identified here at the beginning. It's one of them with a certain amount of stake and that's predetermined. It's written in the Genesis block. Now the Genesis block also has a seed which you can think of it as a random string that is going to produce a sequence of random choices for leaders so-called that will be assigned to each every slot that is coming up next. So this leader here will be responsible for producing a block for that particular slot and only that entity is going to be responsible for producing that block here. Now observe that because the seed is part of the Genesis block, it's agreed already what is the slot-eater sequence. Now the sampling of that slot-eater sequence is done according to weight that is based on the stakeholder distribution. That means that the more stake you have, the more likely you are to be assigned on a certain slot. Otherwise, the assignment is completely independent. So now the protocol starts. All stakeholders have a public key and a secret key that corresponds to this little signature. And now the protocol follows an extremely simple discipline. At every slot, there is one slot leader that is responsible. And that one is going to issue a block. It's not necessary that this may happen. For example, a slot leader might be offline or it might be controlled by the adversary and prefer not to do that. So the protocol will still continue and parties will extend the previous block they know following a longest-chain rule. Very simple, exactly like in the case of Bitcoin, excluding the fact that there is no difficulty to take into account. So the protocol is simple, but how do you analyze that? So here's the first glimpse of how do we perform the security analysis of this. So the first important object to observe here is what we call a characteristic string. The characteristic string is as long as the number of slots you have in a system execution. And it's zero if the slot belongs to the nonest party, whereas if it's malicious, it's one. Observe that the characteristic string is something that the parties themselves do not know. But we know that we observe the execution of the protocol that follows some adversarial strategy that is determined as the adversary proceeds together with the protocol that the parties that run the protocol. So let's imagine that this is the string that characterizes how the protocol executes. And let's see how does the protocol extends. And along this protocol execution, I will define this tree, which we're going to call a fork, and is produced based on that characteristic string. So here is a zero node, which corresponds to the Genesis block, and that's always assumed to be honest. And now we're here at the first slot where it's an honest party that produces block one. Now what happens next is that we do have an adversarial slot. Without loss of generality, the adversary need not act at that particular moment. So he can wait up to the third slot where we have an honest party, and here is what the adversary does. The adversary who controls slot two, he produces a block and presents that first to the party that will produce the slot of the third position. So now what happens is that this party and this party have been split in two. So and this honest party now is extending this particular path that we call a time. So this particular fork, as we will see, is going to have three times. And the adversary is going to schedule its attack so that it will divide the chains that the parties are actually extending as the protocol proceeds. So let's look at what happens at position five. At this moment, the adversary who is in control of the fourth slot, he produces a block here and presents that to party five. Now observe that this party observes this time, which is of length three, including the Genesis block, and it's as good as this one. The adversary who is in total control of the ordering of messages can convince that party at position five to extend this one. In a similar way, the same thing happens in six, and finally the adversary convinces the party at position nine to extend that particular block. So what you have witnessed is how this simple protocol that I described in the previous slide gives rise to a rather complex execution where the adversary can switch the positions of the honest parties to different sides. So what is the problem here? How can we think about this protocol with all the knowledge that we have gained through all these previous works that started on proof of work? The situation is quite different, as we'll see. First of all, observe that the adversary now is in a much better position. So the protocol execution compared to proof of work protocol-based execution is much better here. Why? Because it can see ahead of time how stakeholders are activated. It can generate multiple different blocks for the same slot at any time without cost. So contrary to how Bitcoin works where the adversary has to invest computational power to extend the specific like chain, the same is not true here. Finally, the adversary can wait and act just before an honest party becomes activated. It doesn't need to do anything in the slots that it's assigned to himself. He can just wait until an honest party is activated and then at that moment can choose the best possible course of action. So there's no need for the adversary to commit ahead of time how it extends a chain. So let's look at the strings and say, here is the characteristic strings. There are exponentially many of them in an execution. Which, from once, are the ones that the adversary prefers? Now you can see that the string 000 is obviously a string that the adversary does not like. And it's very easy to see that there is nothing really the adversary can do here. We have just a complete sequence like that. On the other hand, just look at that string, 00110001. Now that string is actually a string that the adversary can do a complete attack. We call that string forkable. How does the attack work? So now you can see it here. Why we call that string forkable? Just look exactly about what happens here and imagine that you are the next honest party to be activated exactly after this point. Now observe how this looks and just see that it is absolutely in the discretion of the adversary to serve you either the upper time or the lower time of that fork. That's because that time is of length 5. And this one is at length 4, but the adversary is in control of that slot. So when you come up here as an honest party, it will be up to the adversary to serve you whatever time it prefers. So this is a bad string for us and a string that the adversary wins. So we call that string forkable. So the main point is going to be if you pick a string at random, what is the probability that it's forkable? And that's the core point of the security analysis. To understand that, we have to introduce two quantities which are useful. So we call them reach and margin. But first observe that we're just going to focus on what we call a closed fork. A closed fork is a fork that ends on just nodes that correspond to honest parties. So the leaves of that tree is just honest parties because we don't need to consider those forks that end on adversarial blocks exactly because the adversary can always fill them in at the right time. Now for each one of those times, just observe that we can define two useful quantities. The first one we call the reserve which corresponds to how many blocks the adversary can add to extend a certain time. So in this particular case, this one has a reserve of three because there are three adversarial slots coming up. So for example, when an honest party is activated here, the adversary can use the reserve of three to advance this time by three blocks. At the same time, there is another parameter, another quantity which we call gap which says how far away behind is this time from the leading time of the fork? So if we take the reserve and we subtract the gap from it, we define a quantity which we call reach and this says how much this time is behind the leading time in a fork. So reach and margin are going to be the two important quantities in the probabilistic analysis that we will do. The nice thing is that combinatorially you can show that the string is forkable if and only if there is some closed fork for which it holds that the margin is zero, at least zero, where the margin is basically you take the time which is the longest and you compare it with the one which is second longest and you try to see what is the difference between the two. So this is what we show in establishing the probabilistic experiment that determines the reach and margin. What happens is that reach and margin, they do like a complex random walk as new stakeholders are elected to add the block. So when you have a one which means it's adversarial, what happens is that reach and margin are extended by one. On the other hand, if you have a zero, what we would like to happen is that reach and margin are decreased. Basically it would have been this setting, just this final line here. If it was like that, that would have been a simple random walk. But what happens actually is that this only happens in one case. So reach and margin decrement in this case. But what happens is that reach will never drop below zero. So if it is zero, it will remain zero because reach expresses the advantage of the adversary. And now what's very interesting that happens in this recursive formula is that when the margin is zero, then the reach is decremented, which basically means that it's possible for the adversary to compensate for the margin for how much it is behind by sacrificing reach. Now if you take this recursive formula and you apply it to the experiment that samples the next slot leader, what happens is that we do have a two-dimensional random walk. And this two-dimensional random walk is kind of simple when variable reach and margin are positive and negative, respectively. So then the two variables behave like a simple random walk. But what happens when reach is positive, then margin gravitates and sticks to zero. So here it's a dependency and the two-dimensional aspect of this random walk is revealed. So now we have to see what is the probability that if we take a long string in this two-dimensional random walk, we're going to end up with a margin which is at least zero. And what we prove is that this will happen with very small probability. That's going to be 2 to the minus square root of n times a constant. And the key idea is that we can divide the two-dimensional space into three areas, what we call them hot, volatile, and cold. What happens is that the volatile area is the one which is at the center of the two axis when the margin and reach are close to zero and that's actually our initial state. And then we're going to have a cold region which basically when the margin is negative and that's safe. And then we're going to have a hot region where basically we've lost the game. So what happens and what we prove is that if you start from the volatile state, as it is the case in our game, the probability of moving to the hot state is negligibly close to zero to the minus square root of n, whereas there is a constant probability of moving to cold. And the key observation is that once you move to cold, then you will remain to cold. Basically random walk has moved away from the volatile and hot territory and now we're safe. Given that all this happens with error to the minus square root of n, and we have a constant probability of doing this transition, what we need to do is divide this into square root of n regions and then we can see that with very high probability in one of those steps of the process, you're going to transition from the volatile to cold state. And basically that means that you're safe. So finally, this concludes that the density of these four double strings is just that. So armed with this, now we show how we can actually go to the dynamic state case. So the dynamic state what happens is that we run an instance of the basic protocol for a certain number of slots, assuming some initial randomness seed, which is part of the Genesis block. And now let's assume that we have a magic beacon that when we reach that end of that sequence of blocks, it will give us a new seed that we can use to sample again from the stakeholder distribution. So the beacon comes, it gives us another seed, and now, and that's what's neat about this, we can use the blockchain itself to refresh our stakeholder distribution and use the new stakeholder distribution that has arisen as the stake has shifted on this initial sequence of blocks. So here you can see like this self-referential aspect but we use the blockchain that we have here, the short segment, and we can receive that process using the beacon choosing a new stakeholder distribution. Now this is used now with a new seed to create another stakeholder distribution and the protocol continues. So of course, in practice, we do not have such a trusted beacon. So how can we solve that? And the answer is coming from God. Or more specifically, guaranteed output delivery coin tossing. So guaranteed output delivery coin tossing or God coin tossing has this godly property that it guarantees the output. Basically, that means that if you have honest majority, you are guaranteed to produce an unbiased seed. So what we have to do is use this little short opportunity of time we have to create this blockchain segment so that we can run this God coin tossing protocol that is going to be enough to produce the seed for the next epoch. And that is going to be done by using this tool called publicly verifiable secret sharing which is something that we can construct using simple cryptographic tools. So based on all that, we finally have our proof ledger objective and even though I don't have the time to go over the detail of the proof, what we show is that the Roboros protocol, assuming a certain restriction on how adaptive is the adversary, we can prove the properties of common prefix same quality and same growth that you've heard in previous talks with negligible error in K which means that Roboros will give rise to a robust transaction ledger. So some things I don't have the time to cover in this talk but you can find in the paper is that on top of what we have we also provide an incentive structure for the protocol based on which, and I'm going to skip those slides now but I'm just going to focus on this final point. We actually prove that for this incentive reward mechanism that we have we can prove that running the Roboros protocol is an approximate Nash equilibrium and the good feature about this is that contrary to Bitcoin we can actually establish this incentive compatibility of the protocol. Some further details and I'm going to finish with some performance characteristics that you can see here. This is an implementation using 40 nodes in the Amazon cloud. We have implemented our protocol and we have benchmarked it and you can see here I appreciate the efficiency of the proof-of-stake protocol. In this case the transaction per second is about 250 in this simple implementation that we have you can compare this with 7, 8 or 9 transaction per second that you might get from a protocol like Bitcoin. So some upcoming work that we have is solving two open questions that were left in this one. So semi-synchronous setting, basically parcel synchrony and adaptive corruption is dealt with in an upcoming work joined with Broward, David, Peter, Gaz and Alex Russell and you can find this on ePrint. So further work is here and you can find the talk online and time is running out but this is related work and you can find a comparison in the ePrint version of the paper as well as in the proceedings and this brings me to the end. Thank you very much for your attention.