 Thank you very much. All right, I'm running a timer to keep myself on time, not only because I'm sure I'm standing between you all and lunch, but also because I'm very jet lagged and I would rather not put you guys as well as myself to sleep in the middle of a presentation. I have fallen asleep during a presentation once before and I would prefer not to repeat it. So without further ado, I am pleased to present this joint work with Jonathan Katz and Julian Loss on synchronous consensus with optimal asynchronous fallback guarantees. So just to give you an overview of what we're going to cover, first I'm going to introduce the classical Byzantine agreement problem for those for whom it's been a while since you've seen it or for those who have never seen it. We're gonna talk a bit about feasibility results for this problem from prior work in both the synchronous network setting where you have a known bounded message delay or the asynchronous network setting where you may have unbounded delays on messages. And then finally, we're gonna spend most of our time today looking at this question which says, how can we design some sort of compromise protocol that gives you stronger security guarantees if it so happens that messages are delivered in a timely fashion, but it still has some really clear, well-defined fallback guarantees otherwise if there are message delays. Okay, so first we're going to talk about what exactly the Byzantine agreement problem is. So if that's old hat to you, you can tune out for the next five minutes or so. So Byzantine agreement has N parties. They all have an input bit, zero or one. And then the parties talk to each other, they exchange messages. And at the end, the goal is that they all output the same bit, either zero or one. And the catch is that they have to do this even though some fraction of the parties are malicious and they might never send messages at all or they might send false messages or they might say different things to different parties. We want, even in those cases, that all parties output the same bit. So to be a little bit more formal about what exactly we want our protocol to achieve, we're going to define the following security properties. First we have T consistency, which says that if at most T of the parties are corrupted, malicious, dishonest, whatever you wanna call them, then all honest parties output the same value. And this by itself isn't particularly a difficult problem to solve. For example, you could just say that all honest parties should output zero, no matter what. So to make things a little more interesting, we're going to add an additional requirement which is called T validity. And this one says that if at most T parties are corrupted, the same as before, and additionally, all honest parties have the same input, then all honest parties are going to output that value. So if a protocol, in the rest of this talk, if a protocol is T consistent and T valid, then we're going to say it's T secure. Okay, so for the rest of the talk, we're going to assume that we have a public key infrastructure that the parties can use to authenticate each other and authenticate themselves, and also that we have these idealized signatures that we'll use as just black box, unforgible objects. And the adversary, which I'll sometimes denote as this script A, can adaptively corrupt and control some fraction of the end parties and we'll give more details in a second. Okay, so as I alluded to before, this problem has been studied a lot in a lot of different and interesting models, and in particular, one of them is the synchronous model. So in the synchronous model, we're going to say that messages are always delivered within some known time-bound Delta that's known to all parties. And the adversary is allowed to reorder or delay messages, but they can never go past this bound Delta. For our purposes, we'll say that A is actually rushing, i.e. that means that they can wait to see all the honest messages that were sent during around before they decide what they themselves are going to do. And we're also going to give honest parties the luxury of having synchronized clocks whenever we're talking about the synchronized model. So on the other hand, this problem has also been studied in an asynchronous model where the adversary can delay messages indefinitely and adaptively. But they have to deliver them eventually. So by adaptively, I mean that they can choose to impose the same delay on all messages or I can say that person A is going to get all of their messages as usual, but person B only gets them after three hours and so on. They can do whatever they like as long as they eventually deliver all of the mail. And for the more honest parties, just to sort of complete the parallel between these two settings as it makes them easier to talk about in later parts of the talk, honest parties also have a clock in this case, but it may not run at the same rate as everyone else's and it may not show at the same time as anyone else. Okay, so this problem has been studied for a long time and we have found that the optimal corruption threshold in each of these settings is respectively N over two corruptions and N over three corruptions in the synchronous and asynchronous settings respectively. And we're so good at solving this problem even that we know protocols that achieve the optimal threshold corruption with constant round complexity, assuming you have set up like a PKI and just as an example, here are two constructions that achieve that in either model. Okay, so if I get very hand wavy for a second, we can roughly compare them along these two properties. We can say that the strength of the synchronous protocols or rather protocols designed for a synchronous network is that they get that higher N over two corruption limit so they can withstand more corruptions. However, we don't necessarily know how they're going to behave as soon as you introduce some message delays. On the other hand, protocols designed for the asynchronous model are going to handle whatever message delays you throw at them but we saw on the previous slide that prior work shows that the best you can do in this case is a lower N over third corruptions. So while I'm not going to tell you in this talk how we can get around prior impossibility results, I am going to talk a bit about maybe some scenarios in which you can get the best of both worlds or rather get a compromise between the two. Okay, so to really formalize the question that we're going to look at in the rest of this talk, let's say that we've fixed two parameters, TA and TS, such that TA is strictly less than N over three and TS is strictly less than N over two. And imagine that the adversary is allowed a choice of one of the following settings immediately before each execution of the Byzantine agreement protocol. They can either choose to have up to TS corruptions and they have to allow the network to be synchronous, i.e. they have to deliver all of the messages on time or they can say actually I'd rather have a smaller number of corruptions but I'm allowed to delay messages as long as I want. So the adversary before each time the honest parties try to run the protocol gets to choose their own adventure. And we wanted to know is there a single protocol that allows the honest parties to achieve secure BA, secure for the threshold shown on either side in both cases. And sort of the intuition behind this question is sort of saying like maybe you're choosing a Byzantine agreement protocol for a network that almost always behaves synchronously but you would really like it to have defined behavior on the one day out of 100 that the messages aren't delivered very well. You would like to know that without you needing to realize this and run a different protocol that you're still going to get sort of the best possible corruption resilience. Okay, so our results we show that such a protocol exists if and only if TA plus two TS is strictly less than N and TA is less than N over three and of course the TA less than N over three is from prior work so really pay attention instead to that TA plus two TS less than N. That's our result. We can do this if and only if that bound is respected. And in the rest of the talk I'm gonna talk about the if of our result, i.e. I'm gonna show you a construction that does this and then the only if which shows that if you have TA and TS such that TA plus two TS is equal or greater than N then there's no such protocol exists. Okay, so if we were very naively just going to do our best at making a protocol that does this as I said people have come up with a lot of very good protocols for solving this problem. So maybe the first thing that we would try to do is just try running a synchronous visiting agreement protocol and hope that it works. So take your favorite end party and round synchronous visiting agreement protocol if you have one and just try. And if that works then great you have your output and if it doesn't work then you wait a while say like N something on the order of N times delta such that if the network is synchronous you should have finished by now. If you're not finished by then okay that's fine you're going to try instead your favorite asynchronous visiting agreement protocol. Okay, so that's our first effort. You picked like I said you picked out such that you'll definitely finish your synchronous phase if the network is synchronous but the problem is that you don't want different honest parties taking different routes through this protocol basically. So for example we can imagine that some honest parties successfully get through the synchronous phase even if the network is asynchronous because the adversary just delivers messages to them in such a way that they're able to complete the protocol but the adversary prevents messages from reaching some other parties and they basically end up having to run the asynchronous path and get stuck in the asynchronous phase with a bunch of adversaries and everyone else has already terminated through the synchronous path. That would be an example of something bad that could happen if we use this first naive protocol. So let's try to fix that problem. So instead you're going to again try your synchronous phase and then you're going to take whatever output you get from that if you do get output and you're going to use that as your input for the asynchronous phase. So that fixes the problem where now we have everyone participating in both phases so no one gets stuck in a dark alley with too many corrupted parties but there's still another problem which is that the synchronous phase might not fail gracefully in an asynchronous network. So for example what we're worried about is that everyone agrees, for example everyone might have the same initial input and in this case validity says that we need everyone to output that bit at the end. However for example what if during the synchronous phase everyone goes from having pre-agreement on zero to agreeing on one and now they all enter the asynchronous phase with one instead and now we have no way to recover validity. So there are just all sorts of little things that can go wrong when we just use our favorite off the shelf synchronous phase. Okay so our idea was that we need to modify the synchronous phase to have certain nice behavior even in an asynchronous network which sounds kind of obvious when I say it that way but basically the idea is that in an asynchronous network the synchronous phase is not really doing much except not breaking things before the asynchronous phase can work. So we know very well what the asynchronous phase gonna do when the network is asynchronous so the synchronous phase needs to just not send everyone off in the wrong direction. Okay so what we do is we replace the off the shelf synchronous phase with a modified version which says that parties can output bot just meaning I don't know if they don't hear from enough people in the first phase and then instead of validity we're going to guarantee weak validity which says that if at most two parties are corrupted and every honest party inputs B then every honest party outputs either B or I don't know and then finally we tell an honest party who outputs bot after the first phase to just use their original bit as input to the next phase. Okay so now we've patched another hole and so now what we have is the honest parties who complete the synchronous phase might have a zero one or they might have I don't know at that point in which case either if they time out or if they received bot from the first phase they're just going to use their original bit. So now the problem that we were worried about where everyone has the same initial input but they somehow get confused or diverged during the synchronous phase when the network's asynchronous we've patched that because now everyone will enter the asynchronous phase with the same bit in that case. Okay unfortunately we have one last problem which says that remember that one of our scenarios is that the network is synchronous but there are more corruptions and so the problem is that ABA off the shelf only guarantees security for up to TA corruptions and so if the network is synchronous we don't really know what it's gonna do as soon as we exceed TA. So the honest for example in the synchronous network the synchronous phase will work and everyone will be in agreement but if the thresholds TS is higher than TA then it could all fall apart in the asynchronous phase now. So you may be seeing kind of a pattern where one of them will do the heavy lifting and the other one just has to not make things go horribly wrong. So in a synchronous network the synchronous phase is really what's going to power the whole thing and give us our nice guarantees and ABA only needs like a stronger validity guarantee. Basically everything should be good at this point in a synchronous network we just need to make sure not to break anything during the asynchronous phase. So we designed a slightly modified asynchronous Byzantine agreement protocol based on this lovely protocol from pod C14 that achieves TS validity and TA consistency. And this is actually where our trade off comes from because as you push TS up it turns out that TA must come down. After all you can't have both of them over and over three but we can push TS up over and over three as long as TA also goes down. Okay so now we've patched all of the holes I sure hope and we have this protocol so everyone inputs they run our modified synchronous Byzantine agreement protocol they either get some output or they output I don't know or if they weren't able to finish that phase then they just use their original input. Everyone runs the asynchronous phase that we just modified and then everyone gets an output. And if the network is synchronous then they always have time to complete the synchronous phase which works exactly as we would hope and if not then they're able to get things back together in the asynchronous phase. Just a quick footnote as I mentioned the honest parties don't necessarily have synchronized clocks when the network is asynchronous and so that means that everyone may observe a different time T out. Everyone might start running the asynchronous phase at a different time but that's okay that's exactly what the asynchronous phase is meant to do it's meant to not worry about stuff like that. So that's okay. All right so we've shown the if by construction and now quickly I'm going to go through the only if or the impossibility result. Okay so imagine that that's you you're honest and the network as we the observer see it is divided into three parts which aren't visible to the honest players like at the low level we're just using this to explain the result. So we have our purple, our blue and our orange groups. Hopefully that looks orange. Okay so assume that so there are TS many people in the purple group, TS many people in the blue group and TA many people in the orange group and this violates our result from the previous part that this TA plus two TS has to be less than N. So this is how we're gonna get our impossibility result by showing that you can't get something to work for these numbers and assume towards a contradiction that we have a protocol that's TS valid in a synchronous network and TA consistent in an asynchronous network. Okay so imagine that you again well smiley guy never receive any messages from any blue nodes but everyone else in the orange and purple groups responds to you normally with as if they had input zero. So you as a person participating in this protocol don't know who's honest and you don't know if the network is synchronous or asynchronous. So what could be going on? One possible explanation is that the network is synchronous. The blue nodes are corrupted and they just don't feel like responding to you so they don't. Everyone else is honest and had input zero and so for TS validity because all of the honest people input zero you need to output zero. So they say yep I had input zero and you say oh I did too when everyone outputs and everyone is happy. Unfortunately there's another possible explanation for the transcript that you saw which is that the network is asynchronous the orange nodes are corrupted. You and all of your friends in the purple group input zero all of the people in the blue group input one and the adversary because the network is asynchronous gets to do whatever they want with the messages and they decide that no messages pass between the blue and purple groups but everyone else is able to talk to each other normally. So this to you looks exactly like this scenario we just described a second ago. So the orange nodes are going to pretend to be honest with input zero and be the same but with input one whenever they're talking to blue nodes. So you say oh I had input zero and the orange nodes say oh yes I had input zero also let's agree on zero and then whenever they're talking to blue nodes who say oh I had input one the orange nodes say oh yes me too definitely let's output one. And so the problem here is that since this looks exactly the same to you as the previous one you should be outputting zero. Symmetrically this looks like something this looks like the symmetric case for everyone in the blue side so they should all be outputting one. However this violates consistency because now you have honest folks outputting different things. So we can't get both TS validity and TA consistency which means you can't get security. And this is basically how we get to our impossibility result which says that TA plus 2TS must be strictly less than N. So to summarize we constructed a protocol for Byzantine agreement that tolerates TS faults if the network happens to be synchronous as long as it respects this bound and we prove that this bound is tight with our impossibility result. So thank you very much. I can take any questions. Yes you need the protocol to terminate in a known time which is why we pick the one that we do which terminates with. Okay I don't really know what to do I don't remember off the top of my head. I can check. Sorry about that. This is slightly tangential but we do, I didn't mention this in our security definition but we do also achieve termination for our full protocol. That's just something that we alighted for the talk. Sorry I didn't catch that last part. So I definitely think that on some level they're trying to do similar things in slightly different ways in that but you could think of this as PBFT for two people who have these two different beliefs so I guess I would say off the top of my head that I think in some ways ours is a little more specific and theirs is a little more general. I have chatted with Dahlia about this but I don't want to make guesses in front of an audience. Sorry can you repeat? Oh yes that was our impossibility result. So our construction shows that we can achieve this for exactly up to TA plus two TS less than N and then this impossibility result shows that as soon as TA plus two TS is equal to N which allows us to get this three part split of the parties then there's no protocol that can achieve both TS validity and TA consistency. You can only get one or the other. So that's how we get, that's why I'm saying the bound is tight.