Fair and Robust Multi-Party Computation using a Global Transaction Ledger

Transcription

1 Far and Robust Mult-Party Computaton usng a Global Transacton Ledger Aggelos Kayas aggelos@d.uoa.gr Hong-Sheng Zhou hszhou@vcu.edu June 10, 2015 Vassls Zkas vzkas@nf.ethz.edu Abstract Classcal results on secure mult-party computaton (MPC) mply that fully secure computaton, ncludng farness (ether all partes get output or none) and robustness (output delvery s guaranteed), s mpossble unless a majorty of the partes s honest. Recently, cryptocurrences lke Btcon where utlzed to leverage the farness loss n MPC aganst a dshonest majorty. The dea s that when the protocol aborts n an unfar manner (.e., after the adversary receves output) then honest partes get compensated by the adversarally controlled partes. Our contrbuton s three-fold. Frst, we put forth a new formal model of secure MPC wth compensaton and we show how the ntroducton of sutable ledger and synchronzaton functonaltes makes t possble to express completely such protocols usng standard nteractve Turng machnes (ITM) crcumventng the need for the use of extra features that are outsde the standard model as n prevous works. Second, our model, s expressed n the unversal composton settng wth global setup and s equpped wth a composton theorem that enables the desgn of protocols that compose safely wth each other and wthn larger envronments where other protocols wth compensaton take place; a composton theorem for MPC protocols wth compensaton was not known before. Thrd, we ntroduce the frst robust MPC protocol wth compensaton,.e., an MPC protocol where not only farness s guaranteed (va compensaton) but addtonally the protocol s guaranteed to delver output to the partes that get engaged and therefore the adversary, after an ntal round of deposts, s not even able to mount a denal of servce attack wthout havng to suffer a monetary penalty. Importantly, our robust MPC protocol requres only a constant number of (con-transfer and communcaton) rounds. Keywords: Btcon, MPC, Farness, Robustness

2 1 Introducton Secure multparty computaton (MPC) enables a set of partes to evaluate the output of a known functon f( ) on nputs they prvately contrbute to the protocol executon. The desgn of secure MPC protocols, ntated wth the semnal works of Yao [Yao82] and Goldrech et al. [GMW87] has evolved to a major effort n computer securty engneerng. Beyond prvacy, a secure MPC protocol s hghly desrable to be far (ether all partes learn the output or none) and robust (the delvery of the output s guaranteed and the adversary cannot mount a denal of servce aganst the protocol). Achevng farness and robustness n a settng where there s an arbtrary number of corruptons, as desrable as t may appear, s prohbted by strong mpossblty results stemmng from the work of Cleve [Cle86] who showed that con-flppng s nfeasble n any settng where there s no honest majorty among partes that execute the protocol. These mpossblty results, combned wth the mportance of the propertes that they prevent, strongly motvate the exploraton of alternate yet stll realstc models that would enable far and robust MPC protocols. Wth the advent of Btcon [Nak08] and other decentralzed cryptocurrences, the works of [ADMM14a, ADMM14b, BK14, KB14] showed a new drecton for crcumventon of the mpossblty results regardng the farness property: enforcng farness could be acheved through mposng monetary penaltes. In ths settng a breach of farness by the adversary s stll possble but t results n the honest partes collectng a compensaton n a way that s determned by the protocol executon. At the same tme, n case farness s not breached, t s guaranteed that no party loses any money (despte the fact that currency transfers may have taken place between the partes). The ratonale here s that a sutable monetary penalty suffces n most practcal scenaros to force the adversary to operate n the protocol farly. Whle the man dea of farness wth penaltes sounds smple enough, ts mplementaton proves to be qute challengng. The man reason s that the way a crypto-currency operates does not readly provde a trusted party that wll collect money from all partcpants and then ether return t or redstrbute t accordng to the pre-agreed penalty structure. Ths s because cryptocurrences are decentralzed and hence no sngle party s ever n control of a money transfer beyond the owner of a set of cons. The mechansm used n [ADMM14a,ADMM14b,BK14,KB14] to crcumvent the above problem s the capablty 1 of the Btcon network to ssue transactons that are tme-locked,.e., become vald only after a specfc tme and pror to that tme may be superseded by other transactons that are posted n the publc ledger. Superseded tme-locked transactons become nvald and reman n the ledger wthout ever beng redeemed. Whle the above works are an mportant step for the desgn of MPC protocols wth propertes that crcumvent the classcal mpossblty results, several crtcal open questons reman to be tackled; those we address heren are as follows. Our Results. Our contrbuton s three-fold. Frst, we put forth a new formal model of secure MPC wth compensaton and we show how the ntroducton of sutable ledger and synchronzaton functonaltes makes t possble to express completely such protocols usng standard nteractve Turng machnes (ITM) crcumventng the need for the use of extra features that are outsde the standard model (n comparson, the only prevous model [BK14] resorted to specalzed ITM s that utlze resources outsde the computatonal model 2 ). Second, our model 1 Note that ths feature s currently not fully supported. 2 An ITM wth the specal features of wallet and safe was ntroduced n [BK14] to express the ablty of ITM s to store and transfer cons. Such cons were treated as physcal quanttes that were moved between players but also locked n safes n a way that partes were then prevented to use them n certan ways (n other words such safes were not local but were affected from external events). 1

3 s equpped wth a composton theorem that enables the desgn of protocols that compose safely wth each other and wthn larger envronments where other protocols wth compensaton take place; a composton theorem for ths class of protocols was not known before. Thrd, we ntroduce the frst robust MPC protocol wth compensaton,.e., an MPC protocol where not only farness s guaranteed (va compensaton) but addtonally the protocol s guaranteed to delver output to the partes that get engaged and therefore the adversary s not even able to mount a denal of servce attack wthout havng to suffer a monetary penalty. In more detals we have the followng. We put forth a new model that utlzes two deal functonaltes and express the ledger of transactons and a clock n the sense of [KMTZ13] that s connected to the ledger and enables partes to synchronze ther protocol nteractons. Our ledger functonalty enable us to abstract all the necessary features of the underlyng cryptocurrency. Contrary to the only prevous formalzaton approach [BK14, KB14], our modelng allows the enttes that partcpate n an MPC executon to be regular nteractve Turng machnes (ITM) and there s no need to equp them wth addtonal physcal features such as safes and locks. Furthermore the explct ncluson of the clock functonalty (whch s only alluded to n [BK14, KB14]) reveal the exact dependences between the ledger and the clock functonalty that are necessary n order for MPC wth compensaton protocols to be properly descrbed. We express our model wthn a general framework that we call Q-farness and may be of ndependent nterest as t can express meanngful relaxatons of farness n the presence of a global deal functonalty. We prove a composton theorem that establshes that protocols n our framework are secure n a unversally composable fashon. Our composton proof treats the clock and ledger functonaltes as global setups n the sense of [CDPW07, CJS14]. We emphasze that ths s a crtcal desgn choce: the fact that the ledger s a global functonalty ensures that any penaltes that are ncurred to the adversary that result to credts towards the honest partes wll be globally recognzed. Ths should be contrasted to an approach that utlzes regular deal functonaltes whch may be only accessble wthn the scope of a sngle protocol nstance and hence any penalty bookkeepng they account may vansh wth the completon of the protocol. Provdng a composton theorem for MPC protocols wth compensaton was left as an open queston n [BK14]. We fnally present a new protocol for far and robust secure MPC wth compensaton. The robustness property we prove guarantees that once the protocol passes an ntal round of deposts, partes are guaranteed to obtan output or be compensated. Ths s n contrast to far MPC wth compensaton [ADMM14a, ADMM14b, BK14, KB14] where the guarantee s that compensaton takes place only n case the adversary obtans output whle an honest party does not. To put t dfferently, t s feasble for the adversary to lead the protocol to a deadlock where no party receves output however the honest partes have wasted resources by ntroducng transactons n the ledger. We remark that t s n prncple possble to upgrade the protocols of [ADMM14a,ADMM14b,BK14,KB14] to the robust MPC settng by havng them perform an MPC wth dentfable abort, cf. [GMW87, IOZ14], (n such protocol the party that causes the abort can be dentfed and excluded from future executons). However even usng such protocol the resultng robust MPC wth compensaton wll need n the worst case a lnear number of depost/communcaton rounds n the number of malcous partes. Contrary to that, our robust protocol can be nstantated so that t requres a constant number of depost/communcaton rounds 2

4 ndependently of the number of partes that are runnng the protocol. Our constructon uses tme-locked transactons n a novel way to ensure that partes do progress n the MPC protocol or otherwse transactons are sutably revertble to a compensaton for the remanng partes. The structure of our transactons s qute more complex than what can be presently supported by btcon; we provde a hgh level overvew of how our protocol can be mplemented va Ethereum 3 contracts. Related work. Beyond the prevous works [ADMM14a, ADMM14b, BK14, KB14] n far MPC wth compensaton there s a number of other works that attempted to crcumvent the mpossblty results for farness n the settng of dshonest majorty by consderng alternate models. Contrary to the approach based on cryptocurrences these works gve an advantage to the protocol desgner wth respect to the adversaral strategy for corrupton. For nstance, n [GKM + 13] a ratonal adversary s proposed and the protocol desgner s prvy to the utlty functon of the adversary. In [ALZ13] a reputaton system s used and the protocol desgner has the avalablty of the reputaton nformaton of the partes that wll be engaged n the protocol. Fnally n [GGJ + 15] a two tered model s proposed where the protocol desgner s capable of dstngushng two dstnct sets of servers at the onset of the computaton that dffer n terms of ther corruptblty. Global setups were frst put forth n [CDPW07] motvated by noton of denablty n cryptographc protocols. In our work we utlze global functonaltes for unversal composton (wthout the denablty aspect) as n [CJS14] where a smlar approach was taken for the case of the use of the random oracle as a global setup functonalty for MPC. Farness can also be consdered from the resource perspectve, cf. [BN00, Pn03, GMPY06], where t s guaranteed due to the nvestment of proportonal resources between the partes runnng the protocol, and the optmstc perspectve, cf. [ASW97,ASW98,CC00], where a trusted medator can be nvoked n the case of an abort. We fnally note that wthout any addtonal assumptons, due to the mpossblty results mentoned above, one can provde farness only wth certan hgh probablty that wll be affectng the complexty of the resultng protocol, see, e.g., [GK09] and references theren. 2 Model In ths secton, we lay down a formal framework for desgnng composable far protocols n the presence of globally avalable trusted resources. In the frst two subsectons, we ntroduce shared (n the sense of the GUC model [CDPW07]) functonaltes Ḡclock and Ḡledger respectvely to formulate the trust resources that provded by Btcon-lke systems. Then n subsecton 2.3, we put forth a new formal model of secure MPC wth compensaton: we ntroduce the noton of Q-farness, and formulate t va a wrapper functonalty; we then consder the realzaton of such wrapper functonalty, and further provde a composton theorem. In the end of ths secton, a samplng functonalty for producng correlated randomness s also descrbed. Ths wll be used as setup n our protocol desgn. 2.1 Global Clock Functonalty and Synchronous Protocol Executons We here frst defne a shared clock functonalty Ḡclock. Ths functonalty can be vewed as an extenson of the clock functonalty that was defned by Katz et al. [KMTZ13]. The man ntuton behnd the clock functonalty s that when all honest partes agree to move to the 3 3

5 next clock tck, then the clock functonalty wll ncrease ts state, τ, by 1. We remark that there are dfferences between our formulaton and that by Katz et al. [KMTZ13]: there, the clock s for a sngle protocol; however, here we ntend to have the clock to be accessed globally. In addton, n [KMTZ13], the functonalty state s bnary whle here, n our formulaton, the state τ s a postve nteger. The detaled descrpton of the clock functonalty can be found n Fgure 1. Functonalty Ḡclock Shared functonalty Ḡclock s globally avalable to all partcpants. The shared functonalty s parameterzed wth varables τ and P. Intally, τ := 0 and P :=. Upon recevng (regster, sd) from some party P, then set P := P {P } and ntalze d P := 0. Upon recevng (clock-update, sd) from some party P P, then set d P := 1. At any moment, f d P = 1 for all P H, where H denotes the set of honest partes, then set τ := τ + 1, and reset d P := 0 for all P P. Upon recevng (clock-read, sd) from some partcpant, return (clock-read, sd, τ) to the requestor. Fgure 1: The clock functonalty. Next, we elaborate and explan how to use the global clock to desgn synchronous protocols. To capture synchronous protocol executon n the global Ḡ clock model we use the compler dea from [KMTZ13]. Frst, as s the case n real-lfe synchronous protocols we assume that the protocol partcpants have agreed on the startng tme τ 0 of ther protocol and also on the duraton of each round. We abstract ths knowledge by assumng the partes know a functon Round2Tme : Z Z whch maps protocol rounds to tme (accordng to the global clock). In partcular, Round2Tme(0) s the tme τ 0 n whch a common reference strng may be ncluded n the ledger. For ρ Z +, Round2Tme(ρ) s the tme n whch the ρth round of the protocol should be completed. That s, f at tme Round2Tme(ρ) + 1 a party P has not receved P j s ρ-round message, then t takes ths message to be a default message. To make sure that no party proceeds to round ρ + 1 of the protocol before all honest partes have completed round ρ, we requre that any two protocol rounds are at least two clock-tcks apart (see [KMTZ13] for a dscusson); formally, for all ρ 0, t holds that Round2Tme(ρ + 1) Round2Tme(ρ) + 2. A synchronous protocol n the above settng proceeds as follows: Upon recevng any actvaton, party P frst queres the clock (.e., send Ḡclock the message (read, sd)) to fnd out the current tme. Denote by τ the tme reported by Ḡclock. P checks that τ Round2Tme(0), and halts f ths s not the case. Otherwse, P checks whether t has completed ts protocol nstructons for rounds 0,..., ρ c, where ρ c = max{ρ s.t. Round2Tme(ρ) τ}. If ths s not the case, P executes ts next pendng nstructon (for round ρ c ); 4 otherwse, P sends (clock-update, sd) to the clock. 5 4 Note that n (G)UC the partes lose actvaton whenever the send or output a message; thus t mght be the case that they need to be actvated (receve messages) multple tmes n any gven round n order to complete ther protocol. 5 Recall that clock-update sgnals to the clock that, accordng to the current vew of the party the clock should proceed. 4

6 2.2 Global Ledger Functonalty Functonalty Ḡledger provdes the abstracton of a publc ledger n Btcon-lke systems (e.g., Btcon, Ltecon, Namecon, Ethereum, etc). Intutvely, the publc ledger could be accessed globally by protocol partes or other enttes ncludng the envronment Z. Protocol partes or the envronment can generate transactons; and these vald transactons wll be gathered by a set of ledger mantaners (e.g., mners n Btcon-lke systems) n certan order as the state of the ledger. More concretely, whenever the ledger mantaners receve a vector of transactons tx, they frst add the transactons n a buffer, assumng they are vald wth respect to the exstng transactons and the state of the ledger; thus, n ths way a vector of transactons s formed n the buffer. After certan amount of tme, denoted by T, all transactons n the buffer wll be glued nto the ledger state n the form of a block. In Btcon, T s 10 mnutes (approxmately); thus n about every 10 mnutes, a new block of transactons wll be ncluded nto the ledger, and the ledger state wll be updated correspondngly. Functonalty Ḡledger Shared functonalty Ḡledger s globally avalable to all partcpants. The shared functonalty s parameterzed wth a predcate Valdate, a constant T, and varables state, buffer and counter. Intally, state :=, buffer :=, and counter := 0. Upon recevng (submt, sd, tx) from some partcpant, send (clock-read, sd) to Ḡ clock and receve (clock-read, sd, τ) from Ḡclock. If Valdate(state, (buffer, tx)) = 1, then set buffer := buffer tx. If τ T counter > T, then set state := state Blockfy(τ, buffer) and buffer := and counter := counter + 1. Upon recevng (read, sd) from some partcpant, return (read, sd, state) to the requestor. Fgure 2: The publc ledger functonalty. To enable the ledger to be aware of tme, the ledger mantaners are allowed to read the state of another publcly avalable functonalty Ḡclock defned above. We remark that all gathered transactons should be vald whch s defned by a predcate Valdate. In dfferent systems, predcate Valdate wll take dfferent forms. For example, n the Btcon system, the predcate Valdate should make sure that for each newly receved transacton that transfers v cons from the orgnal wallet address address o to the destnaton wallet address address d, the orgnal wallet address address o should have v or more than v cons, and the transacton should be generated by the orgnal wallet holder (as shown by the ssuance of a dgtal sgnature). Furthermore, pror to each vector of transactons becomng block, the vector s passed through a functon Blockfy( ) that homogenzes the sequence of transactons n the form of a block. Moreover, n some systems lke Btcon, t may add a specal transacton called a conbase transacton that mplements a reward mechansm for the ledger mantaners. In Fgure 2 we provde the detals of the ledger functonalty. 2.3 Q-farness and Secure Computaton wth Far Compensaton In ths subsecton, we provde a formal framework for secure computaton wth far compensaton. In the sprt of [GMPY06], our man tool s a wrapper functonalty. Our wrapper 5

7 functonalty s equpped wth a predcate 6 Q Ḡ whch can be used to montor the state of the global setup Ḡ. If certan bad event occurs (such as an abort), then the predcate QḠ wll be trggered, and the functonalty wll halt. Wth foresght Q wll ensure that partes that abort are compensated. Any mplementaton of the wrapped functonalty should ensure that such a halt event s not trggered wth non-neglgble probablty. We wll call such an mplementaton a Q-far mplementaton. Our framework can be defned wth respect to any global setup that upon recevng a read symbol t returns ts publc state trans. Let Ḡ be such a global deal functonalty and let QḠ a predcate wth respect to such Ḡ. Let F be a secure functon evaluaton (SFE) functonalty whch s far n the sense of [GMPY06]: t returns output n two dfferent ways: () delayed delvery: (delver, sd, m, P ) sgnfyng delayed output delvery 7 of m to party P, () far delvery: (far-delver, sd, (m, P 1 ),..., (m, P k ), (m S, S)) that results n smultaneous 8 delvery of outputs m 1,... m k to partes P 1,..., P k and output m S to S. The wrapper functonalty W that wll be used n the defnton of Q-far secure computaton s gven n Fgure 3. The ntuton s that the Q predcate wll be appled on the publc state of Ḡ whenever the wrapper breaks the far delvery of the nner functonalty F. We are now ready to defne Q-farness wth respect to a global functonalty. Defnton 2.1. We say protocol π realzes functonalty F wth Q Ḡ -farness wth respect to global functonalty Ḡ, provded the followng statement s true. For all adversares A, there s a smulator S so that for all envronments Z t holds: ExecḠπ,A,Z ExecḠ,W(F,QḠ) S,Z The followng lemma captures the ntuton that computng the nner functonalty s at least as strong as computng t wth Q-farness. Lemma 2.2. Let Ḡ be a global deal functonalty. Let QḠ be any predcate wth respect to Ḡ. Then for all adversares A, there s a smulator S so that for all envronments Z, t holds: ExecḠ,F σ,a,z ExecḠ,W(F,QḠ) σ,s,z The above lemma can be easly proved, because the smulator S by returnng (far-delver, sd, md) to the wrapper functonalty, can avod the predcate Q Ḡ be trggered. More generally, the protocol σ realzes H wth Q farness usng a functonalty F wth Ḡ farness Q Ḡ provded that for all adversares A, there s a smulator S so that for all envronments Z, t holds: ExecḠ,W(F,QḠ) π,a,z ExecḠ,W(H,Q Ḡ ) S,Z We note that, both protocol π and the functonalty (W(F, Q Ḡ ), Ḡ) are wth respect to the global functonalty Ḡ9. By followng the very smlar proof dea of provng UC/GUC composton [Can01, CDPW07], we can prove the followng: 6 Whenever t s clear from the context we may drop the subscrpt Ḡ. 7 Delayed output delvery s a standard (G)UC mechansm where the adversary s allowed to schedule the output at a tme of ts choosng. 8 Gven that n the (G)UC framework no smultaneous message delvery s supported, the term smultaneous wll refer to fetch mode delvery as defned n [KMTZ13]. 9 In GUC framework [CDPW07], ths s also called, Ḡ-subroutne respectng. 6

8 Wrapper Functonalty W(F, Q Ḡ ) Functonalty W(F, Q Ḡ ) nteracts wth a set of partes P = {P 1,..., P n }, the adversary S and the envronment Z, as well as shared functonalty Ḡ. The functonalty s parameterzed wth an n-party functonalty F and a predcate Q Ḡ. Submttng an nput. Upon recevng (label, sd, x) from a party P, t forwards (label, sd, x) to F. In case F produces a message µ for S t forwards ((label, sd, P ), µ) to S. Assocatng a label to a party. On nput (label, sd, P, L) from S t records L sd,p = L and returns (label, sd, P, L) to P. Generatng delayed output. On nput a message from F marked (delver, sd, m, P ) t forwards m to party P va delayed output. Regsterng far output. On nput a message from F that s marked for far delvery (far-delver, sd, md, (m 1, P 1 ),..., (m k, P k ), (m S, S)), t forwards (md, P 1,..., P k, m S ) to S. Delayed far output delvery. Upon recevng (far-delver, sd, md) from S then provded that a message (md,...) has been delvered to the adversary, all pars (m j, P j ) s assocated wth md are sent to P j s smultaneously. Q Ḡ -far delvery. Upon recevng (Q-delver, sd, md) from S then provded that a message (md,...) has been delvered to the adversary operate as follows. For each par of the form (m, P ) assocated wth md where P s corrupted, the adversary S receves (m, P ). For each party P that s corrupted the par (m, P ) n md s marked as delvered. Every other par n md s marked undelvered. Subsequently perform the followng. On nput a message (delver, sd, md, P ) from S, provded that the record md contans the par (m, P ) that s undelvered then send read to Ḡ, denote the responce by trans and f Q Ḡ (sd, L sd,p, 1, trans) then halt. Else, the party P wll receve m and the par (m, P ) n md s marked delvered. On nput a message (abort, sd, md, P ) from S, provded that the record md contans the par (m, P ) that s undelvered then send read to Ḡ, denote the responce by trans and f Q Ḡ (sd, L sd,p, 0, trans) then halt. Else, the party P wll receve and the par (m, P ) n md s marked aborted. Fgure 3: The wrapper functonalty. Lemma 2.3. Let Q Ḡ be a predcate wth respect to global functonalty Ḡ. Let π be a protocol that realzes the functonalty F wth Q Ḡ -farness. Let σ be a protocol n (W(F, QḠ), Ḡ)-hybrd world. Then for all adversares A, there s a smulator S so that for all envronments Z, t holds ExecḠσ π,a,z ExecḠ,W(F,QḠ) σ,s,z Theorem 2.4. Let Q and Ḡ Q be predcates wth respect to global functonalty Ḡ. Let π be a Ḡ protocol that realzes the functonalty F wth Q Ḡ -farness. Let σ be a protocol n (W(F, QḠ), Ḡ)- hybrd world that realzes the functonalty H wth Q -farness. Then for all adversares A, there Ḡ s a smulator S so that for all envronments Z t holds: ExecḠσ π,a,z ExecḠ,W(H,Q Ḡ ) S,Z 7

9 Please see appendx for the proof. We are now ready to nstantate the noton of Q-farness wth a compensaton mechansm. Computaton wth Far Compensaton. For the case when Ḡ mplements the Btcon-lke ledger and Q Ḡ provdes compensaton of c btcon, where c > 0, n the case of an abort the predcate Q Ḡ (sd, L, bt, trans) operates as follows: t parses L as a par of (address, sk) where address s a btcon address and sk s the correspondng secret-key. Then t parses trans as a btcon ledger that contans transactons. Transactons n trans can also be marked wth metadata. The followng hold : If bt = 1, then Q Ḡ outputs true f and only f the balance of all transactons (both ncomng and outgong) that concern address n trans and carry the meta-data sd s greater equal to 0. If bt = 0, then Q Ḡ outputs true f and only f the balance of all transactons (both ncomng and outgong) that concern address n trans and carry the meta-data sd s greater equal to c. 2.4 Correlated Randomness as a Samplng Functonalty Our protocols are n the correlated randomness model,.e., they assume that the partes ntally, before recevng ther nputs, receve approprately correlated random strngs. In partcular, the partes jontly hold a vector R = (R 1,..., R n ) ({0, 1} ) n, where P holds R, drawn from a gven effcently samplable dstrbuton D. Ths s, as usual, captured by gvng the partes ntal access to an deal functonalty F D corr, known as a samplng functonalty, whch, upon recevng a default nput from any party, samples R from D and dstrbutes t to the partes. Hence, a protocol n the correlated randomness model s formally an F D corr-hybrd protocol. Formally, a samplng functonalty F D corr s parameterzed by an effcently computable samplng dstrbuton D and the (ID s of the partes n) the player set P. Functonalty F D corr Functonalty F D corr nteracts wth a set of partes P = {P 1,..., P n }, the adversary S and the envronment Z. The functonalty s parameterzed wth a dstrbuton sampler D. Upon recevng (request, sd) from any party or the adversary, set R = (R 1,..., R n ) D and for each P P send (request, sd, R ) to P (or to the adversary f P s corrupted). Fgure 4: The correlated randomness functonalty. 3 Our far protocol compler In ths secton we present our far protocol compler. Our compler comples a synchronous protocol π sh whch s secure (.e., prvate) aganst a corrupted majorty n the sem-honest correlated randomness model (e.g, an OT-hybrd protocol where the OT s have been pre-computed) nto a protocol π whch s secure wth far-compensaton n the malcous correlated randomness model. The hgh-level dea s the followng: We frst comple π sh nto a protocol n the malcous correlated randomness model, whch s executed over a broadcast channel and s secure wth 8

10 publcly dentfable abort. (Roughly, ths means that someone observng the protocol executon can decde, upon abort, whch party s not executng ts code.) Ths protocol s then transformed nto a protocol wth far compensaton as follows: Every party (after recevng hs correlated randomness setup) posts to the ledger transactons that the other partes can clam only f they, later, post transactons that prove that they follow ther protocol. Transactons that are not clamed ths way are returned to the source address; thus, f some party does not post such a proof t wll not be able to clam the correspondng transacton, and wll therefore leave the honest partes wth a postve balance as ther transactons wll be refunded. Observe that these are not standard Btcon transactons, but they have a specal format whch s descrbed n the followng. Importantly, the protocol we descrbe s guaranteed to ether produce output n as many (Btcon) rounds are the rounds of the orgnal malcous protocol, or to compensate all honest partes. Ths robustness property s acheved by a novel technque whch ensures that as soon as the honest partes make ther ntal transacton, the adversary has no way of preventng them from ether computng ther output or beng compensated. Informally, our technque conssts of splttng the partes nto slands dependng on the transactons they post (so that all honest partes are on the same sland) and then allowng them ether compute the functon wthn ther sland, or f they abort to get compensated. (The adversary has the opton of beng ncluded or not n the honest partes sland.) 3.1 MPC wth Publcly Identfable Abort As a frst step n our compler we nvoke the sem-honest to malcous wth dentfable abort compler of Isha, Ostrovsky, and Zkas [IOZ14] (hereafter referred to as the IOZ compler). Ths compler takes a sem-honest protocol π sh n the correlated randomness model and transforms t to a protocol n the malcous correlated randomness model (for an approprate setup) whch s secure wth dentfable abort,.e., when t aborts, every party learns the dentty of a corrupted party. The compler n [IOZ14] follows the so called GMW paradgm [GMW87], whch n a nutshell has every party commt to ts nput and randomness for executng the sem-honest protocol π sh and then has every party run π sh over a broadcast channel, where n each round ρ every party broadcast hs round ρ messages and proves n zero-knowledge that the broadcasted message s correct,.e., that he knows nput and randomness that are consstent wth the ntal commtments and the (publc) vew of the protocol so far. The man dfference of the IOZ compler and the GMW compler s that the partes are not only commtted to ther randomness, but they are also commtted to ther entre setup strng,.e., ther prvate component of the correlated randomness. More concretely, the resultng malcous protocol π m (whch s based on the compler n [IOZ14]) has the followng propertes: Every party s commtted to hs setup,.e., the part of the correlated randomness t holds. That s, every party P receves from the setup hs randomness (whch we refer to as P s prvate component of the setup) along wth one-to-many commtments 10 on the prvate components of all partes. Wlog, we also assume that a common-reference strng (CRS) and a publc-key nfrastructure (PKI) are ncluded n every party s local randomess. The malcous protocol uses only the broadcast channel for communcaton. Gven the correlated randomness setup, the malcous protocol s completely determnstc. Ths s acheved n [IOZ14] by ensurng that all the randomness used n the protocol, even the 10 These are commtments that can be opened so that every party agrees on whether or not the openng succeeded. 9

11 one needed for the zero-knowledge proofs, s part of the correlated randomness dstrbuted by the samplng functonalty. 11 π m starts off by havng every party broadcast a one-tme pad encrypton of ts nput wth ts (commtted) randomness and a NIZK that t knows the nput and randomness correspondng to the broadcasted message. By conventon, the next-message functon of the malcous protocol s such that f n any round the transcrpt seen by a party s an abortng transcrpt,.e., s not consstent wth an acceptng run of the sem-honest protocol, then the party outputs (see below for a detaled formulaton). There s a (known) upper bound on the number ρ m of rounds of π m. We also stress that, gven approprate setup, the IOZ-compler acheve nformaton-theoretc securty, and needs therefore to buld nformaton-theoretc commtments and zero-knowledge proofs. As n ths work we are only after computatonal securty, we modfy the IOZ compler so that we use (computatonally) UC secure one-to-many commtments [CLOS02] and computatonally UC secure non-nteractve zero-knowledge proofs (NIZKs) nstead f ther.t. nstantaton suggested n [IOZ14]. Both the UC commtment and the NIZKs can be bult n the CRS model. Moreover, the use of UC secure nstantatons of zero-knowledge and commtments ensures that the resultng protocol wll be (computatonally) secure. Usng the setup wthn a subset of partes. A standard property of many protocols n the correlated-randomness model s that once the partes n P have receved the setup, any subset P P s able to use t to perform a computaton of a P -party functon amongst them whle gnorng partes n P \ P. More concretely, assume the partes n P have been handed a setup dstrbuted allowng them to execute some protocol π for computng any P -party functon f; then for any P P, the partes n P can use ther setup wthn a protocol π P to compute any P -party functon f P. Ths property whch wll prove very useful for obtanng computaton wth robustness or compensaton, s also satsfed by the IOZ protocol, as the partes n P can smply gnore the commtments (publc setup component) correspondng to partes n P \ P. Makng Identfablty Publc. The general dea of our protocol s to have every party ssue transactons by whch he commts to transferrng a certan amount of btcon per party for each protocol round. All these transactons are ssued at the begnnng of the protocol executon, but every party can clam the commtted cons transferred to hm assocated to some protocol round ρ only under the followng condtons: (1) the clam s posted n the tme-nterval correspondng to round ρ; (2) the party has clamed all hs transferred btcons assocated to the prevous rounds; and (3) the party has posted a transacton whch ncludes hs vald message for round ρ. In order to ensure that a party cannot clam hs btcons unless he follows the protocol, the ledger (more concretely the valdaton predcate) should be able to check that the party s ndeed postng a message correspondng to ts next protocol message. In other words, n each round ρ, P s round-ρ message acts a wtness for P clamng all the btcons transferred to hm assocated wth ths round ρ. To ths drecton we make the followng modfcaton to the protocol: Let f(x 1,..., x n ) = (y 1,..., y n ) denote the n-party functon we wsh to compute, and let F +1 be the (n + 1)-party functon whch takes nput x from each P, [n], and no nput from P n+1 and outputs y to each P and a specal symbol (e.g., 0) to P n+1. Clearly, f π sh s a sem-honest n-party protocol for computng f over broadcast, then the n + 1 protocol π sh n whch every P 11 As an example, the challenge for the zero-knowledge proofs s generated by the partes openng approprate parts of ther commtted random strngs. 10

12 wth [n] executes π sh and P n+1 smply lstens to the broadcast channel s a secure protocol for F +1. Now f π m denotes the (n + 1)-party malcous protocol whch results by applyng the above modfed IOZ compler on the (n + 1)-party sem-honest protocol for computng the functon F +1, then, by constructon ths protocol computes functon F +1 wth dentfable abort and has the followng propertes: Party P n+1 does not make any use of hs prvate randomness whatsoever; ths s true because he broadcasts no messages and smply verfes the broadcasted NIZKs. If some party P, [n] devates from runnng π sh wth the correlated (commtted) randomness as dstrbuted from the samplng functonalty, then ths s detected by all partes, ncludng P n+1 (and protocol π m aborts wth ths party). Ths follows by the soundness of the NIZK whch P needs to provde provng that he s executng π sh n every round. Due to P n+1 s role as an observer who gets to decde f the protocol s successful (P n+1 outputs 0) or some party devated (P n+1 observes that the correspondng NIZK verfcaton faled) n the followng we wll refer to P n+1 n the above protocol as the judge. The code of the judge can be used by anyone who has the publc setup and wants to follow the protocol executon and decde whether t should abort or not gven the partes messages. Lookng ahead, the judge s code n the protocol wll be used by the ledger to decde wether or not a transacton that clams some commtted cons s vald. 3.2 Specal Transactons supported by our Ledger In ths secton we specfy the Valdate and the Blockfy predcates that are used for achevng our protocol s propertes. More specfcally, our protocol uses the followng type of transactons whch transfer v cons from wallet address to wallet address j condtoned on a statement Σ: B v,address,address j,σ,aux,σ,τ (1) where σ s a sgnature of the transacton, whch can be verfed under wallet address ; τ s the tme-stamp,.e., the current value of the clock when ths transacton s posted by the ledger note that ths tmestamp s added by the ledger and not by the users, aux {0, 1} s an arbtrary strng 12 ; and the statement Σ conssts of three arguments,.e., Σ = (arg 1, arg 2, arg 3 ), whch are processed by the valdate predcate n order to decde f the transacton s vald (.e., f t wll be ncluded n the ledger s next block). The valdaton happens by processng the arguments of Σ n a sequental order, where f whle processng of some argument the valdaton rejects, algorthm Valdate stops processng at that pont and ths transacton s dropped. The arguments are defned/processed as follows: Tme-Restrctons: The frst argument s a par arg 1 = (τ, τ + ) Z (Z + { }) of ponts n tme. If τ > τ + then the transacton s nvald (.e., t wll be dropped by the ledger). Otherwse, before tme τ the cons n the transacton reman blocked,.e., no party can spend them; from tme τ untl tme τ +, the money can be spent by the owner of wallet address j provded that the spendng statement satsfes also the rest of the requrements/arguments n statement Σ (lsted below). After tme τ + the money can be spent by the owner of wallet address wthout any addtonal restrctons (.e., the rest of the arguments n Σ are not parsed and the transacton s dealt wth as a standard Btcon transacton wth recever address ). As a specal case, f τ + = then the transferred cons 12 Ths strng wll be ncluded to the Ledger s state as soon as the transacton s posted and can be, therefore, referred to by other spendng statements. 11

13 can be spent from address j at any pont (provded the spendng statement s satsfed); we say then that the transacton s tme-unrestrcted, 13 otherwse we say that the transacton s tme restrcted. Spendng Lnk: Provded that the processng of the frst argument, as above, was not rejectng, the valdate predcate proceeds to the second argument, whch s a unque anchor, arg 2 = α {0, 1}. Informally, ths serves as a unque dentfer for lnked transactons; that s, when α, then the Valdate algorthm of the ledger looks n the ledger s state and buffer to confrm that the balance of transactons to/from the wallet address address wth ths anchor arg 2 s at least v > v cons. That s, the sum of btcons n exstng vald transacton (n the state of n the buffer) wth recever address address and anchor arg 2 mnus the sum of btcons n exstng vald transacton (n the state or n the buffer) wth sender address address and anchor arg 2 s greater than v. If ths s not the case then the transacton s rendered nvald; otherwse the valdaton of ths argument succeeds and the algorthm proceeds to the next argument. To spce up the termnology, we call a transacton whch has a non- anchor argument a lnked transacton. State-Dependent Condton: The last argument to be valdated s arg 3, whch s a relaton R : S B T {0, 1}, where S, B, and T are the domans of possble ledger-states, ledgerbuffers, and transactons, respectvely (n a gven encodng). Ths argument defnes whch type of transactons can spend the cons transferred n the current transacton. That s, n order to spend the cons, the recever needs to submt a transacton tx T such that R(state, buffer, tx) = 1. We pont out that as wth standard Btcon transactons, the valdaton predcate wll always also check valdty of the sgnature σ wth respect to the wallet address. Moreover, the standard Btcon transactons can trvally be casted as transactons of the above type by settng α = and Σ = ((0, ),, R ), where R denotes the relaton whch s always true. The Blockfy algorthm groups transactons n the current buffer and adds a tmestamp The protocol Let π m denote the above descrbed malcous protocol. Consstently to our termnology, let Round2Tme(1) denote the tme n whch the partes have agreed to start the protocol executon. Wlog, assume that Round2Tme(1) > 2T Furthermore, for smplcty, we assume that each party P receves ts nput x wth ts frst actvaton from the envronment at tme Round2Tme(1) (f some honest party does not have an nput by that tme t wll execute the protocol wth a default nput, e.g., 0). Informally, the protocol proceeds as follows: In a pre-processng step, before the partes receve nput, the partes nvoke the samplng functonalty for π m to receve ther correlated randomness. 16 The publc component of ths randomness ncludes ther protocol-assocated wallet address whch they output (to the envronment). The envronment s then expected to submt ρ m specal (as above) con-transfers for each par of partes P P and p j P; the source wallet-address for each such transacton s P s,.e., address and the target wallet-address 13 Ths s the case wth standard Btcon transactons. 14 Ths s the absratcton needed for our protocol; n actual crypto-currences Blockfy would have a more complcated functonalty (cf. Secton 2.2). 15 That s we assume that at least four Btcon rounds (recall that T denotes the duraton of a Btcon round) plus four extra clock-tcks have passed from the beggng of the experment. 16 In an actual applcaton, the partes wll use an unfar protocol for computng the correlated randomness. As ths protocol has no nputs, an abort wll not be unfar (.e., the smulator can always smulate the vew of the adversary n an abortng executon.) 12

14 for s P j s,.e., address j, and the correspondng anchors are as follows: α,j,ρ = (pd,, j, ρ), for (, j, ρ) [n] 2 [ρ m ], where 17 pd s the GUC protocol ID for π m. Snce by assumpton, Round2Tme(1) > 2T + 2, the envronment has suffcent tme to submt these transacton so that by the tme the protocol strarts they have been posted on the ledger. At tme Round2Tme(1) T the partes receve ther nputs and ntate the protocol executon by frst checkng that suffcent funds are allocated to ther wallets lnked to the protocol executons by approprate anchors, as above. If some party does not have suffcent funds then t broadcast an abortng message and all partes abort. (Note that ths s a far abort and no party has spent any tme nto makng transactons.) Otherwse, partes make the specal transactons that commt them (see below) nto executng the protocol, and then proceed nto clamng them one-by-one by executng ther protocol n a round-by-round fashon. Note that the protocol s executed n Btcon rounds so that the partes have enough tme to clam ther transacton. In fact, every protocol round s stretched to a Btcon rounds,.e., Round2Tme( + 1) Round2Tme() T, whch wll guarantee that any transacton submtted for round ρ, ρ = 1,..., ρ m 1, of the protocol, has been posted on the ledger by the begnnng of round ρ + 1. By usng a constant round malcous protocol π m (e.g., the modfed compled protocol from [IOZ14] nstantated wth a constant round sem-honest protocol) we can ensure that our protocol wll termnate n a constant number of Btcon rounds and every honest party wll ether receve ts nput, or wll have a postve balance n ts wallet. As already mentoned, achevng such a robustness property wth known protocols would requre a lnear (n the number of corrupted partes) number of rounds whch for large player sets s unrealstc. Remark 3.1 (On avalablty of funds). Unlke exstng works, we choose to explctly treat the ssue of how funds become avalable to the protocol by makng the off-lne transfers external to the protocol tself (.e., the envronment takes care of them). However, the fact that the envronment s n charge of pourng money nto the wallets that are used for the protocol does not exclude that the partes mght be actually the ones havng done so. Indeed, the envronment s goal s to capture everythng that s done on the sde of, before, or after the protocol, ncludng other protocols that the partes mght have partcpated n. By gvng the envronment enough tme to ensure these transactons are posted we ensure that some honest party not havng enough funds corresponds to an envronment that makes the computaton abort (n a far way and only n the pre-processng phase, before the partes have nvested tme nto postng protocol transactons). Another ssue to be dscussed, s how we arrange that the balance of honest partes s postve n case of an abort. Ths s acheved as follows by explotng the power of our specal transactons: we requre that the auxlary strng of a transacton of a party P j whch clams a commtted transacton for some round ρ ncludes hs ρ-round protocol message. We then have the relaton of ths transacton be such that t evaluates to 1 f only f ths s ndeed P j s next message. Thus, effectvely the valdate predcate mplements the judge and can, therefore, decde f some party aborted: f some party broadcasts a message that would make the judge abort, then the valdate predcate drops the correspondng transacton and all clams for commtted transactons correspondng to future rounds, thus, all other partes are allowed to reclam ther commtted btcons startng from the next round. The last queston s: how s the ledger able to know whch partes should partcpate n the protocol? Here s the problem: The adversary mght post n the frst round (as part of the commttng transacton for the frst round) a fake, malcously generated setup. Snce the ledger s not part of the correlated randomness samplng, t would be mpossble to decde whch s 17 Recall that we assume P = n. 13

15 the good setup. We solve ths ssue by a the followng technque that s nspred by [BCL + 05]: The ledger 18 groups together partes that post the same setup; these partes form slands,.e, subsets of P. For each such subset P P {P n+1 } whch ncludes the judge P n+1, the ledger acts as f the partes n P are executng the protocol π m P (whch, recall, s the restrcton of π m to the partes n P ) for computng the P -party functon F +1 P ( x) defned as follows: let the functon to be computed be f( x), where x = (x 1,..., x n ), and F +1 be as above, then F +1 P ( x) = F +1 ( x P ) where x P = (x 1,..., x n) wth x = x for P P and x beng a default value for every P P. Ths solves the problem as all honest partes wll be n the same sland P P (as they wll all post the same value for publc randomness); thus f the adversary chooses not to post ths value on behalf of some corrupted party, he s effectvely settng ths party s nput to a default value, a strategy whch s easly smulatable. (Of course, the above soluton wll allow the adversary to also have slands of only corrupted partes that mght execute the protocol, but ths s also a fully smulatable strategy and has not effect on far-compensaton whatsoever corrupted partes are not requred to have a postve balance upon abort). The fnal protocol πm B s detaled n the followng. The protocol ID s sd. The functon to be computed s f(x 1,..., x n ). The protocol partcpants are P = {P 1,..., P n }. We assume that all partes have regstered wth the clock functonalty n advance and are therefore synchronzed once the followng steps start. Setup Generaton Tme τ 2 = Round2Tme(1) 2T 2: The partes nvoke the samplng functonalty,.e., every party P P starts off by sendng the samplng functonalty a message (request); the samplng functonalty returns (R prv, R pub ) to P where R prv s P s prvate component (ncludng all random cons he needs to run the protocol, along hs sgnng key sk ) of the setup and R pub s the publc component (the same for every party P j ) whch ncludes the vector of UC commtments (Com 1,..., Com n ), where for j [n], Com j s a commtment to R prv j, along wth a vector of publc (verfcaton) keys (vk 1,..., vk n ) correspondng to the sgnng keys (sk 1,..., sk n ) and a common reference strng CRS. Every party outputs ts own publc key, as ts wallet address for the protocol,.e., address = vk. Check Avalablty of Funds Tme τ 1 = Round2Tme(1) T 2: Every party P P does the followng: P reads the current state from the ledger. If the state does not nclude for each (, j, ρ) [n] 2 [ρ m ] a transacton B c,address,address,σ 0,j,ρ,aux0,j,ρ,σ,τ, where Σ 0,j,ρ = ((0, ), (sd,, j, ρ), R ) then P broadcasts and every party aborts the protocol executon. Input and Commttng Transactons Tme τ 0 = Round2Tme(1) T: Every party P receves ts nput x (x = 0 f no nput s receved n the frst actvaton of P for tme Round2Tme(1) T) and submts to the ledger the followng commtment transactons: For each P j P : B c,address,address j,σ,j,1,aux,j,1,σ,τ, where aux,j,1 = R pub and Σ,j,1 = (arg 1,j,1, arg 2,j,1, arg 3,j,1 ) wth 18 Throughout the followng descrpton, we say that the ledger does some check to refer to the process of checkng a correspondng relaton, as part of valdatng a specal transacton. 19 Recall that, by defnton of the clock, every party has as much tme as t needs to complete all the steps below before the clock advances tme. 14

16 arg,j,1 1 = (Round2Tme(1), Round2Tme(1) + 1) arg,j,1 2 = (sd,, j, 1) arg,j,1 3 = R,j,1 defned as follows: Let P = P {P n+1 }, where P n+1 denotes the judge, be the player set mplct n R pub, 20 and let P P denote the set of partes (wallets), such that n the frst block posted after tme Round2Tme(1) T all partes P k P had exactly one transacton for every P j P wth arg k,j,1 1 = (Round2Tme(1), Round2Tme(1) + 1), arg k,j,1 2 = (sd, k, j, 1), and aux 1 k,j,1 = Rpub. Furthermore, let P = P {P n+1 }, and let π m P be the protocol wth publc dentfablty for computng F +1 P, descrbed above and denote by R pub P the restrcton of the publc setup to the partes n P. Then R,j,1 (state, buffer, tx) = 1 f and only f the protocol of the judge wth publc setup R pub P accepts the auxlary strng aux tx n tx as P s next message n π m P (and does not abort). 2. For each round ρ = 2,..., ρ m and each P j P : B c,address,address j,σ,j,ρ,aux 1,j,ρ,σ,τ, where aux 1,j,ρ = Rpub and Σ,j,ρ = (arg 1, arg 2, arg 3 ) wth arg 1 = (Round2Tme(ρ), Round2Tme(ρ + 1) + 1) arg 2 = (sd,, j, ρ). arg 3 = R,j,ρ defned as follows: Let P, P, π m P be defned as above (and denote P = {P 1,..., P m }. Then R,j,ρ (state, buffer, tx) = 1 f and only f, for each r = 1,..., ρ 1 and each party P k P, the state state ncludes transactons n whch the auxlary nput s aux k,r such that the protocol of the judge wth publc setup R pub P, and transcrpt (aux 1,1,..., aux m,1),..., (aux 1,ρ 1,..., aux m,ρ 1), accepts the auxlary strng aux tx n tx as P s next (ρ-round) message n π m P (and does not abort). Clamng Commtted Transactons/Executng the Protocol Tme τ Round2Tme(1): For each ρ = 1,..., ρ m + 1, every P does the followng at tme Round2Tme(ρ),: 1. If τ = Round2Tme(ρ m + 1) then go to Step 4; otherwse do the followng: 2. Read the ledger s state, and compute P, P, π m P as above. 3. If the state state s not abortng,.e, t ncludes for each r = 1,..., ρ 1 and each party P k P n whch the auxlary nput s aux k,r such that P executng π m P wth publc setup R pub P, prvate setup R prv, and transcrpt (aux 1,1,..., aux m,1),..., (aux 1,ρ 1,..., aux m,ρ 1) for the frst r 1 rounds does not abort, then compute P s message for round ρ, denoted as m ρ, and submt to the ledger for each P k P a transacton B c,addressk,address,σ k,,ρ,auxρ k,,ρ,σ,τ, where aux ρ k,,1 = m ρ and Σ k,,ρ = (arg 1, arg 2, arg 3 ) wth arg 1 = (0, ) arg 2 = (sd, k,, ρ) arg 3 = R. 4. Otherwse,.e., f the state state s abortng, then submt to the ledger for each round r = 1,..., ρ 1, and each P k P a transacton by whch the commtted trans- 20 Recall that R pub ncludes commtments to all partes prvate randomness (ncludng the judge s P d ) used for runnng the protocol, whch s an mplct representaton of the player set. 15