 All right, so thank you everyone for being here for the last talk of the session. It's been a long day so In this talk, I'll tell you about roboros a probably secure provost take 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 realises this robust transaction ledger and as you learned This was the objective of a paper by Juan Carayma self and Leonardo since DKL we formalize this definition this as an objective and This gave rise to some Pull-up work which we find the model and definition some of which was heard in this session Which now we can say we have finally a Simulation-based definition which which is composable Now once you have an objective, which is cleanly defined as such now you can ask Do we know the best way to realize it? So trying to answer that question is 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 was as I cited But we also know From the way the protocol actually works in the real world That it accept a 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 circulate were 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 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 We 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 block So You can classify all these protocols in this like 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 will have decentralization So if you put it here together and you can think like the objective is to have a ledger Well, 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 non-energy efficient and there's a direct way of also Implementing a ledger by just composing sequentially a series of business and agreement protocols and you can see that this would not be as the centralized 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's more It can be more decentralized than you know, this classical business in agreement sequence 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 last number of participants So if such 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 as a possible course of action and 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 part is to use Computational power and try to bias the protocol To it 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's 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 dividing rounds which we call them slots and Messages are sent through a diffusion mechanism. So basically this is the same model that you've seen the previous two talks the adversary Gun is rushing which means that he has the advantage you 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 those other messages to others So in this setting this is how a first rendering over 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 pretty determined. 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 leader sequence? Now the sampling of that slot leader 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 You know 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 an honest party Whereas malicious Where 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 arbitrary 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 I will define this tree which we're gonna call a fork and is Produced based on that characteristic string So here is a zero node which corresponds to a Genesis block and that's always assumed to be honest And now you hear we're here at slots the first slot where it's an honest party that uses 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 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 to 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're seeing is gonna have three times and The adversary is gonna 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 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 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 other side 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. They 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 zero zero zero 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 Zero zero one one zero zero zero one Now that string is actually a string that the other side can do a complete attack. We call that string forkable How does the attack works 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 the 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 gonna 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 But an 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 that computer in the probabilistic analysis that 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 mark 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 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 is we do have a two-dimensional random walk and these two dimensional random walk It's kind of simple when variable reach and margin are positive and negative respectively So then the two variables like behave like a simple random walk But what happens when margin when reach is positive then margin gravitates and sticks to zero So here it's a dependency and the two-dimensional 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 gonna 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 gonna be two 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 of the two axis When the margin and reach are close to zero and that's actually our initial state and then we're gonna have a cold Region which basically when the margin is negative and that's safe And then we're gonna 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 health state is Negatively 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 gonna 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 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 that 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 would do not have such a trusted beacon So how do we 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 very valuable 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 chain growth that you've heard in previous talks With negligible error in the 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 gonna 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've benchmarked it and you can see here 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 seven eight or nine Transaction per second that 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 Brown David Peter Gazin Pete and Alex Russell and you can find this On e-print so further work is here and you can find the talk you can find the talk online and The time is running out, but this is related work Which you can find a comparison in the e-print version of the paper as well as in the proceedings and this brings me to the end Thank you very much for your attention