 Hey, so today I'm going to talk about founding secure computation on blockchains. And this is joined to work with Whipple and Abhishek. So what is the main motivation for it, blockchain? The existence of blockchain, whether irrespective of your individual views on its existence, it exists. And more concretely for us, we want to examine the foundation of secure computation in the context of blockchains. So what does that mean? Now, parties no longer just communicate with each other when they run a protocol, but they also exchange messages with the blockchain. So what does this mean? So we want to ask the question, which is, what change does this make to the study of protocols in the setting, if any? And the first step in this process is obviously going to be establishing a model. And there's been this really, really nice line of work recently, which capture the essence of blockchains and actually prove that under certain assumptions, these blockchains actually satisfy this property. And this is a work starting with this work in 2016, and it's still sort of ongoing. But for this talk, I'm going to consider a very, very simplified model. And it will suffice. The main ideas and challenges in this work can be illustrated in this really simple model. And you'll see that this model is sort of unrealistic in some sense. But I should point out that in our paper, we actually consider the full realistic model. OK, so what is the model? So the model assumes this oracle, which I'll call the blockchain oracle. And it also has an additional timer with some parameter delta. So the delta here is to sort of indicate the average time blocks are created in a blockchain. So over time, parties send messages to the oracle. And after completion of this delta, this oracle collects all the messages along with some identifying information, sends it back. And now we require some certain properties from this blockchain. So what are some of these properties? One is we want all parties to have a consistent view of the blockchain. Next, we want that if messages are sent, they should appear immediately on the next block. And then the third property is that only the oracles can create blocks. Again, this is a super idealistic version of the blockchain. In the paper, we consider a more realistic model. Cool. So we're talking about something what we call a blockchain hybrid model. And what does it mean? I'll say a party is blockchain active if it can sort of read and write to the blockchain. Now, when establishing the model, an important thing I need to note is that the simulator has the same access to the blockchain as every other party. This is in contrast to some other recent work where the simulator can potentially even rewind the blockchain and so on. So this gives the blockchain, in the case where the simulator can rewind, sort of a local flavor of the blockchain to the protocol. While in our setting, the blockchain is sort of global, wherein other protocols and other things can also use the blockchain, independent of this. All right. Great. So I'm going to state our results, first in terms of for zero knowledge, and then more general secure computation. So for zero knowledge, we show that if only the adversary is blockchain active, then black box zero knowledge is impossible. Then we show in the positive result that if we mandate all parties to somehow use the blockchain and we see how, that we can actually have a zero knowledge protocol in this setting. So this is a super constant round protocol. And in fact, this is tight, and we show that a constant round black box zero knowledge in this model is impossible. So for this talk, I'm going to focus only on the first two. And you can see the paper for the impossibility result. So moving on to more general secure computation, we sort of overcome the impossibility and show that concurrent secure computation is possible in the setting. But not everything is all rosy. We also show that universally composable commitments are impossible in this model. Sure. So again, I'm going to focus only on the positive result in this setting. So the main thing I want you to take away from this talk is that in context of secure computation, the blockchains have both destructive and constructive use cases. So let's jump right in. And I'm going to start with zero knowledge and a very, very quick overview of the definition of zero knowledge. So here I have a prover and a verifier, and the prover wants to prove membership of some statement x. And it does so by exchanging messages of the verifier. And there are some properties that typical protocols require. One is completeness, meaning that if the statement is actually in this is a member, then the prover can convince the verifier of this. The second is if the statement is not a member, then no matter how the prover behaves, it shouldn't be able to convince the verifier other than with some really small probability. And the third is when the verifier is trying to cheat, where it's trying to sort of glean some information from the prover that it doesn't already have. And this is defined with respect to an ideal world where only the verifier exists, but not the prover. And this is formalized by saying, there exists some entity called the simulator, which has the same input as the verifier. It doesn't get the additional input that the prover does. And it's able to somehow generate a transcript that looks the same to the verifier. So the verifier is now able to learn any information by itself that it could have learned from the prover. That's establishing this property of zero knowledge. But now in our setting, we have this blockchain looming over us and this definition just to indicate that. So what about the impossibility? So in terms of black box protocols, the advantage a simulator in the black box setting has over a regular prover is that the simulator is able to rewind the verifier or an adversary. It's able to make the adversary go back in time. And so the main idea here is to construct a verifier that prevents a simulator from rewinding. So the idea is really simple. So every time the verifier has to send a message, it takes the transcript so far, puts it onto the blockchain, and then waits for a response. Once the response arrives with the message, it checks if there's a different transcript for the same session already on the blockchain. So for a simulator to be able to rewind, there must be at least two partial transcripts of the same session on the blockchain. So the verifier will never respond to the prover if it finds another session. So this prevents the simulator from ever being able to rewind the blockchain in the setting. Note that here only the verifier is using the blockchain. The prover is sort of oblivious to the existence of the blockchain. So this is going to be an important point where we show that it's impossible if only the adversary's blockchain active. And but if all the parties are blockchain active, then we actually show some positive results. So the structure of the zero-knowledge protocol follows this preamble approach from Prabhakaran, Rose, and Sahai. And specifically, it has these three stages. The first is the verifier committing towards a challenge. And the second is what we're going to call extraction opportunities or slots. This is to enable a simulator to extract the challenge that the verifier commits to. And the last phase is going to be the proof system. Concretely, you can think of it as the Hamiltonicity proof system or something like that. So why do we enforce this structure? This structure is useful because it gives you the simulation guarantee that if you're able to extract the challenge in even one of these slots, then the rest of the protocol can be simulated in a straight-line manner, no more rewinding. So if I'm able to rewind once during these slots, then I don't have to bother with rewinding any time in the future. So let's look at how this protocol could potentially work. So now we have the blockchain. And the main idea is to use the blockchain as a course timer. So what does that mean? That means every party is going to have a timer with some timeout parameter k. And every time a block comes, it's going to come down on the timer. And then it's going to run the protocol. So for instance, I should note importantly that parties are not required to post anything on the ledger. So the use of the ledger in this protocol is only going to be read. So for instance, say they run this first slot and a block appears, both of them added. And the second block appears, so on. And say now the third block appears. Here I'm assuming the verifier is cheating, so it hasn't updated its local state. But the prover sees, OK, my timeout was three and there are three blocks here. I'm done. And the verifier hasn't completed, so I'm going to abort. So the question is, why is this useful? How does this help us? So we want to recall the impossibility. We want to stop the adversary from preventing rewinding, right? So contrary, let's think of the case where you have four slots and a timeout of three. And then if the protocol actually computes, you're going to have potentially less than three blocks. So the yellow arrows indicate a block appearing during the execution of the protocol. And now I'm going to call the blocks where the slots where a block appeared as bad, and the slots where the block didn't is good. Now I have two good slots where the adversary is not waiting on a block, right? Now I can potentially rewind the adversary to my heart's content, extraction, done. So are we done, though? And it turns out there is a really small, subtle issue which shows up in the context of this setting is that of timing leakage. What does that mean? So it means that simulation typically takes time larger than the running time of the adversary, of the honest execution of the protocol. So in, for instance, concretely, think of this really bad case where the actual execution runs, it maybe takes one block duration in the blockchain world. But while simulating it, it takes three blocks duration. And this is now trivially distinguishable by a distinguisher who has access to the blockchain. So the important point to note is that the time the simulator takes to complete simulation and the number of computation steps that the simulator takes are slightly different, right? So now what we can hope to do is, if it's parallelizable, do some of these computation steps in parallel, and then hopefully there is no timing leakage. And this is exactly what we do. So we have this notion of a main execution, and we have the notion of a rebound execution. And note that these are run in parallel. And I've indicated by the height to be the duration that the verifier takes to respond to the challenges or the execution of the slot. And note that even for the same slot in the rebound execution, the verifier can potentially take longer. And what's the main difference between the main execution and the rebound execution is that the main execution, you isolate the adversary from the blockchain. Meaning any query that it sends to the blockchain, you don't send it. Anything that the blockchain sends, you don't send to the adversary. So what does this mean? So if I have potentially blocks coming from the blockchain, I know that in these blocks on the rebound execution, the adversary is expecting a blockchain, a block rather. So these are all bad slots. Now I'm guaranteed there's at least one good slot, and I can rewind. And this is pretty much all we needed, right? Once we get one slot where we can rewind, we're done. So it turns out that for simulation to, for extraction to succeed, we need at least super constant many slots, which in turn means we need super constant many rounds. And unfortunately, this turns out to be tight, and we show in the paper that there does not exist a constant round protocol in this setting with black box simulation. I should note that there are some similarities, superficial similarities to the timing model where parties have synchronized clock and have delays to make protocols work, but there are slight differences in the setting. In the timing model, the simulator can control the clock. Here sort of there's an unforgeable clock from the blockchain. And in their timing model setting, the adversary can be rebound at any point, and but here we have this notion of safe and unsafe, and this requires actually new rewinding techniques. Okay, moving on to concurrent self-composition. So what is secure computation? A really, really quick overview. Parties jointly want to compute a function of the private inputs, they communicate, and at the end, everybody gets their output. So how do you define security? Security is defined with respect to an ideal world where everybody sends their inputs to an ideal party, and the ideal party computes the output and sends it to them. So you say that for every set of corrupt parties executing the protocol, there exists a simulator that corrupts the same set of parties and the views are sort of indistinguishable. You don't need to really know what the exact definition is to proceed, but again, to know we have a looming blockchain. So let's consider three protocol executions. These are the transcripts of the execution of the same protocol with potentially different inputs. So I consider this notion of only self-composition where it's only the same protocol that's being run, as opposed to general composition where I might have protocol A and protocol B messages. And the self-composition allows for arbitrary interleaving. So I can concurrently arbitrary interleave the messages. And why is this model interesting? It turns out that it's impossible in the plain model. So what do we do? The prior work typically takes, you know, there are some weaker security notions, or alternatively, you establish some trust assumptions. In our setting, we construct a protocol in the blockchain model. So what does that mean? It means that our protocol works in a sort of decentralized trust assumption, right? So it's not like we're somehow overcoming the impossibility. We're showing that it is possible to construct a protocol, and this implies that, you know, it's sort of in the decentralized trust assumption. Okay, so just quickly to summarize why the impossibility holds. It was initially showed by Linda in 2004 that it's impossible in the black box setting, and this impossibility was extended to the non-black box setting and, you know, various other models. So the basic idea is this. If I think of blue as one protocol execution and green as the other, say I need to rewind at this point. And the adversary at green has committed to its input. But the problem is now when I rewind beyond the input commitment phase, the adversary can potentially change the message or change its input. And this leads to a whole lot of problems during simulation and it's something that we want to avoid. And I'll come back to this point in a bit. Okay, so the structure for our concurrently secure computation to identify what we need is based off these, you know, works in weaker models and the protocol works like this. Most of this is sort of immaterial, but I'll focus on the important part. So I have some notion of a trapdoor generation. I have a commitment phase. I have coin tossing and then the actual protocol. And it turns out that it's sufficient to build a commitment scheme that's concurrently extractable. And once I do that, the rest of the protocol as before can be sort of simulated in a straight line manner and I don't need to rewind anywhere else. So the point is that I now need to build this concurrently extractable commitment scheme. And the structure is the same as something that you've seen before when I talked about the zero-knowledge protocol. I have a commitment, initial commitment phase where the committer commits to a message. And as before, I have these extraction opportunities or slots. So remember, the impossibility stemmed from the fact that you were rewinding beyond the sort of, the input commitment of a party. Now, intuitively, I'm going to sort of commit to the blockchain, right? So if I commit to the blockchain, there's one would hope that there's no way of going beyond it because now I've committed something to a blockchain, I can't change the value that I committed to the blockchain. So the idea is this. Now, the first message, which is the commitment, sends it to the blockchain, waits for a block to be created. Now, both the committer and the receiver have this commitment, right? Now, as before, they have this timer and they start the execution of the protocol. The rest of it is identical as in the zero-knowledge case. But how do we extract? Remember, now, because we are in the setting of concurrent execution, the slots itself might be split over multiple rounds, right? And now they might be interleaved with other slots and rewinding one slot could potentially lead to rewinding other slots and so on, and this leads to an issue, right? And to solve this, we look to this really, really nice work in this sort of independent setting or a different setting by Goya, Lin, Pandey, Paas, and Sahai, and they talk about extraction in the presence of a constant number of external messages. They show that if you have a constant number of external messages, then you can construct a concurrent, secure, concurrently extractable commitment scheme, right? That's great, like, can we now apply this to our setting? We have, you know, the external messages are now messages from the blockchain, and now we're trying to extract while we have the blockchain, and remember, we can't go beyond, we can't rewind beyond any of the blockchain messages because, you know, the blockchain is fixed. But unfortunately, it turns out that the number of messages that the protocol execution gets from the blockchain are not constant. In fact, you know, we can only weakly bound it by the number of protocol executions that are running in the concurrent setting. So our main challenge, which, unfortunately, I won't have time to go over, is to show how this sort of robust extraction lemma extends to the setting where we have this blockchain, where there are potentially non-constant many number of messages. And to sort of conclude, I've shown you sort of protocols that the destructive nature in the sense that, you know, general protocols that we know don't extend to the blockchain setting, and then we have these constructive protocols where I've shown you, OK, zero noise protocol that actually works, and in fact, we are able to sort of overcome some impossibility result in the concurrent composition setting, and we actually can give a protocol in the blockchain model. And that's it, and if you have any questions, I'd be happy to take them. Questions? So these external messages that come from the blockchain in your construction, do they need to have some structure? Like is it like some actual part of the, or is it just any message from the blockchain? So for us, we assume that the blockchain oracle sends messages only periodically, and it's identifiable as, you know, blockchain messages. So I can't force them, in the simplified model, at least, yes. So actually, this is also for the zero-knowledge protocol. You sort of just use the blockchain as a timer. Yes, for the zero-knowledge protocol, we use it only as a timer. But for here, you actually have to post a message to the blockchain. So can you, like, wouldn't it also make sense to use the blockchain also, like, for some kind of computation in the protocol? Sure. I mean, so we want to use it in a minimal sense, right? We are just saying, OK, the blockchain exists. We are talking about the most general setting, you know? This is, in an idealized world, this is what one would hope a blockchain gives you. We don't know about, you know, can you do computation on the blockchain? Maybe it's sort of orthogonal. Why shouldn't the simulator be allowed to rewind the blockchain? OK, so that's more of a different philosophy, in the sense that you can allow the simulator to rewind the blockchain, but then the blockchain can be only used by the protocol that the simulator is simulating, right? Because if you're revinding the blockchain, it can't be used by another, you know, something, some other party, because now it's seeing the blockchain roll back. So you want the blockchain to be global, in the sense that I'm using the blockchain to do this, but other parties elsewhere in the world are also using the blockchain to do something. So I don't want the simulator to be able to rewind the blockchain. Do you have any restriction on the blockchain, or you can use even a Bitcoin blockchain to run your protocol? So this follows from these modelings of the blockchain that as long as the protocol satisfies these certain properties that these recent works show as modeling of the blockchain, it's sufficient for us. It's like, for instance, don't you have a space issue? Because if many players want to write, then there is a block site that is limited. Sure, those are potential issues that we sort of ignore and assume that, you know, how many of our messages are set? Every block is unlimited. Yeah, so we assume the idea. Thank you. Let's take the speaker again.