 Hey everyone and welcome to today's Protocol Lab Research Seminar. Today we are joined by Shorbeck Deb. Shorbeck is currently a second year PhD student at the University of Washington in the Department of Electrical and Computer Engineering. Previously he worked as an industrial researcher at NEC Corporation in Japan working on the state-of-the-art signal processing modules for 5G technology. Before that he graduated from the Indian Institute of Technology in Bombay with a dual-degree bachelor's and master's in electrical engineering and completeness thesis on Frugal 5G. And today he's going to be talking to us about his work titled OSAT, Proof of Work Availability and Unpredictability Without the Work. So Shorbeck, I'm going to hand it over to you and away we go. Thank you for the introduction, thanks everyone for coming to this talk. So today I'll be talking about OSAT, which is the first provably secure proof of state blockchain protocol that achieves both dynamic availability and unpredictability. This is a joint work with my advisor, Professor Sriram Kandan from University of Washington, Seattle, and Professor David Stee from Stanford University. Here will be the flow of the talk. So we'll first go through the introduction to the problem that we try to solve in this work. Then we'll go to the protocol description of the OSAT and then we finally will understand the proof behind the security of the OSAT. Before going to the OSAT, let us understand what are the key features of Bitcoin that we try to emulate into the proof of state protocol. So Bitcoin achieves three key properties. It is secure under honest majority while guaranteeing dynamic availability and unpredictability. The question that we ask in this work is that can one design a proof of state protocol that can also achieve all these three properties or not. So before answering this question, let us understand dynamic availability and unpredictability in the context of Bitcoin and the existing proof of state protocol. Dynamic availability in Bitcoin can be best understood from the evolution of Bitcoin's total hash rate since its conception. This total hash rate that comprises of both honest and adversarial computational power in the system at any time has seen a 14 orders of magnitude change since its inception. As an indicator of its dynamic availability, the Bitcoin protocol has been continuously adding transaction to the ledger for the past 11 or 12 years. The main characteristic about Bitcoin guaranteeing dynamic availability is that it remains secure under honest majority. To be precise, consider that in the first year of the operation of the Bitcoin, all of the nodes in the system are honest. Consequently, the system evolves to give this snapshot of blockchain at the end of the first year. At the beginning of the second year, the adversary joins the system. Although the resulting adversarial hash rate is less than the honest adversarial hash rate in the second year, the second year adversarial hash rate is much higher than the first year honest hash rate. Now what the adversary can do is that it can try to rewrite history by going back in time and mining blocks for the time when it was not online and in order to overwhelm the existing public canonical chain. However, in Bitcoin, the probability of mining block is directly proportional to the computational power. So the canonical chain also evolves in that time and so the adversary will never be able to rewrite the history and able to catch up with the canonical chain. Thus, it is safe for Bitcoin to guarantee dynamic availability to all nodes to be able to join the system irrespective of whether that node is honest or adversarial. Now the question we ask is that whether a proof-of-stake protocol can also guarantee the same or not. Let us first see how existing proof-of-stake protocols try to answer it. In the context of dynamic availability in proof-of-stake protocols, the sleepy model of consensus like sleepy model of consensus of snow, white and auroboral genesis, they have used longest chain protocol in an attempt to guarantee dynamic availability. However, without careful design, the longest chain protocols in proof-of-stake are vulnerable to costless simulation attacks. Let us see how this costless simulation attack works. Similar as before, consider that the adversary joins the network in the beginning of the second year. And although the adversarial stake is less than the honest stake in the second year, the second-year adversarial stake is still higher than the first-year honest stake. Now the adversary can use its second-year stake to almost instantaneously participate in the past lottery to win blocks all the way back to the genesis and then grow a chain there from the genesis that surpasses the current longest chain. So this is possible in proof-of-stake protocol because there is no notion of arrow of time in proof-of-stake protocol. In contrasting Bitcoin, each node had to do some computational work to propose blocks and that imbued a notion of arrow of time in the system. So due to the absence of this notion of arrow of time in proof-of-stake protocols, this costless simulation attack is possible wherein a newly joined node not only increased the current adversarial stake but effectively increased the past online adversarial stake as well. I'd like to point out that even using verifiable random function is not enough to get a different against this kind of costless simulation attack. So sleepy model of consensus and autoborals genesis have sidestepped this attack by assuming that the adversarial stake is constant while honest stake can vary. In context of Bitcoin, this will be akin to assuming that the adversarial mining power is fixed at genesis. There's a question of whether a proof-of-stake protocol can guarantee dynamic availability just like in Bitcoin or not is left unanswered. As for unpredictability in Bitcoin, due to proof-of-work mining, no node including itself can predict when a node will be able to mine a block. For illustration, consider this blockchain in the Bitcoin. In Bitcoin, for mining the next block, a node has to keep trying different non-tests until the proof-of-work puzzle is satisfied. However, the node does not know when will it satisfy the puzzle. Neither does some adversarial node can predict when this node will be able to mine a block. Only after the node finally satisfies the puzzle does everyone know that the node has been able to mine a block. Thus, the Bitcoin mining process is totally unpredictable. For proof-of-stake protocol, commenting about unpredictability is a bit more complicated. If a nice proof-of-stake puzzle like hash function is used for determining the winner of the lottery, then everyone can predict who wins when. This makes the system vulnerable to bribery attacks. On the other hand, if more sophisticated puzzles like a verifiable random function is used as consistent with many of these papers, then no one can predict who wins except the winner itself. However, now an adversarial node can advertise its prospects of winning in the future lotteries in some black market. The Bitcoin-like unpredictability is still elusive in proof-of-stake protocols. The main contribution of our work is that we present POSET, the first proof-of-stake protocols that guarantee both proof-of-work style dynamic availability and proof-of-work style unpredictability while being provably secure under honest majority. Let's go through the protocol description of this one. In order to achieve dynamic availability and unpredictability in POSET, we use verifiable delay functions for conducting the lottery. So what is this verifiable delay function or VDF as it's called in short? It's a tuple of three functions, the setup function, the eval function and the verify function. There are two key properties that motivated us to consider VDF for the purpose of conducting the leader election. Computing eval function of VDF even with parallel processes takes at best linear time and no less than that. However, the verification of the work done in computing the eval function can be done blazingly fast in polylevel. With these two properties, it ensures that the VDF computation is not costlessly computable. It gives an unpredictable randomness decal. Now let us see how POSET uses this VDF. For this, let us first recall the proof-of-work mining in Bitcoin. Consider this blockchain. Suppose a new node at the tip of the blockchain is received at a node. Under proof-of-work, a node will select a nonce at random. This nonce will be used to check whether the proof-of-work puzzle is satisfied or not. If no, then a node will select another nonce at random. If yes, if the proof-of-work puzzle is satisfied, then the node is able to append a block at the tip of the blockchain. In POSET, instead of proof-of-work puzzle, we use a VDF puzzle that is constructed from the eval function of the VDF. Now when a block is received, a non-source of randomness ran-source is extracted from the block and check whether the VDF puzzle is difficultly satisfied or not for this updated ran-source. If the POSET puzzle is not satisfied, then the updated ran-source is sent again to the VDF puzzle. If yes, then the block is proposed and the updated ran-source is embedded in that block. The actual eval function of VDF that is used in conducting the lottery to propose the next block follows this iterative template. To summarize, in POSET, for conducting the lottery to propose a block, the randomness embedded in the parent block is used as the source of randomness. In order to propose the first block after the genesis, the node will use the randomness RLG embedded in the genesis block to compute the eval function and a winner will embed the updated randomness RS1 into that block. Similarly, for proposing the second block, the nodes will use the randomness RS1 embedded in the block 1 to compute the eval function for proposing block 2 and so on. However, this block-by-block update of a source of randomness gives an adversary many more random chances, independent random chances, to increase the growth rate of the private adversarial chain. To concrete this intuition, consider an adversary that is trying to create a longer private fork from the genesis. As each block offers an independent source of randomness and due to nothing at stake phenomenon, the adversary will grind on all the blocks from the public canonical chain by the parallel execution of multiple verifiable delay functions. So as expected, the growth rate of the longest chain is directly proportional to the honest state. However, the growth rate of the adversarial tree, instead of being just proportional to the adversarial state, it is amplified by a factor E. So extrapolating this nothing at stake attack that leverages this block-by-block update of randomness, the adversary can grow trees on all blocks in the honest chain, with each of them having an amplification factor E on their growth rate. For the adversarial trees that are far from the tip of the longest chain, they are less likely to catch up with the public canonical chain. But the trees that are close by, they are more likely to catch up due to randomness. So this looks scary as it seems like that the adversary would always succeed in this private adversarial attack. However, the good news is that for adversarial stake fraction beta less than 1 by 1 plus E, if one waits for a sufficiently long time, one can find this special green block in the longest chain such that with high probability, no adversarial tree starting from any of its ancestral blocks would be able to catch up with the longest chain containing this green block. Thus going forward, this green block will always be present in the prefix of the longest chain. Such a phenomenon is called as convergence in the literature. So for adversarial stake fraction beta less than 1 by 1 plus E, with block-by-block update of source of randomness, poset is secured against private attack. However, bitcoin is secured against private attack for all beta less than half. So as we are trying to replicate the properties of bitcoin in proof of stake, the obvious question would be whether we can push the security threshold for poset to 1 half or not. This would make this will make poset guarantee similar security as bitcoin. To do so, the natural question step would be can we have a less frequent update of randomness that can push the security threshold against private attack to poset half or not? So we find out that the answer is yes. So with less frequent update of source of randomness, the source of randomness required for computing the eval function of BDF for proposing the next block is updated once every seed for illustration. Consider this blockchain with resulting randomness from the computation of eval functions for each block being also depicted. Consider epoch of C consecutive blocks, then under the idea of less frequent update of the source of randomness, the randomness embedded in the genesis block is used as source randomness for computing the eval function for each block in epoch 1. For blocks in epochs 2, the randomness embedded in the last block of the epoch 1 is used as source randomness and so on. This changes the modest opportunity for how any node, any new node can join the system. So now assuming that all the VDS are of the same speed, if an honest load joins at the middle of the epoch, it would never be able to participate in the evolution of the system as its BDF will be always lagging behind the VDS for the existing nodes. So any new node has to wait until the end of the current epoch and then they can start participating in the evolution of the system. So now by controlling how frequently the source of randomness is updated, that is by tuning the value of C, one can control the amplification factor phi C of the growth rate of the adversarial tree. For instance, for C equals to 1, we go back to our original case of updating source of randomness in every block, which gives the highest amplification factor. For C equals to 2, the amplification factor is decreased. For C equals to 3, the amplification factor is decreased even further. We show that the amplification factor is a decreasing function on C. Eventually for C tending to infinity, we have amplification factor approach 1, which is also the case in bitcoin. So now the question is that with randomness being fixed for C epochs, is unpredictability even possible or not? The short answer is in post-site with its careful design, it still retains its unpredictability. Let's understand how. Consider this to be the state of the blockchain with RS0 being the randomness embedded in the last block of the epoch. Now, after receiving this last block, any node will start evaluating the eval function of VDF with RS0 being the source of randomness. The VDF guarantees that the unpredictability when this node will be able to become the winner of the lottery. Suppose that the node is able to win the lottery and propose a block with randomness RS1 embedded in it. Now this node will start evaluating the eval function of VDF with RS1 being the new source of randomness. So this new computation can be thought of as a continuation of the computation that has been done since the beginning of the epoch. Again, the randomness in VDF guarantees unpredictability when this node can win the next lottery. Incorporating all these design choices, we finally present the main theorem that guarantees security for posets while ensuring dynamic availability and unpredictability. So for some time t, consider all those on a stake that have been online in the system since at least time t minus bit theta c. Represent them by lambda f ct. We assume that this lambda f ct is upper bounded by lambda max, which is a valid assumption in the poop of stake system. Let lambda at be all adversarial stake online at time t. Let delta be the network delay. Then if this condition is satisfied, this big condition is satisfied, then we can show that the poor poset is secure against the private adversarial attacks. I'd like to point out that using proof techniques from everything is a waste paper, like the techniques like block tree partitioning and Nakamoto blocks would provide a security proof that shows that this security theorem holds true for all spectrum of attacks and not just private adversarial that we have discussed in the previous slide. So let us see how to prove this security theorem for all attacks. In order to prove the security of poset, a series of four system transformations are done in such a manner, so that if the system at the end of the fourth transformation is secure with high probability, then the original system that is poset is also secure with high probability. With the system at the fourth transformation, it is much easier to analyze the security using tools based on branching random box from everything is a waste paper. So the first system transformation is important for incorporating all possible adversarial attack and not just the private adversarial attack. To appreciate it, we start with the simple scenario of private adversarial attack. Consider this public canonical chain, but each of the blocks have been made by honest tools. Let us consider this on one is block H1 and see how private adversarial attack against this block works. Under private adversarial attack, the adversarial nodes would only make private adversarial chain from one of the ancestral blocks of H1 and make it public once it becomes longer than the canonical public chain. At this point, this adversarial chain would become the public canonical chain. This affects the liveness and the persistence of transaction in the block H1. Due to nothing at stake, the adversarial nodes can mine many more private adversarial chain. In order to show that the system remains secure, that its block H1 is persistent and life, it is clear that one has to evaluate the growth of the canonical chain and all possible adversarial or private adversarial chains and show that the canonical honest chain always grows at a faster rate than all private adversarial chains for all time. However, in reality, the blockchain is a mixture of blocks mined by adversarial and honest nodes. There is forking going on among honest blocks due to latency and some of the adversarial could be public. Some of the adversarial blocks might be private, so we need a clean way to evaluate this growth rate of the adversarial trees and honest blocks. This is where the first system transformation comes into the picture. For this transformation, we consider an hypothetical omnipresent viewer who is able to see all block mining, honest or adversarial, without any network latency with a global clock in hand. Assume this time axis of the global clock which starts at time 0. The genesis block is considered to be honest and it's put into this fictitious system dying 1 at the beginning. Suppose the next honest block H2 was mined after a time that is more than the network latency delta away from the previous honest block H1. So in this case, we append this block H2 to the fictitious honest chain in the system dying 1. Similarly, for this block H3, which has been mined more than network latency delta away from the block H2. On the other hand, if this honest block H, if an honest block is made less than network latency delta away from this previous honest block H3, then it is put in the same level as the previous honest block in this fictitious system dying 1. As for the adversarial blocks, all adversarial blocks that are reachable from the honest block H1 without going to another honest block is put as an adversarial tree rooted in the block H1. So similarly for this adversarial block on the left hand side, which is reachable from the honest block H2 without going to any other honest block is put as an adversarial tree rooted in the block H2 in this fictitious system dying 1. So now this view resembles the system view in the simple scenario of the private adversarial attack. So let us see what do we get from this system transformation. Consider this fictitious honest chain in the dying 1 system. Consider this honest block J and consider this to be the depth of the fictitious chain going through this fictitious chain going through this honest block J in dying T. Suppose these are the lengths of the all the adversarial trees rooted in the ancestral blocks of the block J at dying T. Then this block green block J is called Nakamoto block. If the depth of the honest fictitious chain is longer than the than all adversarial trees rooted in the previous honest blocks for all dying T, presence of Nakamoto block in the fictitious system indicates that the prefix of the block J in the original system denoted here this prefix denoted by the CJ will persist in the canonical chain for all dying T. Therefore, for any time T and for sufficiently long interval length S, we want to show that under some conditions, there exists a Nakamoto block within this interval with high probability. That would imply that there will be frequent occurrence of Nakamoto blocks, which would indicate the liveness in the original system. So using remaining system transformation, we want to show we show that the probability of non-existence of Nakamoto block in in a sufficiently long interval at any time T is negligible. So the second system transformation removes the mining leg. Let us understand what is this mining leg. Consider this fictitious honest chain at some time T. If a new node joins the system, it cannot participate in the evolution of the honest chain immediately, as we discussed before in the FORSET protocol. So it has to wait until the end of the current evoke epoch to be able to participate. That implies that the honest take that participates in mining remains constant within the epochs. And any analysis would have to take into consideration this timing random variable. This leads to the complexity in the analysis. So Dying II system removes this dependency. In Dying II system, the honest take can participate in the evolution of the honest chain if they had been active since at least certain sigma c times. We show that the probability that there exists no Nakamoto block within the interval of length f in Dying I system is closely approximated by that in system Dying II. For the third transformation, we go from a dynamic system to a static system. So again, consider this snapshot of the Dying II system. Observe that in Dying II system, honest take that can participate in evolution of the system can vary with time. Similarly, the adversarial state that can participate in the evolution of system can also vary with time. This time varying nature of the state makes the analysis complicated. However, having a constant stake over the system's clock would make the analysis much more simpler. As has been done in the original, everything is a waste paper. So we have a new fictitious system as 0 to do that. Given that we have this constraint on the relationship between the adversarial and honest take, we assume that the adversarial stake is at its maximum. We pick a certain positive number lambda h and evaluate a function alpha t. This alpha t would become the local clock for this fictitious system SS0 with respect to the local clock of the Dying II system. Now in SS0, we have constant adversarial stake from the perspective of the local clock of SS0. So this graph shows the local clock of SS0 with respect to the local clock of Dying II system. Now both the adversarial stake and the honest stake are constant. So we show that in this transformation, the probability of the non-existence of Nakamoto block within an interval of length s in Dying II system is less than that in the static system SS0. In this final transformation, we upgrade the adversary by giving it additional powers. Let us understand why we need to take that step. Consider this state of the system SS0 with its honest chain and adversarial trees rooted in blocks f0 and h1. Observe that the depth of these adversarial trees at any time are dependent on the location of the root block on the chain, especially due to the randomness grinding, which it can only do at the epoch ending. We can have easier analysis of the non-existence on Nakamoto block if the height of the adversarial trees are independent of the location of the root on its block. So in this new system SS1, we featured a more powerful adversarial model, but in an adversarial node minus a new block at the beginning of the tree, it gets a one-time gift of c minus one block. Fc is the epoch length. This also signifies the end of the epoch so the adversary can grind over the randomness tree. After that, the adversary operates as it operated before and there are no more gifts. Similarly for the other adversarial trees, we show that the non-existence on Nakamoto block in SS0 is bounded by that in SS1. Now in the static system SS1, we analyze the non-existence of the Nakamoto block in any sufficiently long interval of length. To do so, we employ the techniques from everything in the waste paper. First, we analyze the growth rate of the adversarial trees in SS1 using branching random walks. Then we show that if this particular condition is satisfied, then following events, following two events, happens for every block within the interval length with negligible probability. So the first event is that any nearby adversarial trees can catch up with the fictitious honest chain very soon. It happens with very negligible probability. The second event that any adversarial tree catches up with the fictitious honest chain far ahead in time also happens with negligible probability. This would imply that the event that there are no Nakamoto blocks in an interval of length S happens with negligible probability. Now the question is what is the right value of C, this right value of C, the epoch length to choose from. In one hand, we have the dependency of the security threshold on C. It shows that with increasing the value of C, the security threshold approaches the desired value of one house. On the other hand, the latency to confirm transactions is directly proportional to C. This creates a tension between the security threshold and latency. So depending on the application, if you are geared for security, you would tune the parameter value to be a bit higher. If your application is tuned for less latency, then you will tune, then you will have your parameter C to be a bit less. So this is how you choose the value of C. So to summarize our work, the process successfully guarantees proof-of-works dynamic availability and unpredictability while being provably secure under honest majority. So for future work, one direction we have been taking is to think about taking it is to upgrade POSAT to have the feature of dynamic state. So in our current model of POSAT, every node has a static state that remains same from the genesis. How in practice, adversaries can grind on keys of their accounts and transfer state to useful accounts. Having dynamic state would save God POSAT from such grinding attack. Another path forward is to see whether one can build a dynamically available proof-of-stake protocol that does not require any dependence on the error of time such as BDF. Finding an impossibility result or otherwise in this regard would be interesting. That's all for my talk. Awesome, perfect.