 Hi, I am Lisa and I will be talking about our work blockchains enable non-interactive MPC This is a joint work with we pull goyal Brian partner and if I'm song First let us briefly talk about what is MPC. It stands for secure multi-parter computation Imagine for parties Brian if I'm we pull and Lisa wish to compute a function F on their private inputs X1 X2 X3 and X4 However, the parties do not trust each other MPC provides a solution to this problem allowing the parties to compute the output of the function While ensuring that nothing besides this output is leaked Since its formal introduction in the 80s, there has been a lot of research on MPC on its assumptions its communication complexity And important for us its round complexity Now we know that four routes are necessary and sufficient for MPC in the fully malicious case in the plain model Unfortunately, even the protocols which satisfy this optimal round complexity are sometimes problematic as they typically assume synchronous communication from the participants Why is this a problem? Well, imagine a voting process in some large country If the voting is conducted via an off-the-shelf MPC protocol All voters of that country must be online at the same time, which seems like a very unrealistic assumption In our work, we attempt to alleviate this problem For this we will rely on public bulletin boards and we will assume that these bulletin boards provide an unforgeable proof of publication As multiple prior works noted, site bulletin boards exist in real life with the most notable example being the blockchains In addition to the bulletin boards, we will assume something which we call conditional storage and retrieval systems, CSARs Intuitively they allow parties to securely store a secret under a release condition, which can be basically any NP statement Then if some party shows that it can satisfy this release condition, the secret is privately released to that party Recently a few works appeared that provide similar functionalities based on blockchains And we show that one of them indeed satisfies our security definition for CSAR Since both bulletin boards and CSARs can be instantiated using blockchains In the following for simplicity, we will say that we work in the blockchain model Note that there are two kinds of MPC participants in our work We will refer to the parties who provide inputs as contributors And we will refer to the parties who wish to receive the output as evaluators Note that some parties might be both contributors and evaluators, but this is not a requirement In fact, these two groups can be completely disjoint In this model, our goal will be to provide a solution for MPC Which satisfies the property that MPC participants are not required to interact with each other And MPC contributors who are not interested in learning the output can go offline after a single round More formally, we show that any MPC protocol pi Which is secure against fully malicious adversaries Can be transformed into another MPC protocol pi prime in the blockchain model Which is also secure against fully malicious adversaries and does not require participants to interact with each other MPC contributors are required to participate for only a single round The evaluators might need to participate for multiple rounds The adversary is allowed to corrupt as many MPC contributors in pi prime As it can corrupt MPC participants in the original protocol pi Additionally, the adversary is allowed to corrupt all of the evaluators In addition to our main result, we provide further variations In the first one, we show that in our scheme, the communication and state complexity of the underlying MPC protocol Are very important as they have implications for the number of CSAR calls that we make in our resulting construction To improve the efficiency of our scheme, we propose an MPC protocol Which achieves the property that its combined communication and state complexity are independent of the function f that we are trying to compute Using this new protocol as the base of our transformation We achieve a result similar to our non-interactive construction, which now additionally has an improved number of CSAR calls Finally in the other variation of our main construction, we show how a similar non-interactive transformation Can be achieved with the property that the resulting protocol additionally provides guaranteed output delivery For this, we will require that the original protocol provides guaranteed output delivery as well In the following, we will start by discussing the main ideas of our construction Next, I will provide an overview of the challenges that we encountered and the ways we solved them We will finish by discussing the variants of our construction that provide further desirable properties Okay, so let's dive right in The main idea in our construction is fairly simple Given an interactive MPC protocol pi, each MPC contributor garbles the next message function for each round of pi While hard coding its private inputs Then each contributor simply stores each of its garbled circuits and via keys with the CSAR The evaluators can then retrieve the garbled circuits of all the participants from the CSAR and just execute these Well, this sounds fairly simple and straightforward In the construction one must be very careful since there are multiple issues that arise due to its non-interactive nature Note that the garbled circuits of the parties do not have access to the same information as the parties in the original interactive protocol In the sense that the garbled circuit only knows the inputs given to the circuit It does not know, for example, what inputs have been fed into other garbled circuit And it doesn't know whether it has been maybe already executed multiple times on different inputs and so on This certainly cannot happen during the interactive protocol Parties see all the broadcasted messages and they know in which round of the protocol they are at any given time And cannot be forced into executing the same round twice There are multiple challenges that we had to overcome in our construction due to such issues And I will now introduce you to a few of them First note that we are using yaw's garbled circuits and there are a few issues that arise because of their use in our non-interactive setting First of all yaw's construction satisfies the selective security notion Which in particular assumes that the adversarial input is known before the garbled circuit is revealed to the adversary And second of all the security proof of yaw's construction crucially relies on the fact that only a single wire key is revealed for each wire However, in our case, parties store the wire keys before the evaluator even starts the execution And so it is not known which wire keys will be needed during the execution Effectively, this means that before a garbled circuit and its wire keys are obtained by an evaluator The evaluator must fix the input it will be feeding into the Garbled circuit and we must ensure that it receives only the wire keys for that particular input We achieve this by having the evaluator commit to its execution on the public bulletin board In each round i the evaluator will execute the garbled circuits for this round i And post mi which is the concatenation of the outputs of all garbled circuits of round i Only after this commitment mi is posted will the csar release the garbled circuits of the next round Specifically the existence of message mi is checked as a part of the csar release condition This solves the selective security issue as the evaluator is now fixing its input before it obtains the garbled circuit As for the wire keys recall that at the time the parties store those with csar The input which will be used by the evaluator is not known So the parties must store both the key for zero and one for each wire The crucial idea here is that the parties store these keys in two separate csar requests Then the release condition for bit b on some wire x in particular demands that the message mi Contains exactly bit b on the position x This solves the problem of revealing only a single wire key for each wire Another challenge that you had to overcome in our construction is the issue of input consistency Note that if say Weeple broadcasts a message in the original interactive protocol both brian and ifan see this message While weeple's message is part of the input to both brian's and ifan's garbled circuits By itself these circuits cannot verify that the exact same message was used in the input to the other circuit as well So we must somehow prevent a dishonest evaluator from using inconsistent inputs to the garbled circuits This is again solved using the public ballot and board commitments to the course of execution Specifically in the release condition for the garbled circuits and wire keys We will accept only the very first message published by an evaluator as a commitment to a certain round This ensures that there is only a signal message for which any evaluator will receive the keys Another issue which is again related to the non-interactive nature of our protocol Is a problem that the evaluator could retrieve the garbled circuits and execute these out of order This is clearly something that would not happen in the original interactive protocol Where honest parties follow exactly the predefined order of execution So we must ensure that the evaluator does not see the output for some round i Before it fixes its execution for all rounds j which come before i This is again solved using the commitments and carefully constructing the CSIR release conditions In particular to release garbled circuits of a certain round The evaluator must prove that it already committed to the outputs of all prior rounds This is ensured by the CSIR release condition which checks that the outputs for all prior rounds have been posted Finally note that typically a protocol pi would use some data across multiple rounds A party pj's next message function of round i Will output as state as ji And this state will be used as part of the input to the next message function of the next round This state cannot be pre-computed before the protocol execution And it is assumed to be kept private So in our case we would need to ensure that the state cannot be viewed by the evaluator But can still be used by the party's garbled circuit for the next round We solve this problem by modifying the original next message function Specifically we encrypt the state under the public key of the party pj who is doing the garbling And output the encryption of the state instead of the state itself In the next round we simply decrypt this ciphertext to obtain the state and then continue with the original next message function This allows contributors to use state across multiple rounds while ensuring that the state is still kept private Hopefully this gave you some idea of what challenges we encountered and what approaches we took to solve these As a recap in our main result We provided a construction which given a protocol pi in a fully malicious model Transforms it into another protocol pi prime in the blockchain model Which does not require interaction between the abc participants and requires only a single round of interaction from the contributors In addition to this main construction, we provide two variations One is the protocol which focuses on improving the number of csar calls of our construction The other is the protocol which achieves guaranteed output delivery Meaning that the dishonest parties cannot prevent honest parties from learning the output We start with improving the number of csar calls of our construction Note that the csar storage requests consist of each contributor Storing a gubbled circuit for each round of the construction as well as storing two wire keys for each wire of each gubbled circuit Similarly, the release requests each evaluator will perform consists of retrieving All gubbled circuits as well as a single wire key for each wire of each gubbled circuit So as you can see the number of input wires in our construction Is the dominant factor in the number of csar requests At the same time, we know that the inputs to each gubbled circuit are messages exchanged by the parties in the previous round Plus the state passed from the gubbled circuit of the same party from the previous round Together this means that the number of csar requests is approximately the same as the combined communication and state complexity of the underlying protocol pi To reduce this combined communication and state complexity We propose a protocol which is secure against fully malicious adversaries And which combined complexity is independent of the function being computed To achieve this we start with an mpc protocol by brakowski at all This protocol is secure against semi malicious adversaries and its combined communication and state complexity Depend only on security parameters, number of parties and input and output sizes Note that this satisfies our requirement of combined complexity being independent of the function f To achieve a similar result in a fully malicious setting We extend the semi malicious construction by kylian's pcp-based zero-knowledge protocol Which is executed after each round of the semi malicious construction to ensure the correct behavior of the parties Here minor tweaks are needed in order to ensure that the combined complexity of the resulting protocol still satisfies our requirements Specifically in kylian's construction the pcp is used across multiple rounds And so typically it would be stored as part of the state However, we can easily remove this requirement by simply recomputing the pcp whenever it is needed Building up on this new protocol as well as our main result We are able to achieve a protocol in a blockchain model, which is secure against fully malicious adversaries Does not require interaction between the mpc participants Is singled around for the parties who supply inputs but are not interested in the output and The number of csai requests in this protocol is independent of the function f which is being computed Our final result is a non-intractive construction, which provides the guaranteed output delivery property It might seem like using an underlying protocol, which provides guaranteed output delivery is enough to ensure that the same Property holds after our non-intractive transformation However, this is not the case As i mentioned earlier in our original construction the csai release condition considers only the very first message published as the output of some round to be valid This needs to be done to ensure that only a single wire key is revealed for each wire of each garbled circuit Those a dishonest evaluator can always disrupt execution of an honest evaluator by publishing a wrong message on the bulletin board We solve this issue by first of all introducing a deadline By which all garbled circuits and keys must be stored Then we switch to a csai which releases the secrets publicly after a release condition has been satisfied Note that already in the original construction all of the outputs of the garbled circuits are signed by those garbled circuits Now if an evaluator attempts to commit to an output When checking the release condition the csai can use the now public information about the previous round So garbled circuits and wire keys and can verify whether the evaluator was behaving honestly If this is the case even if the output is malformed for example has some invalid signatures The evaluator is not at fault and the malformed output is the result of some malicious mpc contributor providing an invalid garbled circuit Obviously in this case the evaluator is allowed to proceed Since the evaluator can now always advance in its execution We can conclude that if the original protocol satisfies the guaranteed output delivery Our new protocol has this property as well To conclude I would like to elaborate on how our work fits into the existing mpc literature The line of work which is very relevant to ours are the works on non-intractive mpc These works typically consider a setting where a number of parties submit a single message to a server Essentially an evaluator that upon receiving all of the messages computes the output of the function Our work differs from the line of work on non-intractive mpc in several aspects First in our work parties do not need to communicate directly with the evaluators So there is one additional level of non-intractiveness Second in those works the adversary is typically allowed to learn the so-called residual function Which is the original function restricted to the inputs of the honest parties This in particular means that the adversary can learn the outcome of the original function on every possible choice of adversarial inputs This is not the case in our construction Another very interesting line of works are those on reusable non-intractive secure computation Intuitively NISC typically consider two parties A sender and a receiver A receiver starts by publishing a reusable encoding of its input x This allows any sender with input y to let the receiver obtain the output of any function f computed on x and y By sending a single message to the receiver This setting is slightly different from ours Where we aim to ensure that parties do not need to interact with each other And can leave after the first round if they are not interested in learning the output Finally several works appeared quite recently that similar to us aim to improve the flexibility of the mpc protocols Gage mpc for example focuses on designing non-intractive mpc protocols Which use blockchains to provide short term security without residual leakage This work uses an incentive based notion of security Fluid mpc allows parties to dynamically join and leave the computation And he also focuses on status parties, which can only send a single message Simulator us user and fluid mpc allow the mpc participants to leave after the first round if they are not interested in learning the output however to execute the mpc protocol both schemes rely on A number of committees of different parties which interact with each other And each committee must provide honest majority In our case, there is no need for such an assumption on the evaluator's side Even if there is a single evaluator who is dishonest our protocol still preserves input privacy of the honest contributors I thank you for your attention. And if you have any questions, please feel free to send me an email. Thank you