 So hi, my name is Raphael Paz and I will talk about this work with Hubert and Elaine on Consensus through this notion of herding. I will get to what that is towards the end of the talk But for it let me start by summarizing what consensus is So this is in fact a very old test that we studied since basically 78 We have a set of nodes here. We have I don't know six five of them and And these nodes would like to agree on an ever-growing list of transactions Okay, so this is today what we call a permission blockchain But I said this has been around for a long time with names such as state machine replication BFT and so on and so forth What do we mean for these nodes to agree on these transactions? Well, typically we require two properties the first one is consistency and consistency roughly speaking says that if I take any two Nodes then their view of these transactions that they have should be the same and a second property is liveness Which roughly speaking says that whenever a node wants to add a transaction that it should get incorporated in everybody's view sufficiently fast So a little bit more formally Consistency actually consists of two parts the first one says that at any given point in time if we take two nodes me and you Either my ledger my view of the transactions that have been confirmed so far is as is a prefix of yours or vice versa And a second property which is sometimes called future self consistency says that my Ledger should always be a prefix of my future self Is this very loud? Can you like lower a little bit? liveness is actually parameterized Liveness is parameterized by a function t and this function determines how fast a Transaction is guaranteed to be introduced into a ledger So whatever an honest guy would like to add a transaction if we satisfy t liveness That means that everybody should have this transaction inside the ledger within t of n comma K steps where n is the number of players and k is the some security parameter So there's a fixed bound on how long it takes for a transaction to get incorporated and both these properties covers Don't need to hold with probability one, but one minus negative probability This notion of liveness in fact very strong. This is often called synchronous liveness So to achieve something like this, we need to consider a synchronous model of communication So in a synchronous modern model of communication We in essence allow people to communicate in rounds think of a round as a time step And we have the guarantee that whenever a good guy sends a message it gets to everybody within some maximum Delay and this delay is called Delta Okay, so there is a maximum upper bound on a time it takes for a message to get delivered to everybody In fact often for simplicity We can just assume that even if a bad guy sends a message There's also this maximum delay of Delta until it gets delivered to everybody So whenever somebody sends a message Either good or bad it gets delivered to everybody within Delta time steps And this assumption is often without list of generality typical as the case in a classic Setting it's also the case for what I'm considering here. So for now. I'm just gonna assume that Additionally whenever you send a message The message is authenticated so we know whenever somebody sends a message who it comes from so this is a set a very old model going back to the late 70s and Basically, a lot of things are known for this thing almost everything you want to know So the earliest results said that if you'd like to achieve consensus you need to assume that Two-thirds of the nodes are honest and the rest can be completely malicious So I'm going to consider a setting where some nodes are completely Maliciously controlled and others are honest and so as long as one third are honest we can achieve it and this is optimal However, if we additionally have access to a public key infrastructure Then we can do a lot better and then we can actually get security even if we just have a single honest guy So we can handle any number of corruptions Yet those protocols take require a lot of rounds However, if we additionally assume that 50 percent are honest We can also get something that gives you liveness within a constant number of time steps So what I mean by constant here is actually takes a constant times delta time steps In order to for a transaction to be confirmed. Okay, so there's still a little gap Whether one could do better than number two here, but except for that pretty much everything is known Let me go over the general principle for getting consensus protocols In fact, most of them follow the following simple Recipe so we're gonna have a protocol proceeds in epochs In each epoch we select some leader how this leader is selected is not important Think of it as just being round round robin So first the first guy goes and the second guy goes and so on so forth and this leader gets to propose any set of any batch of new transactions and the way he proposes them is by just sending it out to everybody else and Then these guys are gonna run something called a Byzantine agreement protocol to agree on this batch of transactions Okay And once they've agreed on these set of transactions We now say that that set of transactions has now been added to this ledger and has now been confirmed So I have to tell you what Byzantine agreement is most of you probably know it, but let me just very quickly repeat it So in a Byzantine agreement protocol, it's very similar to a consensus protocol Except it's just a single shot game So we have this set of notes each of them have some input And they talk to each other eventually generate some output and we require three properties Take any two honest guys They should agree on what the output is so they should always get the same output Termination just says it should terminate within some fixed polynomial time in Delta and the interesting property here is That of validity validity says that if all of the honest guys start off with the same Input then they should also get there as an output Okay, so in particular if we go back to this original recipe This liveness condition to borrow that whenever somebody wants to add a new transaction They send it to the leader the leader if he's honest He's gonna actually send it to everybody and then by the validity requirement of the Byzantine agreement protocol We know that everybody now starts off with the same input The batch of transactions and they will therefore agree to it So therefore that transaction will be added and we're done and consistency of this Recipe follows directly from consistency of the or the agreement property of the Byzantine agreement protocol So very nice. We just need to construct Byzantine green protocols and that can also be done And so that's it Now the topic of this talk, of course in the era of Bitcoin is to handle Consensus in in a logical setting so setting with a number of nodes is huge The typical setting where these original protocols were considered had three or five or six nodes It was they were not meant to handle a Scenario where you have a huge number of nodes whereas the Bitcoin protocol And the blockchain that underlies it indeed handles this huge number of players So that's awesome So by By handing a large number of players mean I mean that we have a protocol that scales polylogrhythmically in the number of players Okay, so it turns out that Nakamoto's blockchain protocol actually does And that's great, but unfortunately it does rely on this proof of work So it's very expensive and waste a lot of computational effort In particular, I think at the moment it's more than the total solar production in the us. It's quite a lot Okay, so a little bit more formally by communication efficient consensus We would like to have a consensus protocol satisfying two properties The first one is that the total number of bits that players multicast in total among them Should be polylogrhythmic in the number of players And the total length of the the transactions and the security parameter Okay So basically polylogging a number of players And then multiplied by the the total length of the transactions Additionally, we also require for this not to be trivial We also require that whenever somebody would like to add a transaction We have liveness the transaction should get confirmed within some polylogrhythmic time also Okay, so basically everything both the communication complexity and live nature to be polylogrhythmic in number of players And now you see this and you think well, you know, this should be kind of easy to do There is a trivial folklore approach, right? If we have a protocol that handles a large number of players, why don't we just sub-select a small group And then write it among those guys Very easy, right? And we have very different methods of sub-selecting a committee of players to run this And indeed it does work But that approach of sub-selection in fact only gives you a protocol with static security In particular if we get to adapt the cloud corrupt nodes Then this can be completely broken because I can just if I know exactly who gets elected I can just corrupt only those guys and I'm corrupting a small fraction of players and I control everything So that's not so great In fact Even if I have a communication efficient Byzantine agreement protocol That is adaptive is secure this method still doesn't work and In fact, there has been some recent work including by ourselves That show how to achieve Byzantine agreement protocols that are communication efficient and adaptive secure But plugging those things into this paradigm still won't work And the issue is regarding the leader Because we remember in this recipe we need to first have a leader who sends things out and then they we use business agreement If this leader is corrupted The validity condition we had from underlying Business agreement protocol gives us nothing because if the leader is corrupted he can send garbage to the players And we're not guaranteed to make any progress okay, uh, so The question then that would like to address is whether we can get a communication efficient consensus protocol That is also adaptive is secure and that's the topic of this talk and As I mentioned Nakamoto's original protocol indeed satisfies this guarantee and this was shown a few years ago Uh, but it requires proof of work Okay, however, it shows that assuming 50 percent of the players honest In this proof of work model and using a random oracle we can get a protocol that is communication efficient and handles adaptive security Uh The same year it was also shown by chen and Mikali That you can also achieve it without proof of work And they indeed obtain in the public key model and using a random oracle They show a communication efficient protocol That is secure the specter adaptive attackers Under assuming one third of the players are at most corrupted But this time they use erasures So they assume that you can erase Computation and you erase your memory completely Let me explain how either proof of work or razors help us overcome the issue Roughly speaking the issue with sub selection Is that it should be hard to predict who is the leader in advance? right the first thing I okay If I can predict who is the leader in advance, they're just going to corrupt him and then I can create havoc right because I Let him send garbage transactions With proof of work Nobody can predict in advance if we're doing this mining. I can never know who's going to be elected leader. So that seems to be good, right? Another approach And that's the approach used by chen and Mikali is to use a vrf and you heard about that in the previous talk So use this verifiable random function Which allows me to figure out whenever I'm going to become the leader But nobody else can figure out before it has happened So we allowed it is kind of a secret sub selection where the person who gets elected on the committee figured out But nobody else finds out unless until they reveal the proof that they've been elected So that's great. That means with the fact that you cannot figure out who is the leader in advance Both of these approaches Now here's comes the interesting thing It shouldn't just be hard to predict who's the leader up priori But it should actually be hard to predict who's the leader even after he has become the leader up posteriori So what do I mean by this? After leader speaks I know who the leader is right and then I can just take him and corrupt him Now he's only sent something out So I can't deal with that but I can just send out some other message And given that there is some delay on this network I can just slow down the first one and make the second message come faster And therefore I get these two conflicting transactions again So that seems to be a issue that's harder to deal with and indeed the way they are dealt with With proof of work is that actually just because you manage to mine something once That will not help you to mine again. You're like the leader, but Even if I take you afterwards, that doesn't mean you're going to be more lucky to be elected leader again To send an invalid thing And the way chenemy cali deal with this issue is that you're elected leader you send out this transaction for everybody But as soon as you send it out you erase the relevant state needed for the vrf So you send it out I come and corrupt you and then you're like, well, I'm not the leader anymore I could not have been leader before and I don't have the key anymore Okay So this is how eraser deals with it now One issue with this approach which has been raised By several people is that it doesn't really seem rational for me to erase this thing because by erasing it I'm kind of losing a possibility that I can use later on So our main result is indeed showing that you can overcome This issue and not deal with erasures at all. So we present a protocol in the pki and cirrus models. We don't even need a random oracle Assuming standard crypto assumptions of our bilinear maps, in particular, we need a non interactive as your knowledge with adaptive security That handles the same one-third corruption Without erasures without proof of work and read from the oracles all right, so in The rest of the talk let me convey on a high level what our approach is. So as I mentioned The idea is going to be relying on this notion called herding And the way we're going to do this is in fact as a first step We're going to define a new type of single shot consensus primitive That's going to be different than just business agreement. It's something we're going to call batch agreement And it's going to have slightly stronger stronger properties And then we're going to show to implement this new type of batch agreement from herding What's batch agreement? So batch agreement is a little bit more complicated than than just business agreement So here we consider an execution where the players Before starting a protocol get to interact with an environment and the environment is providing them transactions So i'm getting some transactions. You're getting some transactions, blah blah blah And at some point the environment says start so it tells everybody let's start the protocol At that point they have seen a list of transactions Okay, we call this time t0 Then they run the protocol and then generate some output The security properties the first two agreement determination just as before agreement says that we have the same output But validity on our hand is stronger Validity says that any transaction that anybody has seen Up to time t0 when the guy said start minus some delay Needs to be included So it sort of says whatever I have seen up until time t0 minus 10 seconds I need to include it in my output and so should everybody else So this notion you can see if you have this thing you can very easily get consensus because you just sequentially repeat this One after one after another and that guarantees that whenever somebody wants to add a transaction it will get other Sufficiently fast Okay, so the question is how do we achieve this thing? All right to do that we're going to rely on this idea of herding What is herding herding? Is actually something that came up in the economics literature and probably even earlier in In in the literature on the social Social science, okay, I don't know what the area was called there. Yeah, so this is what it's about. So let's say We would like to Decide whether smoking causes cancer or not We start off having some initial beliefs about whether it does or not So we call this w is a state-of-the-world which is a bit either 0 or 1 does smoking cause cancer We start with his initial beliefs And then we're going to speak one after another So first I go and I'm going to output a guess for whether I think smoking causes cancer or not I guess yes, okay, and then you go and then you make a guess But the point is you have already heard my guess So right now you have your beliefs, but you're going to update your beliefs based on my beliefs based on my guess, right? Now if we assume that everybody's original beliefs are as strong All right, so we have seen as much evidence. We've just seen the signals, but whether this is the bit is 0 or 1 So if the beliefs are as strong In that case and we assume that Players are rational and not only they're rational, but they assume that everybody's rational and so on so forth It's called common knowledge rationality Then what we should do at any given point is I should just output Make a majority decision If I have seen the first guy says no the second guy says no Even if I originally believed that it's yes, I'm like, well, you know that guy was rational So he must have had a bit that it's no zero and then the next guy must have told so also So therefore I should change my mind and output no also So what happens at this point? Well, even if I think it's a yes if the first two guys say no I'm gonna also say no and then a third fourth guy will say no and so on so forth And we get what's called an information cascade. So everybody says no. So this is very nice Uh, or not is it's sometimes called the foolishness of crowds because it leads to Sometimes crazy Decision even though everybody starts off with having like good beliefs You just have a few silly individuals that start off saying bad things and it just Propagates and this is one way to explain the spread of fake news and so on so forth, right but Not on the other hand that they all agree, right They don't agree on the truth, but they always agree and this kind of happens with probability almost one So we're going to use a very similar approach To get the consensus and to get batch agreement We're going to given a set of a transaction a batch of transactions We're going to give it a score. So each individual is going to assign a score to whatever to some batch of transactions And the way it's going to assign its score is going to be by first Looking at this batch of transaction and giving it some initial score Think of this initial score as my initial belief I had Okay And then I'm going to add to that the number of votes I've seen for that batch So people are going to be voting people are going to say which is which one do you think is the best? And that's going to be a vote for it. So my score now for this transaction is going to be how much I believe It was worth at first plus how many votes I've seen for it And then basically we're going to do the same type of Herding type of protocol So people are going to go one after another and they're going to Send a vote for the transaction that they think is the best The batch of transactions that they think have the highest score according to them So when it's my turn to go, I just vote say I put a vote for my best transaction according to the score Okay, now it remains to see how in what order people are going to go The way we decide the order is again using a vrf But there's a little trick here. I'm not just applying the vrf to To the run number like it was done before but I'm also going to apply the vrf to the set of transactions and the run number Okay, and we just do this for polo grit me many times All right, so very easy. I start off with my Original set of transactions that I've heard from the environment. I'm going to score that Then when it's my turn to go, I send a vote for that Then it's your turn to go Then you're going to vote for your best batch of transactions and so on and so forth And we update our scores are therefore beliefs based on how many votes I've seen This vrf needs to be adaptive secure and we've shown in an earlier paper you can do that based on goss Goto's astrophobia so high and that's where we need this by linear maps All right, I haven't told you how to set the initial score and that's actually going to be the important part of it The way we're going to set the initial score is by first Given a batch of transactions tx I'm going to determine how old this batch is I will say that the transaction has a certain age That's going to have the age of the oldest mistransaction in tx So let's say we have some bad guy who's going to propose some batch of transactions that to me Look old because it has missed some transaction that I have seen That I have seen in my view But he has excluded in that case. I'm going to refer to this one as being old has been a long time Uh It's not freshly more because it's missing something that should have been there. Okay I will now set my initial score My original belief of this transaction thing Basically some exponential decaying function Uh of the age of the uh of the transaction So it's going to be some some constant times one minus epsilon times the age of the transaction And in fact the right way to look at this is due to age and time divided by delta What delta is the network propagation time? So really you want to Sometimes exponential they're decreasing in the age In terms of network propagation So why do I have this bizarre scoring function? The idea is the following and this is the key for for the proof If I take two honest guys Their initial scores are actually going to differ by very very little Because the difference in uh in age between Because the because of this network propagation assumption any two honest batches of transactions Are going to have very small gaps Additionally we have that if I take some some honest guy His batch he's going to score it high His original batch has age zero It's very young so therefore it's going to have a score of at least C So it's going to have a high score now What happens now is uh I'm not going to really go over the proof But the idea here is that if the initial score differ by very little That means that scores that good guys have will differ by very little And that means that good guys in efforts are going to concentrate their voting effort on the same Transactions and you can prove and this is a little bit tricky to do But it follows using proofs similar to the way blockchain the protocol to analyze that it will eventually be some set of transactions that get a lot of votes Now since By this observation two each good guy scores his transaction high Good guys will never vote for any transactions That are very very old because their score is just going to be too low And consequently from that we have Validity and the agreement property will basically fall out from the idea that if That as we argued before some transaction is going to get a lot of votes But and here is the point The key point why we're tying this the eligibility property of when you can vote to the transaction You can argue that the number of total votes that can be sent is going to be small and From that We can improve agreement and here we rely on two thirds honesty obviously. I'm not going over any details, but So to summarize we've shown here is that in the public key model with a common reference string Assuming standard crypto assumptions. We can get a communication efficient consensus protocol That handles Attackers corrupting up to a one third of the players We don't we need no erasures no proof of work the random oracles And what I think is probably the most cool thing here is that we're using this idea from Social sciences and economics this idea of hoarding that is typically viewed as a kind of a bad thing And use it for for something good To To leave us some open questions and very natural thing is can we do better than one third? We believe we can do we think one should be able to get it up to one half And another nice thing is to deal with partial synchrony And two thing worth mentioning is in fact in this other work, we have shown that a pki is needed. So you cannot remove it and Stronger corruption models are actually not possible Thank you questions for rafael So thanks for nice talk. Um, I have a question So is this protocol or this technique that you use related to avalanche also somehow because it looks very similar Similar to this kind of voting and infection and then they all turn I saw some medium articles at some point Yeah, uh, I purely I don't think it it is but you know I don't know all right Okay, the very last question of the so I'll tell you two questions. So why is it look? Wait, wait, wait Okay, you can say I just had a short question about the eraser sort of thing Do you think one could use Save one say use like some cryptographic parameters like one time signatures. Like can we incentivize I guess, uh People to raise to a raise right like say that, you know, if we have one time signatures Then yeah, you can spend you you better delete your key because otherwise, uh, if it's used twice You lose. I don't know everything or deposit or something Yeah, well, so I guess what we show here is you don't even have to think about it but Yeah, I don't know like in fact the way this The way these things work is that you You have this vrf key that needs to be used in order to compute the future Still so that's why it's a little bit complicated because you want to allow the good guy to be able to To you reuse the key many times in the future So actually technically what you need here is some kind of forward secure a vrf Where you can evaluate on index one two three four five until I but you cannot evaluate it But you can you want to remove erase the possibility of evaluating on the past and still while being able to do it in the future So that's why it's a little bit tricky And even if I even if I try to erase, you know with active corruption, we know it's not so easy to actually erase things In practice so So was that after the fact deletion again? so that's a In our model of adaptive corruption, which is also the same model as All notions of adaptive corruption in the in this vein of work Whenever I corrupt you if you have sent a message, I cannot delete it So we're still in a synchronous model in the sense that you've sent something out I can delay it by delta steps, but I cannot delete it Right after corrupting you so one could potentially consider a stronger model where I corrupt you And then if this has not been delivered yet, then I can Remove it because you're bad at this point And in that model it turns out you cannot get communication efficient And that's an upcoming policy paper showing that All right now we come to the very last question with this gentleman Okay, so you're saying just just one Okay So you're saying that you can ask you're saying that it's logarithmic in the number of parties But it doesn't look logarithmic because you I mean Every party has to sign this transaction. So why why is it? No, no, no, no, no It's not everybody's sign in transaction. I am proposing The transaction I'm making this yeah, so why so I'm only picking people to vote on these things I'm only picking polylogic many people. I didn't tell you what the parameters are but yeah And also this scoring function should be more generic. I mean it should be a generic solution It's not like because it's really particular, but it looks like it could be you just need some properties of the function Yeah, yeah, so the only properties you want are these two things. This is just some function satisfied that We want something that behaves this way that We have something with initial scores will not differ a lot, but if I have some old transaction It should really bring down the Bringing down by lot So I guess these two things and additionally property that all transactions should be scored low All right, let's thank rafael and the rest of the speakers