Fair and Robust Multi-party Computation Using a Global Transaction Ledger

Abstract

Classical results on secure multi-party computation (MPC) imply that fully secure computation, including fairness (either all parties get output or none) and robustness (output delivery is guaranteed), is impossible unless a majority of the parties is honest. Recently, cryptocurrencies like Bitcoin where utilized to leverage the fairness loss in MPC against a dishonest majority. The idea is that when the protocol aborts in an unfair manner (i.e., after the adversary receives output) then honest parties get compensated by the adversarially controlled parties.

Our contribution is three-fold. First, we put forth a new formal model of secure MPC with compensation and show how the introduction of suitable ledger and synchronization functionalities makes it possible to describe such protocols using standard interactive Turing machines (ITM) circumventing the need for the use of extra features that are outside the standard model as in previous works. Second, our model, is expressed in the universal composition setting with global setup and is equipped with a composition theorem that enables the design of protocols that compose safely with each other and within larger environments where other protocols with compensation take place; a composition theorem for MPC protocols with compensation was not known before. Third, we introduce the first robust MPC protocol with compensation, i.e., an MPC protocol where not only fairness is guaranteed (via compensation) but additionally the protocol is guaranteed to deliver output to the parties that get engaged and therefore the adversary, after an initial round of deposits, is not even able to mount a denial of service attack without having to suffer a monetary penalty. Importantly, our robust MPC protocol requires only a constant number of (coin-transfer and communication) rounds.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Secure multiparty computation (MPC) enables a set of parties to evaluate the output of a known function $f(\cdot )$ on inputs they privately contribute to the protocol execution. The design of secure MPC protocols, initiated with the seminal works of Yao [31] and Goldreich et al. [21] has evolved to a major effort in computer security engineering. Beyond privacy, a secure MPC protocol is highly desirable to be fair (either all parties learn the output or none) and robust (the delivery of the output is guaranteed and the adversary cannot mount a “denial of service” against the protocol). Achieving fairness and robustness in a setting where there is an arbitrary number of corruptions, as desirable as it may appear, is prohibited by strong impossibility results stemming from the work of Cleve [16] who showed that coin-flipping is infeasible in any setting where there is no honest majority among parties that execute the protocol. These impossibility results, combined with the importance of the properties that they prevent, strongly motivate the exploration of alternate – yet still realistic – models that would enable fair and robust MPC protocols.

With the advent of Bitcoin [28] and other decentralized cryptocurrencies, the works of [1, 2, 7, 27] showed a new direction for circumvention of the impossibility results regarding the fairness property: enforcing fairness could be achieved through imposing monetary penalties. In this setting a breach of fairness by the adversary is still possible but it results in the honest parties collecting a compensation in a way that is determined by the protocol execution. At the same time, in case fairness is not breached, it is guaranteed that no party loses any money (despite the fact that currency transfers may have taken place between the parties). The rationale here is that a suitable monetary penalty suffices in most practical scenarios to force the adversary to operate in the protocol fairly.

While the main idea of fairness with penalties sounds simple enough, its implementation proves to be quite challenging. The main reason is that the way a crypto-currency operates does not readily provide a trusted party that will collect money from all participants and then either return it or redistribute it according to the pre-agreed penalty structure. This is because crypto-currencies are decentralized and hence no single party is ever in control of a money transfer beyond the owner of a set of coins. The mechanism used in [1, 2, 7, 27] to circumvent the above problem is the capability¹ of the Bitcoin network to issue transactions that are “time-locked”, i.e., become valid only after a specific time and prior to that time may be superseded by other transactions that are posted in the public ledger. Superseded time-locked transactions become invalid and remain in the ledger without ever being redeemed.

While the above works are an important step for the design of MPC protocols with properties that circumvent the classical impossibility results, several critical open questions remain to be tackled; those we address herein are as follows.

Our Results. Our contribution is three-fold. First, we put forth a new formal model of secure MPC with compensation and we show how the introduction of suitable ledger and synchronization functionalities makes it possible to express completely such protocols using standard interactive Turing machines (ITM) circumventing the need for the use of extra features that are outside the standard model (in comparison, the only previous model [7] resorted to specialized ITM’s that utilize resources outside the computational model²). Second, our model is equipped with a composition theorem that enables the design of protocols that compose safely with each other and within larger environments where other protocols with compensation take place; a composition theorem for this class of protocols was not known before and requires a new framework for synchronization in the global UC setting that can be of independent interest. Third, we introduce the first robust MPC protocol with compensation, i.e., an MPC protocol where not only fairness is guaranteed (via compensation) but additionally the protocol is guaranteed to deliver output to the parties that get engaged and therefore the adversary is not even able to mount a denial of service attack without having to suffer a monetary penalty. In more details we have the following.

• We put forth a new model that utilizes two ideal functionalities and expresses the ledger of transactions and a clock in the sense of [24] that is connected to the ledger and enables parties to synchronize their protocol interactions. Our ledger functionality enable us to abstract all the necessary features of the underlying cryptocurrency. Contrary to the only previous formalization approach [7, 27], our modeling allows the entities that participate in an MPC execution to be regular interactive Turing machines (ITM) and there is no need to equip them with additional physical features such as “safes” and “locks.” Furthermore the explicit inclusion of the clock functionality (which is only alluded to in [7, 27]) and a synchronous framework for protocol design given such clock reveal the exact dependencies between the ledger and the clock functionality that are necessary in order for MPC with compensation protocols to be properly described. We express our model within a general framework that we call $\mathsf {Q}$-fairness and robustness and may be of independent interest as it can express meaningful relaxations of fairness and robustness in the presence of a global ideal functionality.

• We prove a composition theorem that establishes that protocols in our framework are secure in a universally composable fashion. Our composition proof treats the clock and ledger functionalities as global setups in the sense of [11, 13]. We emphasize that this is a critical design choice: the fact that the ledger is a global functionality ensures that any penalties that are incurred to the adversary that result to credits towards the honest parties will be globally recognized. This should be contrasted to an approach that utilizes regular ideal functionalities which may be only accessible within the scope of a single protocol instance and hence any penalty bookkeeping they account may vanish with the completion of the protocol. Providing a composition theorem for MPC protocols with compensation was left as an open question in [7].

• We finally present a new protocol for fair and robust secure MPC with compensation. Our robustness property guarantees that once the protocol passes an initial round of deposits, parties are guaranteed to obtain output or be compensated. This is in contrast to fair MPC with compensation [1, 2, 7, 27] where the guarantee is that compensation takes place only in case the adversary obtains output while an honest party does not. To put it differently, it is feasible for the adversary to lead the protocol to a deadlock where no party receives output however the honest parties have wasted resources by introducing transactions in the ledger. We remark that it is in principle possible to upgrade the protocols of [1, 2, 7, 27] to the robust MPC setting by having them perform an MPC with identifiable abort, cf. [21, 23], (in such protocol the party that causes the abort can be identified and excluded from future executions). However even using such protocol the resulting robust MPC with compensation will need in the worst case a linear number of deposit/communication rounds in the number of malicious parties. Contrary to that, our robust protocol can be instantiated so that it requires a constant number of deposit/communication rounds independently of the number of parties that are running the protocol. Our construction uses time-locked transactions in a novel way to ensure that parties do progress in the MPC protocol or otherwise transactions are suitably revertible to a compensation for the remaining parties. The structure of our transactions is quite more complex than what can be presently supported by bitcoin; we describe in high-level how our protocol can be implemented via Ethereum³ contracts.

Related Work. In addition to the previous works [1, 2, 7, 27] in fair MPC with compensation, very recently, Ruffing et al. [30] address equivocation issues via penalty mechanism, and design decentralized “non-equivocation” contracts.

There are a number of other works that attempted to circumvent the impossibility results for fairness in the setting of dishonest majority by considering alternate models. Contrary to the approach based on cryptocurrencies these works give an advantage to the protocol designer with respect to the adversarial strategy for corruption. For instance, in [18] a rational adversary is proposed and the protocol designer is privy to the utility function of the adversary. In [3] a reputation system is used and the protocol designer has the availability of the reputation information of the parties that will be engaged in the protocol. Finally in [17] a two tiered model is proposed where the protocol designer is capable of distinguishing two distinct sets of servers at the onset of the computation that differ in terms of their corruptibility.

Global setups were first put forth in [11] motivated by notion of deniability in cryptographic protocols. In our work we utilize global functionalities for universal composition (without the deniability aspect) as in [13] where a similar approach was taken for the case of the use of the random oracle as a global setup functionality for MPC.

Fairness was considered from the resource perspective, cf. [8, 19, 29], where it is guaranteed due to the investment of proportional resources between the parties running the protocol, and the optimistic perspective, cf. [4, 5, 9], where a trusted mediator can be invoked in the case of an abort. We finally note that without any additional assumptions, due to the impossibility results mentioned above, one can provide fairness only with certain high probability that will be affecting the complexity of the resulting protocol, see, e.g., [22] and references therein.

In concurrent and independent work, Kosba et al. [26] propose a framework for composable protocols based on a ledger. and explore a notion of fairness with compensation. Our work goes beyond fairness and provides a treatment of robustness. Furthermore we provide a synchronous framework with a global clock (of independent interest) that uses the ledger as a global setup to achieve fairness and robustness and we prove a composition theorem for our framework.

Organization. We start with preliminaries in Sect. 2. Then in Sects. 3 and 4, we lay down a formal framework for designing composable fair protocols in the presence of globally available trusted resources. In Sect. 3, we introduce two shared functionalities $\bar{\mathcal {G}} _{\textsc {clock}}$ and $\bar{\mathcal {G}} _{\textsc {ledger}}$ respectively to formulate the trust resources that are provided by Bitcoin-like systems. Subsequently, in Sect. 4, we put forth a new formal framework for secure MPC with compensation: we introduce the notions of $\mathsf {Q}$-fairness, and $\mathsf {Q}$-robustness via wrapper functionalities; we then consider the realization of such wrapper functionalities, and further provide a composition theorem. In Sect. 5, we present a protocol in our new framework to achieve our new notions of fairness and robustness. We refer the reader to the full version of our work [25] for a discussion about implementing our protocol within Ethereum, supplementary material for Sects. 2 and 3, and for the formal proofs of our theorems.

2 Preliminaries

Throughout the paper we assume an (often implicit) security parameter denoted as $\kappa$. For a number $n\in \mathbb {N}$ we denote by [n] the set $[n]=\{1,\ldots ,n\}$ and denote by $0^n$ (resp. $1^n$) the all-zero (resp. all-ones) string of length n. For a randomized algorithm $\text {Alg}$ we denote by $\text {Alg}(x;r)$ the output of $\text {Alg}$ on input x and random coins r. To avoid always explicitly writing the coins r, we shall denote by $y\overset{\$}{\leftarrow }\text {Alg}(x)$ the operation of running $\text {Alg}$ on input x (and uniformly random coins) and storing the output on variable y. We write $f: X\overset{\$}{\rightarrow } Y$ to denote a probabilistic function with domain X and range Y. We use the standard definition of negligible and overwhelming (e.g., see [20]).

For a multiparty function $f:(\{0,1\}^*\cup \{\lambda \})^n\rightarrow ( \{0,1\}^*\cup \{\perp \})^n$ for parties in $\mathcal {P} =\{p_1,\ldots ,p_n\}$ and for a set $\mathcal {P} \subseteq \mathcal {P}$, we denote by $f|_{|\mathcal {P} '|}$ the restriction of f to the parties in $\mathcal {P} '$, namely, if each $p_i\in \mathcal {P} '$ has input $x_i$, then the output of $f|_{|\mathcal {P} '|}$ is the output of f evaluated on inputs $x_i$ for each $p_i\in \mathcal {P} '$ and $x_j=\lambda$ for each $p_j\in \mathcal {P} {\setminus }\mathcal {P} '$.

We describe our results in the extension of Canetti’s UC framework [10] to allow for global setups, known as GUC [11]. As argued above, this is the natural model to consider execution in the present of a globally synchronized clock and a ledger/bulletin board. Consistently with the (G)UC notation, we denote local (UC) functionalities by calligraphic letters, as in $\mathcal {F}$, and add a bar to denote global functionalities, as in $\bar{\mathcal {G}}$. Furthermore, we denote by $\phi$, the dummy protocol. Note that in GUC $\phi$ might receive inputs for its (UC) hybrids and/or for the global setup, where an implicit mechanism is assumed to allow the environment to define the intended recipient of each submitted input to $\phi$. For a protocol $\pi$, a (local) UC functionality $\mathcal {F}$ and a global setup $\bar{\mathcal {G}}$ we denote by ${\textsc {Exec}}^{\bar{\mathcal {G}}, \mathcal {F}}_{\pi , \mathcal {A}, \mathcal {Z}}$ the output of the environment $\mathcal {Z}$ in an execution of $\pi$ having hybrid access to $\bar{\mathcal {G}}$ and $\mathcal {F}$ in the presence of adversary $\mathcal {A}_{}$. We assume some familiarity with the UC and/or the GUC framework.

Correlated Randomness as a Sampling Functionality. Our protocols are in the correlated randomness model, i.e., they assume that the parties initially, before receiving their inputs, receive appropriately correlated random strings. In particular, the parties jointly hold a vector $\varvec{R_{}}=(R_{1},\ldots ,R_{n})\in (\{0,1\}^*)^n$, where $P _{i}$ holds $R_{i}$, drawn from a given efficiently samplable distribution $\mathcal {D}$. This is, as usual, captured by giving the parties initial access to an ideal functionality , known as a sampling functionality, which, upon receiving a default input from any party, samples $\varvec{R_{}}$ from $\mathcal {D}$ and distributes it to the parties (see [25] for details). Hence, a protocol in the correlated randomness model is formally an -hybrid protocol. Formally, a sampling functionality is parameterized by an efficiently computable sampling distribution $\mathcal {D}$ and the (ID’s of the parties in) the player set $\mathcal {P}$.

3 Model

In this section and next section, we lay down a formal framework for designing composable fair protocols in the presence of globally available trusted resources. We introduce in the current section, shared (in the sense of the GUC model [11]) functionalities $\bar{\mathcal {G}} _{\textsc {clock}}$ and $\bar{\mathcal {G}} _{\textsc {ledger}}$ respectively to formulate the trust resources that are provided by Bitcoin-like systems. We stress that these two functionalities can be thought of as a single global functionality and in our description are allowed to communicate. Nonetheless, we choose to describe then as two separate functionalities, because as we argue, the clock $\bar{\mathcal {G}} _{\textsc {clock}}$ can also be used alone (without $\bar{\mathcal {G}} _{\textsc {ledger}}$) to naturally model synchronous computation with a global notion of time.

3.1 Global Clock Functionality and Synchronous Protocol Executions

In this section we describe how to model execution of synchronous protocols that can access a global-clock setup. This is an adaptation of the original idea by Katz et al. [24], where a clock was modelled as UC functionality that is local to the calling protocol, and is of independent interest as a model for the design of synchronous protocols. In addition to being a more realistic model for capturing time in UC, the notion of the global clock allows for synchronous execution of any protocols that choose to use it.

Before defining our clock, we recall the reader the clock and model of synchronous execution from [24] and then highlight the main differences. The clock in [24] is a UC functionality that keeps an indicator bit b originally set to 0. The parties can send to the clock special “update” messages, and once the clock sees that all honest parties agree to update the state it sets $b:=b\oplus 1$. The clock then continues to receive “update” messages, and again, once it sees that all honest parties have requested to update after the last switch of the bit b it switches it again. To make sure that the adversary is given enough activations, whenever the clock receives an “update” message from the honest party it notifies the adversary. In addition to “update” messages, the parties can send the clock a “read” message which the clock replies with the current value of b.

The use of such a clock to keep a round structure is as follows: Whenever a party observes a switch of the bit b, it interprets it as a round advance. Thus, a synchronous protocol with access to such a clock is executed as follows. In each round, every party performs all its protocol instructions for the current round, and at the end sends an “update” message to the clock; from the point where the party updates (its round has finished) it queries (“reads”) the clock with each following activation to detect when all parties have also finished their rounds (i.e., when the value of b switches). Once this happens, the party starts its next protocol round.

An issue with the above clock is that in order to execute two protocols using the same clock we need to make use of the joint-state UC theorem [15]. Instead, in this work we take an alternative modelling approach and define a shared clock functionality $\bar{\mathcal {G}} _{\textsc {clock}}$. This functionality can be viewed as a shared version of the clock functionality which was defined by Katz et al. [24]. The main intuition behind our clock functionality is that all honest parties can use it to ensure that they proceed with their rounds at the same pace. On a high level, the clock operates as follows: any party that wishes to be synchronised with the global clock can send $(\textsc {register}, \mathsf {sid})$ to the clock and subsequently it can send it $(\textsc {clock}\text {-}\textsc {update}, \mathsf {sid})$ commands, where $\mathsf {sid}$ is $\bar{\mathcal {G}} _{\textsc {clock}}$’s identifier. The clock stores a global-time counter $\tau$ (initially set to 0), and as soon it is instructed by all currently honest parties and by associated shared functionalities⁴ to advance the time (i.e., receives $(\textsc {clock}\text {-}\textsc {update}, \mathsf {sid})$ it increases its state-counter $\tau$ by 1.

The main difference between our formulation and that by Katz et al. [24] is that in [24] the clock is a UC functionality which is local to a single protocol and waits for an “update” message by every honest party to advance its state; however, here we intend to have the clock to be accessed globally and used by arbitrary protocols. Therefore we give the power to the environment to define the clock’s speed. Indeed, if there are no associated shared functionalities, the environment can instruct dummy parties to send inputs $(\textsc {clock}\text {-}\textsc {update}, \mathsf {sid})$ to $\bar{\mathcal {G}} _{\textsc {clock}}$ and advance the clock whenever it wishes. An additional difference is that in [24], the clock state is binary while here, in our formulation, the state $\tau$ is a positive integer which indicates the time that has passed from point zero (i.e., from the beginning of time).

Next, we elaborate and explain how to use the global clock to design synchronous protocols. We remark that the model of synchronous protocol execution of [24] cannot be used in our setting as the environment can make the clock advance before honest parties have time to take actions in any round. Indeed, in the ideal setting the environment can keep sending $(\textsc {clock}\text {-}\textsc {update}, \mathsf {sid})$ to the dummy parties, which will forward it to the clock making its state to advance; to make sure that the protocol is indistinguishable, honest parties would have to do the same, thereby giving away the activations that they need for executing their protocol instructions such as send and receive operations.⁵ This might, at first, seem like a bug but it is in fact a feature. It captures the fact that since time is a quantity that should be in the control of the environment, if the environment chooses to advance time too fast then some protocol might not have enough time to perform their operations for each round, and might therefore need to give up.

To make sure that the environment cannot exploit such fast-forwarding of the clock we use the following idea: We allow the clock to receive from honest parties or (non-shared) ideal functionalities a special $(\textsc {Clock}\text {-}\textsc {Fast})$ message, which makes it set an internal indicator from 0 to 1. This indicator will be added onto the response of the clock to $\textsc {clock}\text {-}\textsc {read}$ queries, and will make any synchronous protocol or corresponding functionality that reads the clock and observes this indicator being set to one to immediately terminate with a default value. This way we ensure that an environment that tries such a fast-forward distinguishing attack will be forced to make any synchronous protocol behave in a default way, a behavior which, as we see, is easily imitated in the ideal world. The detailed description of the clock functionality can be found in Fig. 1.

We stress that having a global $\bar{\mathcal {G}} _{\textsc {clock}}$-hybrid model makes the mode of execution of synchronous protocols more intuitive compared to [24]. Here is how synchronous protocols are executed in this setting. First, as is the case in real-life synchronous protocols, we assume that the protocol participants have agreed on the starting time $\tau _0$ of their protocol and also on the duration of each round.⁶ We abstract this knowledge by assuming the parties know a function $\mathtt{Round2Time}:\mathbb Z \rightarrow \mathbb Z$ which maps protocol rounds to time (according to the global clock) in which the round should be completed. For $\rho \in \mathbb Z$, $\mathtt{Round2Time} (\rho )$ is the time in which the $\rho$th round of the protocol should be completed. To make sure that no party proceeds to round $\rho +1$ of the protocol before all honest parties have completed round $\rho$, we require that any two protocol rounds are at least two clock-ticks apart (see [24] for a discussion); formally, for all $\rho \ge 0$, it holds that $\mathtt{Round2Time} (\rho +1)\ge \mathtt{Round2Time} (\rho )+2$.

Fig. 1.

The clock functionality

A synchronous protocol in the above setting proceeds as follows where the parties keep locally track of the current round $\rho$ in the protocol they are in:

• Upon receiving a $(\textsc {clock}\text {-}\textsc {update}, \mathsf {sid})$ input (from its environment) where $\mathsf {sid}$ is the ID of $\bar{\mathcal {G}} _{\textsc {clock}}$, party $P _i$ forwards it to $\bar{\mathcal {G}} _{\textsc {clock}}$.

• Upon receiving a $(\textsc {clock}\text {-}\textsc {read}, \mathsf {sid})$ input (from its environment), party $P _i$ forwards it to $\bar{\mathcal {G}} _{\textsc {clock}}$ and outputs the response to the environment.

• Upon receiving a $(\textsc {Clock}\text {-}\textsc {Fast})$ input (from its environment), party $P _i$ forwards it to $\bar{\mathcal {G}} _{\textsc {clock}}$.

• Upon receiving any message $(\textsc {Input},\mathsf {sid} ')$ where $\mathsf {sid} '$ is the session ID of a protocol $P _i$ is involved in, do the following: Send $(\textsc {clock}\text {-}\textsc {read}, \mathsf {sid})$ to $\bar{\mathcal {G}} _{\textsc {clock}}$ and denote the response by $(\textsc {clock}\text {-}\textsc {read}, \mathsf {sid},\tau ,\mathtt {fast})$; if $\mathtt {fast} =1$ then output $\textsc {Clock}\text {-}\textsc {Fast}$ to the environment. Otherwise do:

  • if $\tau \le \mathtt{Round2Time} (\rho -1)$ halt;

  • else, if $\mathtt{Round2Time} (\rho -1)< \tau \le \mathtt{Round2Time} (\rho )$ execute the next pending round$-\rho$ instruction (if all the instructions for round $\rho$ are finished halt.)

  • else, if $\tau > \mathtt{Round2Time} (\rho )$ and there are still pending instructions for the current round, send $(\textsc {Clock}\text {-}\textsc {Fast})$ to $\bar{\mathcal {G}} _{\textsc {clock}}$.

  • else, i.e., if $\tau > \mathtt{Round2Time} (\rho )$ and $P _i$ has completed all round-$\rho$ instruction, then set $\rho :=\rho +1$ and halt.

It is easy to verify that the above mode of operation will guarantee that the parties are never out-of-sync, since as soon as the first party issues a $\textsc {Clock}\text {-}\textsc {Fast}$ message for the clock, all synchronous protocols will enter the mode of outputting $\textsc {Clock}\text {-}\textsc {Fast}$ for every input that the environment hands them (that is not intended for the clock). However, there is one more thing that needs to be taken care of. Since in the real-world the parties go to a default mode (where they output $\textsc {Clock}\text {-}\textsc {Fast}$ to every query) when the environment does not give them sufficient time, this should also be the case in the ideal world. To achieve this we use another idea inspired by the guaranteed termination functionality from [24]: Let $\pi$ be a synchronous protocol with round-to-time function $\mathtt{Round2Time}:\mathbb Z \rightarrow \mathbb Z$, where in each round, each party needs exactly m activations to perform its instructions⁷. We introduce a wrapper $\tilde{\mathcal {W}}$ which, at a high level, forwards messages to and from its wrapped functionality but stores a round-index and checks, as the protocol would, that every party issues to the wrapped functionality, at least m activations for each round $\rho$ in the intended interval. If this is not the case the wrapper sends $(\textsc {Clock}\text {-}\textsc {Fast})$ to $\bar{\mathcal {G}} _{\textsc {clock}}$ and responds with $\textsc {Clock}\text {-}\textsc {Fast}$ form that point on. The detailed description can be found in the full version [25].

3.2 Global Ledger Functionality

Functionality $\bar{\mathcal {G}} _{\textsc {ledger}}$ provides the abstraction of a public ledger in Bitcoin-like systems (e.g., Bitcoin, Litecoin, Namecoin, Ethereum, etc.). Intuitively, the public ledger could be accessed globally by protocol parties or other entities including the environment $\mathcal {Z}$. Protocol parties or the environment can generate transactions; and these valid transactions will be gathered by a set of ledger maintainers (e.g., miners in Bitcoin-like systems) in a certain order as the state of the ledger. More concretely, whenever the ledger maintainers receive a vector of transactions $\varvec{\mathtt {tx}}$, they first add the transactions in a buffer, assuming they are valid with respect to the existing transactions and the state of the ledger; thus, in this way a vector of transactions is formed in the buffer. After a certain amount of time, denoted by $\mathtt {T}$, which will be also referred to as a ledger round, all transactions in the buffer will be “glued” into the ledger state in the form of a block. The adversary is allowed to permute the buffer prior to its addition to the ledger. In Bitcoin, $\mathtt {T}$ is 10 min (approximately); thus in about every 10 min, a new block of transactions will be included into the ledger, and the ledger state will be updated correspondingly.

Fig. 2.

The public ledger functionality.

To enable the ledger to be aware of time, the ledger maintainers are allowed to “read” the state of another publicly available functionality $\bar{\mathcal {G}} _{\textsc {clock}}$ defined above. Furthermore, to ensure that the ledger is activated at least once in each time-tick⁸ (i.e., each advance of the $\bar{\mathcal {G}} _{\textsc {clock}}$ state) we have the ledger, with every message it gets from a party other than the adversary, send a $(\textsc {clock}\text {-}\textsc {update}, \mathsf {sid})$ message to $\bar{\mathcal {G}} _{\textsc {clock}}$. (Recall that, as defined, $\bar{\mathcal {G}} _{\textsc {clock}}$ always waits for at least one such message from the ledger before advancing its time counter.)

We remark that all gathered transactions should be “valid” which is defined by a predicate $\mathsf {Validate}$. In different systems, predicate $\mathsf {Validate}$ will take different forms. For example, in the Bitcoin system, the predicate $\mathsf {Validate}$ should make sure that for each newly received transaction that transfers v coins from the original wallet address $\mathtt {address} _o$ to the destination wallet address $\mathtt {address} _d$, the original wallet address $\mathtt {address} _o$ should have v or more than v coins, and the transaction should be generated by the original wallet holder (as shown by the issuance of a digital signature). Furthermore, prior to each vector of transactions becoming block, the vector is passed through a function $\mathsf {Blockify} (\cdot )$ that homogenizes the sequence of transactions in the form of a block. Moreover, in some systems like Bitcoin, it may add a special transaction called a “coinbase” transaction that implements a reward mechanism for the ledger maintainers.

In Fig. 2 we provide the details of the ledger functionality.

4 $\mathsf {Q}$-Fairness and $\mathsf {Q}$-Robustness

In this section, we provide a formal framework for secure computation with fair and robust compensation. In the spirit of [19], our main tool is a wrapper functionality. Our wrapper functionality is equipped with a predicate $\mathsf {Q}_{\bar{\mathcal {G}}}$ which is used to make sure that the outcome of the protocol execution is consistent with appropriate conditions on the state of the global setup $\bar{\mathcal {G}}$. Intuitively, the predicate $\mathsf {Q}_{\bar{\mathcal {G}}}$ works as a filter, such that if certain “bad” event occurs (e.g., an abort), then the wrapped functionality will restrict the simulators influence. More concretely, the predicate $\mathsf {Q}_{\bar{\mathcal {G}}}$ has three modes $\mathsf {Q}^{\text {Init}}_{\bar{\mathcal {G}}}$, $\mathsf {Q}^{\text {Dlv}}_{\bar{\mathcal {G}}}$ and, $\mathsf {Q}^{\text {Abt}}_{\bar{\mathcal {G}}}$, where $\mathsf {Q}^{\text {Init}}_{\bar{\mathcal {G}}}$ specifies under which condition (on the global setup’s state) the protocol should start executing; $\mathsf {Q}^{\text {Dlv}}_{\bar{\mathcal {G}}}$ specifies under which condition parties should receive their output; and $\mathsf {Q}^{\text {Abt}}_{\bar{\mathcal {G}}}$ specifies under which condition the simulator is allowed to force parties to abort. With foresight $\mathsf {Q}^{\text {Init}}_{\bar{\mathcal {G}}}$ will ensure that the protocol is executed only if all honest participants have enough coins; $\mathsf {Q}^{\text {Dlv}}_{\bar{\mathcal {G}}}$ will ensure that honest parties do not lose coins if they execute the protocol; and $\mathsf {Q}^{\text {Abt}}_{\bar{\mathcal {G}}}$ will ensure that honest parties might be forced to an “unfair” abort (i.e., where the adversary has received his output) only if they are compensated by earning coins (from the corrupted parties). We will call an implementation of a wrapped version of $\mathcal {F}_{\textsc {}}$ a $\mathsf {Q}$-fair implementation of $\mathcal {F}_{\textsc {}}$.⁹

Our definition of $\mathsf {Q}_{\bar{\mathcal {G}}}$-fairness can be instantiated with respect to any global setup that upon receiving a $\textsc {read}$ symbol (from any protocol participant or functionality) it returns its public state $\mathsf {trans}$. Concretely, let $\bar{\mathcal {G}}$ be global ideal functionality and let $\mathsf {Q}_{\bar{\mathcal {G}}}$ a predicate, as above, with respect to such $\bar{\mathcal {G}}$. Let also $\mathcal {F}$ be a non-reactive functionality¹⁰ which allows for fair evaluation of a given function (SFE) in the sense of [19], i.e., it has two modes of delivering output: (i) delayed delivery: $(\textsc {deliver}, \mathsf {sid},m, P)$ signifying delayed output delivery¹¹ of m to party P, (ii) fair delivery: $(\textsc {fair}\text {-}\textsc {deliver}, \mathsf {sid}, (m,P_{i_1}), \ldots , (m, P_{i_k}), (m_\mathcal {S}, \mathcal {S}))$ that results in simultaneous delivery of outputs $m_{i_1}, \ldots m_{i_k}$ to parties $P_{i_1}, \ldots , P_{i_k}$ and output $m_\mathcal {S}$ to $\mathcal {S}$. We note that (G)UC does not have an explicit mechanism for simultaneous delivery of outputs. Thus, when we refer to simultaneous delivery of a vector $(m_{i_1},\ldots ,m_{i_k})$ to parties $P_{i_1}, \ldots , P_{i_k}$, respectively, we imply that the functionality prepares all the output to be delivered in a “fetch mode” as defined in [24]; that is:

• The functionality registers the pairs $(m_{i_1},P_{i_1}), \ldots , (m, P_{i_k})$ as “ready to fetch” and sends the set $\{(m_{i_j}, P_{i_j}) | P_{i_j} \text { is corrupted}\}$ to $\mathcal {S}$.

• Upon receiving an input $(\textsc {fetch}\text {-}\textsc {output},P_i)$ from party $P_i$, if a message $(m_{i},P_{i})$ has been registered as “ready to fetch” then remove it from the “ready to fetch” set and output it to $P_i$ (if more than one such messages are registered, deliver and remove from the “ready to fetch” set the first, chronologically, registered such pair); otherwise send $({\textsc {fetch}\text {-}\textsc {output}},P_i)$ to $\mathcal {S}$.

4.1 $\mathsf {Q}_{\bar{\mathcal {G}}}$-Fairness

The wrapper functionality $\mathcal {W}$ that will be used in the definition of $\mathsf {Q}$-fair (secure) computation is given in Fig. 3. The intuition is as follows: Prior to handing inputs to the (wrapped) functionality $\mathcal {F}_{\textsc {}}$, the parties can request the wrapper to generate on their behalf a resource-setup (by executing an associated resource-setup generation algorithm $\text {Gen}$) which allows them to update the global setup $\bar{\mathcal {G}}$; this resource setup consists of a public component $RS^\mathtt{pub} _{P,\mathsf {sid}}$ and a private component $RS^\mathtt{priv} _{P,sid}$.¹² Both these values are given to the simulator, and the public component is handed to the party.

From the point when parties receive their inputs the $\mathsf {Q}$ predicate is used as a filter to specify the wrapper’s behavior and add the fairness guarantees. More concretely, upon receiving an input from a party, the wrapper checks on the global setup to ensure that $\mathsf {Q}^{\text {Init}}$ is true, and if it is not true it aborts (i.e., sets all honest parties’ outputs to $\perp$ and blocks any communication between $\mathcal {F}_{\textsc {}}$ and the adversary). This means that if the environment has not set up the experiment properly,¹³ then the experiment will not be executed and the wrapped functionality will become useless. This formally resolves the question “What happens if some party does not have sufficient coins to play the protocol?” which leads to some ambiguity in existing bitcoin-based definitions of computation with fair compensation [7].

The predicates $\mathsf {Q}^{\text {Dlv}}$ and $\mathsf {Q}^{\text {Abt}}$ are used to filter out attempts of the simulator to deliver outputs or abort when $\mathsf {Q}^{\text {Dlv}}$ and $\mathsf {Q}^{\text {Abt}}$ are violated.¹⁴ Concretely, any such attempt will be ignored if the corresponding predicate is not satisfied.

Intuitively, by requiring the protocol to implement such a wrapped version of a functionality, we will ensure that the parties might only abort if $\mathsf {Q}^{\text {Abt}}$ is true, and might output a valid (non-$\perp$) value if $\mathsf {Q}^{\text {Dlv}}$. As we shall see in Sect. 4.2, by a trivial modification of the fairness wrapper, we can capture a stronger property which we will call $\mathsf {Q}$-robustness; the latter, roughly, guarantees that honest parties which start the protocol will either receive their output (and $\mathsf {Q}^{\text {Dlv}}$ being true) or will abort and increase their revenue. (I.e., there is no way for the adversary to make the protocol abort after the first honest party has sent its first input-dependent message).

Fig. 3.

The $\mathsf {Q}$-Fairness wrapper functionality.

Definition 1

We say protocol $\pi$ realizes functionality $\mathcal {F}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}$-fairness with respect to global functionality $\bar{\mathcal {G}}$, provided the following statement is true. For all adversaries $\mathcal {A}$, there is a simulator $\mathcal {S}$ so that for all environments $\mathcal {Z}$ it holds:

$$ {\textsc {Exec}}^{\bar{\mathcal {G}}}_{\pi , \mathcal {A}, \mathcal {Z}} \approx {\textsc {Exec}}^{\bar{\mathcal {G}},\mathcal {W} _{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F})}_{\mathcal {S}, \mathcal {Z}} $$

More generally, the protocol $\sigma$ realizes $\mathcal {H}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}'$ fairness using a functionality $\mathcal {F}$ with fairness $\mathsf {Q}_{\bar{\mathcal {G}}}$ provided that for all adversaries $\mathcal {A}$, there is a simulator $\mathcal {S}$ so that for all environments $\mathcal {Z}$, it holds:

$$ {\textsc {Exec}}^{\bar{\mathcal {G}},\mathcal {W} _{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F})}_{\pi , \mathcal {A}, \mathcal {Z}} \approx {\textsc {Exec}}^{\bar{\mathcal {G}},\mathcal {W} _{\mathsf {Q}',\bar{\mathcal {G}}}(\mathcal {H})}_{\mathcal {S}, \mathcal {Z}} $$

We note that, both protocol $\pi$ and the functionality $(\mathcal {W} _{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F}),\bar{\mathcal {G}})$ are with respect to the global functionality¹⁵ $\bar{\mathcal {G}}$. By following the very similar proof idea in [11], we can prove the following lemma and theorem:

Lemma 1

Let $\mathsf {Q}_{\bar{\mathcal {G}}}$ be a predicate with respect to global functionality $\bar{\mathcal {G}}$. Let $\pi$ be a protocol that realizes the functionality $\mathcal {F}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}$-fairness. Let $\sigma$ be a protocol in $(\mathcal {W} _{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F}),\bar{\mathcal {G}})$-hybrid world. Then for all adversaries $\mathcal {A}$, there is a simulator $\mathcal {S}$ so that for all environments $\mathcal {Z}$, it holds

$$ {\textsc {Exec}}^{\bar{\mathcal {G}}}_{\sigma ^\pi , \mathcal {A}, \mathcal {Z}} \approx {\textsc {Exec}}^{ \bar{\mathcal {G}},\mathcal {W} _{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F})}_{\sigma , \mathcal {S}, \mathcal {Z}} $$

Theorem 1

Let $\mathsf {Q}_{\bar{\mathcal {G}}}$ and $\mathsf {Q}_{\bar{\mathcal {G}}}'$ be predicates with respect to global functionality $\bar{\mathcal {G}}$. Let $\pi$ be a protocol that realizes the functionality $\mathcal {F}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}$-fairness. Let $\sigma$ be a protocol in $(\mathcal {W} _{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F}),\bar{\mathcal {G}})$-hybrid world that realizes the functionality $\mathcal {H}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}'$-fairness. Then for all adversaries $\mathcal {A}$, there is a simulator $\mathcal {S}$ so that for all environments $\mathcal {Z}$ it holds:

$$ {\textsc {Exec}}^{\bar{\mathcal {G}}}_{\sigma ^\pi , \mathcal {A}, \mathcal {Z}} \approx {\textsc {Exec}}^{ \bar{\mathcal {G}},\mathcal {W} _{\mathsf {Q}',\bar{\mathcal {G}}}(\mathcal {H})}_{\mathcal {S}, \mathcal {Z}} $$

Is the Ledger Functionality Sufficient for $\mathsf {Q}$ Fairness? We will construct secure computation protocols based on the ledger functionality $\bar{\mathcal {G}} _{\textsc {ledger}}$ together with other trusted setups. We may wonder if we can construct secure computation protocol from $\bar{\mathcal {G}} _{\textsc {ledger}}$ only. The answer if negative. Indeed, we prove the following statement.

Theorem 2

Let $\mathsf {Q}_{\bar{\mathcal {G}}}$ be a predicate with respect to global functionality $\bar{\mathcal {G}} =\bar{\mathcal {G}} _{\textsc {ledger}}$. There exists no protocol in the $\bar{\mathcal {G}} _{\textsc {ledger}}$ hybrid world which realizes the commitment functionality ${\mathcal {F}}_{\textsc {com}}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}$ fairness.

The proof idea is very similar to the well-known Canetti-Fischlin [12] impossibility proof and can be found in [25].

4.2 $\mathsf {Q}_{\bar{\mathcal {G}}}$-Robustness

The above wrapper $\mathcal {W}$ allows the simulator to delay delivery of messages arbitrarily. Thus, although the predicates do guarantee the promised notion of fairness, the resulting functionality lacks the other relevant property that we discussed in the introduction, namely robustness. In the following we define $\mathsf {Q}$-robustness which will ensure that if any party starts executing the protocol on its input (i.e., the protocol does not abort due to lack of resources for some party), then every honest party is guaranteed to either receive its output without loosing revenue, or receive bottom and a compensation. This property can be obtained by modifying the wrapper $\mathcal {W}$ using an idea from [24] so that in addition to the global-setup-related guarantees induced by predicate $\mathsf {Q}$, it also preserves the guaranteed termination property of the wrapped functionality.¹⁶

More concretely, in [24], a functionality was augmented to have guaranteed termination, by ensuring that given appropriately many activations (i.e., dummy inputs), from its honest interface, it computes its output.¹⁷ In the same spirit, a wrapper which ensures $\mathsf {Q}$-robustness is derived from $\mathcal {W}$ via the following modification: As soon as a fair-output is registered (i.e., upon the wrapper receiving $(\textsc {fair}\text {-}\textsc {deliver}, \mathsf {sid},\mathsf {mid},(m_1, P_{i_1}), \ldots , (m_{k}, P_{i_k}), (m_\mathcal {S}, \mathcal {S}) )$ from its inner functionality) it initiates a counter $\lambda =0$ and an indicator variable $\lambda _{i_j}:=0$ for each $P_{i_j}\in \{P_{i_1},\ldots , P_{i_k}\}$; whenever a message is received from some $P_{i_j}\in \{P_{i_1},\ldots , P_{i_k}\}$, the wrapper sets $\lambda _{i_j}:=1$ and does the following check: if $\lambda _{i_j}=1$ for all $P_{i_j}\in \{P_{i_1},\ldots , P_{i_k}\}$ then increase $\lambda :=\lambda +1$ and reset $\lambda _{i_j}=0$ for all $P_{i_j}\in \{P_{i_1},\ldots , P_{i_k}\}$. As soon as $\lambda$ reaches a set threshold T, the wrapper simultaneously delivers each $((m_{1},P_{i_k}), \ldots , (m_{k},P_{i_k})$ (i.e., prepares them to be fetched) without waiting for the simulator and does not accept any inputs other than $(\textsc {fetch}\text {-}\textsc {output},\cdot )$ from that point on. When this happens, we will say that the wrapper reached its termination limit. We denote by $\hat{\mathcal {W}} ^T$ the wrapper from Fig. 3 modified as described above. Note that the wrapper is parameterized by the termination threshold T.

The intuition why this modification ensures guaranteed termination is the same as in [24]: if the environment wishes the experiment to terminate, the it can make it terminate irrespective of the simulator’s strategy. Thus a protocol which realizes such a wrapper should also have such a guaranteed termination (the adversary cannot stall the computation indefinitely.)

Definition 2

We say protocol $\pi$ realizes functionality $\mathcal {F}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}$-robustness with respect to global functionality $\bar{\mathcal {G}}$, provided the following statement is true. There exists a threshold T such that for all adversaries $\mathcal {A}$, there is a simulator $\mathcal {S}$ so that for all environments $\mathcal {Z}$ it holds:

$$ {\textsc {Exec}}^{\bar{\mathcal {G}}}_{\pi , \mathcal {A}, \mathcal {Z}} \approx {\textsc {Exec}}^{\bar{\mathcal {G}},\hat{\mathcal {W}} ^T_{\mathsf {Q},\bar{\mathcal {G}}}(\mathcal {F})}_{\mathcal {S}, \mathcal {Z}}. $$

Moreover, whenever the wrapper reaches its termination limit, then for the state $\mathsf {trans}$ of the global setup $\bar{\mathcal {G}}$ upon termination it holds that $\mathsf {Q}^{\text {Dlv}}_{\bar{\mathcal {G}}}(\mathsf {sid},P,RS^\mathtt{pub} _{P,\mathsf {sid}}, \mathsf {trans})$ for every party $P\in \mathcal {P}$.

The composition theorems for $\mathsf {Q}$-fairness from Sect. 4.1 can be adapted in a straight-forward manner to $\mathsf {Q}$-robustness. The statements and proofs are as in the previous section and are omitted. We note in passing that since the wrapper $\hat{\mathcal {W}}$ is in fact a wrapper which restricts the behavior of $\mathcal {S}$ on top of the restrictions which are applied by the $\mathsf {Q}$-fairness wrapper $\mathcal {W}$, a protocol which is $\mathsf {Q}$-robustness is also $\mathsf {Q}$-fair with respect to the same predicate $\mathsf {Q}$.

4.3 Computation with Fair/Robust Compensation

We are now ready to instantiate the notion of $\mathsf {Q}$-fairness with a compensation mechanism. For the case when $\bar{\mathcal {G}}$ corresponds to a Bitcoin-like ledger, e.g., $\bar{\mathcal {G}} = \bar{\mathcal {G}} _{\textsc {ledger}}$, and $\mathsf {Q}_{\bar{\mathcal {G}}}$ provides compensation of c coins, where $c>0$, in the case of an abort, the resource-setup generation algorithm $\text {Gen}$ a pair of $(\mathtt {address}, \mathsf {sk})$ where $\mathtt {address}$ is a bitcoin address and $\mathsf {sk}$ is the corresponding secret-key and the predicate $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{coin}=(\mathsf {Q}^{\text {C-Init}}_{\bar{\mathcal {G}}},\mathsf {Q}^{\text {C-Dlv}}_{\bar{\mathcal {G}}},\mathsf {Q}^{\text {C-Abt}}_{\bar{\mathcal {G}}})$ operates as follows. On input a session ID $\mathsf {sid}$, a party id P, a wallet address $RS^\mathtt{pub} _{P,\mathsf {sid}}$, and a string $\mathsf {trans}$ which is parsed as a bitcoin ledger that contains transactions:¹⁸

• $\mathsf {Q}^{\text {C-Init}}_{\bar{\mathcal {G}}}$ outputs true if and only if the balance of all transactions (both incoming and outgoing) that concern $RS^\mathtt{pub} _{P,\mathsf {sid}}$ in $\mathsf {trans}$ and carry the meta-data $\mathsf {sid}$ is higher than a fixed pre-agreed initialization amount.¹⁹

• $\mathsf {Q}^{\text {C-Dlv}}_{\bar{\mathcal {G}}}$ outputs true if and only if the balance of all transactions (both incoming and outgoing) that concern $RS^\mathtt{pub} _{P,\mathsf {sid}}$ in $\mathsf {trans}$ and carry the meta-data $\mathsf {sid}$ is greater or equal to 0.

• $\mathsf {Q}^{\text {C-Abt}}_{\bar{\mathcal {G}}}$ outputs true if and only if the balance of all transactions (both incoming and outgoing) that concern $RS^\mathtt{pub} _{P,\mathsf {sid}}$ in $\mathsf {trans}$ and carry the meta-data $\mathsf {sid}$ is greater or equal to a fixed pre-agreed compensation amount.

If a protocol $\pi$ realizes a functionality $\mathcal {F}$ with $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{coin}$-fairness (resp. $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{coin}$-robustness), i.e., with respect to the global functionality $\bar{\mathcal {G}} _{\textsc {ledger}}$, we say that $\pi$ realizes $\mathcal {F}$ with fair compensation (resp. with robust compensation). Because our results are proved for $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{coin}$, to keep the notation simple in the remainder of the paper we might drop the superscript from $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{coin}$, i.e., we write $\mathsf {Q}$ or $\mathsf {Q}_{\bar{\mathcal {G}}}$ instead of $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{coin}$.

5 Our $\mathsf {Q}_{\bar{\mathcal {G}}}^\mathsf{Coin}$-Robust Protocol Compiler

In this section we present our fair and robust protocol compiler. Our compiler compiles a synchronous protocol $\pi _\mathtt{SH}$ which is secure (i.e., private) against a corrupted majority in the semi-honest correlated randomness model (e.g., an OT-hybrid protocol where the OT’s have been pre-computed) into a protocol $\pi$ which is secure with fair-compensation in the malicious correlated randomness model. The high-level idea is the following: We first compile $\pi _\mathtt{SH}$ into a protocol in the malicious correlated randomness model, which is executed over a broadcast channel and is secure with publicly identifiable abort. (Roughly, this means that someone observing the protocol execution can decide, upon abort, which party is not executing its code.) This protocol is then transformed into a protocol with fair compensation as follows: Every party (after receiving his correlated randomness setup) posts to the ledger transactions that the other parties can claim only if they, later, post transactions that prove that they follow their protocol. Transactions that are not claimed this way are returned to the source address; thus, if some party does not post such a proof it will not be able to claim the corresponding transaction, and will therefore leave the honest parties with a positive balance as their transactions will be refunded. Observe that these are not standard Bitcoin transactions, but they have a special format which is described in the following.

Importantly, the protocol we describe is guaranteed to either produce output in as many (Bitcoin) rounds as the rounds of the original malicious protocol, or to compensate all honest parties. This robustness property is achieved by a novel technique which ensures that once the honest parties make their initial transaction, the adversary has no way of preventing them from either computing their output or being compensated. Informally, our technique consists of splitting the parties into “islands” depending on the transactions they post (so that all honest parties are on the same island) and then allowing them to either compute the function within their island, or if they abort to get compensated. (The adversary has the option of being included or not in the honest parties’ island.)

5.1 MPC with Publicly Identifiable Abort

As a first step in our compiler we invoke the semi-honest to malicious with identifiable abort compiler of Ishai, Ostrovsky, and Zikas [23] (hereafter referred to as the IOZ compiler). This compiler takes a semi-honest protocol $\pi _\mathtt{SH}$ in the correlated randomness model and transforms it to a protocol in the malicious correlated randomness model (for an appropriate setup) which is secure with identifiable abort, i.e., when it aborts, every party learns the identity of a corrupted party. The compiler in [23] follows the so called GMW paradigm [21], which in a nutshell has every party commit to its input and randomness for executing the semi-honest protocol $\pi _\mathtt{SH}$ and then has every party run $\pi _\mathtt{SH}$ over a broadcast channel, where in each round $\rho$ every party broadcasts his round $\rho$ messages and proves in zero-knowledge that the broadcasted message is correct, i.e., that he knows the input and randomness that are consistent with the initial commitments and the (public) view of the protocol so far. The main difference of the IOZ compiler and the GMW compiler is that the parties are not only committed to their randomness, but they are also committed to their entire setup string, i.e., their private component of the correlated randomness. In the following, for the sake of completeness, we enumerate some key properties of the resulting maliciously secure protocol $\pi _\mathtt{Mal}$ (which is based on the compiler in [23]) that will be important for our construction:

• Every party is committed to his setup, i.e., the part of the correlated randomness it holds. That is, every party $P _{i}$ receives from the setup his randomness (which we refer to as $P _{i}$’s private component of the setup) along with one-to-many commitments²⁰ on the private components of all parties. Without loss of generality, we also assume that a common-reference string (CRS) and a public-key infrastructure (PKI) are included in every party’s setup. We refer to the distribution of this correlated randomness as $\mathcal {D}_\mathtt {Mal}$.

• The protocol $\pi _\mathtt{Mal}$ uses only the broadcast channel for communication.

• Given the correlated randomness setup, the protocol $\pi _\mathtt{Mal}$ is completely deterministic. This is achieved in [23] by ensuring that all the randomness used in the protocol, even the one needed for the zero-knowledge proofs, is part of the private components that are distributed by the sampling functionality.²¹

• $\pi _\mathtt{Mal}$ starts off by having every party broadcast a one-time pad encryption of its input with its (committed) randomness and a NIZK that it knows the input and randomness corresponding to the broadcasted message.

• By convention, the next-message function of $\pi _\mathtt{Mal}$ is such that if in any round the transcript seen by a party is an aborting transcript, i.e., is not consistent with an accepting run of the semi-honest protocol, then the party outputs $\perp$. Recall that the identifiable abort property ensures that in this case every party will also output the identity of a malicious party (the same for all parties).

• There is a (known) upper bound on the number $\rho _\mathrm{c}$ of rounds of $\pi _\mathtt{Mal}$.

We remark that, given appropriate setup, the IOZ-compiler achieves information-theoretic security, and needs therefore to build information-theoretic commitments and zero-knowledge proofs. As in this work we are only after computational security, we modify the IOZ compiler so that we use (computationally) UC secure one-to-many commitments [14] and computationally UC secure non-interactive zero-knowledge proofs (NIZKs) instead if their information-theoretic instantiation suggested in [23]. Both the UC commitment and the NIZKs can be built in the CRS model. Moreover, the use of UC secure instantiations of zero-knowledge and commitments ensures that the resulting protocol will be (computationally) secure.

Using the Setup Within a Subset of Parties. A standard property of many protocols in the correlated-randomness model is that once the parties in $\mathcal {P}$ have received the setup, any subset $\mathcal {P} '\subset \mathcal {P}$ is able to use it to perform a computation of a $|\mathcal {P} '|$-party function amongst them while ignoring parties in $\mathcal {P} \setminus \mathcal {P} '$. More concretely, assume the parties in $\mathcal {P}$ have been handed a setup allowing them to execute some protocol $\pi$ for computing any $|\mathcal {P} |$-party function f; then for any $\mathcal {P} '\subseteq \mathcal {P}$, the parties in $\mathcal {P} '$ can use their setup within a protocol $\pi |_{\mathcal {P} '}$ to compute any $|\mathcal {P} '|$-party function $f|_{|\mathcal {P} '|}$. This property which will prove very useful for obtaining computation with robustness or compensation, is also satisfied by the IOZ protocol, as the parties in $\mathcal {P} '$ can simply ignore the commitments (public setup component) corresponding to parties in $\mathcal {P} {\setminus }\mathcal {P} '$. It should be noted that this is not an inherent property of the correlated randomness model: e.g., protocols based on threshold encryption do not immediately satisfy this property (as players would have to readjust the threshold).

Making Identifiability Public. The general idea of our protocol is to have every party issue transactions by which he commits to transferring a certain amount of coins per party for each protocol round. All these transactions are issued at the beginning of the protocol execution. Every party can claim the “committed” coins transferred to him associated to some protocol round $\rho$ only under the following conditions: (1) the claim is posted in the time-interval corresponding to round $\rho$; (2) the party has claimed all his transferred coins associated to the previous rounds; and (3) the party has posted a transaction which includes his valid protocol message for round $\rho$.

In order to ensure that a party cannot claim his coins unless he follows the protocol, the ledger (more concretely the validation predicate) should be able to check that the party is indeed posting its valid next message. In other words, in each round $\rho$, $P _{i}$’s round-$\rho$ message acts as a witness for $P _{i}$ claiming all the coins committed to him associated with this round $\rho$. To this direction we make the following modification to the protocol: Let $f(x_1,\ldots ,x_n)=(y_1,\ldots ,y_n)$ denote the n-party function we wish to compute, and let $f^{+1}$ be the ($n+1$)-party function which takes input $x_i$ from each $P _{i}$, $i\in [n],$ and no input from $P _{n+1}$ and outputs $y_i$ to each $P _{i}$ and a special symbol (e.g., 0) to $P _{n+1}$. Clearly, if $\pi _\mathtt{SH}$ is a semi-honest n-party protocol for computing f over broadcast, then the $n+1$ protocol $\pi _\mathtt{SH} ^{+1}$ (in which every $P _{i}$ with $i\in [n]$ executes $\pi _\mathtt{SH}$ and $P _{n+1}$ simply listens to the broadcast channel and outputs 0) is a semi-honest secure protocol for $f^{+1}$.

Now if $\pi _\mathtt{Mal} ^{+1}$ denotes the $(n+1)$-party malicious protocol which results by applying the above modified IOZ compiler on the $(n+1)$-party semi-honest protocol $\pi _\mathtt{SH} ^{+1}$ for computing the function $f^{+1}$, then, by construction this protocol computes function $f^{+1}$ with identifiable abort and has the following additional properties:

• Party $P _{n+1}$ does not make any use of his private randomness whatsoever; this is true because he broadcasts no messages and simply verifies the broadcasted NIZKs.

• If some party $P _i$, $i\in [n]$ deviates from running $\pi _\mathtt{SH}$ with the correlated (committed) randomness as distributed from the sampling functionality, then this is detected by all parties, including $P _{n+1}$ (and protocol $\pi _\mathtt{Mal} ^{+1}$ aborts identifying $P_i$ as the offender). This follows by the soundness of the NIZK which $P _{i}$ needs to provide proving that he is executing $\pi _\mathtt{SH}$ in every round.

Due to $P _{n+1}$’s role as an observer who gets to decide if the protocol is successful ($P _{n+1}$ outputs 0) or some party deviated ($P _{n+1}$ observes that the corresponding NIZK verification failed) in the following we will refer to $P _{n+1}$ in the above protocol as the judge. The code of the judge can be used by anyone who has the public setup and wants to follow the protocol execution and decide whether it should abort or not given the parties’ messages. Looking ahead, the judge’s code in the protocol will be used by the ledger to decide whether or not a transaction that claims some committed coins is valid.

5.2 Special Transactions Supported by Our Ledger

In this section we specify the $\mathsf {Validate}$ and the $\mathsf {Blockify}$ predicates that are used for achieving our protocol’s properties. More specifically, our protocol uses the following type of transactions which transfer v coins from wallet $\mathtt{address}_{i}$ to wallet $\mathtt{address}_{j}$ conditioned on a statement $\varSigma$:

$$\begin{aligned} \mathbb {B}_{v,{\mathtt{address}_{i}},{\mathtt{address}_{j}},\varSigma ,\mathtt{aux},\sigma _i,\tau } \end{aligned}$$

(1)

where $\sigma _i$ is a signature of the transaction, which can be verified under wallet $\mathtt{address}_{i}$; $\tau$ is the time-stamp, i.e., the current value of the clock when this transaction is added to the state by the ledger—note that this timestamp is added by the ledger and not by the users,—$\mathtt{aux} \in \{0,1\}^*$ is an arbitrary string²²; and the statement $\varSigma$ consists of three arguments, i.e., $\varSigma =(\mathtt{arg{1}},\mathtt{arg{2}},\mathtt{arg{3}})$, which are processed by the $\mathsf {Validate}$ predicate in order to decide if the transaction is valid (i.e., if it will be included in the ledger’s next block).

The $\mathsf {Validate}$ Predicate. The validation happens by processing the arguments of $\varSigma$ in a sequential order, where if while processing of some argument the validation rejects, algorithm $\mathsf {Validate}$ stops processing at that point and this transaction is dropped. The arguments are defined/processed as follows:

• Time-Restrictions: The first argument is a pair $\mathtt{arg{1}} =(\tau _{-},\tau _{+})\in \mathbb Z \times (\mathbb Z ^+\cup \{\infty \})$ of points in time. If $\tau _{-}>\tau _+$ then the transaction is invalid (i.e., it will be dropped by the ledger). Otherwise, before time $\tau _-$ the coins in the transaction “remain” blocked, i.e., no party can spend them; from time $\tau _-$ until time $\tau _+$, the money can be spent by the owner of wallet $\mathtt{address}_{j}$ provided that the spending statement satisfies also the rest of the requirements/arguments in statement $\varSigma$ (listed below). After time $\tau _+$ the money can be spent by the owner of wallet $\mathtt{address}_{i}$ without any additional restrictions (i.e., the rest of the arguments in $\varSigma$ are not parsed). As a special case, if $\tau _+=\infty$ then the transferred coins can be spent from $\mathtt{address}_{j}$ at any point (provided the spending statement is satisfied); we say then that the transaction is time-unrestricted,²³ otherwise we say that the transaction is time restricted.

• Spending Link: Provided that the processing of the first argument, as above, was not rejecting, the $\mathsf {Validate}$ predicate proceeds to the second argument, which is a unique “anchor”, $\mathtt{arg{2}} =\alpha \in \{0,1\}^*$. Informally, this serves as a unique identifier for linked transactions²⁴; that is, when $\alpha \ne \perp$, then the $\mathsf {Validate}$ algorithm of the ledger looks in the ledger’s state and buffer to confirm that the balance of transactions to/from the wallet address $\mathtt{address}_{i}$ with this anchor $\mathtt{arg{2}}$ is at least $v'\ge v$ coins. That is, the sum of coins in the state or in the buffer with receiver address $\mathtt{address}_{i}$ and anchor $\mathtt{arg{2}}$ minus the sum of coins in the state or in the buffer with sender address $\mathtt{address}_{i}$ and anchor $\mathtt{arg{2}}$ is greater equal to v. If this is not the case then the transaction is rendered invalid; otherwise the validation of this argument succeeds and the algorithm proceeds to the next argument.

• State-Dependent Condition: The last argument to be validated is $\mathtt{arg{3}}$, which is a relation $\mathcal {R}: \mathcal {S} \times \mathcal {B} \times \mathcal {T} \rightarrow \{0,1\}$, where $\mathcal {S}$, $\mathcal {B}$, and $\mathcal {T}$ are the domains of possible ledger-states, ledger-buffers, and transactions, respectively (in a given encoding). This argument defines which type of transactions can spend the coins transferred in the current transaction. That is, in order to spend the coins, the receiver needs to submit a transaction $\mathtt {tx} \in \mathcal {T}$ such that $\mathcal {R} (\mathsf {state},\mathsf {buffer},\mathtt {tx})=1$ at the moment when $\mathtt {tx}$ is to be validated and inserted in the $\mathsf {buffer}$. In our construction this is the part of the transaction that we will take advantage to detect cheating (and thus $\mathcal {R}$ will encode a NIZK verifier etc.).

We point out that as with standard Bitcoin transactions, the validation predicate will always also check validity of the signature $\sigma _i$ with respect to the wallet $\mathtt{address}_{i}$. Moreover, the standard Bitcoin-like transactions can be trivially casted as transactions of the above type by setting $\alpha =\perp$ and $\varSigma =((0,\infty ),\perp ,\mathcal {R}_\emptyset )$, where $\mathcal {R}_\emptyset$ denotes the relation which is always true.

To simplify the structure of our special transactions and ease their implementation, we impose the following additional constraints: whenever a time-restriction is given, i.e., $\arg _1 = (\tau _{-}, \tau _{+})$ then it must be that $\alpha \ne \bot$. Furthermore, if a time-restricted transaction is present with anchor $\alpha$ from $\mathtt {address} _1$ to $\mathtt {address} _2$, the only transactions that are permitted with anchor $\alpha$ in the ledger would be time-unrestricted transactions originating from either $\mathtt {address} _2$ within the specified time-window, or $\mathtt {address} _1$ after the specified time window.

The $\mathsf {Blockify}$ Algorithm. This algorithm simply groups transactions in the current buffer and adds a timestamp from the current round. We choose to ignore any additional functionality (e.g., such as a reward mechanism for mining that is present in typical cryptocurrencies — however such mechanism can be easily added independently of our results).

5.3 The Protocol

Let $\pi _\mathtt{Mal} ^{+1}$ denote the protocol described in Sect. 5.1. Let $\mathtt{Round2Time} (1)$ denote the time in which the parties have agreed to start the protocol execution. Without loss of generality we assume that $\mathtt{Round2Time} (1)>\mathtt {T} +1$ where $\mathtt {T}$ is the number clock ticks for each block generation cf. Fig. 2.²⁵ Furthermore, for simplicity, we assume that each party $P _{i}$ receives its input $x_i$ with its first activation from the environment at time $\mathtt{Round2Time} (1)$ (if some honest party does not have an input by that time it will execute the protocol with a default input, e.g., 0).

Informally, the protocol proceeds as follows: In a pre-processing step, before the parties receive input, the parties invoke the sampling functionality for $\pi _\mathtt{Mal} ^{+1}$ to receive their correlated randomness.²⁶ The public component of this randomness includes their protocol-associated wallet $\mathtt {address} _i$ which they output (to the environment). This corresponds to the resources allocation step in the $\mathsf {Q}$-robustness wrapper $\hat{\mathcal {W}}$. The environment is then expected to submit $\rho _\mathrm{c}$ special (as above) transactions for each pair of parties $P _{i}\in \mathcal {P}$ and $P_j\in \mathcal {P}$; the source wallet-address for each such transaction is $P _{i}$’s, i.e., $\mathtt {address} _i$ and the target wallet-address for is $P _{j}$’s, i.e., $\mathtt {address} _j$, and the corresponding anchors are as follows: $\alpha _{i,j,\rho }=(\mathsf {pid},i,j,\rho )$, for $(i,j,\rho )\in [n]^2\times [\rho _\mathrm{c} ]$, where²⁷ $\mathsf {pid}$ is the (G)UC protocol ID for $\pi _\mathtt{Mal} ^{+1}$. Since by assumption, $\mathtt{Round2Time} (1)> \mathtt {T} +1$, the environment has sufficient time to submit these transaction so that by the time the protocol starts they have been posted on the ledger.

At time $\mathtt{Round2Time} (1)$ the parties receive their inputs and initiate the protocol execution by first checking that sufficient funds are allocated to their wallets linked to the protocol executions by appropriate anchors, as above. If some party does not have sufficient funds then it broadcasts an aborting message and all parties abort.²⁸ This aborting in case of insufficient funds is consistent with the behavior of the wrapper $\hat{\mathcal {W}}$ when $\mathsf {Q}^{\text {C-Init}}_{\bar{\mathcal {G}}}$ is false. Otherwise, parties make the special transactions that commit them (see below) into executing the protocol, and then proceed into claiming them one-by-one by executing their protocol in a round-by-round fashion.

Note that each protocol round lasts one ledger round so that the parties have enough time to claim their transactions. This means that $\mathtt{Round2Time} (i+1)-\mathtt{Round2Time} (i)\ge \mathtt {T}$, which guarantees that any transaction submitted for round $\rho$, $\rho =1,\ldots ,\rho _\mathrm{c}-1$, of the protocol, has been posted on the ledger by the beginning of round $\rho +1$. Observe that by using a constant round protocol $\pi _\mathtt{Mal} ^{+1}$ (e.g., the modified compiled protocol from [23] instantiated with a constant round semi-honest protocol) we can ensure that our protocol will terminate in a constant number of ledger rounds and every honest party will either receive its input, or will have a positive balance in its wallet.

Remark 1

(On availability of funds). Unlike existing works, we choose to explicitly treat the issue of how funds become available to the protocol by making the off-line transfers external to the protocol itself (i.e., the environment takes care of them). However, the fact that the environment is in charge of “pouring” money into the wallets that are used for the protocol does not exclude that the parties might be actually the ones having done so. Indeed, the environment’s goal is to capture everything that is done on the side of, before, or after the protocol, including other protocols that the parties might have participated in. By giving the environment enough time to ensure these transactions are posted we ensure that some honest party not having enough funds corresponds to an environment that makes the computation abort (in a fair way and only in the pre-processing phase, before the parties have invested time into posting protocol transactions).

Here is how we exploit the power of our special transactions in order to arrange that the balance of honest parties is positive in case of an abort. We require that the auxiliary string of a transaction of a party $P _{j}$ which claims a committed transaction for some round $\rho$ includes his $\rho$-round protocol message. We then have the relation of this transaction be such that it evaluates to 1 if only if this is indeed $P _{j}$’s next message. Thus, effectively the validate predicate implements the judge in $\pi _\mathtt{Mal} ^{+1}$ and can, therefore, decide if some party aborted: if some party broadcasts a message that would make the judge abort, then the validate predicate drops the corresponding transaction and all claims for committed transactions corresponding to future rounds, thus, all other parties are allowed to reclaim their committed coins starting from the next round.

Before we give the protocol description there is a last question: how is the ledger able to know which parties should participate in the protocol? Here is the problem: The adversary might post in the first round (as part of the committing transaction for the first round) a fake, maliciously generated setup. Since the ledger is not part of the correlated randomness sampling, it would be impossible to decide which is the good setup. We solve this issue by the following technique that is inspired by [6]: The ledger²⁹ groups together parties that post the same setup; these parties form “islands”, i.e., subsets of $\mathcal {P}$. For each such subset ${\mathcal {P}'}\subseteq \mathcal {P} \cup \{P _{n+1}\}$ which includes the judge $P _{n+1}$, the ledger acts as if the parties in ${\mathcal {P}'}$ are executing the protocol $\pi _\mathtt{Mal} ^{+1}|_{\mathcal {P}'}$ (which, recall, is the restriction of $\pi _\mathtt{Mal} ^{+1}$ to the parties in ${\mathcal {P}'}$) for computing the $|{\mathcal {P}'}|$-party function $f^{+1} |_{{\mathcal {P}'}}(\varvec{x})$ defined as follows: let the function to be computed be $f(\varvec{x})$, where $\varvec{x}=(x_1,\ldots ,x_n)$, and $f^{+1}$ be as above, then $f^{+1} |_{{\mathcal {P}'}}(\varvec{x})=f^{+1} (\varvec{x}_{{\mathcal {P}'}})$ where $\varvec{x}_{{\mathcal {P}'}}=(x_1',\ldots ,x_n')$ with $x_i'=x_i$ for $P _{i}\in {\mathcal {P}'}$ and $x_i'$ being a default value for every $P _{i}\not \in {\mathcal {P}'}$. This solves the problem as all honest parties will be in the same island ${\mathcal {P}'}\subset \mathcal {P}$ (as they will all post the same value for public randomness); thus if the adversary chooses not to post this value on behalf of some corrupted party, he is effectively setting this party’s input to a default value, a strategy which is easily simulatable. (Of course, the above solution will allow the adversary to also have “islands” of only corrupted parties that might execute the protocol, but this is also a fully simulatable strategy and has no effect on fair-compensation whatsoever—corrupted parties are not required to have a positive balance upon abort).

The final protocol $\pi _\mathtt{Mal}^\mathbb {B}$ is detailed in the following. The protocol ID is $\mathsf {sid}$. The function to be computed is $f(x_1,\ldots ,x_n)$. The protocol parties are $\mathcal {P} =\{P _{1},\ldots ,P _{n}\}$. We assume all parties have registered with the clock functionality in advance and are therefore synchronized once the following steps start.

• Phase 1: Setup Generation

  Time $\tau _{-2}=\mathtt{Round2Time} (1) - \mathtt {T}-2$:

  The parties invoke the sampling functionality for $\mathcal {D}_\mathtt {Mal}$, i.e., every party $P _{i}\in \mathcal {P}$ starts off by sending the sampling functionality a message $(\textsc {request}, \mathsf {sid})$; the sampling functionality returns $(R^\mathtt{priv} _i,R^\mathtt{pub})$ to $P _{i}$ where $R^\mathtt{priv} _i$ is $P _{i}$’s private component (including all random coins he needs to run the protocol, along with his signing key $\mathsf {sk} _i$) of the setup and $R^\mathtt{pub}$ is the public component (the same for every party $P _{j}$) which includes the vector of UC commitments , where for $j\in [n]$, is a commitment to $R^\mathtt{priv} _j$, along with a vector of public (verification) keys $(\mathsf {vk} _1,\ldots ,\mathsf {vk} _n)$ corresponding to the signing keys $(\mathsf {sk} _1,\ldots ,\mathsf {sk} _n)$ and a common reference string CRS. Every party outputs its own public key, as its wallet address for the protocol, i.e., $\mathtt {address} _i=\mathsf {vk} _i$.

• Phase 2: Inputs and Protocol Execution

  Time $\tau _{-1}=\mathtt{Round2Time} (1) - 1$:

  Every party $P _{i}\in \mathcal {P}$ receives its input $x_i$ ($x_i=0$ if no input is received in the first activation of $P _{i}$ for time $\mathtt{Round2Time} (1)$) and does the following to check that it has sufficient fund available: $P _{i}$ reads the current state from the ledger. If the state does not include for each $(i,j,\rho )\in [n]^2\times [\rho _\mathrm{c} ]$ a transaction $\mathbb {B}_{c,\mathtt {address},\mathtt {address} _i,\varSigma ^0_{i,j,\rho },\mathtt{aux} ^0_{i,j,\rho },\sigma ,\tau }$, for some arbitrary $\mathtt {address}$ and where $\varSigma ^0_{i,j,\rho }=((0,\infty ),(\mathsf {sid},i,j,\rho ),\mathcal {R}_\emptyset )$ then $P _{i}$ broadcasts $\perp$ and every party aborts the protocol execution with output $\perp$ (i.e., no party does anything from that point on. Recall that $\rho _\mathrm{c}$ is the upper bound on the number of rounds of $\pi _\mathtt{Mal} ^{+1}$, cf. Sect. 5.1. Time $\tau _0=\mathtt{Round2Time} (1)$:

  Every $P _{i}$ submits to the ledger the following “commitment” transactions:³⁰

  • 1. For each $P _{j}\in \mathcal {P}: \mathbb {B}_{c,\mathtt {address} _i,\mathtt {address} _j,\varSigma _{i,j,1},\mathtt{aux} _{i,j,1},\sigma ,\tau }$, where $\mathtt{aux} _{i,j,1}=R^\mathtt{pub}$ and $\varSigma _{i,j,1}=(\mathtt{arg{1}} _{i,j,1},\mathtt{arg{2}} _{i,j,1},\mathtt{arg{3}} _{i,j,1})$ with

    • $\mathtt{arg{1}} _{i,j,1}=(\mathtt{Round2Time} (1)+\mathtt {T},\mathtt{Round2Time} (1)+2\mathtt {T}-1)$

    • $\mathtt{arg{2}} _{i,j,1}=(\mathsf {sid},i,j,1)$

    • $\mathtt{arg{3}} _{i,j,1}=\mathcal {R} _{i,j,1}$ defined as follows: Let $\mathcal {P} ^{+1}=\mathcal {P} \cup \{P _{n+1}\}$, where $P _{n+1}$ denotes the judge, be the player set implicit in $R^\mathtt{pub}$,³¹ and let $\mathcal {P} ^{+1}_i\subseteq \mathcal {P} ^{+1}$ denote the island of party i including the judge, i.e., the set of parties (wallets), such that in the first block posted after time $\mathtt{Round2Time} (1)$ all parties $P _k\in \mathcal {P} ^{+1}_i$ have exactly one transaction for every $P _{j}\in \mathcal {P}$ with $\mathtt{arg{1}} _{k,j,1}=(\mathtt{Round2Time} (1)+\mathtt {T},\mathtt{Round2Time} (1)+2\mathtt {T}-1)$, $\mathtt{arg{2}} _{k,j,1}=(\mathsf {sid},k,j,1)$, and $\mathtt{aux} ^1_{k,j,1}=R^\mathtt{pub}$. Furthermore, let $\pi _\mathtt{Mal} ^{+1}|_{\mathcal {P} ^{+1}_i}$ be the protocol with public identifiability for computing $f^{+1} |_{\mathcal {P} ^{+1}_i}$, described above and denote by $R^\mathtt{pub} |_{\mathcal {P} ^{+1}_i}$ the restriction of the public setup to the parties in $\mathcal {P} ^{+1}_i$. Then $\mathcal {R} _{i,j,1}(\mathsf {state},\mathsf {buffer},\mathtt {tx})=1$ if and only if the protocol of the judge with public setup $R^\mathtt{pub} |_{\mathcal {P} ^{+1}_i}$ accepts the auxiliary string $\mathtt{aux} _\mathtt {tx}$ in $\mathtt {tx}$ as $P _{i}$’s first message in $\pi _\mathtt{Mal} ^{+1}|_{\mathcal {P} ^{+1}_i}$ (i.e., it does not abort in the first round).

  • 2. For each protocol round $\rho =2,\ldots ,\rho _\mathrm{c}$ and each $P _{j}\in \mathcal {P}$: each party posts the transaction: $\mathbb {B}_{c,\mathtt {address} _i,\mathtt {address} _j,\varSigma _{i,j,\rho },\mathtt{aux} ^1_{i,j,\rho },\sigma ,\tau }$, where $\mathtt{aux} ^1_{i,j,\rho }=R^\mathtt{pub}$ and $\varSigma _{i,j,\rho }=(\mathtt{arg{1}},\mathtt{arg{2}},\mathtt{arg{3}})$ with

    • $\mathtt{arg{1}} =(\mathtt{Round2Time} (\rho )+\mathtt {T},\mathtt{Round2Time} (\rho +1)+2 \mathtt {T}-1)$

    • $\mathtt{arg{2}} =(\mathsf {sid},i,j,\rho )$.

    • $\mathtt{arg{3}} =\mathcal {R} _{i,j,\rho }$ defined as follows: Let $\mathcal {P} _i^{+1}, \pi _\mathtt{Mal} ^{+1}|_{\mathcal {P} _i^{+1}}$ be defined as above (and assume $\mathcal {P} ^{+1}_i=\{P _{i_1},\ldots ,P _{i_m}\}$. Then $\mathcal {R} _{i,j,\rho }(\mathsf {state},\mathsf {buffer},\mathtt {tx})=1$ if and only if, for each $r=1,\ldots ,\rho -1$ and each party $P _{i_k}\in \mathcal {P} ^{+1}_i$, the state $\mathsf {state}$ includes transactions in which the auxiliary input is $\mathtt{aux} _{{i_k},r}$ and the protocol of the judge with public setup $R^\mathtt{pub} |_{\mathcal {P} ^{+1}_i}$, and transcript $(\mathtt{aux} _{{i_1},1},\ldots ,\mathtt{aux} _{{i_m},1}), \ldots , (\mathtt{aux} _{{i_1},\rho -1},\ldots ,\mathtt{aux} _{{i_m},\rho -1})$, accepts the auxiliary string $\mathtt{aux}$ in $\mathtt {tx}$ as $P _{i}$’s next ($\rho$-round) message in $\pi _\mathtt{Mal} ^{+1}|_{\mathcal {P} ^{+1}_i}$ (i.e., it does not abort in the $\rho$-th round).

• Phase 3: Claiming Committed Transactions/Executing the Protocol

  Time $\tau \ge \mathtt{Round2Time} (1)$:

  For each $\rho =1,\ldots ,\rho _\mathrm{c} +1$, every $P _{i}$ does the following at time $\mathtt{Round2Time} (\rho )$:

  • 1. If $\tau =\mathtt{Round2Time} (\rho _\mathrm{c} +1)$ then go to Step 4; otherwise do the following:

  • 2. Read the ledger’s state, and compute $\mathcal {P} ^{+1}_i, \pi _\mathtt{Mal} ^{+1}|_{\mathcal {P} ^{+1}_i}$ as above.

  • 3. If the state $\mathsf {state}$ is not aborting for $\mathcal {P} ^{+1}_i=\{P _{i_1},\ldots ,P _{i_m}\}$, i.e., it includes for each $r=1,\ldots ,\rho -1$ and each party $P _{i_k}\in \mathcal {P} _i^{+1}$ a transaction in which the auxiliary input is $\mathtt{aux} _{{i_k},r}$ such that $P _{i}$ executing $\pi _\mathtt{Mal} ^{+1}|_{\mathcal {P} ^{+1}_i}$ with public setup $R^\mathtt{pub} |_{\mathcal {P} ^{+1}_i}$, private setup $R^\mathtt{priv} _i$, and transcript $(\mathtt{aux} _{{i_1},1},\ldots ,\mathtt{aux} _{{i_m},1}), \ldots , (\mathtt{aux} _{{i_1},\rho -1},\ldots ,\mathtt{aux} _{{i_m},\rho -1})$ for the first $r-1$ rounds does not abort, then compute $P _{i}$’s message for round $\rho$, denoted as $\text {msg} _\rho$, and submit to the ledger for each $P _k\in \mathcal {P} ^{+1}_i$ a transaction $\mathbb {B}_{c,\mathtt {address} _i,\mathtt {address},\varSigma _{k,i,\rho }',\mathtt{aux} ^\rho _{k,i,\rho },\sigma ,\tau }$, where $\mathtt{aux} ^\rho _{k,i,\rho }=\text {msg} _\rho$, $\mathtt {address}$ is the address that was the input of the first transaction with link $(\mathsf {sid}, i, k, \rho )$ and $\varSigma _{k,i,\rho }'=(\mathtt{arg{1}},\mathtt{arg{2}},\mathtt{arg{3}})$ instantiated as follows: $\mathtt{arg{1}} =(0,\infty )$; $\mathtt{arg{2}} =(\mathsf {sid},k,i,\rho )$; $\mathtt{arg{3}} =\mathcal {R}_\emptyset$. For each such transaction posted enter $(\mathsf {sid}, k,i, \rho )$ in a set of “claimed” transactions $\mathrm {CLAIM}_i$.

  • 4. Otherwise, i.e., if the state $\mathsf {state}$ is aborting, then prepare for each round $r=1,\ldots ,\rho -1$, and each $P _k\in \mathcal {P}$ a transaction by which the committed transaction towards $P _k$ corresponding to round r is claimed back to $\mathtt {address} _i$, i.e., $\mathbb {B}_{c,\mathtt {address} _k,\mathtt {address} _i,\varSigma ,\mathtt{aux},\sigma ,\tau }$, where $\mathtt{aux} =\perp$ and $\varSigma =(\mathtt{arg{1}},\mathtt{arg{2}},\mathtt{arg{3}})$ instantiated as follows: $\mathtt{arg{1}} =(0,\infty )$; $\mathtt{arg{2}} =(\mathsf {sid},i,k,r)$; $\mathtt{arg{3}} =\mathcal {R}_\emptyset$. The above transaction is posted as long as it is not claimed already, i.e., $(\mathsf {sid}, i,k, r) \in \mathrm {CLAIM}_i$ in a previous step.

This completes the description of the protocol. The protocol terminates in $O(\rho _\mathrm{c})$ ledger rounds. A depiction of the transactions that are associated with a protocol round is given in Fig. 4.

Fig. 4.

The transactions associated with the first round r of our protocol compiler. $R_i(\cdot )$ is a relation which is true given the r-th round message of $P _i$ (for the given correlated randomness and previous messages); $m_i$ is the message of player $P _i$ for round r. Player 3 aborts in the r-th round of the protocol and players 1,2 collect their reward.

Observe that by using a constant-round protocol $\pi _\mathtt{Mal}$  [23], we obtain a protocol with constantly many ledger rounds. Furthermore, as soon as an honest party posts a protocol-related transaction, he is guaranteed to either receive his output or have a positive balance (of at least c coins) after $O(\rho _\mathrm{c})$ ledger rounds. The following theorem states the achieved security. We assume the protocol is executed in the synchronous model of Sect. 3.1.

Theorem 3

Let $\bar{\mathcal {G}} =(\bar{\mathcal {G}} _{\textsc {ledger}},\bar{\mathcal {G}} _{\textsc {clock}})$, The above protocol in the $(\bar{\mathcal {G}},\mathcal {F}_{\textsc {corr}}^{\mathcal {D}_\mathtt {Mal}})$-hybrid world realizes $\tilde{\mathcal {W}}(\mathcal {F})$ with robust compensation.

Proof

(sketch). We first prove that the above protocol is simulatable, by sketching the corresponding simulator $\mathcal {S}$. If the protocol aborts already before the parties make their transactions, then the simulator can trivially simulate such an abort, as he needs to just receive the state of the ledger and see if all wallets corresponding to honest parties have sufficient funds to play the protocol. In the following we show that the rest of the protocol (including the ledger’s contents) can be simulated so that if there is an abort, honest parties’ wallets have a positive balance as required by $\mathsf {Q}$ fairness. First we observe that the simulator $\mathcal {S}$ can easily decide the islands in which the parties are split, as he internally simulates the sampling functionality. Any island other than the one of honest parties (all honest parties will be in the same island because they will post transactions including the same public setup-component) is trivially simulatable as it only consists of adversarial parties and no guarantee is given about their wallets by $\mathsf {Q}$-fairness. Therefore, it suffices to provide a simulator for the honest parties’ island. To this direction, the simulator uses the simulator $\mathcal {S} _{\pi _\mathtt{Mal} ^{+1}}$ which is guaranteed to exist from the security of $\pi _\mathtt{Mal} ^{+1}$ to decide which messages to embed in the transactions of honest parties (the messages corresponding to corrupted parties are provided by the adversary). If $\mathcal {S} _{\pi _\mathtt{Mal} ^{+1}}$ would abort, then $\mathcal {S}$ interacts the ideal functionality to abort and continues by claiming back all the committed transactions to the honest parties’ wallets, as the protocol would. The soundness of the simulation of $\mathcal {S} _{\pi _\mathtt{Mal} ^{+1}}$ ensure that the output of the parties and the contents of the ledger in the real and the ideal world are indistinguishable.

The fact that the protocol will eventual terminate given sufficient rounds of activating every party (i.e., in the terminology of Definition 2, given a sufficiently high threshold T) follows by inspection of the protocol: in each round every party needs at most a (fixed) polynomial number of activations to post the transactions corresponding to his current-round message-vector. (In fact, the polynomial is only needed in the initial committing-transactions round and from that point on it is linear). To complete the proof, we argue that (1) when the protocol does not abort, every honest party has a non-negative balance, and (2) when the protocol aborts, then honest parties have a positive balance of at least c coins as required by predicate $\mathsf {Q}$ for the simulator to be able to complete its simulation and deliver the (possibly aborting) outputs. These properties are argued as follows:

Property (1): The parties that are not in the honest parties’ islands cannot claim any transaction that honest parties make towards them as the ledger will see they as not in the island and reject them. Thus by the last round every honest party will have re-claimed all transactions towards parties not in his island. As far as parties in the honest island are concerned, if no abort occurs then every party will claim all the transactions from parties in his island, and therefore his balance will be 0.

Property (2): Assume that the protocol aborts because some (corrupted) $P _i$ broadcasts an inconsistent message in some round $\rho$. By inspection of the protocol one can verify that honest parties will be able to claim all transaction-commitments done to them up to round $\rho$ (as they honestly execute their protocol) plus all committed transactions that they made for rounds $\rho +1\ldots ,\rho _\mathrm{c}$. Additionally, because $P _i$ broadcasts an inconsistent message in round $\rho$, he will be unable to claim transactions of honest parties done from round $\rho$ and on; these bitcoins will be reclaimed by the honest parties, thus giving their wallets a positive balance of at least c coins.