 Hi everyone. I'm Sophia and I'm going to be talking about YOSO. YOSO is joint work with Craig, Shai, Hugo, and Tal at Algorand and with Jesper and Bernardo at Orhus University and the Concordium Blockchain Research Center. YOSO stands for You Only Speak Once and as the name suggests, it describes a class of protocols where no participant needs to speak more than once. This kind of protocol is particularly useful when dealing with a strong adaptive adversary who can kill or corrupt a party as soon as it speaks. In this work, we make two contributions. We define a formal YOSO model and we show two MPC protocols with guaranteed output delivery within that model. Before getting into our contributions, I'd like to give more motivation for the YOSO model, in particular in the context of MPC. Let's start with the usual MPC scenario. So imagine that Alice, Bob, and Charlie want to compute a joint function f of their secrets x1, x2, and x3. But the problem is none of them are willing to reveal anything about their secrets except for the function output. So one approach is for the three of them to find someone that they all trust and send their inputs directly to that trusted party and then have that trusted party publish the function output y. But trust is hard to come by and it could be that there isn't any one party that all three of Alice, Bob, and Charlie are comfortable relying on. So using secure multi-party computation or MPC for short, Alice, Bob, and Charlie can instead outsource the computation of f to several parties. They don't have to trust any specific party. Each one of Alice, Bob, and Charlie only needs to trust that some of these parties are behaving honestly without necessarily knowing which ones. So in other words, they need to trust that if an adversary is controlling some of these parties, maybe by having installed malware on the machines, that adversary was only able to corrupt up to some threshold T of the parties. So then during the MPC protocol, these parties talk to one another and as a result of that conversation, Alice, Bob, and Charlie learn the function output. The first guarantee we want from MPC is that as long as the adversary corrupted fewer than the threshold T of the parties, Alice, Bob, and Charlie learn the correct y. So the adversary shouldn't be able to trick Alice, Bob, and Charlie into accepting the wrong output. But even more than that, we demand the strongest MPC guarantee, which is guaranteed output delivery. So the adversary shouldn't even be able to carry out a denial of service attack and prevent Alice, Bob, and Charlie from getting anything. And of course, we also want privacy. So we want to be sure that the adversary and the machines she controls don't learn anything else about X1, X2, and X3. Okay, but now let's come back to our assumption that the adversary corrupted fewer than the threshold T of the parties. If we only have a couple parties and we have a very powerful adversary, maybe it's unrealistic to assume that she can't corrupt more of the parties. And if that happens, we don't get any of our guarantees, we don't get guaranteed output delivery or privacy. So however many parties we think our powerful adversary can corrupt, we need to involve enough parties in our computation to make sure that our threshold T is higher than the adversary's corruption power. If we think that the adversary can corrupt up to a million parties and we're running an MPC, where the corruption threshold T is equal to half of the participants, we need to make sure that we have at least two million participating machines. But once we involve millions of parties, maybe by outsourcing to blockchain, we run into an efficiency problem. Almost all MPC protocols require that all participants talk to all of the other participants. And when there are just a couple of participants, this isn't so bad. But when we have millions of parties, this gets to be prohibitively inefficient. And in fact, the goal we want to set for ourselves to avoid this kind of inefficiency is that the total communication of our protocol be sublinear in the number N of participants. So this means that in a given round of the computation, only a small set of parties, which we'll call a committee, should say anything. And in this picture, our speaking committee are the parties colored in blue. The issue now is that once this committee has spoken, the adversary who's always watching the network sees who spoke and learns that this committee of parties might be important. Since the committee is relatively small, the adversary might be able to quickly target all of them for corruption, maybe with some sort of zero day exploit. So we want to make sure that even if we're dealing with a powerful adaptive adversary, who's able to instantly corrupt anyone they want, our protocol still gives us the guarantees we want, as long as the adversary is limited to corrupting T, which we take to be half of the total number of parties. In order to do that, we need to make sure that even if every party is killed immediately after it speaks, we still get our guarantees. And that's why we come to the you only speak once or you so model. After the first committee is dead, if the computation isn't complete yet, we need another committee to pick up the torch and continue. But as soon as that committee speaks, it might also be killed. And so yet another committee, the pink committee must rise to take its place and carry the torch and so on and so forth. So in the you so model, even if every party is killed as soon as it speaks, the computation must carry on to completion. Now that we have our motivation, let's move on to our contributions. Like I mentioned at the beginning, there's two parts to our paper, the formal modeling of you so protocols and to you so MPC constructions. The great thing about our model is that it cleanly splits you so protocols into two components, which can be considered totally independently. So the first component is RA, which stands for role assignment. It deals with how committees can be chosen in such a way that the adversary can't anticipate who they will be. And the second component, which is role execution deals with what these committees will do once they're chosen. Let's take a quick look at role assignment. We've seen this kind of role assignment in a number of places already. Most notably, we have Bitcoin where the role of block creator is assigned through proofs of work. And this has exactly the property we're looking for, which is that no one knows before the minor speaks that that particular minor has won the right to publish a block. So even the most clever adaptive adversary can't target the next block minor until it's too late. And they've already played their role. Algorand does something similar, but without proofs of work. They use verifiable random functions to run a lottery. Just like in Bitcoin, no one knows who the winners of the lottery will be until they've spoken and thus already played their part. Bitcoin and Algorand are different from NPC protocols in that the roles parties play don't require any secrets. But if Alice, Bob and Charlie want to outsource an NPC, they will have to secret your their inputs to the appropriate committee. And they can't know the identity of the committee. If that identity is public, this tells the adversary exactly who they should target. This leads to a difficult question. How can we enable the sending of a secret to one specific party without knowing who that party is? The work of Ben Hamouda at all from TCC last year gives a really elegant solution using something called nominating committees. And we also have an ongoing work on E print with an alternative approach, which supports a higher threshold team. Both of these solutions results in the publication of a set of anonymous public keys. So the owners of the corresponding decryption keys know who they are. But no one else knows who owns the corresponding decryption keys. So once that's done, anyone can encrypt a message under one of these keys and broadcast it without knowing who will be able to decrypt. Only the party holding the corresponding decryption key will know that this message is intended for her, and she'll be able to decrypt it. The guarantee we need from the real assignment mechanism is that at most a threshold T prime of the members of the committee should be corrupt. And we take T prime to be half of the size of the committee. Once the rules have been assigned, we can move on to executing the protocol. The execution can be specified in terms of roles, not the machines executing those roles. And examples of roles are the first member of the third committee, or maybe the verifier in the seventh NISIC. The roles communicate with one another over broadcast channel and through private communication to future roles, who haven't spoken yet, using the anonymous public keys. The specified protocol need only be secure as long as at most the threshold T prime of the members of each committee are corrupt. And it's up to the role assignment mechanism to guarantee that this is in fact the case. I want to mention two existing protocols that are compatible with this model. So the first one is the work of Ben Hamouda et al. from TCC 2020, which deals with maintaining and resharing a secret from committee to committee. Another cool protocol is fluid MPC, which is also at crypto this year, and they describe how to do MPC with abort. They don't explicitly use a role assignment mechanism, but their protocol could be combined with one to get YOSO style guarantees. In our protocols, we prioritize preventing denial of service attacks. So we aim for guaranteed output delivery instead of security with a board. And this brings me to our two MPC constructions that achieve this. Let's start with a construction that uses computational assumptions. In this construction, we're going to use one global public encryption key. And in the slide, this is the lock in the upper right corner, and it's available to everyone. The corresponding secret key will be secret shared among the current committee, which is in blue. Anyone can provide an input to the MPC by encrypting a secret to the public key and broadcasting the ciphertext. But in order to use this for MPC, we need several properties of the encryption scheme. The first is that decryption should be as non-interactive as possible. This means that each committee member should be able to derive a partial decryption from the ciphertext and its key share. And these decryptions can be combined to recover the plaintext. So on the slide, this recovery is through addition, but it doesn't have to be. And as a side note, so of course before publishing the partial decryption, the committee members need to erase their state and their key shares to make sure that our adaptive adversary can't learn the key when she corrupts them. All right. So another requirement is that the secret key can be reshared with minimal interaction. This is necessary because otherwise once our blue committee speaks, the secret key and all secrets that haven't been decrypted yet are lost forever. So in the same breath in which they publish the partial decryptions, we want our blue committee to reshare the secret decryption key to the next committee, which is the one in green. Now, what we have lets us maintain secrets and reveal them at the appropriate time, but in order to support computation on those secrets, we need an additional property. We need our encryption scheme to be homomorphic. If it's fully homomorphic, then we're basically done. We can have the blue committee perform the entire computation homomorphically and publish partial decryptions of the output that can then be combined to recover the output itself. But using a fully homomorphic encryption scheme wouldn't be concretely efficient, so we might want to use an additively homomorphic encryption scheme instead. Then we would use beaver triples to enable every multiplication. I won't explain beaver triples in the interest of time. I'll just say that they can be used for multiplication, but their use does require some interaction, and they can be generated for us by committees that don't hold decryption key shares. Each of our key holder committee members then performs only linear operations homomorphically and uses a beaver triple to do a multiplication, which involves the decryption of some masked values. Our blue committee performs this decryption of masked values, and in the same breath, they need to reshare the secret key to the next committee, which picks up the computation from there. This next green committee does more linear computation, and the next time a multiplication needs to be done, it again uses a beaver triple, and again in the same breath, hands the computation over to the next committee, which might do more linear computation. And finally, when the computation is over, the last committee decrypts the output. This whole thing is very similar to the CDN protocol from 20 years ago with basically minimal changes to enable the passing of the computation from committee to committee. That's all I want to say about the computational protocol. So next, let's take a look at our second construction, which is information theoretic. It might seem a little funny to consider an information theoretic construction when it'll need to run on top of a computational roll assignment protocol, but we think it's still interesting to try to minimize the necessary assumptions. Trying to eliminate assumptions altogether turns out to be quite challenging in the YOSO protocol. Most information theoretic MPC techniques use something called verifiable secret sharing. Like all forms of secret sharing, verifiable secret sharing, or VSS, proceeds into phases. We have dealing where the blue party deals the secret to the green parties and at some point down the line, the green parties might try to reconstruct that secret. However, in VSS, the dealing phase has an extra verification step where the shareholders and possibly the dealer talk more to make sure that everyone agrees that we have a valid reconstructable sharing. The problem with this in the YOSO model is that after this verification step, everyone has spoken. So the fact that the green party has once had a valid sharing is now totally useless since they're probably dead. A simple yet powerful solution to this is something we call future broadcast. So in a future broadcast protocol, each of our parties takes the messages she would have sent in the future and shares them to a separate fresh committee that's in charge of then sending that message on her behalf. This lets our parties speak once but at the same time schedule multiple messages that can be sent at different times in the future and can be triggered by arbitrary conditions. Our parties schedule some messages for the verification step and some for future use, whether for reconstruction or within an NPC. One great thing about future broadcast is that it can use a less powerful tool than VSS. We only need robust secret sharing, which doesn't consider a corrupt dealer. And this is perfect since if our dealing party is corrupt, she could say anything anytime she wants in the future and we don't really need to commit her to something at the time of the future broadcast itself. Another neat feature of this scheme is that if we think of all the values sent using future broadcast as resharings of the original share, we basically for free get the values held by the set of red and orange committees are equal. This is true since the honest members of the green committee will always honestly reshare their actual shares and as long as there are enough honest green parties, the corrupt parties will not be able to tamper with the reshared values. So there's really much more that we need in order to get from verifiable secret sharing to a full-fledged NPC. For instance, we need our parties to be able to prove that something they publish is a product of two things that were shared. And there are many more subtleties and techniques that we need to get to our NPC that I just won't go over. This is a really simplified picture. Each of these tricks uses layers upon layers of additional committees which makes our information theoretic solution far from practical but it's still a really interesting feasibility result. That's all I want to say about our second construction. So to recap, the Yoso model gives us a neat separation between role assignment and role execution and in our work we show two Yoso NPC protocols, one of which is computational and one information theoretic. Both of those get us guaranteed output delivery against an adaptive adversary which can corrupt up to half the total number of parties and they both have total communication which is sublinear in N which is really cool. Finally, Yoso unearths a huge number of open problems. Basically everything we've asked about NPC before, we can ask again in the Yoso model. So for instance, notice that our computational construction requires some setup in the form of the distribution of the secret key to the first committee. We can ask can we get efficient protocols without setup? Can we get constant round protocols without setup? Can we do best of both world's protocols which get guaranteed output delivery when half of the parties are corrupted and unanimous abort if there's a dishonest majority? And so on and so forth. There's really, the sky is the limit here. Thank you everyone for listening and I hope to see you at the live session.