 Okay, I'm going to talk about internet scale consensus. This is joint work with the Ido Bentov and Raphael Paz Okay, some of you may remember that in August last year Delta Airlines had one day of complete outage You couldn't book flights all the flights were cancelled and this turned out to be a failure of their computing infrastructure Something similar happened to the National Science Foundation. If you were trying to submit a proposal back in July Sorry, you had to wait and Okay, so I wouldn't be too upset if I'm and you tell me I cannot fly and If you tell me I cannot do science. I reassure you I'll be very cranky Okay, the moral of the story is that we need two things replication and robustness Okay, so this is a very simple idea But it is precisely this very simple idea that gave birth To an entire research area called distributed systems and there has been 30 years of Wonderful research and development in this area Okay, so in distributed systems We care about a very important abstraction called a state machine replication This is also known as a linearly ordered lock or consensus So what's state machine replication? Let's consider a typical scenario Suppose we have Google Google wallet is a mission-critical application And suppose they want to replicate their servers And this has to be a good idea because if you put your money in Google wallet You don't want to lose the money if the server goes down. Okay So now imagine all of these servers they want to agree on a linearly ordered log of transactions and There are two important security properties that we care about Consistency and liveness Consistency says that the honest notes must agree on what the log is and Liveness says that and if a client submits a transaction then This transaction should appear in all of the server's locks very quickly Okay And So this might be Deceptively simple, you know, you may think this is a very simple problem Indeed the problem is somewhat trivial if all these servers are honest and Correctly follow in the protocol But the issue is that if some of these servers are compromised and compromised servers for instance can be behaving arbitrarily then it turns out the the problem is very much non-trivial Okay When we traditionally when we think about consensus and this is what I talked about is kind of the typical scenario that we think about and The deployment is typically within a single organization. We have a relatively speaking small-scale deployment The nodes are interconnected with fast local area network and because these notes belong to the same organization We assume that they're mutually trustful okay, and Then in the year one after Bitcoin there was Genesis and this kind of this was really exciting development because it opened a new chapter for distributed consensus and and it's amazing because now we can do internet scale consensus and Internet scale consensus obviously raises new challenges. So For instance on the internet, you know, we may have thousands and millions of notes The notes may sometimes have bad network connections and some notes may have outages. So there's a lot more unpredictability and also You know on the internet Everyone's kind of acting selfishly. So we assume that the notes are mutually distrustful and all of these raise new challenges I talk quite frequently with people in the cryptocurrency community and it seems like everyone kind of believes that These classical consensus protocols aren't a great fit for this internet scale deployment and the reason being that they are not Quote-unquote robust enough. So so this intuition may seem very very nice, but it's on the other hand. It's also somewhat Unsatisfying because for instance, it doesn't tell us Exactly what robustness means what new robustness properties are we looking for for internet scale deployment and only when we can only when we can answer this question Can we proceed to address the later questions such as, you know, why aren't Traditional protocols robust enough and how can we actually achieve robustness? Okay So I'm going to try to and Try to answer these questions and maybe at least give a partial answer to these questions and Oh and before that I wanted to say and you know I actually I asked the various people in the cryptocurrency community what they mean by Robustness, but it turns out that the community doesn't actually have a clear way of articulating what kind of properties they are looking for And interestingly like in the script or currency community what this interesting phenomenon is that the scientific understanding kind of is lagging behind the empirical success and this reminds me of this Interesting thing that my colleague I mean consider he used to say You know in the systems research community a very frequent question you'd ask other researchers is What's the time from your research paper to real-world deployment? Okay, so for classical technologies like you'd expect an answer Let's say within between five years to ten years Before something like cryptocurrency like in this area the answer to this question is negative six months Okay So let's begin with the most basic question. What is robustness? I'm going to make an analogy. We just had our Presidential election what happens when you ask 300 million people to vote Okay, so what's going to happen is that only a hundred and sixty million of them will show up and So what we can hope for is that you know perhaps among the people who actually do show up Maybe we can hope that 51% of them are honest because otherwise we cannot really predict the outcome of the election and We can kind of think of Consensus in you know very much the same way and I'm going to call this the sleepy model of consensus And we are going to assume that the nodes and are either sleeping which means that they're offline or they're awake Which means that they're online and actively participating in the protocol So sleepy for instance can be a result of an bad network connection Maybe the nodes have temporary outages and so on so forth And also importantly the status of each node can change like maybe a notice and has an outage But later it recovers from the outage when the Prince kisses Snow White she wakes up and she continues to participate in the protocol Very robustly. Okay And well, I'm going to make a couple other assumptions The first two are pretty standard the malicious nodes can behave arbitrarily and in particular our adversary like Dan And can be very very smart and you know, he can deviate from the protocol in very smart ways Perhaps to like diverge the opinions of the honest notes. Okay, and the adversary is allowed to Delay and reorder messages arbitrarily But on the other hand, we are also going to assume that and the nodes who actually are online they have They can receive messages relatively quickly They may receive messages out of order, but they are going to receive them relatively quickly because if not We are just going to treat these nodes as being offline. Okay So a very natural question we may want to ask in the setting is can we and achieve consensus Assuming that among the people who actually show up 51% of them and are honest Okay So before Telling you the answer to this question I wanted to say this is actually the best you can hope for because we actually have a lot of bounds showing that if Among the people who show up only like less than 50% are honest, then you cannot hope to reach consensus I'm not going to explain this lower bound and and also here are some and Some things that I actually mean when I asked this question So we are going to assume that the protocol cannot anticipate how many people are going to show up It could be like maybe 30% will show up. It could be 1% will show up Maybe I anticipate that 30% will show up But in the end only 1% showed up and I wanted to be the case that the people the 99% of people who didn't show up They should not hamper the progress of the people who actually do show up Okay, so also maybe in the beginning and a lot of nodes are sleeping But maybe later they they wake up and at the moment they wake up They are going to receive all the pending messages and we want to say that for those notes that wake up They are going to make progress and you know start to agree with the rest of the network Okay So you'd think like this is a very very natural question and with 30 years of research on distributed systems We would have answered this question by now But the answer actually may surprise you because it turns out that our classical protocols break down in this model and we can actually even say something Something stronger because even when we are willing to assume That amount of people who show up and 99% of them are honest And this is still not enough because even even when 99% of them are honest We still cannot and none of the classical protocols will actually work Okay, so this seems like a very strong claim that I'm making I'm going to explain Very quickly on why this is the case it turns out that for classical consensus protocols and Roughly speaking and there are two broad classes and synchronous protocols and asynchronous protocols in the synchronous model We typically assume that the messages sent will be delivered immediately Whereas in the asynchronous model The adversary can delay and reorder messages arbitrary lay and the delay can be indefinite and unknown to the protocol and up front so we know a lot about Both models and there have been many protocols proposed in the past that solve the consensus protocols solve the consensus problem In these settings. So I just have to convince you why and each class of protocols do not work It's relatively easy to see why synchronous protocols fail because in our model remember we allow nodes to go to sleep and When they wake up, they are going to receive the pending messages So this is a way for for you to break the synchrony assumption Basically messages are not necessarily received immediately and obviously in such a model all of the synchronous protocols don't work And perhaps it's a more interesting question to ask why the even the asynchronous asynchronous protocols don't work Okay, so here in the classical asynchronous model if a node goes to sleep We are going to pessimistically treated as being corrupt So imagine you have an asynchronous protocol that can tolerate and let's say up to one-third corruptions Okay, what's going to happen is let's say it turns out only what 1% of people showed up and In this case the protocol is going to treat like 99% of the nodes as being corrupt and What's going to happen is like the nodes are going to kind of wait to collect let's say Collect votes from two-thirds of the people but in this case only 1% of the people showed up So you are never going to collect enough more votes and therefore the protocol gets stuck Okay, so the fundamental problem here is that as I said we cannot anticipate how many people are going to show up Okay, so I've kind of talked about what I mean by robustness and why classical protocols fail I wanted to make a remark, you know I've only talked about really one aspect of robustness and robustness can mean many other things like for instance when particularly interest Aspect is incentive compatibility. This is something that is very very important in the internet scale deployment But perhaps of less concern if you know in this classical setting where you have a single organization But but this can be a topic for a separate talk We also have other works such as the Fruits in paper that addresses and the incentive compatibility issue And and for the purpose of this talk, we are going to kind of focus on how to address the sleepiness issue So I'm going to tell you how we can design probably secure protocols that give you a robustness Okay, and how do we do this? Let's turn back to the people and hear what the people have to say, you know the community the people tell us that Bitcoin snagamoto blockchain protocol is an exceptionally robust Okay, and in fact, it's actually quite amazing if you think about it because the Bitcoin protocol has been up and running and pretty much without interruption for the past eight years and For this reason people refer to Bitcoin as the honey badger of money and honey badger as we all know is a very robust animal okay, and In fact the people are right because we can actually formally prove that the Nakamoto blockchain protocol Does give you a consensus in the sleepy model and in fact our paper kind of implies this. I'm not going to explain why and So that's Good, but the biggest drawback of Bitcoin as we all know is that it's enormously wasteful The electricity consumed by Bitcoin is greater than the largest nuclear plant in the United States Which is more than 10% of all of the solar power in the United States Okay, so therefore we want to ask the following question. Can we achieve the robustness properties of Nakamoto consensus? But you know not have to pay the expensive proof of work. How can we do this? Well, let's first try the most natural idea, right? Let's take Nakamoto's blockchain and maybe try to just remove the proof of work And but really the challenge here is how you can do this in a way that doesn't break security Okay, I'm going to explain how to do this But in order to tell you how to do this I'm going to first explain how Nakamoto blockchain works And I'm going to do this relatively quickly because maybe many of you are already very familiar with Nakamoto blockchain What is the blockchain? It's a chain of blocks And how do we build a blockchain? Imagine we have this chain and we want to extend the next block So what do we do we take a bunch of transactions that we want to confirm? Maybe one of the transactions is that Dan wants to pay Elaine 50 bitcoins Maybe to purchase Elaine's car. Okay I'm going to take a hash function and I'm going to hash the following things This blue guy is the previous block that I want to extend and I'm going to take the the transactions I want to confirm and also a puzzle solution I'm going to hash all of these things together and if the outcome is less than a difficulty parameter D Then I say that I have found a solution Okay, so the screen guy is called the puzzle solution and whenever I find a puzzle solution. I'm able to mine the next block Okay One reason why Bitcoin is computationally expensive is none because we assume that the let's see Let's assume the hash function is a random oracle and in order for me to find a solution I have to try many different Pieces of the jigsaw puzzle until you know, I can find one that satisfies this inequality. Okay And it's very important that the honest notes are going to believe in the longest chain if you see multiple forks and the reason being that Imagine Dan our adversary He purchases the car from from Elaine. He receives the car and now he wants to erase this transaction So he can double spend his money and how does Dan do this so he can basically mine a longer chain than the main chain and but The intuition is that if the transaction is buried deep enough in the blockchain Then Dan cannot successfully mine a longer chain unless he has the majority of the hash power And this intuition has been formalized in some earlier works for it For example, the very elegant work of great great at all and also passed it off Okay So now we know how the Nakamoto blockchain works and let's try to remove the the proof of work Okay, so one thing that we Observe is that we can think of the Nakamoto blockchain as performing leader election whenever you successfully find the puzzle solution you are the next leader and you'll get to propose the next batch of batch of transactions Okay And our key idea here is that we want to restrict the puzzle space so in in bitcoins Nakamoto blockchain The nodes have to try many different puzzle solutions But what if let's say, you know that there aren't so many puzzle solutions to try and then you don't have to work so hard Okay And so for the time being for simplicity, let's consider a permission setting meaning that we know exactly which nodes are participating in the protocol and every node and notes the public keys of every other node Later in the talk I'm going to remark how to take this permission protocol and make it permissionless by doing proof of stake. Okay So remember that this was our Nakamoto blockchain People have to work very hard, but let's restrict the puzzle space. How do we do this and? Imagine the nodes are weakly synchronized. Everyone has like a weakly synchronized. I mean they have a weakly synchronized clock Okay, let's let's say now in every time step and then it's going to and hash his name Concatenated with the current time and if the outcome is less than the difficulty parameter Then is elected a leader in this round in this time step and if he is the leader he can and Take the block he wants to extend he can take a batch of transactions he can also take the current time step and he's going to sign all of these and things and this Allows him to mine the next block and everyone can verify You know that the block is correctly formed by checking that then is indeed the leader in this time step and That the block is correctly signed by dance public key Okay, so this seems like a very natural idea, but but the question is whether this protocol is secure Okay, well, it turns out the answer is no the this protocol actually it doesn't work and And and fundamentally because the adversary can and has a lot of advantage in comparison with the honest notes like for instance When the honest notes get elected, he's going to sign exactly one block But when the adversary gets elected, he can sign many blocks and also the honest notes are only going to mine in the present They are going to take the current time step and try to hash it Whereas the adversary can pick future time steps and hash, you know as many times as he wants Okay, so in order to make the protocol secure, we have to kind of constrain The ways in which the adversary can behave and here here are a couple ideas. Let's let's say the time stamps in the blocks have to strictly increase and Let's also require that the honest notes will reject any blockchain where the block has a future timestamp So if we do this then you can see, you know when the adversary gets elected He's not able to sign many blocks because the timestamps have to strictly increase and also the adversary can't just take a future time and time step and try to hash it Okay, so now the question is is this fixed protocol and now secure Okay, well, it turns out that this is kind of like a trick question because the answer is yes it is indeed secure, but it's non-trivial to see this and What's most not trivial? I won't have time to explain the details here but essentially In in this protocol, there are ways that the adversary can attack the system that was previously not possible in the Nakamoto blockchain and Therefore because of this reason the previous Nakamoto and blockchain analysis and they failed to work Okay, and therefore in order for us to prove this protocol secure we have to do much more work I will have time to cover the proof if you are interested you can read our paper We actually are going to release a new version in pretty soon And in the paper, we also have some additional results like we can weaken the assumption by removing the random Oracle and we can achieve adaptive security through complexity leveraging. Well, it turns out that in this case even complexity leveraging is non-trivial and I won't Go into more details and I wanted to say so our protocol is called sleepy consensus I wanted to say that I think one particularly attractive application of sleepy consensus is for a consortium blockchain What is a consortium blockchain? This is something that the banks really want like they want to have a distributed ledger And maybe each bank will contribute some consensus notes and this will allow them to do much faster interbank settlement Okay, and there are a bunch of projects and companies in the cryptocurrency space that are trying to help the banks build a consortium blockchain What's nice about sleepy in the setting is that because of our ability to deal with the sleepiness You'll get some of these properties kind of for free like you it's very easy to reconfigure the system it's very easy to recover from thoughts and also in this Consortium blockchain setting the admin is and the banks will have to administer their notes In a decentralized fashion like it will be really nice if let's say I'm a bank and I can kind of spawn some replicas and Maybe reboot my machines without having to coordinate with other banks. So this protocol will allow you to do that Okay, if you are interested in deploying our protocol, like we'll be very happy to talk to you guys Okay, so to quickly summarize I've talked about how to take the Nakamoto blockchain protocol and how to remove the proof of work in a secure way such that we get an instance of permission consensus and I think what's interesting is that we can achieve on these new robust these properties that that was Not possible with these classical consensus protocols Okay, but it would also be nice like I said to have a permissionless protocol as well and in fact we can do this we can take sleepy and and Recast it to the permissionless setting by doing proof of stake. So at a very very high level, you know, improve our work The rough idea is that your voting power is proportional to Your computational power but whereas in proof of stake Your voting power is roughly speaking proportional to your stake in the system Okay So we also have a paper on and the proof of stake protocol It's called Snow White and the paper is up on eprint and we are also going to release a new version pretty soon. Okay So to conclude we've come a really long way we've you know, we started with Distributed consensus, but with relatively small scale deployment But now we are in this internet scale the distributed systems You know on the internet, no one knows you are a Pokemon These are pictures taken from a bootcamp hosted by our crypto currency center called IC3 Okay, well I see three has very colorful activities. That's why you should become our partner And also we must not forget that then is our very very smart adversary And if your protocol isn't probably secure, he surely will find a vulnerability and earn other bitcoins for himself. Okay so to conclude and Internet scale distributed systems very exciting, you know, Bitcoin is really just a glimpse into our future And there are like through the process of working on this like we realized that there are a lot more questions that we don't understand Then the ones that we understand so we need a new theoretical framework to kind of Analyze and reason about these protocols and we also need probably secure Protocol design and implementations and this area should be of particular interest to the real world crypto audience because this is where like Crypto can make a real-world impact like the community is actually hungry for These you know modern fancy crypto protocols that may like for instance involve zero-knowledge proofs and multi-party computation And remember what I said in this area The time from your research paper to deployment is negative six months So you don't have to worry about, you know, it takes a long time for your research to make a real-world impact Thank you very much Right, so we do have time for questions At least two questions. So, Sarah, okay Um, can I just ask quickly so you said that your fix involves Timestamping stuff and basically saying that people don't accept timestamps in the future But how does can you just give a hint of how that works in a fully asynchronous setting because surely people would disagree about when The future is and so the synchrony there are two notions of synchrony when is clock synchrony and the other is now Synchrony so in this case we are assuming that the clock the clocks are weakly synchronized So like your clock is relatively close to mine like in in the first day. There was a very nice talk on NTP security. So for instance, you know clock synchrony can be achieved through things like NTP protocols Hi, thanks. Nice talk. So in you showed the original in the Nakamoto chain you have the hash function of the last block and the coins and the puzzle solution and in your System you just have a hash of your name and the time So why don't you include the last block in that hash as well? And that will actually and Give the adversary more advantage because the adversary can like let's say the adversary and somehow controls the last block Right, and he can try many different contents of the last block and now he can try many different things So so you wouldn't be able to prove the protocol secure if you do that. Okay, thanks Very nice talk. I'm wondering how does this compare in terms of number of transactions you can get to saying like like there are a certain distributed Transaction systems out there How's it compare and performance which is usually what people are about when they talk about scale? That's a very good question. So we actually we do have an implementation and we are in the process of like running evaluations and so what I can say is that like for this classical basing team for tolerance protocols like PBFT typically and You have like quadratic metadata overhead because everyone has to send every everyone else like some Metadata in the protocol, but here like everything is linear. So I think it really depends on whether your system is network bound are and whether the system is Network bound if the system like is bandwidth bound, let's say that then potentially This protocol can can't be nice, but if it's kind of latency bound and Then PBFT like like if you don't saturate our network bandwidth then like in the optimistic case Like you only need like constant number of runs, but here maybe you need to wait for a few more blocks to get Confirmation Excellent talk. So just one quick question So so in your model basically you can tolerate like most of the onus knows just In sleep node, but the thing that if you in this mode how you guarantee that on is the node always have the connection with other onus knows and So so that's a very good question and Essentially like we have this Like in this model if You have a relatively fast network and you can receive messages within like some parameter delta delay that then you are you are considered as Being online however, like if you temporarily, let's say you suffer from a network Bad network connection and your messages are being delayed for a long time at this moment. We are going to treat you as sleepy and so we basically it's kind of in order for the model to make sense there has to be this this and Cutoff data that we pick and then you can say okay if you can receive messages and you know fast where fast is relative to data then then we can't we treat you as Being online. Thank you. Okay, so let's thank Lane again