 I'm Peter Gagi, I'm a research fellow at IOHK and we are now at Cambridge, Massachusetts and I'm going to give a talk on Uroboros and Uroboros PROWS, which are two proof-of-stake protocols that underlie the Cardano project. Uroboros is unique in being the first proof-of-stake protocol with provable security guarantees being published in a peer-reviewed conference crypto 2017. Provable security is an approach that is being adopted by cryptographers in academia for decades already and it's a way to design protocols where as opposed to trying to just design them in a best effort way you instead aim for a clear security guarantees that can be mathematically proven in a rigorous computational model. Approvable security treatment of the protocol consists of defining the model in which we look at the protocol, describing the protocol and defining the required goals that we want to achieve with this protocol and then giving a mathematical proof that this protocol actually achieves these goals in this model against an arbitrary adversarial behavior that the model allows. Thank you very much Amy for the kind introduction. So yes I will be talking today about Uroboros and Uroboros PROWS, the two proof-of-stake algorithms that one of them is underlying Cardano already now and the second one is potentially might replace him at some point. And first let me mention that the whole line of work on Uroboros blockchain is joint work with Agelos Kias, Alex Russell, Bernardo David and Roman Olinikov and actually these gentlemen are the authors of the first Uroboros paper and I joined the team when we started working on PROWS. I will be talking about both of these protocols and also I would like to acknowledge Alex for creating an older version of these slides that will be used throughout the talk. So the roadmap for today, so I will be first very briefly talking about Bitcoin and proof-of-work although we all have an overview of how this roughly works, is just to make sure we are on the same page and to be able to draw comparisons later. Then what follows out from this first part is that this is not the end of the story and this motivates why we want to look at the proof-of-stake instead. And then I will spend most of my time talking about how Uroboros works. I will describe you the model in which we look at how Uroboros works and in which we prove the security guarantees. I will describe how the protocol works and I will try to show you some details from the security proof of the protocol. So this will be more of a theoretical look at Uroboros. And then I will also talk about prowess briefly by describing the differences from Uroboros and how this helps us make Uroboros better, namely secure in a semi-synchronous setting and with adaptive corruptions. I will talk in detail about what this means. So let's start with Bitcoin and proof-of-work. We all know this part so Bitcoin as we all know is a cryptocurrency that appeared in 2008, at least the proposal. And what was novel about Bitcoin is the idea of a decentralized ledger mechanism that is being maintained in a permissionless setting. So anyone can enter the setting, participate in the protocol. And this was possible due to a novel security assumption, namely the majority of adversarial computing power, sorry, the assumption that majority of the computing power is controlled by honest parties. This is the crucial security assumption that Bitcoin is relying on. Of course, it inspired a huge amount of follow-up work and there is a huge amount of cryptocurrencies that came to exist after Bitcoin. Some try to aim for richer transactions, which are often called smart contracts. Some aim for better privacy and some aim for different consensus mechanisms. And actually a different consensus mechanism is what I will be talking about mostly. But from a theoretician's perspective, the first question you should ask and needs to be asked when you look at Bitcoin is what problem does Bitcoin solve? And this question wasn't rigorously asked for quite some time and later this was formalized, mostly in the GKL work. And it turns out that the question is how a distributed collection of parties can agree on a dynamic evolving sequence of transactions, which we will call ledger, in such a way that it maintains two properties. The first one is called persistence. And it means that any transactions that already entered the ledger will be immutable. And the second one is called liveness and means that if I want to include a transaction into the ledger, eventually this will happen. This is an informal description of a property that can be captured formally. And of course, it's parametrized somehow to give some concrete meaning to this eventually. But this is the intuition. And this all should be happening in a setting where parties can join and leave the execution of the protocol. And we have to account for some parties that might behave adversarily and try to disrupt the protocol. And the way Bitcoin goes about this, of course, is by storing this ledger in a data structure called a blockchain, which consists of a genesis block that is agreed upon at the beginning. We assume that everyone agrees upon how this genesis block looks. And then a sequence of blocks where each of them contains some transactions and also a hash of the previous block. So this particular block commits to the entire history of transactions in Bitcoin. And of course, the major challenge in Bitcoin and in cryptocurrencies in general is how to achieve consensus on changes on extending this blockchain. And the interesting point here from a theoretical perspective is that this is outside of classical distributed computing models because it no longer makes sense to speak about majority of players. This is due to the CBL attack, which we all know, right? If it costs you nothing to enter the space and there are no identities, then you can just create as many players as you want if you try to disrupt the system. And the solution that Bitcoin uses to overcome this problem is a combination of two things. So the first one is proof of work. So as you all know, a block in Bitcoin looks like this and it contains a work nonce, which is a proof that whoever created the block invested a particular amount of work. And this certifies that the work was invested. And the second part of the solution is the longest chain rule, which means that if I'm a party looking at the potential candidates for the state of the ledger, I will simply choose the one chain that I see that is the longest I have seen so far, or at least contains most work. So in a very simplified cartoon version, Bitcoin works like this. If you are a node, what you do is you just simply repeat the following. You collect all the pending transactions, you collect any chains that you have seen on the network, you adopt the longest one out of those as your current state. I mean, of course, it has to be valid in terms of the transactions that it contains and other things. And then you simply try to mine a new block on top of this chain by trying to solve this proof of work. And if you succeed, you add it to the blockchain and you broadcast it so that everyone can adopt it as well. And what this whole procedure achieves is called eventual consensus. Because if we have an adversary that tries to compromise the persistence, for example, he might try to remove a particular transaction that is in one of the blue blocks from the ledger. He would have to create an alternative blockchain or an alternative fork from the blockchain that would have to be longer than the major one. And of course, this is highly unlikely if he only controls a minority of the computing power. This is the carton version of the main security argument of Bitcoin. And this means that the deeper the blocks are, the increasingly immutable they are. But another way how to see this is that this actually yields as an implicit mechanism for a ledger election. So you can see all these people that are doing the mining, doing trying to complete these proofs of work as competing in a ledger election process where the probability of succeeding, which means being able to extend the chain, is proportional to the computing power. What is nice about Bitcoin is that, first of all, it is simple. The protocol is much simpler than previous protocols trying to achieve consensus in permissioned settings, for example. And it neatly solves this challenge, how to achieve this consensus in a fluid population of participants. But also, and also with previous impossibility results, which told us that something like this should not be possible, our sidestep, thanks to this ingenious new assumption of the majority of computational power. And actually, it's amenable to formal analysis, which already happened to some extent in academic literature. So there is Gara Edal in 2015, gave analysis of Bitcoin in the synchronous setting. Then Pas et al in the semi-synchronous setting. And Badejo Edal at crypto 2017 gave a UC-based characterization of what Bitcoin achieves. So that's all good and nice, but we wouldn't be here if this was the fine answer. And so Bitcoin also has some disadvantages. And the main one is the computational raise that is necessarily happening to maintain this proof of work. Because this assumption of honest computational power, honest majority of computational power, that's essential for Bitcoin security. And so as Bitcoin grows, the need for computational power being wasted in the process of maintaining the ledger also increases. And this can actually to some extent be quantified. It's hard to get precise numbers, but the estimates are on the order of single units of gigawatts being needed for maintaining the Bitcoin network, which roughly corresponds to powering a million U.S. homes or an entire country, as you can see in the news. But what is, at least for me, more worrying about this is that these estimates are growing due to the growing popularity of Bitcoin. So for example, it almost tripled over the last six months as the price has soared. And this doesn't seem to be sustainable in the long term. And remember that security of Bitcoin crucially relies on this. So clearly from a theoretical but also from a practical perspective, a very important challenge is to try to replace proof of work with some other mechanism. And if we try to aim for a similar mechanism, which we also can see as a lottery or a leader election mechanism, what we would like to do is to do this election based on different resources than computational power. There are actually several proposals trying to do this. There were proposals looking at disk space as being the resource to be used, maybe useful computation as opposed to the useless computation that is being used in Bitcoin, maybe useful storage of useful data. But I would say that the most appealing approach is to, instead of all these real life resources, try to use an abstract resource. And clearly, the choice of the abstract resource would be to use the coin itself, the owning of the coin itself. And this is exactly the line of thought that leads to proof of stake, the topic I will be talking about. So basically proof of stake is this approach of shifting this election process to a setting where your probability of winning is proportional to the fraction of the currency that you own. This has several advantages because, as you know, the ledger already contains the information about how the currency is distributed among the participants. So basically the first idea how we could do this is simply in steps, always elect the smallest unit of the coin and just try to look who owns it and let this guy be the leader. This would lead to participants being elected leaders proportionally to the stake that they own. This was actually proposed in the context of Bitcoin as well and that's why originally it was called follow the Satoshi by the smallest unit of account in Bitcoin. And from a high-level perspective, it looks awesome because we just got rid of the need of the physical resources that would underlie the election process, but otherwise nothing needs to change, right? Except that it's not so easy. So the main challenge when you want to design the, I mean there are several challenges, but the main challenge when you want to design a proof of stake protocol is that for this election that I just described, you need some randomness to elect, for example, this coin and what I described. And this randomness, this randomness needs to be unbiased, unbiased by the parties involved, potentially malicious parties. And this is really crucial because as soon as the adversary can bias the randomness, he can bias the election process and he can try to hijack the whole chain and bad things happen. So the first challenge is how to produce this randomness. The first strawman proposal that was actually even implemented in several existing cryptocurrencies and that comes to our mind, if you try to think about it, is that, okay, the blockchain already contains some effectively randomly looking data, which are the hashes of the blocks. So one thing you could do is just try to hash the blockchain as far as you see it for now, then this will identify a particular coin and then this will somehow identify its owner and this owner is allowed to create the next block. That sounds good, it just doesn't work. And the reason for this is well known, it's called rejection sampling. What the adversary can do if he gets into a position of creating a block, he can try to locally test whether if he creates a particular block, what would be the outcome of this process and if it turns out that the next elected leader would be someone else, he just discards this block and tries again and he does this locally until he is lucky and until the outcome of this process is that he would be the leader of the next block again and then he can do this on and on and basically hijack the chain. So this is obviously unacceptable. This is called a grinding attack, it's one form of it, it's a simplified one, one can see many variants of this and this is mostly to illustrate that it's not as easy to make this idea work as it would look at first sight and there are actually a lot of subtle challenges in it. I don't know, at least some of the constructions that deal with this problem and give some rigorous guarantees in terms of security of the proof of stake protocol. Uroboros is the protocol that I will talk about and now I'll just sketch how these protocols deal with this particular challenge of getting randomness. So what Uroboros does, it implements a secure multi-party computation to generate the randomness. I will go into the details later and this actually gives us clean randomness unbiased by the adversary as long as some assumptions that I will detail later are satisfied. A different class of protocols, snow-wide and Uroboros prowls, they choose a slightly different approach. They do use hashing which is what I described before but in a much more careful way and they do give a rigorous analysis that this grinding attack actually can be contained and the randomness can be used for staking without jeopardizing the security properties of the blockchain. So it's hashing is used and then by careful analysis we can show that this doesn't do any harm and in this place I also have to mention Algorand which actually predates all the proposals above but uses a different approach so I will not have a chance to go into details of that in the talk. The approach is that contrary to the above constructions which aim for an eventual consensus just like I showed you aiming for the longest chain rule and accepting the longest chain, Algorand simply tries to get a complete consensus for every block. But why I mention it here is because it still needs randomness for its running so it has to address similar problems and it does it in a similar way to the constructions in the second ball and namely it does use some hashing and it does an analysis that shows that grinding the effects of grinding are can be contained and limited. There were also several solutions of proof of stake in the wild so I will just list them here the NXT cryptocurrency peer coined DPOS that seems to be underlying BitShares team and DOS. There is discussion about Casper at Ethereum and so on. So let me now move to the main part of the talk where I will try to give you some insight into how Uroboros works, in what model we analyze it and how we try to prove it secure. So from a really top-level view Uroboros is a protocol that assumes synchronous time and communication so we look at it in a synchronous network model. This is something that an assumption that will be relieved in proud but for Uroboros this is how we analyze it and it does provide persistence and liveness. The two properties that I told you about that we care about it provably achieves persistence and liveness under the following assumptions. We assume that the adversary controls a minority of the stake throughout the whole execution of the protocol. We assume that corruptions from the adversary are not immediate so the adversary might corrupt parties but there is some delay in this corruption. This is also an assumption that can be alleviated in proud and we do it in proud and stake shifts are happening at a bounded rate so this seems like a practically reasonable assumption. We are assuming for example that not all the stake will transfer from one account to another one within a single transaction and there is a bounded rate of how the stake shifts. So let me detail a bit about the communication model. I said it's a synchronous model. We assume that participants have synchronized watches and we split all the time into slots for example in the Cardano implementation of Uroboros one slot is 20 seconds just so that you can imagine a particular number there and we assume that all messages that are being sent by players by honest players are received by all the other honest players in the same slot so within this 20 seconds this is the synchronicity assumption of the model. A property of the protocol is that all the parties only communicate by broadcast which in practice is implemented by peer-to-peer gossiping but we give the adversarial parties so any parties corrupted by the adversary we give them the power to send arbitrary messages to arbitrary subsets of the players and arriving at arbitrary times. So this is the communication model. So let's now take a look at how the protocol works from a top level view. It's divided into epochs. Each epoch is a sequence of R slots so it's a particular time interval. This would be the colored boxes down there the big ones as you can see each of them consists of several blocks that were produced in this epoch and within each of these epochs we need something that is called a stake taking distribution. This will be the distribution that will be used to sample the winners of the election process and the way we obtain this stake distribution for a particular so for example for the yellow epoch we obtain the stake distribution by simply taking a snapshot of how the assets are distributed in a particular moment in the previous epoch so in this case it would be in the blue epoch and except for the stake distribution we also need randomness and the randomness is produced in the previous epoch by a multi-party computation so during the blue epoch there is an NPC running which leads to an unbiased probably unbiased randomness that is then used in the yellow epoch to to sample the winners of the election. These are called slot leaders in Uroboros so this for every slot as I told you about these slots for every slot we elect a unique player that is allowed to create a block in that slot and the sequence of these players these slot leaders is called a leader schedule and that is sampled using the stake distribution and the randomness that I described to you and that come from the previous epoch so this circle of epochs that each of the epochs relies for its stake distribution and randomness on the previous epoch this is how Uroboros looks from a very top level perspective and if we want to analyze the security of Uroboros then well if I want to tell you something about it I will go and I will approach it in the same way that we do in that it is done in the paper which is doing it in two steps first looking at one single epoch assuming that the stake is static because it's there is a just a fixed stake distribution that is being used for sampling the slot leaders and the randomness is clean and given at the beginning this is called a static static setting for example and then I will tell you how to bootstrap to analyze the whole protocol and the sequence of these epochs so first let's take a look at the static case we assume that there is a genesis block that that contains the public keys of the players together with their stake with the proportional stakes these are given at the beginning and shared by all the players and we also assume that there is a sufficiently long clean random string for the leader election and now we are going to look at one particular epoch of length R and try to show that during this particular epoch persistence and liveness is achieved so as I said in this static case the leader selection is simple there is just a public publicly known function L that takes the randomness of that is to be used for this epoch and generates all all the leaders the generates the whole sequence of the whole leader schedule in such a way that each leader is selected independently from the other leaders and proportionally to its stake this is what one would expect and since the function L is public and the randomness is public the whole leader's leader schedule is public as well so everyone knows the leader schedule in advance then we can talk about when is a blockchain considered valid it has to start with the with the genesis block that is agreed upon everyone knows it it has to contain a sequence of blocks of course that are associated with increasing slot numbers and each contains a hedge of the previous one and they contain non conflicting transactions but what is important is that there doesn't have to be a block for each of the slots because maybe the the unique slot leader that was chosen for that particular slot did not produce a block maybe he was malicious maybe he he was offline for whatever reason so we consider the chain valid if even if there are slots without blocks but each of the blocks has to be signed by the leader of the slot to which this this block claims to belong this is important and that's why the structure of the blocks in uroboros is as follows it contains of course the transaction the hedge of the previous block and the slot number but on top of it it also contains a signature that comes from the from the secret key that corresponds to the public key that is present in the stake distribution right so the stake distribution is simply a distribution of stake over public keys and then this can be used to to verify that the block was actually signed by the proper proper slot leader for that particular slot so the protocol in the static case looks as follows again the the the party collects all the transaction that sees on the network and the collects all broadcasted blockchains it adopts the longest one as its current state and then if the party figures out that it that she's the leader of for for the particular slot currently happening it just creates an additional block signs it and broadcasts it to broadcasts it to everyone and this block is of course created on top of the longest chain that the party has seen so far so you can see that deliberately and by design this protocol is very similar to what is happening in bitcoin although we get rid of the of the proof of work aspect and the the election looks different in particular it's important to to observe that it's also a longest chain rule protocol so we do have this longest chain rule that governs which which chain is to be considered the current state however the analysis is is different in many or in several crucial aspects from bitcoin namely in our setting the the adversary in contrast to the bitcoin adversary has several additional powers at its disposal first of all it he knows the entire sequence of leaders ahead of time because as I said it is public and and second of all he can generate multiple blocks per multiple blocks per every slot where he is the slow leader because this is this is basically for free it only costs you one signature to generate a block so this this extends the powers of the adversary that's not the case in proof of work where you have to work hard to to create every every block and so an obvious question is how much does this increase the power of of the adversary and can we prove that it doesn't allow him to disrupt the security of the of the blockchain what what the paper does is it introduces a framework to describe the combinatorial behavior that is happening when when we are extending this this chain in this in this manner that I described to you with some slots belonging to honest parties and some slots being controlled by the adversary so to talk about this we will we will use the notion of a characteristic string which is basically just a binary string a string of zeros and ones that that describe how the slots are distributed among honest parties and the adversary so it's a string of our bits and the zero always means that the slot leader for the particular slot and that at that position is an honest party and one means that it's a it's an adversarial party so you can you can notice that this string in the execution of the protocol is just binomially distributed with the parameter 1 minus epsilon over 2 where where this is the the the relative stake of the adversary that that we assume in the in the in the in the distribution of in the stake distribution and the hope would be that as the adversary controls the minority of the stake it will also control a minority of the slots so less than one half of the bits in this bit string will be will be one and the hope is that this is sufficient to observe that that the dynamics of the protocol as it will be happening will will lead to persist will achieve persistence and liveness so let's see let's see how to go about that how to how to actually show this so as I said the goal is to to show persistence and liveness but it is well known that in blockchain based protocols one can actually show three more basic properties common prefix chain quality and chain growth and these three properties together imply both persistence and liveness this this is from the gkl 15 work where common prefix simply means that any two chains possessed by any two honest parties potentially at different time moments have the property that if you cut k the final k blocks from one of the chains it will become a prefix of the other one this is common prefix chain quality is a property that shows that that says that any chain possessed by an honest party has the property that at least one of the blocks within the last k blocks was honestly generated by an honest party and chain grown growth simply means that there is a lower bound to the to the growth of the chain at every at every sequence of say k slots actually it turns out that the most difficult property to to prove for roboros but also I think in general is common prefix and so I will talk a bit about how this is achieved and then very quickly glows over the other two properties so but to get some intuition let's let's take a look at an example of how the dynamics of the protocol works so let's imagine that we have this epoch with what nine slots and we have a we have an agreed upon genesis block and we have a characteristic string down here I remember that zeros mean that this is an honest honest slot so the slot leader for that slot is honest and one means that that the slot leader is adversarial so what can be happening so the first slot leader is honest so he follows the protocol and he simply creates a block that extends the longest chain which is just the genesis block that's easy then it's adversaries then is the turn of the adversary and of course he can he can just create a block that does not extend the longest chain but creates an alternative chain then it's an honest player's turn again and as we know the protocol says that the honest party should extend the longest chain available the longest chain it has seen so far but in case there are several chains of the same length to be on the safe side we we we let the adversary decide which which of the chains will be extended by by this honest party to be yes to be to be on the safe side in the analysis so for example let's say in this case the adversary makes the the honest party extends this upper chain then it's adversaries turn again he can do something like this for example then it's an honest party's turn but what and maybe the honest party extends this one because both of the chains were of the same length but then what the what the adversary can do is only at this point creates additional blocks that belong to its to its slots and then use these blocks to convince the the next honest party to extend this new third middle chain right then it's adversaries turn again maybe maybe he doesn't use his slot and in the next one he does produce a block as you can see in the in the slides and finally makes the the last honest party extend this this longest middle chain so what we can see from this toy example is that the dynamics is already far from trivial even in this simple static setting and what different paths in this in this tree that you can see correspond are basically different histories of transactions so and even here with with minority of adversarial slots the adversary was able to create three of them even though they are of different lengths and so we would like to to show that it can never happen that the adversary manages to create two alternative histories that have forked sufficiently far in the in the past and and are of equal length because then basically the the honest party doesn't know which of these histories to believe and and persistence is clearly violated right and to be able to show this formally there is a there is a forks calculus introduced in the paper where we formalize this where this notion is is formalized we talk about a fork which is which is just a name for for such a such a tree as you can see up there and which is an abstraction of what were the chains that were being sent around by by parties so it's a graph that indicates these these chains nodes of course correspond to blocks edges correspond to this predecessor relation we have a genesis block there we we this this double circle nodes correspond to honest blocks and single circle one correspond to adversarial blocks all nodes are labeled with their slot number with the number of the slot that they belong to and each node has a unique edge of course to a previous previous node with a smaller label what is important to to notice is that according to the protocol all play and to the according to the model all players hear all honest broadcasts and honest players speak at most ones in any slot and what these two observations mean for the for the graph is that any honest slot is associated with exactly one honest node and the depth of any honest block exceeds the depths of all previous honest blocks because if an honest party broadcasted the block then any later honest party will not be willing to exceed to extend a chain that will be shorter than the one that this honest party already broadcasted this is due to the synchronicity assumption of of the broadcast so formally a fork is a for a particular characteristic string w is a labeled rooted tree where each node is labeled by by an element from from zero to n and it satisfies the four conditions that the the root is labeled with zero edges are directed away from from the root labels increase along each of the paths honest slots so the slots that belong to that have a zero in this characteristic string they label unique vertex and the depth of the honest vertices increase and any any tree that satisfies this for condition is called a fork for the particular string so if we fix a string there is a large set of forks that can potentially occur as the dynamics of the of the protocol evolves and we want to argue about all of these forks and so the idea when we want to prove common prefix property for the for the protocol our goal is to show that if we start by choosing this characteristic string from this binomial distribution that I told you about then the probability that common prefix will be violated is is small is negligible but the way we want to go about it is to actually show that if common prefix would be violated for this particular string it would mean that a very very obscure fork has has occurred so the graph has some very unexpected properties namely namely there are two widely diverging paths so there are two long parts that have diverged from each other a long time ago this this would be necessary for for a violation of common prefix and so we can try to just show in a combinatorial way that over the probability of sampling this characteristic string with overwhelming probability we end up with a string that doesn't allow a fork that would have this this undesirable property so none of the forks that are admissible for this particular bit string would have this this undesirable property and this is the way we want to go about it to just show that this is not this this is far from straightforward okay so first the first definition we call a string such a bit string we call it forkable if it has this property that there exists a fork there exists this graph this this tree that has two two paths that are of maximum length within this fork and they they diverge at the beginning so they have no no overlap except for the genesis block and here is a particular example in an interesting one where we have nine nine slots three three honest one then three adversarial one and then three honest ones again so the adversary only controls one third of the of the slots but what it can do is okay let the let the honest guys do their job then create an alternative part of length three let the let the final honest guys create the extent his upper chain and then exposed create an additional three three blocks in the lower chain and this basically creates two paths that are both of length six and they they the only intersect the only block in the intersection of these paths is the genesis block so this shows that this string this particular string of length nine is forkable even though it only contains one third of adversarial slots so this is this is this is a bit worrying when it means that the analysis will be will be quite involved and what actually what one can observe quite easily is that no string of density less than one third is forkable so this is like a corner case the adversary needs at least one third of of ones in the string to be able to to to create such a fork so if we were aiming for one third security would be basically done quite easily but but what we what we what uroboros is aiming for is a security up to up to adversaries that contain any honest any any arbitrary large minority of of the stake and this this turned out to be much more involved so of course one can observe that if the adversary controls more than one half of the of the slots the string is clearly forkable because the adversary can just ignore whatever the honest guys do and do his own stuff and make it as long as he at least as long as the honest parties but what is interesting is this space between one third and one half and to be able to say something about it we need to to argue probabilistically so we have to to count in the distribution of these forkable strings this binomial distribution that I told you about and ask the question what is the probability that the particular string that is sampled from this distribution will be forkable in this sense of this definition and this is a this is a question that is answered already in the uroboros paper but the a stronger bound is achieved by rassel adal in a particular write-up that you can find on eprint in the way in the sense of this theorem which says that if we draw this speed string from a binomial distribution with this parameter one minus epsilon over two which corresponds to the to the to the relative stake of the adversary then the probability that the string is forkable decreases exponentially with the length of the string and this together with the reduction theorem that basically says that if a bit string permits common prefix violation then there must be a forkable strict substring of a particular length somewhere in the in the bit string this together with the theorem and via union bound of course gives us the desired result that the common prefix violation can also be upper bounded by a similar exponential bound so I will briefly I will briefly talk about how this theorem is is proven it's via a martingale argument and the relevant feature that we that needs to be looked at is two-dimensional quantity that tries to capture some properties of the longest chain so far so it's a quantity that evolves as the as we are processing the bit string and it captures the the some properties of the longest chain in so far in this in this tree and the second longest chain these are the it turns out it's sufficient to look at these two of course they they may change throughout the the running of the experiment but it's such a two-dimensional quantity I will now try to show you what this quantity is so let's introduce some hopefully intuitive terms for that so if we look at the at the fork like this one in the picture below and we look at the particular part in it let's let's look at the part denoted by T that's the the one the the upper one then the gap of T is simply the difference in the length of this part from the length from the longest part that is present in the fork so for example the gap of T is four the reserve of this part is the number of adversarial slots that follow after the end of this path T so in this case it's three because the adversary has three slots at his disposal after the end of this of this path why is this important because if the adversary decides that he wants to do so he can extend T by at most three blocks just whenever he wants because he has control over these slots right and and the reach of T is simply the difference between the reserve and the gap and and the intuition is that the reach of a particular path tells us how much can the adversary extend this path if he wants to with respect or relative to the longest part in the in the in the fork right so in this case the reach is minus one which means if that if the adversary wants to make the path it tries to make the path as long as possible it would he could extend it to to be one block shorter than the longest part in the in the fork and we can go one level higher and look at the particular fork and say that the reach of the whole fork so remember the fork is just this this tree is the maximum of all reach values for all the paths in the fork and the margin of the fork is the second best disjoint reach so so the the reach of the second longest completely disjoint path in in this tree and then even one level higher we can talk about a particular string characteristic string and we say we define these two quantities rho and mu where rho is the maximum reach over all forks that are compatible with this string so if you have a string you have a set of all forks that that belong to to this to this bit string to this characteristic string and rho is the maximum reach of all of them and mu is the maximum margin of all of them and then not so difficult to see fact is that that the characteristic string is forkable if and only if the the mu quantity turns out to be non-negative for the for the whole bit string this is intuitively this is because it means that if the there exists a fork for the particular string in which if the adversary wants he can extend the second longest disjoint chain to the length of the longest disjoint chain which means he can produce two histories that are of the same length and they fork at the beginning which means he can puzzle all the honest parties and violate persistence and so what we want to achieve is to show that with this distribution of the of the characteristic string the probability that mu is non-negative is is negligible and the idea that is that is followed in the paper is to analyze this powers random variables well for this distribution of of w and with some work one can show that actually these two quantities inductively follow a particular recursive expansion that I show you here how how these two quantities evolve if you add a zero or a one to the end of the to the end of the string and you can actually define a related martingale to to these random variables lambda and mu okay it should be actually row and mu and then you can apply as my inequality to this martingale and this will give you the the result I will know not go into into that but I hope this at least gives you the intuition of how the proof goes and this concludes the proof of common prefix thanks to the reduction that that I already mentioned to you okay so so this was about common prefix chain growth and chain quality and I will just mention that of course persistence and liveness follow from these three properties in a quite standard way okay so this establishes that the static the static part of the protocol which only describes one epoch does achieve persistence and liveness as we wanted in and this can be formally established but now we we need to somehow bootstrap and get to the to the dynamic protocol where where one epochs follow one epoch follows another and for this as I said we need we need randomness we need updated randomness for the new for the new epoch to be to be used for sampling the slot leader slot leader schedule and what uroboros does is it uses a secure multi-party computation as protocol to generate this randomness with using the blockchain itself during this epoch as the communication medium and the randomness that is then generated is guaranteed to be clean as long as the majority of the stakeholders or the slot leaders for that particular epoch are honest and the tool that we use for this protocol is publicly verifiable secret sharing where which is a protocol where with the dealer and the family of players where the dealer can choose a value and share it to produce shares for each of the each of the players and then players can both check whether the broadcasted shares are valid in the sense that together they they really reflect the consistent value and also if it is valid then majority of the players can reconstruct this value but the minority of the players can learn nothing about the value and this is very useful for the goal that we have because we can simply make the parties use pvss to share a random string that they generate and after all the and also what we do for efficiency reasons is that the parties also commit to this string and after all these commitments are put into the blockchain the players simply open the commitments and explore the values to get the new randomness but if someone fails to open his commitment then the pvss shares can be used to reconstruct his value and and in this way achieve the clean randomness for the next epoch when it comes to practicality of uroboros it was actually implemented by iohk as as the consensus algorithm are underlying cardano there are several ways how one can look at the performance one that is also presented in the paper is that one can compare how much time one needs in minutes to to achieve 99.9 percent assurance against an adversary that is trying to make a double spending attack where in the case of uroboros we can model this attack we can do actually the optimal attack that the adversary can do for a double spending this follows from the four calculus that i showed you in the case of bitcoin we only do the double spending attack that you would expect the the simple one so potentially there are better attacks against against bitcoin but this already this attack is sufficient to show that actually this comparison turns out significantly in favor of uroboros so you can see several you can see how this this turns out for various values of the adversarial either stake ratio or computational power ratio and there are two columns for uroboros one is the general one which is assuming an arbitrary adversary that's what we have done so far but the other one which I think is is relevant for practice as well or maybe even more is assuming a covered adversary which is a weaker adversary that doesn't want to give away that he behaves adversarial is for example he's not willing to sign two blocks that would belong into the same slot because that would clearly identify him as being malicious and there might be some out of band ways to to punish him or this is not specified in the protocol but but there might it might be undesirable for the adversary to give away that he doesn't follow the protocol and if he decides to operate in such a covered way the guarantees are of course even stronger okay so that much for uroboros and let me now describe how prowess differs from uroboros and what are the goals that we had in mind when trying to design prowess and how do we achieve these goals so in a nutshell prowess is an improved version of uroboros that achieve security in a semi synchronous communication model and despite full fully adversarial adaptive corruption so these are two goals that uroboros achieves and the tools that are used to to achieve these goals are local and private leader selection forward secure signatures and using hashing to obtain randomness and i will now go into into the details of both of these these goals that we achieve and all the three met tools that we used to achieve them and hopefully give you in a limited time a brief overview of how prowess differs from from uroboros so you can see these two goals that that we have listed up here as basically strengthening of the adversarial powers in the model that we are analyzing uroboros in so the first strengthening is that we assume semi synchronous communication so the black text on the slide is simply the slide that was describing the communication model for uroboros in the original paper and the red text highlights the differences in the model in which we look at prowess so now we still have slots but the honest players are only guaranteed that the messages from them are delivered to other honest players within at most delta slots so with some delay and this delay is fully controlled by the adversary individually for each message and each recipient the adversary can decide how this message will be delayed and this bound delta is unknown to the product to the protocol so the parties cannot cannot exploit the knowledge of delta and what we show is that the security of prowess probably degrades gracefully with increasing delta of course you with increasing with worse and worse network you cannot maintain the same security and performance but it degrades gracefully which is not this did not follow from the analysis of uroboros because the that analysis only assume synchronous communication and the second strengthening that we that we make strengthening of the adversary is that it can make immediate corruptions so it can just at any point in the execution of the protocol it can corrupt any party and immediately obtain all of its all of its memory including its secret keys and act on behalf of that party this is was also something that not only was not captured by the by the model of the original uroboros paper but also would be disastrous for the protocol because because once the once the slot leader schedule is public the adversary could just corrupt the slot leaders and he could he could hijack the chain so the only restrictions that the adversary still needs to to obey is that it still only can corrupt minority of the state throughout the the experiment and we still assume that the state shifts are happening at the bounded rate so this is the second strengthening that that we apply to the model and the three tools that we are using to be able to prove persistence and liveness also in this doubly strengthened model is so the first tool is that we use local private leader selection remember in uroboros we chose the the leader schedule publicly here we don't do it we use a tool called verifiable random functions which is a cryptographic primitive that basically consists of two procedures one is called evaluate it so vrfs are like a public public key cousins of prf of pseudo random functions and so the first the first procedure called evaluate needs the secret key of the and using the secret key it and it takes an input and produces the corresponding output which is unique for this input and this key it looks pseudo random to anyone who doesn't know the secret key and the function also produces a proof so that the party owning the secret key can convince anyone else that this is indeed the output for that corresponding input and the secret key and then of course there is a second verify procedure that allows you if you only control the public key it allows you to check that for a particular input the corresponding output and proof are correct so this is a vrf and you can use it in a natural way to to get a leader selection lottery for for deciding slot leaders in a in a local and private way so every stakeholder simply has a his own secret key for a for a vrf and he just plugs into this vrf the randomness for that epoch and the the slot number and looks at the output and if the output is smaller than some threshold that that is derived from his particular stake ratio if it is smaller than than he's just a he's a leader for that slot an interesting point here is that this function phi that that creates the threshold from your from your stake needs to be sub linear with respect to the stake as opposed to the case in world boroughs where the where the the slot leader attribution was public because if if it is public you can you can actually make it linearly proportional to your stake but that's not the case in the in the private leader selection case if you want to maintain in what we call independent aggregation which means that if you have a particular pile of stake it doesn't help you to split the stake into several piles and pretend that you are several players to increase your chances of becoming a leader if we want to maintain this property then the function actually needs to be sub linear so we have such a function in browse a similar construction was also used previously in the nxt cryptocurrency and also in algorand for for doing private leader selection it's actually not enough to use an arbitrary vanilla vrf a generic one because we need some security also in case when the keys of the vrf are adversarially generated because every player will be generating the keys for himself so we don't want corrupted players to be able to win to cheat the leader selection lottery by improperly generating the vrf keys but in the paper we give a use a functionality of a vrf that is sufficient for this for this task and we also give an efficient realization of it assuming random oracles and computational diffie helman assumption and what is interesting about this local and private leader election is that it produces empty slots and multi leader slots because now the the leader selection cannot be like synchronized throughout the all the parties so if every party decides locally whether he or she is a slot leader it means that there will be slots that contain no leaders and there will be slots that contain several leaders and to analyze this and show that persistence and liveness is still maintained we need to make an extension of the fork of the strings analysis I will not go into how we do it but we do it in the browse paper and interestingly now the ratio of empty slots basically how many slots turn out to have no slot leader is a protocol parameter that's and it will be hidden in this in this phi function and this actually turns out to be useful because such short leader loss periods help us in the analysis in the semi synchronous setting because they kind of allow parties to synchronize when over the short periods of silence and it's important also to to mention that this doesn't a great performance because now we can aim for much shorter slots because our assumption is not that messages will be delivered within the slot as it was the case for uroboros and the second tool that we use in prowess is our key evolving signatures these are digital signature schemes with a special property where the public keys are fixed but the secret keys can be evolved in such a way that you can update it in every step in our case that would be every slot and even if you get hold of someone's secret key for a particular slot you are not able to forge signatures for previous slots so if any party if a party deletes its its its older secret keys as it is prescribed by the protocol before broadcasting any messages even when when it acts as a slot leader in a particular slot then even if the party gets immediately corrupted by the adversary the adversary can no longer create blocks in in the in the name of this party for past slots and for this slot because the keys are already delayed deleted or evolved and this helps us to to manage to achieve adaptive security to manage with the adversary that is allowed to do immediate corruptions so such a key such a key evolving signature scheme is used for signing blocks in prowess and we also give a uc functionality for for key evolving signatures that is sufficient for this role and and we give a realization of it and the final tool that I want to mention is that prowess also moves away from the mpc to to for generating the randomness for for the next epoch for slot leader selection what it does instead is again turning to hashing because it's much more efficient but recall that there was this basic complaint against hashing which is that the adversary can do rejection sampling and to prevent this what we do is that into every block we include an additional vrf value from the leader so if you turn out to be a leader producing a block you also include a particular vrf value using your secret key for the vrf and these values are hashed together from from the whole past epoch to create the randomness for the next epoch at one at one shot and this means that if with with clean randomness the the next epoch thanks to the static analysis there would be there would be only a negligible probability of violating say common prefix or any other of the desired properties then an adversary who is able to do rejection sampling polynomially many times cannot increase this probability sufficiently to make it non-negligible the actual bound in the paper is much more nuanced but but even this argument is sufficient on the asymptotic level okay right so these are the three three main differences of of prowess compared to Uroboros and the two the two goals that we achieve by by these three changes I will not go into further details and I will if you are interested in any additional details just either look into the papers that are all an imprint or ask me and with this I will finish the talk so thank you for your attention