 This is about the game theoretic aspects of blockchain protocol, which are extremely important. When you analyze a protocol, you can think of different parties acting in a good versus bad, or bad versus good, so the adversary would like to subvert the honest parties. So you can think of them in this way, and in some sense this is the classic cryptographic setting. On the other hand, the way things work in the world is not so black and white if you want. There is like rational actors that basically participate in the protocol, and they may have an incentive to deviate from the way the protocol operates. So while Bitcoin has proven to be quite resilient, we know that from an incentive point of view the protocol does not work well, and it's actually possible to deviate from the protocol and get an advantage against players that actually do follow the protocol. So proving that following the protocol is an equilibrium from a rational point of view, this is something that touches on game theory, and when you have a complex game between rational participants, a Nash equilibrium is a strategy for participants that says, if I know that you follow the equilibrium strategy, it doesn't make sense for me to deviate from that strategy. One of the major updates and something that I included in my presentation today here at Oxford about Ouroboros was our proof that the protocol is an approximate Nash equilibrium. It basically states that parties are the incentive structure that the protocol provides, such as that parties have gained no advantage by deviating from the honest protocol strategy. So if you have a malicious coalition that would like to change the way that the protocol operates in their own machines, they will not gain a substantial advantage compared to the other parties that actually follow the protocol. Thank you everyone for being here for the crypto seminar. It's a great pleasure to be here and present to you Ouroboros. This is a proof-of-stake blockchain protocol that I will describe to you and its properties. So feel free to ask any questions during the talk, we can do it this quite interactively. So I'm going to start with a general discussion about Bitcoin blockchain systems and what do they try to achieve and what is the motivation for building a proof-of-stake system. So well you will know Bitcoin and like many people have said is a remarkable solution. So the question I like to ask is what is the problem that it solves? So this is one of these like interesting settings that you have in crypto and distributed system theory where you have a protocol which is very successful and when it was introduced it was introduced outside the usual cycle of scientific research where problems are posed, solutions are given and analyzed. Instead what we had was a protocol which was launched in the form of an actual implementation in early 2009 and since then it became immensely successful. So understanding it from a computer science research point of view is a very fascinating question that also inspired me early on in this domain. So it's important to distinguish from the point of view of CS theory protocol solutions like what is the Bitcoin protocol and the objectives that they try to meet. And it's very important to understand these objectives because only then we're able to reevaluate whether the specific solutions we have like the Bitcoin system for instance is the ones that are best fit for the objective. So what you may call the objective that Bitcoin tries to solve is the notion of a robust transaction ledger which is something that we have investigated formally in previous work which I'll say a few words about. So once you have completely understood the objectives then you can go and ask questions about whether the specific protocol design is best and exploring this protocol design space with protocols and assumptions under which the protocols meet the objectives is what propels research in cryptography but also in general in computer science. So the first analysis of the Bitcoin from this point of view was conducted in this previous research which was joined with Juan Garay and Iguos Leonardo which we call it analyzing the Bitcoin backbone protocol. The intention there was to extract the main features of the Bitcoin system, abstract away things that were not relevant to a first analysis and present in the form of pseudocode in an algorithmic way in a way that it's possible to describe in a handful of pages how the protocol works while keeping all the important features that would be relevant for a proper analysis. And now you compare to that like what is the objective. So in that paper we also gave a specific objective that it seemed the protocol was trying to solve and that is building a transaction ledger in the presence of an adversary that tries to subvert two basic properties. So these were called persistence and liveness and I would say a few words about them in the coming slides. So what we provided in that work was a proof that in a static setting it is possible to demonstrate that this protocol actually meets the objective of a robust transaction ledger under certain assumptions. And these assumptions in the paper were involving a concept related to proof of work and more specifically the random oracle model which was the main tool to obtain the properties of the proof of work that were necessary for the proof to go through. So this analysis is not the end. On the contrary it's actually the beginning because once you have something like that you can start asking questions like the one that you see for example on the upper right. Given now that we have an objective and that objective is met by the specific protocol, is that protocol the best way to solve it while maintaining the basic properties? So this is the same question that you can ask so many, so many other cases when you are in computer science or in cryptography theory. So if the objective is sorting, is your sorting algorithm the best way to do it? If your objective is a digital signature, is that specific digital signature the best way to do it? So now you can ask the same question here. If the objective is a robust transaction ledger, is the Bitcoin protocol the best way to solve it? And answering what is best, it has to take many things into account. So one, especially because we are in a security setting, one thing to ask is performance and that's like the most straightforward, like we would like to have the most efficient solution. And the other thing, especially because we are in a security setting, is to ask are the assumptions under which the protocol meets the objective, the ones that are the most realistic in practice? That's the second important point. So the design challenges for finding alternative protocols, they have this performance dimension. So Bitcoin is slow and we would like to see whether it's possible to get a faster protocol. It's worth pointing out that if you compare it in net transaction processing time, transaction per second of visa is at least 2,000, PayPal 100, by various measurements Bitcoin is far less than that. Clearly not something that could scale at the global level as is the intended application domain for Bitcoin. Energy also is very high and this actually come from the other dimension that is related to Bitcoin operation. So Bitcoin relies on proof of work as its core assumption, if you want, as one of its core cryptographic components. And it's reasonable to ask whether it is necessary to achieve this level of decentralization that Bitcoin has. To some degree it seems like it's quite important, but that's something that has to be challenged if we are to explore this design space. So given that our objective is to have a robust transaction ledger, let's focus a little bit and understand what is that objective. So as I mentioned, there are two properties that we're interested in, persistence and liveness. So persistence refers, and this is like a high level description of the property, that basically transactions are recorded in the ledger and when they are confirmed by one node, because that's at the centralized system, so there are many nodes that are implementing that ledger, so if you hear from a node that the certain transaction is confirmed, this transaction has been stabilized in the ledger and when this transaction is confirmed by another node, there won't be disagreement about how it has been stabilized. Stabilized here means that it has been given a specific position in the lifetime of the system and therefore once it's confirmed, all the nodes will confirm it in the same way. So persistence is just one side of the coin. Question? Right. So yeah, confirmed here is, in more general you can think of it as a certain predicate that examines the blockchain as reported by one of the nodes with respect to a certain transaction and says I feel safe that this transaction is fine, but in the case of Bitcoin it's exactly the way you said, so the transaction has a number of blocks on top of it. So persistence is only one side of the coin because it says if one node confirms, then the others will not disagree. You can think of it as a basic safety property in the language of distributed systems. But it's not a liveness property. It doesn't say that eventually the system will confirm anything. It says if it confirms, then there's no disagreement about what is confirmed. So we want also to make sure that eventually the system confirms transactions which are reported and that's what is captured by liveness. So this is the objective and now that we have this as an objective, the question is how do we implement something like that? So Bitcoin does that implementation but we can try to achieve something similar in different ways. So what is a design space? There's many choices. So to begin with we can also examine a completely centralized solution and then you can think like the problem becomes quite trivial. Like we have a database, it's one server, records transactions as they appear. It tells you they are confirmed simple. So you can think of all the solutions in this two-dimensional space where the centralization like goes to the right and performance energetically goes to the top. So it's straightforward that if you have a centralized database, that's basically as efficient you might hope you can be. Like there's only one node, there's nothing to disagree, there's nothing to communicate. This is going to be the maximum throughput that you can get. Of course you can parallelize it, you can do like many things to it but it's a single point basically. So that's like quite high on this dimension and clearly it's well very low on the decentralization dimension. There's no decentralization at all. So then there is a very vast class of protocols that you can think that you can use here and these are these Byzantine agreement protocols that there is a very extensive literature in distributed systems that studies that problem. So the Byzantine agreement literature has protocols that operate typically under the following conditions. You have a set of nodes which either they have authenticated channels with each other or they belong to an identity infrastructure so there is a PKI, they can issue signatures and they can communicate with each other either via broadcast or point-to-point channels. So you can think of this as a static decentralized setting. Set of nodes sending messages to each other with the objective to reach consensus about let's say what happened and you can certainly solve that robust transaction ledger using a series of Byzantine agreement instances for the transactions that are emitted by the users of the system. Clearly this is more decentralized than having a centralized database and well it's also less efficient. These protocols they do require some substantial effort in order to produce a unique view among the servers because and these have to be stressed here these protocols are assumed to operate in the presence of an adversary that tries to subvert the joint view of the servers. Now where does Bitcoin fit in that? Well Bitcoin is very decentralized in the sense that it does not even require an identity infrastructure of any kind. So anyone can be a node of the Bitcoin system as long as they open their computer and download the client. So the only thing that they have to agree is on an initial starting position the Genesis block and once they have this initial starting position they can start contributing to the system without any introduction or help or joining procedure to the system. So it's a completely open system very decentralized therefore but not efficient not good in the performance direction. So what's interesting here is to ask like what is there in the upper right corner if anything at all? Is it feasible to get something which approximates the performance that you would get from let's say business agreement or centralized databases but is as decentralized as Bitcoin or at least close to being as decentralized. So this is the motivation and exploring this design space is one of the very interesting open questions in the greater blockchain research area. So this motivates proof of stake. Proof of stake is a class of consensus protocols that attempt to fit exactly in this design space territory which had the question mark in the previous slide. So how to understand how proof of stake works? So generating the next block in Bitcoin is like an election. So you can think that the way Bitcoin works there is basically a lottery in one of the entities that are running the protocol is elected to issue the block with a probability which is proportional to its has in power. Because it is decentralized collisions may happen but that's why the way the Bitcoin system works is that it obeys a longest chain rule where longest here is to be interpreted in a broad way. So what is longest might actually be different depending on how you instantiate how you analyze this. But essentially there is a way to select the best chain out of those that are available and having this chain selection rule enables parties to converge to one unique joint history. So with this as a starting point if Bitcoin what it does is essentially a randomized election for picking the next candidate that is eligible to produce a block maybe we can do it differently if that's the logic. So here is how proof of stake the main idea behind proof of stake. Instead of actually thinking of hashing power how about we just use the amount of stake that a certain stakeholder has as it is reported in the blockchain itself. Here this uses the observation that hashing power is something that you would buy with money and now let's assume that all the money there is is what you have in the blockchain itself. So therefore we can quote unquote cut the middle man cut the middle entity here and just read directly refer to the amount of stake that you have in the system as it is reported in the blockchain itself. So instead of thinking of the entities that are in the protocol as the miners these are the stakeholders which are reported in the ledger and then now we need the randomized process that will take the current stake and elect the next miner which is able to produce a block. So basically you put it in this point of view proof of stake is quite decentralized is more decentralized than business agreement protocols because it allows the set of stakeholders responsible for running the protocol to shift arbitrarily as the system evolves. So this is not a static system it's a system that when it starts from a certain point it might this initial point might lead to other states and eventually the set of nodes that share the responsibility for running the protocol can be completely disjoint to the set of nodes that started the system and furthermore it has the capability at least in theory to be vastly more efficient than what Bitcoin is because there is absolutely no need to employ proof of work in order to perform this procedure. You can invoke standard cryptographic tools to perform that leader election process at least again in principle so the network can actually run at the maximum synchronization speed that can be allowed whereas in the case of Bitcoin it is clear that the role of proof of work interacts with the network synchronization speed and should be sufficiently hard to enable the parties to synchronize their joint views. At least that's the hope and based on these hopes since as early as 2011 an array of systems were proposed in the same tradition as Bitcoin that attempted to take the ideas I just mentioned and implement them into something that works and there is a number of blockchain systems that are based on proof of stake and I cite here a few of them that used essentially the same ideas Peercoin and Next are two examples which were quite prominent and the concept was that you have an eligibility function that determines the next stakeholder to issue a block and this is what is based on the current view that every stakeholder has and then the level of the stakeholder possesses will calibrate the eligibility threshold so if you have a higher stake you have a higher probability of being eligible for issuing the next block and that in a sense would parallel the way Bitcoin works if you have more hashing power you're more likely to be the one that will issue the next block so there were very few principled approach of how to design it one which is worth mentioning is by Bent of Gabisol and Nisrahi who identified the issue in previous solutions that the random selection process is something that can be subject to attack and having a way to do this without bias should be an important design consideration they suggested using collective coin flipping to do that without actually providing though a security analysis of their solution so the current state of things that motivated our work in this protocol which I will be presenting to you today was that while there were many interesting ideas about how proof of stake protocols should be designed we had a big array of attacks that were identified by the community and it was very unclear how could a protocol withstand those attacks and provide a proper transaction ledger some of the attacks that were considered are the ones that you see in this slide the first example is what was called the grinding attack where basically a malicious stakeholder tries to ahead of time try many different ways to finish the head of the chain that it has so that it gets an advantage this generalizes to what is being called the nothing at stake attack where contrary to Bitcoin in the proof of stake in principle there seems to be nothing to prevent a set of malicious stakeholders to try all possible histories that a protocol might follow while it executes and they can in principle vote in all of them since they have nothing really to lose by voting in all of them contrast to Bitcoin where hashing power cannot be used in two different chains exactly because you can only apply your computational power either to one or the other so an attacker will have to choose which chain to follow and then you can have circularity problems that occur even in the case coin flipping is used and the issue here is if you want to generate fresh randomness you have to have agreement between the participants but if you are going to use the blockchain itself for agreement this creates a circularity problem you're using randomness to generate a blockchain but then the blockchain itself relies on this randomness for its security so how can you resolve this circularity argument between the coin flipping procedure the procedure that execs randomness and the blockchain that itself is being built based on that randomness so this is the state of affairs that motivated our design and I'll tell you a little bit about what is our contributions in a high level and then we can come to specific details so first of all it's a formalization of what is the proof-of-stake design challenge then a construction which is Uroboros the proof-of-stake protocol that we have designed which we designed contrary to what was followed before together with a proof-of-security that it satisfies the properties of a robust transaction ledger in a proper model and one important aspect of the proof strategy that we have is that agreement is shown to hold for a small initial segment of the system operation which then becomes, which then is violated if you let it advance but then we can show that we can use this short period of agreement to bootstrap a secure multi-party computation protocol that can produce unbiased randomness and thus concede the next segment of the protocol operation so this creates a bootstrapping opportunity that can take a short agreement opportunity which is analyzed independently in a combinatorial sense as I will show you and then you can extend that to an arbitrary amount of time by using cryptographic techniques from secure multi-party computation so this is the general design strategy and this kind of circularity that exists in this design strategy and proof is also what gave the name of the protocol which you might be aware of this Uroboros is the snake that eats its tail and it represents this circular motion that is reflected in the design and proof strategy of the protocol so let's see a little bit how the protocol works in more detail so that's the static stake setting it's that very short initial segment which I mentioned so this is how the first small period of operation that you will see in an Uroboros instance the moment the protocol starts so the protocol assumes that there is an initial set of stakeholders and an initial string of randomness which is assumed on its so this is like an initial assumption about the system which is given for free so that's if you want the genesis block and you can think of this as a common reference point that all clients have using this initial randomness there is a deterministic process that can take the randomness and determine a sequence of stakeholders weighted by stake that will be responsible for time intervals identified as slots in that initial segment so what you see here is slots which are defined as denoted by this E value for an opportunity where an election took place and that is the election leader which is assigned to that so we're going to have one stakeholder responsible for each one of those slots now this is the stakeholder that will be responsible for issuing a block during that slot and that's a stakeholder that will be responsible for issuing a block on that slot issuing a block means basically signing a set of transactions or signing the contents of the block as we will see since this what is the contents of the block is a bit more nuanced otherwise the protocol will advance like a regular blockchain in other words the contents of that block will contain a hash of the previous block and so forth issuing a block in a certain slot is not something which is mandatory or necessary for the protocol to advance slots have a specific deadline and once they have passed the protocol will move on so that means that you can have empty slots like these the actual time window that is represented by every slot should be sufficiently long so that the majority of the network can synchronize with each other and can only be experimentally determined we have done this actually experimental investigation of what is the right length of the slot using an Amazon cloud deployment of an implementation of roboros which I'll say a few words at the end and the slot configuration that worked in a geographically diverse deployment was 20 seconds so 20 seconds was enabling the overwhelming majority of stakeholders to actually converge and to actually have a message transmitted to each other so that's like the round time that you need for node 1 to send a message to node 2 for example like one of the nodes is in Brazil the other node is in Germany and there was another node in Japan and another node in the United States and 20 seconds was sufficient time for them to synchronize with each other so you have blocks produced one block in every slot they contain inputs that are determined for that block and some of the stakeholders are not present so what's important to point out is that every stakeholder is elected using the seed which is available in the Genesis block proportional to the stake so let's say if there is a stakeholder that has 100% of the stake he will be the only one which is present and selected as leader the more diverse is the stakeholder distribution the better it is for the diversity of entities that are responsible for every slot okay so now let's come to see what we want to prove about that and again I stress that in this first analysis that I say in the first part of the description of the security proof the intention is that we're going to analyze a very short segment of the system operation then we're going to apply this bootstrapping idea using secure multi-part computation which I'll come to it afterwards so let's analyze the initial segment what kind of properties do we want for this blockchain that the stakeholders are building so first we want the common prefix property which you see described here for any two rounds and two honest parties that have chain C1, C2 respectively it should hold that if you remove K blocks from the chain C1 you will find yourself in a prefix of C2 so this common prefix property is a fundamental agreement property that you would like to have from this data structure essentially that means that what the honest players build is a chain which has a big common trunk and potentially some orphaned twigs that are going left and right as this common trunk grows so this is captured by this common prefix property now common prefix doesn't tell you anything about what are the contents of that chain so this is provided by this chain quality property that says if you take the proportion of blocks in any K long subsequence the blocks that are produced by the adversaries should be less than mu times K so mu here should be some fraction that shows how many blocks were produced by an adversary in any K long segment of an honest parties chain finally chain growth which has the coefficient tau it says if you look at the chain of an honest party and you look at it at two different moments of time it has grown in terms of length by a certain amount which is this chain growth coefficient we call it tau so we will show that a robust transaction ledger is something that reduced to these basic properties if you want like double spending or something like that it will be eventually as we will show something to be prevented by the combination of those properties so for example double spending will be violating a common prefix type of attack so it will be a common prefix attack so double spending basically means that the honest parties of the system believe a certain chain at the second moment but suddenly like at another moment when you ask them they believe something else and a certain transaction has disappeared that they believed if that transaction is more than K blocks deep in the ledger and it has disappeared that will be in violation of this of this prefix condition here because you would have something that you removed K blocks from it and it's not in the prefix of C2 so basically here any type of attack that you can think of against like the ledger aspect can be reduced to an attack against one of those three properties or a combination of those properties so let's look a little bit about the common prefix property and the question is like will the honest players converge so convergence in the common prefix setting can be actually reduced in this initial segment can be reduced to a combinatorial question so and if you have completely phased out in the first part of this talk you can just like focus back in and just think about this combinatorial question it's a clean cat question which you can think about it completely independently of whatever I was talking before stake, bitcoin or anything it's just a question about strings and things that in a certain combinatorial structure that you have to build for those strings so let's understand a little bit like just this issue so take a string let's say this one and think of a tree that you can build on it that obeys to the following in the following way if you have a zero like this positions these are the honest stakeholder slots referring to the previous discussion so this is where blocks were issued by the honest stakeholders as the protocol was executing so for example like this guy created that block and that guy number five created that block once are the positions that correspond to the malicious stakeholders they can do whatever they want they can like extend different chains and they can create forks they can do whatever they want they have absolutely no obligation to follow the protocol and furthermore contrary to bitcoin they don't even have to invest effort to do expand this part of the chain or another so they can create things like that for example they can sign two blocks here they can extend this chain or they can extend that chain so here you see an example of a possible protocol run that depends on that specific string that corresponds to the slot sequence as it is divided between honest stakeholders for zero and malicious stakeholders for one so what happened was first of all like this stakeholder produced this block one which is honest then this guy malicious he came he created a fork extending this block and also this block then this guy delivered that part to this guy so this guy extended this one this guy had no clue about this one then another malicious he extended both of those he delivered this one to this honest guy who naively just produced this one he didn't know anything about the rest and so forth the only the basic thing you assume is that as the honest parties operate they follow the longest chain rule because this is how our protocol works so in particular this honest stakeholder could not have extended this particular chain or because he prefers the one that has the longest blocks so he chose this one so this is up to the delivery that is performed by the malicious parties and so forth so the question now that arises is the following if I give you a certain string like this is it possible to finish that string in a situation where a fork as wide as the string exists that's the combinatorial question so we call such strings forkable strings so these are the bad strings so whenever a string is forkable appears in the sequence of later elections we have a forking opportunity on the other hand if no such forking is feasible the fork would collapse and it was going to be only a single long chain that can appear in the sequence of those slots so is that clear at least at an intuitive level any question that you'd like to ask? Yes well yes good question the thing is that because the one in the middle it's longer indeed but it has only adversarial blocks up to here so it's strategically up to the adversary whether it wants to reveal it at that moment so therefore this chain you can think of it not necessarily as long as up to here but here or there so it's feasible for the adversary to convince this person to sign here because yes exactly he would reveal just one of them on the other hand he has to reveal this one because this was issued by an honest party so in other words this guy when he was here he would see this one because that was emitted by an honest party and this one so he would just see maybe a portion of this one at the discretion of the adversary but let's say the adversary here prefers not to use that so he hides it he chosen this one but the way we model our security models thinks of the adversary in a rushing mode so he has full control of the network so he can deliver chains in the order that it prefers that only makes it stronger so in this case he prefers to deliver this one this chain first to this stakeholder so he will choose this one as opposed to that one you can make a weaker model where let's say you can flip a coin between those two but that would just make the adversary weaker and it's unclear whether you know practice would actually support that yes longer means number of blocks and if they're equal would just let the adversary choose whichever it prefers so that gives to him only bigger power yeah yes exactly so the only thing that the adversary cannot prevent is whether there is like a chain like that which has an honest party so this one will have to be transmitted so he cannot stifle that chain so if that chain had three blocks let's say it would be infeasible so this number five would actually go there yes exactly but that would depend on whether he has a one like so it really depends on the string so if it has zeros yeah so each one is one block yeah so this is a pure combinatorial question in the sense like I give you a string what's the most complicated such tree structure you can make that's the question and specifically and a forkable string will have the property of enjoying quote-unquote two forks throughout the whole length whereas a string that has no fork it will have a single longest path that's what we prefer right the single longest path is what we prefer so for instance if you take zero zero zero zero no once at all it's just only one path I just said all zeros let's say so if it's all zeros like no malicious stakeholders then it's just one chain I mean that's well that's very unlikely let's say obviously on the other hand if you take a string that has humming weight or humming ratio let's say 50% or more like it has more ones than zeros or actually equal ones and zeros then you can easily see that you can fork it in a very straightforward manner so essentially the adversary can be completely silent up until the end and then suddenly boom get an equally long other chain but this is not bad right so in a sense we were expecting that so we were expecting that the moment we're going to hit 50% the moment the adversary controls 50% of the stake which will reflect which will translate probabilistically to a 50% humming ratio string we're going to lose security so on the other hand the all zero case it works for us we knew that as well but it won't happen right so we would like to examine the situation where some of the stakeholders are malicious and we're interested of course in the case where the stakeholders are below strictly below 50% so this becomes like a nice combinatorial a question which we have completely investigated and you can prove like first an easy statement which actually it's a nice exercise if you want to think about it suppose that you have a humming weight ratio of less than one third you can prove that there are no forkable strings like with less than one third forkable means that you can find it is three structure and you're going to have at least two we call them times at least two of those threads that are string as wide as the string whereas the compliment like not forkable means that one of the times has is bigger so so eventually the honest parties will converge let's say if you wait for that long long enough so here is good like it's a kind of a nice exercise to show that it's the humming weight ratio is less than one third like you can get like no forkable strings but it's much harder to go to the setting where you are between one third and one half this requires so there you get forkable strings and their density gets higher the closer you go to 50% the moment you hit 50% then all strings are forkable so what we prove is basically that the density drops exponentially at most with minus asymptotic square root of n where n is the length of the string so basically it's negligible the amount of the density of forkable strings as you go closer to 50% and here you can also have a so what you would expect from some some negligible function like that so the closer you go here like the alright so I have another interesting discussion about covert adversaries so but I'll have to skip it I'll just go and say a few words you can define like a simpler notion of forking it's a forking that you can deny because for example like this you cannot deny right if you reveal that you signed twice to different times to different forks so if they compare notes they will know that stakeholder in that slot was actually doing something wrong so it's interesting to also ask how much you can fork in a deniable fashion and if you go to the deniable or covert fashion we can actually show a much better bound okay so this gives you a little bit of an idea about how the system works I'm going to have to I went a bit slower than what I was expecting I still have five minutes is that yeah so I'll I'll just tell you a little bit I'm going to skip forward I'm going to say maybe one minute about how this bootstrapping stage works so basically you get these stakeholders you do this procedure with the chain but now you would like to let the stake move on and repeat the process so what happens is that let's imagine you have a beacon that is going to create another random value and you can create now a stakeholder distribution not by assumption but by the blockchain itself so now you can repeat the same process on and on you get again the leader election process that's the stakeholder distribution changed according to this now you get another procedure like that the only problem here is where does this beacon coming from and this is what we can show to solve using secure multi-party computation but with a very efficient secure multi-party computation protocol the nice thing about this protocol is that we can use the blockchain itself as the broadcast channel over which we can run secure multi-party computation I'm not going to go to the details of this because we're a bit out of time we'll be happy to discuss with them after the talk I'll just say a little bit about the incentive structure so how do incentivize parties to execute the protocol so in order to do that we have a concept that we call input endorsement so inputs in the case of a blockchain that is used for transaction ledger is sets of transactions they have to be endorsed to go to the blockchain so this is the idea that we use and I will explain why this is a good thing so a sequence of transactions need to be endorsed to be included in a block the input endorser is associated with every slot in the same way as the leader of the slot is associated with the slot however an endorsed input an endorsed sequence of transactions can be included in the ledger in any upcoming block up to 2K slots in the future and this is an essential aspect in our equilibrium proof so these are the assumptions we do about protocol costs that issuing blocks is easy but it is expensive to run the secure multiparty computation protocol and it is expensive to endorse transactions because you need to verify them so these are the expensive actions so we're going to assume that this is like almost negligible and we would like to incentivize for those actions so you have to be rewarded for those so based on that we have a reward mechanism which is very different from bitcoin which operates only at epoch levels and then it provides rewards to parties for being a committee member committee is the parties that run the secure multiparty computation protocol and endorsing a set of inputs and sending messages for the NPC protocol so they get like rewards which are given to them in proportion to how much they participate in terms of endorsing and sending messages for the multiparty computation protocol so based on this reward function we can prove that the protocol itself is an approximate Nash equilibrium so and that's in contrast to bitcoin where we know that the protocol it's not an equilibrium the proof essentially the way it works is that it considers a coalition of rational players that deviates from the protocol specification in some arbitrary way and it proves that no matter what they do our properties of chain quality, common prefix and chain growth essentially but most importantly chain quality ensures that the parties that are following the protocol will be guaranteed to have all their messages which produce rewards included in the blockchain therefore their rewards will not be affected by the arbitrary deviation of the malicious coalition that means eventually that the malicious coalition might get an advantage but that advantage is bounded and hence we have an approximate Nash equilibrium and the level of approximation is something that can be calibrated in the parameterization of the protocol is that the coalition should be less than 50% of the stake and otherwise this whole proof will not work I have more stuff to tell you about delegation and online codes and our implementation as well as performance comparison but we will have to leave that for another opportunity so thank you very much for giving the opportunity to talk about this protocol I'd like to finish with an advertisement about PSD and postdoc positions which are now available we have a number of positions open at the University of Edinburgh and if you are interested about working blockchain and you would like to do more work in this domain go check my website where you find an announcement for positions for PSD and postdocs thank you