 All right, welcome. So I'm Aguilos Kajas, chief scientist at IOHK, and chairing cybersecurity and privacy here at the University of Edinburgh. So today, the topic of our discussion is going to be proof of stake protocols and more widely, blockchain protocols. How do you design them? How do you prove them secure? So to get us started, I'd like to do a little bit about cryptographic design in general. Like, how does a cryptographer think when they go about designing a security protocol like a blockchain protocol? So let's get to that. So first, we have an objective, and that objective would be something that we would like to do. So that could be, for example, designing a ledger like a blockchain protocol tries to solve, or it could be something else, like a component, like digital signature. So given that objective, and I'll come to describe a bit later how it's possible to specify that objective specifically, we have two other things we have to determine. Like, the next thing is the resources that are available to the parties that are going to be running the protocol, or to the parties that are going to be using an algorithm to meet the objective. And together with the resources, we have to design and describe a threat model. Now these two, they come hand in hand. So the resources would be things that when we write our algorithm, the parties that are using the algorithm are going to have them available. And the threat model would describe what the adversary is allowed and what is not allowed to do. In order to come up with a good threat model, we would have to think exactly what is going to happen when our algorithm is going to be deployed in the real world. And we would like the threat model to completely capture what is going to be happening. Now, given these two then, comes an algorithm or a protocol. So the algorithm or the protocol will be code or a specification for code that uses the resources available and meets the objective given the threat model. Now, this is what we hope that is going to work. Now, what we would like is actually to prove formally that this is the case. Now, typically, this will also involve some other assumptions. And these assumptions could be things that we do believe they're true about the world. For instance, a common assumption that is used in cryptography is that certain computational problems like the well-known discrete logarithm problem is a difficult problem to solve. So these would be the assumptions, let's say, mathematical frequently in nature that we're going to assume when we argue that our protocol or algorithm meets the objective. And finally, given all that, we will have a proof. And that security proof is going to establish that the algorithm meets the objective given the resources in the threat model that we have specified under the assumptions that we have described. So this is the general logic that we use in modern cryptography to argue that protocols are secure. We design them following this logic. And designing of the protocols is actually following a feedback between those. So sometimes we have to revisit the resources that are available. Sometimes we have to revisit the threat model. Then we have to fine tune the algorithm, look at the proof, and then again. Because frequently, things won't be exactly in the way that they are appropriate for a security proof to emerge. The final objective is that this should be solid. And then once we have this, the algorithm and the protocol will be specified and implemented. Now going a step further, we have from the algorithm protocol, we have a specification emerging. And then given that specification, we have the implementation. So this gives a greater picture. So let's see how this can be put in practice. We can see how we can apply this logic to the design of a distributed ledger. So what is the objective in the case of a ledger is something that, let's call it a distributed ledger. We need some more space to describe now what a ledger is. We should not think of a ledger as something tight necessary to the blockchain protocol itself. This is an important point to keep in mind. The blockchain protocol will come as a solution to the ledger problem. So to have a ledger, we need two things, persistence and liveness. These are the two basic properties. These two properties, they do refer to a log of transactions. Persistence is a type of safety property. It basically says that the view of the log of transactions is stable. If you ask any node that is implementing the ledger will give you the same version of the log. And that also should hold true over a period of time. So if you ask today, what is the log? The log that you will find tomorrow will be an extension of the log that you heard yesterday. So this is captured by persistence and it's possible to define this in a mathematically precise fashion. Persistence is not enough. What we also need is that the ledger, the log of transactions, is populated by transactions which are emitted by those that use the log. So liveness basically says that new transactions are added at regular frequency and at minimum there is an upper bound, after which a transaction which is sent to the nodes that are implementing the ledger will be included in the log. So these are the two cornerstone properties of what is the objective of a distributed ledger. So now let's go and see how we can implement that. So we have to talk about resources and we have to talk about the threat model. Let's talk about resources first. So the resources available would be first that parties have private memory and they have the ability to sample random strings. These are important resources for the design of the protocol and in many cases, and these are typical I should say in cryptographic design. So it's typical in cryptographic design that we think that a computer system which we might call it a party for simplicity in the context of a protocol, it has its own memory that only itself can access it and it has the ability to sample randomness and that randomness it's only its own is not shared with other parties. Now this sampling of randomness should also be private in the sense that an attacker from outside should not be able to subvert the randomness of a party. So this is the first important resource. So another resource should be access to a network that is relatively synchronized. Let's call it like this. So basically this says that when a party wants to send a message, access to the network is facilitated and in a relatively synchronous fashion that message is going to reach the other parties. All right and this next would describe now the threat model. Now in the threat model we would like to specify what the adversary is capable of doing. So the adversary should control a number of parties. Now we have to put a bound on how many parties the adversary should control and now depending on the setting we will adjust this bound so that it fits the type of design we would like to make. Now for instance in the proof of work setting let's say as in bitcoin the bound on the number of parts the adversary controls is that it should restrict the adversary to be the minority of the total hashing power which is available to the network. In the case of a proof of stake protocol in contrast we would like the bound to restrict the adversary to the minority of the stake that is recorded in the ledger. So this also provides the threat model. Now with that let's see what would be the solution. Let's make a contrast between the two. Proof of work, proof of stake. In a proof of work setting what we have is that the parties they're going to be communicating with each other solving proof of work and exchanging blocks that will record whatever they want to include in the ledger. So what's happening is that in a proof of work based solution for a ledger like that of bitcoin you have a genesis block which then is extended by parties as they find proof of work. Each of these blocks is a proof of work and inside here you have a number of transactions. In the proof of stake case something similar is happening you have again a sequence of blocks it's one of them has transactions but what you have inside producing its block requires a proof of stake. Let's see the difference between the two. Producing a proof of work requires parties to solve a moderately hard cryptographic equation or inequality specifically in the case of bitcoin. So you can think of the whole protocol operating as an election at any given moment one of the parties is elected to produce the next block and the next block is going to be produced basically at random it's a random sampling by those that are attempting to produce the block. In proof of stake what happens is a similar type of operation in a proof of stake setting the next block is elected by is produced by one of the stakeholders at random based on the stake that is recorded in the blockchain. So what we have in both cases is an election that points to the next eligible party to issue a block. The nature of that election is different in the case of proof of work and let's make it now more specific Bitcoin what we have is that the election is based on solving this moderately hard problem specified by the Bitcoin client let's make it more specific for proof of stake in the case of Uroboros what we have is that the election is based on a cryptographic protocol that creates randomness and stores it in the blockchain. In both cases though the high level logic is similar there's this election process that will enable one of the parties to issue a next block. So this is the central idea that typifies how these blockchain protocols work something it's interesting to point out is a different assumption that happens with respect to the Genesis block. So both protocols have as a requirement to provide parties a Genesis block that they can use as a point of reference of what is the blockchain what is the correct blockchain and that point of reference in the case of Bitcoin specifies just the initial block and that's the initial block plus a setting the difficulty level so the difficulty level is stored in the Genesis block of Bitcoin and here we have an initial stakeholder distribution. So in both cases there is going to be an assumption about the Genesis block so the Genesis block should know something about the status of the world when the blockchain is initiated. In the case of Bitcoin you should hit the right level of difficulty that reflects how many parties will be producing blocks when the blockchain starts and similarly the Genesis they call distribution should be a distribution that has been preset and coded into the Genesis block of the proof-of-stake protocol. In both cases the assumption would be that there must be an honest majority honest majority of stakeholders here honest majority of hashing power here. So this is how the protocols now compare. Now let's look at how do we prove that these protocols are secure and under what assumptions and what arguments the two protocols might be argued to be secure. So let's come now to the proof-of-security. How do we argue that blockchain protocols are secure and again I'm going to make a contrast between a proof-of-war protocol like Bitcoin and a proof-of-stake protocol like Uroboros. So in the case of Bitcoin the logic basically is as follows. What you have in the protocol operation is that multiple blockchains coexist. The reason for that is that parties first of all naturally fork they're not synchronized they're not coordinated they don't do they don't run this protocol in a coordinated fashion so you can have many forks that are naturally emerging. So the same situation will be happening in a proof-of-stake setting I should say. So the two protocols kind of have the same logic in terms of resolving these forks the parties do follow the longest chain. Now the definition of longest is slightly different between the two but let's say in simple terms the proof-of-work based blockchain will follow the chain that has the biggest amount of difficulty or if you want the most amount of blocks if difficulty is fixed for a certain part of the execution and here you will have follow the blockchain with a most amount of stake again the most amount of blocks. So a similar rule in both cases but let's see how this is going to be reflected in the security arguments. Now what happens in proof-of-work is that because solving a block is a moderately hard problem there's going to be these moments here is such a moment where a block is produced uniquely by a single honest party. So in the analysis of the Bitcoin blockchain protocol this has been called a uniquely successful round. So basically it's a period of time where just a single honest party was successful. Now something very interesting happens with those rounds which are uniquely successful and if you look at the protocol execution what is happening is that if such a round happens the block that is produced by the honest party will be adopted by all other honest parties unless and only unless the adversary acts and issues another block that confuses the honest parties and splits them. So the cornerstone of the analysis of the proof-of-work based Bitcoin protocol marking Bitcoin this side again is that the rate of uniquely successful rounds should be bigger than the rate of blocks produced by the adversary and if that is ensured then you can show that the adversary will not be able to maintain what is known as a fork. So this is something that will enable us to prove persistence. So persistence will be implied by this inability of the adversary to maintain a long fork. Now long fork here is relevant and is because it's important to think of a fork over a period of time small forks will occur but eventually over a sufficiently long period a number of such uniquely successful round will occur that will overcome the number of blocks that are produced by the adversary and because the adversary has too much each and all of them it's one of them then he will be unable to and thus the fork will collapse. So this is the central security argument that we used in the backbone paper to establish that the bitcoin blockchain protocol is secure. Now this proof logic is tempting for someone to use it in the proof-of-stake setting. Now unfortunately what I'll show you now is that this is not feasible. The main problem in the proof-of-stake setting which you have a similar situation like that can be illustrated with the following example. So imagine you have a fork that somehow starts from here and there are let's say honest parties being acting here and here you have an adversary who is elected to produce the next block. In the case of Uroboros but also similar in other protocols what is going to happen is that the adversary by being elected to issue the next block he's capable of adding this block in more than one potential blockchain. So he's getting somehow the ability to use the fact that he's elected more than once and this spoils the counting argument that make that security proof go through. This is also consistent with our understanding that proof-of-stake protocols they are more difficult to argue security for and it's correlated with problems that the blockchain community has identified like nothing at stake. Which basically means that it costs really nothing for the adversary to produce blocks in multiple possible histories of the protocol and that's exactly the point that spoils the security argument here. But now the question is that is that the end? Is it just fundamentally impossible to argue that a simple protocol like Uroboros is capable to be proven secure? And the answer is no we can actually produce a proof-of-security we just have to work a little bit harder. So let's see a little bit what is going to make visible the security proof in the case of a proof-of-stake protocol like Uroboros. All right so let's take a kind of deeper dive and see how a Uroboros execution looks like. Let's take an execution segment segment of an execution in the Uroboros protocol. So what's happening is that multiple we can start from this block and there is a potential like multiple blocks may coexist and multiple change. So some of these blocks are produced by the adversary. So here is the adversary that has produced these blocks. Now the reason the adversary is in control of these blocks is that he was elected at that moment and as you see he used the liberty he has to issue multiple blocks for the same position. So this is how the protocol execution looks like. At that particular moment you can imagine that you are the next party to act in the protocol. So here we have a good guy that he comes to do his part and execute the next step in the protocol. So the last honest block that was produced was here and here we have the adversary who is together with that chain which was produced by another honest party. He also has at his disposal other blockchains that it can serve to that party. In the security analysis of Uroboros we assume that the adversary is in full control of the network and it can order messages at the way that he prefers. Thus if he is capable of adding more blocks to that blockchain here it will be feasible for the adversary to serve that blockchain to that party. So for instance imagine that it's possible for the adversary to add three more blocks here. Now that chain becomes more preferable for that party because the adversary can arrange for that blockchain to be served first and that party is using the simple longest chain rule in order to produce the next block. So in that particular case the adversary has the ability to serve that blockchain to that party and the next block that is going to be produced is going to be here. On the other hand the adversary could have selected to serve that blockchain first. Again he's in control of the network. So this situation is not a very desirable situation for Uroboros. The fact of the matter is that the adversary has full control of what blockchain to serve to the party and what we are experiencing here is a fork. Now we would like to argue that this undesirable situation happens with very small probability so the adversary really cannot count on it. So the way that we're going to argue for this is to try to understand what are the fundamental features of that structure as they emerge in the protocol execution. So each one of these threads that you see here we call them tines. So here is a time one and here is time two. Okay so here we have the situation with two times that the adversary can exploit to confuse the honest party that is activated and runs the protocol. So this is the setting that we would like to avoid and here is the one that we hope it happens most of the time. So most of the time what we hope in the protocol that is happening is that the protocol execution starting from here has a single long time and furthermore any other disjoint tines that exist are too short for the adversary to be able to reach the leading one. So basically this is an execution segment that provides the opportunity for the honest parties to adopt using the longest chain rule that block and in consequence that chain. So this is a good situation and we would like to show that this happens almost all the time. Now in order to be able to argue that what is going to happen is that we have to understand the dynamics of this execution segment and how they are translated into this set of tines. So what we observe is that it's possible to define a certain quantity which we're going to call reach that is going to specify for any execution segment how far ahead for each time the adversary can go with respect to the last block that was issued by an honest party. So in this case that's the last block that was issued by an honest party and perhaps the adversary can have one more block here so the reach of that time is going to be one whereas here the reach of these other tines is negative. So reach, negative, negative and positive. So what we observe when we look at an execution segment is that the maximum reach will always be greater or equal zero there is one block that is the leading one that is by an honest party and perhaps the adversary can put some blocks on top of it because he has some slots here he has some opportunities to produce blocks ahead of that and other tines will be behind hopefully. Now what we would like the picture to be is always like that with all other tines having a reach to be negative the second biggest reach we're going to call it the margin so that's the second largest reach. So if the margin is negative we know we are safe because all these other tines are too much behind and they cannot reach the leading one whereas if the margin is greater or equal zero then it's possible for one of the tines to reach that block and then we have a problem execution like the one that we've seen before the adversary can fork the next honest party and deliver to the party any chain that it wishes. So now we would like to show that the margin which is the second largest reach is always going to be negative with overwhelming probability. So how are we going to do that? So in our arsenal of analysis we will put a probabilistic argument which relates to random walks. Random walks is an area of probability which has a lot of applications in blocks and protocols. The most simple random walk is the one that is called one-dimensional random walk and those of you that are familiar with analysis of blocks and protocols or even the white paper of Nakamoto you can appreciate how that relates to basic analysis of the Bitcoin blockchain. So a random walk has in a one dimension starts from a certain point let's say zero and then flipping a coin it either moves forward or backward. Let's say that coin has a probability of coming up heads which is sum number P which is less or equal one-half and here is the coin going forward. Now with probability one minus P we go backwards. So that's a picture of a one-dimensional random walk. Questions that are relevant for random walk are the following. Suppose you start at position zero and we can ask for a certain choice of P what is the probability that you will find yourself at another position? What is possible to show for a one-dimensional random walk is the following. It's possible to divide the region in three segments let's call the middle volatile this one hot and this one cold and then you're going to take a number of steps and after you take a number of steps we will examine what region you are then you're going to take a few more steps and we're going to examine again the region we are. Now it's possible to make an argument and say that if the probability is strictly less than one-half then what happens as you observe is that the random walk will have a tendency to go left in the cold territory and that is indeed the case. We can prove that after a sequence of steps you're going to find yourself in a cold territory and once you find yourself in the cold territory it will be very unlikely that you will be able to return back to volatile or hot. What actually is going to happen is that after a number of sequences of steps you're going to find yourself in this territory and eventually escape to the left that's because the random walk has a bias to the left. The nice thing about this is that it describes a number of phenomena in the analysis of the bitcoin blocks and protocol for instance the fact that a malicious chain will fall behind of the main honest chain and its probabilistic behavior can be modeled by this random walk which is biased to the left. The cold setting is basically the setting where the system is stable because the adversary has found himself behind. This is one-dimensional a random walk unfortunately such a random walk which can be useful when you think about bitcoin cannot be useful in the analysis of Uroboros. It's too simple to capture exactly the phenomenon that the probabilistic behavior of the protocol exhibits. Instead what is interesting is that the protocol is described well by a two-dimensional random walk which I'll give you a short glimpse of. So the two quantities that are relevant in this two-dimensional random walk is margin and reach or to be precise the maximum reach that a certain execution segment has. Remember the maximum reach is going to be the reach of the time which is most ahead and the margin is going to be the second time which we would like to be of negative reach. So what we would like in this two-dimensional random walk is to show that the margin is going to escape towards minus infinity. So as in the case of bitcoin we wanted the chance of the adversary to bring back his chain comparable to the honest parties we wanted that to escape towards minus infinity in the single dimension. Here we would like the margin to go to this minus infinity in that direction because remember margin is what the adversary needs to reach the honest parties that are producing blocks at the head of the chain. Unfortunately the relationship between these two parameters is more complex than a simple composition of two one-dimensional walks and what's happening actually is that the walk is a little bit like that. When you are in that domain you flip again a coin following this behavior which as you see is a one-dimensional type of behavior and given that reach is always positive what happens when you are in that position is that you just go down so like this but now what's happening once you go up should give myself just a little bit more space to show you exactly the phenomenon of this random walk. So once you go up you have again the random walk climbing up like this and as you see so far this is pretty much a simple one-dimensional behavior but once you reach that point what's happening is that the random walk gets attracted to zero so it doesn't follow the same upward path as before and you can see why this complicates the analysis what we would like is that the margin goes towards negative values minus infinity but what happens actually in the protocol is that it is possible for an attacker running against the protocol to use this x dimension which is reached to compensate for margin and maintain it at zero. The question is that is this effect sufficient to prevent this whole random walk from escaping to minus infinity and the answer is that no it's still possible to do an analysis similar to the one analysis I showed you for the simple one-dimensional random walk and that analysis basically also involves defining regions over the two-dimensional space which roughly look like that and repeating the same argument so what's happening is that here is going to be hot here is volatile and here is cold and it turns out that by setting this the areas of these regions suitably what we can show is that the same escape to infinity behavior which is favorable for the honest parties is going to happen in the same way that in the two in the one-dimensional case and this shows how is it possible to get a similar type of analysis for persistence where basically establishes the fact that honest part is converged to a single chain albeit with a more complex argument so this presentation was aimed to give you a glimpse of how security analysis of blocks and protocols is performed I showed you a contrast between Bitcoin and Uroboros inspired from the security arguments that we know for both these protocols and I contrasted both of them so that you can see both the similarity as well as the difference between the two protocols in terms of the security arguments that we use to establish that are secure the situation that comes out from all this discussion is the fact that yes we can prove both protocols being secure under different assumptions this does not affect other aspects of the protocols that are of critical importance such as the performance of the protocol or the energy footprint that this protocol has what we know is that both protocols are secure albeit as you know a proof of stake protocol is a much more efficient protocol in terms of energy consumption compared to proof of war protocol so but that on itself would be the subject of another discussion thank you very much for attending this presentation