Rational Threshold Cryptosystems
aa r X i v : . [ c s . CR ] J a n Rational Threshold Cryptosystems
David Yakira, Ido Grayevsky, and Avi Asayag
Orbs Research { david,ido,avi } @orbs.com We propose a framework for threshold cryptosystems under a permissionless-economic model in which the participants are rational profit-maximizing enti-ties. To date, threshold cryptosystems have been considered under permissionedsettings with a limited adversary. Our framework relies on an escrow servicethat slashes and redistributes deposits to incentivize participants to adhere de-sired behaviors. Today, more than ever, sophisticated escrow services can beimplemented over public blockchains like Ethereum, without additional trustassumptions. The key threat to rational threshold cryptosystems is collusion —by cooperating “illegally”, a subset of participants can reveal the cryptosystem’ssecret, which, in turn is translated to unfair profit. Our countermeasure to col-lusion is framing . If the escrow is notified of collusion, it rewards the framer andslashes the deposits of all other participants. We show that colluding parties findthemselves in the prisoner’s dilemma, where the dominant strategy is framing.
In threshold cryptosystems several parties cooperate in order to produce a signa-ture, decrypt a ciphertext, or reveal a secret. In particular, in a ( t, n )-thresholdcryptosystem there are n participants, any t + 1 of which need to cooperate inorder to use the system. Any smaller subset is doomed to fail.The motivation for our work stems from the key insight that threshold cryp-tosystems have an inherent conflict—on the one hand they require the coopera-tion of their participants in order to function, while on the other hand, in certaincircumstances, cooperation completely undermines the functionality of the sys-tem and is undesired. To our knowledge, this difficulty has not been explicitlyformulated and a proper solution has not been proposed.A simple example is found in ( t, n ) publicly verifiable secret sharing [31],where t + 1 players can co-decrypt a player’s commitment. The players are in-structed to co-decrypt only after all players have shared their commitments, andnot beforehand. Otherwise, the output of the protocol can be easily manipulated([25] use randomness beacons in this spirit).Consider another picturesque example. Satoshi Nakamoto wishes to revealher identity, but only after she dies. She is willing to pay R bitcoins to achieveher goal. She anonymously contacts n known figures in the Bitcoin community David Yakira, Ido Grayevsky, and Avi Asayag and offers them a deal—she would share with them, via Shamir Secret Sharing,a signed Bitcoin transaction transferring each of them
R/n bitcoins, from anaddress known to belong to Satoshi. The secret would include her real-worldidentity, such that the cooperation of t + 1 of them would both reveal her iden-tity and allow each participant to realize her R/n reward. Of course, from theparticipants’ perspective, there is no reason to trust this anonymous character,let alone believe she is Satoshi. All the same, the promised
R/n bitcoins shouldincentivize them to participate . The problem is that while Satoshi only wantsto reveal her secret after she dies, the participants have clear motivation to co-operate before that time and gain an immediate reward (and finally find outwho Satoshi is).Traditional threshold cryptosystems assume that the participants follow theprotocol blindly, unless they have been corrupted by the adversary , which thencontrols their behavior. The adversary is limited and can corrupt up to t < n/ . This model immediately circumvents the key difficulty mentionedabove—when cooperation is not allowed by the protocol, non-corrupted partici-pants will simply refuse to cooperate. Evidently though, an adversary controlling t participants is unlikely to stop there as she is highly motivated to corrupt the t + 1 participant and get control of the underlying cryptosystem.To tackle the problem we must first define formally what can be gained andwhat are the stakes in the system. We therefore start by considering an economiclayer atop the cryptosystem. We abandon the assumption that participants canbe trusted, and assume instead that they are rational entities seeking to max-imize their own profit within this economic environment. To be able to shapetheir behavior we rely on an escrow service that takes deposits and follows aspecific set of rules. Such an escrow can be realized, for example, as a smartcontract over Ethereum [7].The idea of enhancing a cryptosystem using an escrow service was suggestedby Randao [28]—a multi-party coin tossing protocol for generating randomness.There, if a participant fails to submit her valid secret, her deposit is slashed.There are three main caveats to this approach. First, the price of failing theprotocol is low—failing amounts to convincing a single participant to refuseto submit her secret. Second, it remains cryptic as to what is the incentive ofparticipants to join the service in the first place. Implicitly, one can assumethere is some intrinsic value tied to the system, but this is not articulated andRandao does not provide an analysis tying this value to the required deposits.Finally, in its current implementation, Randao invokes too much interaction withEthereum, and cannot scale well with the number of participants . Proving that the transaction indeed encompasses the promised bitcoins, withoutrevealing its input UtxOs, can be done in zero-knowledge. The restriction t < n/ t + 1 honest participants that would advance the protocol. When robustness is notof concern, this restriction can be relaxed. This could be improved using off-chain communication and interactive dispute pro-tocols in the spirit of App. C.ational Threshold Cryptosystems 3
A rational threshold cryptosystem that has been widely studied is rationalsecret sharing [20,19,2,26,15]. There however, only a specific aspect of the prob-lem is dealt with, namely that participants prefer to learn the secret alone . Theobjective of the protocol is to guarantee that all participants learn of the secrettogether. In particular, cooperation at unintended times is not an option undertheir model and is not considered.Our framework handles both problems—cooperating “illegally”, which werefer to as collusion ; and the ability to assure legitimate cooperation when it isrequired, which we refer to as robustness . For a given threshold cryptosystem,our framework allows to assess the economic constraints on collusion (Sec. 5.2)and the price to interrupt with the robustness of the protocol (Sec. 5.3). Itthus allows system designers to build systems with adequate economic collusionresistance and economic robustness, as we show in Sec. 5. It also provides toolsfor users to assess the trustworthiness of the system.We demonstrate the usefulness of our framework with two examples. In thefirst, unique threshold signatures are used to realize a randomness beacon (asdone in [22,28] for example), which is then used for a simple lottery game. Wealso elaborate on Satoshi’s example, previously mentioned.
Shamir’s secret sharing (SSS) [30] is an algorithm that realizes a threshold cryp-tosystem in which t + 1 participants need to cooperate in order to reveal a secret.The procedure is simple. The owner of a secret x randomly generates a degree t polynomial f , where f (0) = x . She then numerates the participants P , . . . , P n and shares with P i the value f ( i ), which is referred to as P i ’s secret key share .Now, any t + 1 participants can reconstruct the secret f (0) by using Lagrangeinterpolation. No smaller set of participants can deduce any information on f (0)whatsoever.Threshold cryptosystems for signatures or encryption consist of two stages:1. A key generation procedure, executed once to set up the system by generatingthe necessary keys—participants end up with secret key shares, that togethercorrespond to some global secret key x ; x is kept secret from all participants,but X , its corresponding public key, is known to all.2. An application stage, where the key shares may be used jointly over andover in order to sign messages or co-decrypt ciphertexts.Since the key shares must be related to one another, key generation must becoordinated and cannot be done independently by each participant. In the ab-sence of a trusted coordinator, Distributed Key Generation (DKG) protocolsallow a set of n participants to jointly distribute key shares, without leaking anyinformation on the secret x , and while maintaining the desired threshold t .Our work relies on a well-known family of DKG protocols for discrete-logbased threshold cryptosystems [14,27,18,17] that rely on SSS. Feldman [14]showed how SSS can be made verifiable , by having the protocol produce public David Yakira, Ido Grayevsky, and Avi Asayag data allowing the participants to check the validity of their private key shares.Feldman’s verifiable secret sharing (VSS) relies on a trusted dealer to generatethe global secret. Pedersen [27] was first to eliminate the need for a trusted dealerby parallelizing n Feldman’s VSS runs, each led by a participant P i committing(publicly) to her local polynomial f i . Then, the global polynomial f is defined tobe the sum of the local polynomials, and the global secret is f (0). This protocolis known as Ped-DKG. In App. A we give an overview of this protocol.In [18,17], Gennaro et al. formulate a minimal set of requirements for a ( t, n )-DKG protocol in discrete-log based cryptosystems over a group G = h g i of primeorder q : Correctness. (C1) There is an efficient procedure that on an input consisting of any t +1 distinct(and correct) secret key shares produced by the protocol outputs the samesecret x . There is another efficient procedure that on an input consistingof n different secret key shares (of which at least t + 1 are correct) and thepublic data produced by the protocol, outputs the secret x .(C2) There is an efficient procedure to calculate g x from the public data producedby the protocol, where x is the unique secret key guaranteed by (C1).(C3) x is uniformly distributed in Z q , hence g x is uniformly distributed in G . Secrecy.
No information on x can be learned by the adversary except for whatis implied by the value g x . More formally, secrecy depends on the existence ofa distribution, parameterized by g x alone, which generates data that is indis-tinguishable from the public data produced by the protocol (in the eyes of theadversary, which is assumed to know t secret key shares). In this section we set the ground for threshold cryptosystems that guarantee cor-rectness, secrecy, and robustness in rational environments. We propose a frame-work that encompasses the entire lifetime of the cryptosystem—from key gener-ation to application. The key generation kick-starts the system by distributing correct keys to the participants. These are later used within some desired appli-cation, in which secrecy and robustness are to be maintained.
In our model a set of n rational participants P , . . . , P n take part in the cryptosys-tem. We cannot expect them to follow some predetermined set of instructions,and assume instead that they are driven to maximize their utility . We make This procedure alludes to some efficient way to verify the validity of a single share.ational Threshold Cryptosystems 5 a distinction between participants and entities —different entities have indepen-dent utilities, but different participants may correspond to the same entity . Theutility of an entity is her total profit (or loss) by the end of the system’s lifetime.We assume the existence of a transparent escrow service that takes partici-pants’ deposits and can burn deposits, or redistribute them, according to pre-determined rules. External entities, i.e., ones that do not have a participant inthe cryptosystem (we refer to them as the public ), are exposed to the cryptosys-tem via the transparent escrow service. Entities communicate with the escrowvia (signed) transactions. The escrow is assumed to be publicly available witha known bound on transactions’ processing time. Such an escrow can be im-plemented as a smart contract over Ethereum . Moreover, we assume a publicbroadcast channel and a complete network of private channels between the par-ticipants (as required by Ped-DKG). Finally, we do not force any constraints onthe ratio between t and n —different ratios reflect different trade-offs. Economic adversarial model.
To formulate our economic model we assumethat a threshold cryptosystem holds some total value R . During its lifetime, αR of that value, for some 0 ≤ α ≤
1, is intended to reward the participants. Thereward however, is conditioned on the cooperation of the participants underapplication-specific limitations. In expectancy, each participant gets αRn . Theremaining, (1 − α ) R goes to the external entities. If t + 1 participants manageto cooperate “illegally” while ignoring the limitations, they can enjoy a largerportion of the reward R . We refer to such cooperation as collusion . The maingoal of our framework is to prevent the option of profitable collusion. Example I.
In a simple lottery game the winning ticket is determined accord-ing to a random value in the form of a unique threshold signature over somenothing-up-my-sleeve (publicly known) value. The total money raised sellinglottery tickets is R , where (1 − α ) R is the total prize and αR is paid to theparticipants generating the signature. The lottery must guarantee that no entity One approach to model permissioned participation is by assuming that participantscorrespond to different entities. Our model is permissionless in this sense. Ethereum, however, has very limited throughput and the cost for on-chain transac-tions is high. While many techniques minimize the on-chain component of the systemand carry all of the heavy lifting off-chain (e.g., TrueBit [32], and Arbitrum [24]),in this section we focus on the economic perspective of our system, and ignore lim-itations imposed by Ethereum. In a sense, we assume “an ideal Ethereum” whosecapacity and utilization costs resemble that of a modern computer. In App. C weshow how to adjust our framework to comply with Ethereum in its current state. This model suits the economic setting in Bitcoin— R is 21 million bitcoins, α = 1, t = n , and one participant can be thought of as one hash rate unit. Selfish mining [13,29]is interpreted as “illegal” collusion, where 51% of the hash rate results in 100% ofthe rewards. Of course, the total hash rate in Bitcoin is ever changing and minersjoin and leave the network as they please, which means maintaining 51% of the hashrate can be difficult. David Yakira, Ido Grayevsky, and Avi Asayag becomes aware of the winning ticket whilst the ticket sale is taking place . Thus,the application-specific limitation is that the signature is produced only afterthe ticket sale closes. Example II.
In Satoshi’s example, R is the total amount of bitcoins paid bySatoshi, and α = 1. Collusion translates to immediate profit rather than havingto wait until Satoshi passes away. Our economic model strongly captures the inherent collusion pressure in thresh-old cryptosystems. The main goal of the framework we propose is to dismantlethis pressure by aligning the participants’ utility-maximizing strategies with theapplication-specific limitations. The system designer’s only tool in shaping thebehavior of the participants is the escrow service, which (unlike the participants)follows prescribed rules in the protocol without deviations.Our first design choice is to condition participation on a deposit made to theescrow. Fundamentally, we interpret a threshold cryptosystem as an investmentchannel in which entities invest an initial sum of money (the deposit), and hopefor a return (the reward, αRn ) . As in any investment channel though, a riskaspect is inevitable . Indeed, the escrow can decide to slash deposits in case complaints are filed.Complaints are the mechanism by which the escrow guides the participants’behavior in practice. The escrow supports a set of complaints that should deterparticipants from deviating from their intended behavior. The complaint mech-anism is composed of four elements:1. Detection. A participant detects unintended behavior by another participant.2. Proof. She provides the escrow with evidence of her findings.3. Arbitration. The escrow verifies her proof.4. Incentive layer. The escrow burns deposits and rewards participants accord-ing to some predetermined specification.A complaint mechanism is measured by its ability to support detection andefficient arbitration of as many unintended behaviors as possible. Moreover, itsdeterrence relies on complaining being profitable, which should be addressed bythe incentive layer.Complaints may have additional consequences atop redistributing and burn-ing deposits. In the original Ped-DKG protocol complaints result in revealing For instance, if the escrow is a smart contract over Ethereum, the schedule of thelottery would be determined by Ethereum block heights—certain block heights forthe ticket sale and later blocks for producing the signature. In our Bitcoin analogy, this is equivalent to miners buying ASICs and paying elec-tricity bills for a potential reward. While in most investment channels the risk stems from market forces, here, there aretwo types of risks: technical risks (e.g., software bugs or cyberattacks) and behavioralrisks, which depend on the choices the other participants make.ational Threshold Cryptosystems 7 secret sub-shares (or excluding participants from the set QUAL, see App. A),but under the assumed adversarial model there, the DKG procedure never fails.In contrast, our framework must allow the protocol to fail, for example when col-lusion was detected. This introduces an attack vector against the system whichis to be mitigated by setting an appropriate cost to failing the system. We referto this cost as economic robustness . Our DKG protocol,
Escrow-DKG , kick-starts the cryptosystem.Participants must first enroll by depositing funds to the escrow. The protocolthen proceeds in phases , roughly corresponding to those of Ped-DKG. All datasubmitted to the escrow is publicly available to all participants. In Fig. 1 wedepict the complete description of the protocol.As in Ped-DKG, when participants detect unintended behavior they may filecomplaints. In Escrow-DKG, when a complaint is filed the protocol enters a dis-pute phase between the prover (the entity filing the complaint and proving it)and the challenger (the entity who challenges the complaint). For the escrow toarbitrate the complaint, the prover submits all necessary data and the escrowexecutes the necessary computations and rules whether the complaint is just (toaccommodate arbitration to Ethereum’s limitations, App. C illustrates an inter-active arbitration protocol in which both sides, the prover and the challenger,take active role). Then, the contract slashes and rewards accordingly. See Ta-ble 1 for details. Once a complaint has been filed, the protocol fails. If desired,the protocol can be easily relaunched. Specifically, we do not consider failing theDKG as the end of the system’s lifetime. As we discuss in Sec. 5.3, we expectfailing the DKG to be very rare as there is no gain in doing so.
Application.
If Escrow-DKG did not fail, we say it has completed successfullyand participants can begin using their key shares, e.g., in producing thresholdsignatures. We emphasize the escrow keeps the deposits in order to incentivizepost-DKG behavior.If required by the cryptosystem (as would often be), any public informationgenerated by Escrow-DKG can be submitted to the escrow. For example, one maysubmit the public key , X . Authenticity of public data submitted to the escrowis subject to complaints (see cm in Table 1). However, after Escrow-DKG has Revealing up to t of her sub-shares, a participant does not leak any information abouther local polynomial. This is of course theoretically true, but weakens the securityguarantees of the protocol. Imagine a situation where participant P has revealed t of her sub-shares (due to t complaints against her). Without loss of generality, letthose be f (2) , . . . , f ( t + 1). Now, in order to reveal f , it suffices to hack any ofthe participants that did not complain, i.e., P t +2 , . . . , P n . This is a much easier taskthen having to specifically hack P . We thus avoid instructing participants to revealtheir sub-shares. David Yakira, Ido Grayevsky, and Avi Asayag Fig. 1:
Escrow-DKG en-rollment transactions to the escrow service. We refer to the participants by theirenrollment order 1 ≤ i ≤ n . To enroll, participant P i locally generates:(a) A random polynomial of degree t over Z q , f i ( z ) = a i, + a i, z + · · · + a i,t z t (b) A private key ξ i ∈ Z q for private communication.(c) Public commitments to f i ’s coefficients, X i,k = g a i,k for k ∈ { , . . . , t } .She then submits her enrollment transaction, tx ( i ) = h ∆, γ ξ i , H ( X i, ) i where, ∆ is her deposit, γ ξ i is her public encryption key and H ( X i, ) is her hashcommitment to her partial secret a i, .2 Public commitments. Every participant P i publishes commitments transaction, tx ( i ) = (cid:2) { X i,k } tk =0 (cid:3) If P i fails to publish tx ( i ) in time, any participant j can file a complaint, cm ( j, i ), against P i . If X i, given in tx ( i ) does not match its hash commit-ment from tx ( i ), or otherwise some commitment fails the group membershiptest a , any participant j can file a complaint cm ( j, i ).3 Sub-shares. Every participant P i locally computes her sub-shares x i,j = f i ( j ) forall j . For j = i she encrypts x i,j using P j ’s public encryption key and publishesthe corresponding sub-share transactions, tx ( i, j ) = h ENC γ ξi (cid:0) x i,j (cid:1)i If P i fails to publish tx ( i, j ) in time, any participant l can file a complaint, cm ( l, i, j ) against her.4 Sub-shares verification. Every participant P i locally verifies that the sub-sharesintended to her are consistent with the public commitments. That is, she checksthat for all j , g x j,i = t Y k =0 (cid:0) X j,k (cid:1) i k If the equality for some j does not hold, P i can file a sub-share complaint, cm ( i, j, ξ i ) against P j .5 Conclusion. If no complaints were filed during the course of the protocol, Escrow-DKG is said to have completed successfully . Each P i can compute her key share x i = P nj =1 x j,i , as well as the global public key X = Q ni =1 X i, . She alsocomputes the public key share g x j for all participants P j . Deposits are kept forthe application stage.If some complaint is filed, it is arbitrated by the escrow, and the protocol can berelaunched with the same set of participants, excluding the one slashed by theescrow. a In [17,18] group membership of the public commitments (verifying that X i,k ∈ h g i )was omitted, but seems necessary for the proofs. We therefore add this verificationcheck in Escrow-DKG.ational Threshold Cryptosystems 9 completed successfully, for robustness, complaints do not fail the cryptosystemand might only invoke slashing of deposits .The main contribution of our framework is its ability to economically dis-courage collusion, i.e., undesired cooperation of t + 1 participants. We introducethe option of framing in case collusion took place during the application stage.At any point in time, any (bonded) entity may publish a framing complaintcontaining evidence of collusion (framings are given in Table 1 as f m ). Un-like regular complaints, framing is not targeted against a specific participantbut rather against the entire system. We are compelled to do so as collusionevidence cannot reveal any information regarding the (true) identities of thecolluding parties. For this reason, framing results in all deposits being burnt,except for the reward given to the framer (see last row in Table 1). Framingopens a new and lucrative opportunity for entities taking part in collusion. Aswe show in the following section, when the system parameters are tuned cor-rectly, entities are better off framing than colluding. Realizing this, entities arediscouraged to collude, fearing another entity would frame. Example I.
In our lottery example, collusion is manifested by the generationof the signature that determines the winner during the ticket sale . The t + 1colluding parties generating the signature can share the lottery prize by buyingthe winning ticket. On the other hand, any entity within the collusion can frameand enjoy a significant reward, while all other participants are slashed. Example II.
In Satoshi’s example, collusion is manifested by reconstructing thesecret while Satoshi is still alive . Participants should be discouraged from doingso, fearing one of them would frame the others to enjoy an additional reward.
The protocol satisfies three properties that we discuss hereafter. Fundamentally,we adapt the original requirements of a DKG protocol presented in Sec. 3 to oureconomic model and prove them assuming that the entities are rational. We note that the escrow service has no deterrence over a slashed participant, P j .To handle this, the corresponding secret key share, f ( j ), is revealed and from thatpoint on the system operates as a ( t − , n − P j ’s slasheddeposit can be used to incentivize participants to help reveal f ( j ). We do not allow framing a specific participant by reveling her private data (e.g., f ( j )), even though it would definitely serve as means to discourage data sharingbetween entities. The problem is that it would also open the opportunity for anyonecontrolling the cryptosystem (i.e., knowing f ) to frame honest participants, increas-ing the profits from collusion. As a matter of fact, “small collusions” (mining poolsin our Bitcoin analogy) are not necessarily bad if the different entities keep havingindividual interests and are incentivized to frame in case the collusion became “big”.0 David Yakira, Ido Grayevsky, and Avi Asayag Table 1: Complaints and FramingThe table depicts the details of complaints, arbitration and the outcomes interms of slashing and rewarding. Notice that all complaints result in some valuebeing burnt: ( n − t ) ∆ in justified framing and ∆/ Title Claim Arbitration procedure Incentives (justified /unjustified) cm ( j, i )or cm ( j, i, l ) P i did not publish tx ( i ) or tx ( i, l ). Trivial check. P i : − ∆P m : + ∆ n − ∀ m = iP j : − ∆P m : + ∆ n − ∀ m = jcm ( j, i ) P i published invalidhash commitment. Compute H ( X i, ) from tx ( i ) and compare it withthe value in tx ( i ). P i : − ∆P m : + ∆ n − ∀ m = iP j : − ∆P m : + ∆ n − ∀ m = jcm ( j, i, ξ j ) P i published an in-consistent sub-share x i,j . Decrypt tx ( i, j ) using ξ j ,and compute g x i,j . Com-pare with Q tk =0 ( X i,k ) j k us-ing data from tx ( i ). P i : − ∆P j : + ∆ P j : − ∆P m : + ∆ n − ∀ m = jcm ( j, i ) P i published in-correct public data tx pub ( i ) (e.g., g f ( i ) ). Use the commitments tocompute the desired value(e.g., Q nj =1 g x j,i ), and com-pare with tx pub ( i ). P i : − ∆P m : + ∆ n − ∀ m = iP j : − ∆P m : + ∆ n − ∀ m = jfm ( j, data ) data serves as col-lusion evidence (e.g., data = f (0)). Verify the evidence (e.g.,check g data = Q ni =1 X i, ). P j : + t∆P m : − ∆ ∀ m = jP j : − ∆P m : + ∆ n − ∀ m = j Claim (Correctness).
If Escrow-DKG (i.e., only the DKG stage) completed suc-cessfully, then the secret key shares and the public data produced by the protocoladmit ( C
1) and ( C Lemma 1.
During Escrow-DKG, if an entity has the possibility to file a justifiedcomplaint, Escrow-DKG would not complete successfully.Proof.
We prove that if an entity has the chance to file a justified complaintagainst another entity, she would do so. This might seem trivial as filing a justi-fied complaint yields an immediate profit to the prover. However, in a pessimistic ational Threshold Cryptosystems 11 scenario, since complaints require relaunching the DKG, they might reduce thevalue R —according to our model, the value R is attached to a specific cryptosys-tem that is launched with a specific DKG run; relaunching implicitly means R might change (e.g., in the lottery example, if the DKG fails, it might reduce thesystem’s credibility and lead to a decrease in ticket sales). We show that evenunder the worst case assumption that R reduces to zero after the complaint, itis still beneficial for entities to complain when possible (even though it impliesthey lose their own profit, αRn ). There are three complaint categories to consider.1. Private data mismatch (sub-share complaint cm ). A participant P j hasclear motivation of having a secret key share that matches the public key.If one of P j ’s sub-shares f i ( j ) does not match P i ’s commitments, she wouldend up with a useless key share that would not allow her to participate inthe protocol. De facto, P j would not be a participant and would lose herexpected profit , αRn . Thus, the immediate reward of ∆ n − suffices for herto complain.2. Public data mismatch ( cm and cm ). In this case any entity, includingexternal entities, can complain. Since external entities have nothing to loseand will gain a profit from complaining, they will do so . Participants know someone would complain and are thus incentivized to do so themselves.3. Missing data ( cm and cm ). While we do mention these complaints, inpractice the escrow service itself can detect missing data. This serves enoughof an incentive to complain for the immediate profit. ⊓⊔ Proof (Correctness).
From the previous lemma we can deduce that no entitycould have made a justified complaint during a successful run of Escrow-DKG.Such a run is equivalent to a Ped-DKG run in which all the participants arecorrect. The equivalence is given by mapping the participants in Escrow-DKGto those in Ped-DKG, and assuming they sample the same local polynomials f i .If all Ped-DKG participants are correct, then no one complains and the data(public and private) produced by the protocol is identical to that in the Escrow-DKG run. ( C
1) and ( C
2) in Ped-DKG imply ( C
1) and ( C
2) in Escrow-DKG. ⊓⊔ Handling ( C
3) is more tricky. Hashing g a i, in the enrollment transactionguarantees that when P j samples her partial secret, a j, , she is unaware of g a i, (for any i ) and cannot relate it to those of the other participants. Assuming oneparticipant sampled her partial secret uniformly in random is enough to concludethat the sum is also distributed uniformly. However, the option of Escrow-DKGto fail (i.e., not to complete successfully) opens the opportunity for participantsto try and manipulate g x . If a participant does not like the sampled g x , shecan fail Escrow-DKG and have it re-sampled in the subsequent run. We furtherrelate to this issue in Sec. 5.3. We implicitly assume that the system rewards only active participants. To prevent spam and unjust complaints, external complaints would be accompaniedby a deposit that would be slashed if they are found unjust.2 David Yakira, Ido Grayevsky, and Avi Asayag
Obviously, a permissionless threshold cryptosystem has scenarios in which itcannot be trusted, e.g., when a single entity controls t + 1 participants in theDKG. While we cannot prevent such scenarios, our goal is to articulate concreteeconomic conditions as to when a given cryptosystem is trustworthy and col-lusion resistant. We say that a threshold cryptosystem is collusion resistant ifit adheres certain conditions which make collusion a non-profitable strategy .The following claim gives a strong condition in this spirit. Claim (Collusion resistance). If R < ( t − ∆ then “two-entity” collusion (i.e.,collusion involving exactly two entities) can only take place between two entitiesthat invested at least ( t +1) ∆ each.The claim implies that one should trust the system to be collusion resis-tant if they believe that there are no two entities controlling at least t +12 DKGparticipants each . Proof.
Consider the case of two separate entities A and B controlling a and b DKG participants respectively. Assume a + b ≥ t + 1 so that if the two entitiescollude they break the system. It is enough to show that for such collusion to beprofitable, A and B would each have to invest at least ( t +1) ∆ .We analyze the payoff matrix of A and B in case collusion took place (seeTable 2). Both entities have two options—to frame or not to frame.Table 2: Framing Payoff MatrixThe case where both A and B do not frame (bottom-right) captures the pres-sure to collude—instead of earning their fair share ( A should earn a · αRn ), thetotal value held by the system, R , is now split solely between these two entities(according to their weights). The other cases are self explanatory from the lastline in Table 1. Entity A Entity B Frame Not frameFrame Both have 0 . t − a ) ∆ − b∆ Not frame − a∆ +( t − b ) ∆ + a · R/ ( t + 1) + b · R/ ( t + 1) In a collusion resistant cryptosystem, the secrecy property defined in Sec. 3 is satis-fied. However, secrecy is not enough—collusion does not imply revealing x . The trustworthiness question we raise here is fundamental also in Bitcoin. One shouldtrust Bitcoin only if they believe no single entity is controlling more than 50% of thehash power. The open nature of Bitcoin and the ability of anyone to start miningmakes this assumption reasonable.ational Threshold Cryptosystems 13
In case B chose to frame, A is obviously better off framing as well (whoevergets her complaint processed first profits while the other gets slashed). Otherwise,in case B does not frame, A ’s utility can either be ( t − a ) ∆ (by framing), or Raa + b ≤ Rat +1 (by not framing) . In case a < t +12 , A is better off framing (for thiswe only need R < ( t − ∆ ). B ’s view is symmetric, which means only if a and b both are at least t +12 no framing would occur.We are not done yet. If a < t +12 then B would disagree to collude with A — B knows A ’s dominant strategy is to frame. For A to convince B she will not frame,her payoff matrix must change—either her profit from framing reduces or herprofit from a successful collusion increases.In the first case, A would have to convince B of an additional loss, ∆ A , incase she (or anyone else for that matter) framed . Her total investment wouldthen be a∆ + ∆ A and in order to be discouraged from framing, this needs to belarger than t∆ − Rat +1 . Simple arithmetics shows that A ’s investment would haveto be larger than (3 t − ∆ (after substituting R with ( t − ∆ ) .Since A ’s investment is higher than ( t +1) ∆ , we conclude that in this scenariocollusion is profitable only if both sides invest more than ( t +1) ∆ . To completethe proof we have to analyze B ’s option to offer A additional profits shouldthe collusion succeed. B could only offer her marginal profit from the collusion(relative to not colluding), which is Rbt +1 − αRbn . This sum, combined with A ’sprofit from a successful collusion, Rat +1 , would have to be larger than A ’s minimalprofit from framing, ( t − t +12 ) ∆ (where the ( t +1) ∆ subtracted is derived from thefact that, in the setting suggested by the claim, A is not willing to invest morethan ( t +1) ∆ ). Our assumption on R does not allow this even if α = 0. ⊓⊔ Interestingly, collusion resistance does not depend on the parameter α or onthe ratio t/n —only the ratio between R and ∆ matters. In practice though, thereward, αRn , needs to be attractive for participants to join. Corollary 1.
In the setting of claim 5.2, if no entity has invested at least ( t +1) ∆ then collusion cannot take place.Proof. If no entity has invested ( t +1) ∆ then no two entities could be found tocollude and obtain t + 1 secret key shares. If entities that invested less than ( t +1) ∆ were to collude, forming a “multiple-entity” collusion, any entity withinthat collusion could view the payoff matrix as herself against the other entities,united. It would thus be profitable for any entity within that collusion to frame.We can thus conclude that no collusion would emerge. ⊓⊔ Not surprisingly, the more participants an entity controls the less she is encouragedto frame. One way to guarantee such loss would be to deposit ∆ A in a side contract which isinstructed to burn the deposit in case framing took place. We note a simple trade-off—the lower R ’s bound is (in terms of ∆ ), the larger ∆ A becomes. In essence this means that locking funds in side contracts is less lucrative,as more funds need to be invested in order to convince B that framing is unprofitable.4 David Yakira, Ido Grayevsky, and Avi Asayag If collusion resistance mitigates the risk of entities breaking the cryptosystem,robustness deals with the possibility of failing it. Economic robustness estimatesthe price of the different ways to fail the system—failing Escrow-DKG (by tak-ing advantage of the complaint mechanism); failing the system during the ap-plication stage (by taking advantage of the framing mechanism); or putting thesystem to a halt (by convincing enough participants not to cooperate).Failing Escrow-DKG can be done by complaining unjustly or by submittinginconsistent data. We set the price of failing Escrow-DKG to be ∆/ x isnot possible, and while last actor attacks allow manipulating g x , it was shownin [17] that the influence on g x is very limited. In our setting this influence comeswith a price, as each attempt to re-sample g x costs ∆/ t + 1 participants to collude and then frame themselvesmust be higher than what they get in the first place which is ( t +1) αRn (addition-ally, they should be compensated for the burnt ∆ due to the framing). Settingthis price high amounts to tuning the ratio t/n and the value α to be ratherhigh.Finally, refusing to cooperate also amounts to failing the protocol. Lack ofcooperation implies n − t participants refuse to reveal their share. By instructingthe escrow to burn all deposits in case of such lack of cooperation, we set theprice of failing at ( n − t ) ∆ . For this price to be high, one should set n − t tobe rather high.It only makes sense to tune the parameters such that failing the protocoleither way costs the same (excluding the DKG stage). This condition yields arelation between α and t/n . A simple computation gives α ∼ n ( n − t ) t . Intuitively,the smaller α is, the higher t/n needs to be. To get α = 0 .
25, we need t/n = 0 . n ∆ . Note the linear dependencein n . Example I.
Let’s try some numbers in our lottery example. For R = 10 , ∆ =10 and α = 0 .
25, the prize is 750 ,
000 and 250 ,
000 is the reward paid to theparticipants generating the randomness for their services. For a 10% ROI (whichis lucrative for, say, a month’s long investment), n would have to be 250 and t = 0 . · n = 225 (note that indeed R is slightly smaller than ( t − ∆ ). Collusionis irrational as long as no entity has 113 participants, which translates to a1 , ,
000 investment. Failing the protocol after the DKG would cost 25 ∆ =250 , Note that even though participants expect a reward of αRn from participating in thecryptosystem, we make a worst case assumption where only one participant gets thewhole αR (thus the αRn factor is ignored in the pricing calculation).ational Threshold Cryptosystems 15 Example II.
Satoshi would deploy a smart contract including the hash of hersecret, and a trapdoor that allows (only) her to invoke slashing deposits. Thetrapdoor would expire within a year, but could be extended for another year, ifSatoshi is still alive (and submits a transaction). We note that in this example,the analysis made above needs some modifications. First, it is known that thesecret share holders are distinct real-world entities (the permissioned setting),and second, even in case of framing, the R/n reward is guaranteed (Satoshi’ssigned transaction will not change). Framing can only yield an additional profitto the framers. This somewhat changes the payoff matrix in Table 2. In thesecircumstances, a less lucrative reward from framing is a better option. That is,framing would reward the framer with t∆ (instead of t∆ ). This would reducethe risk of t + 1 participants deciding to split the costs of the slashing for the im-mediate reward R/n and would enable reducing the size of the deposits (insteadof ∆/ ( t + 1) > R/n , we would need ∆/ > R/n ).Once Satoshi dies, she stops extending the trapdoor and the participantscan safely cooperate and reveal the secret, as framing could no longer invokeslashing . To eliminate the risk of side contracts (mentioned in Sec. 5.2), thedeposits would have to be high enough, so that t∆ is too high an amount forthe participants to put aside. Example III.
In App. D we propose a multi-round leader election protocolthat relies on an escrow service (which could be used to realize a sidechainto Ethereum) that mimics and improves on Bitcoin’s incentive structure.
In this work we defined an economic model for rational threshold cryptosystems,which captures both the economic value produced by such systems, as well asthe rationality of those taking part in the system, acting to maximize theirown profits. We solve the problem of collusion pressure inherent to rationalcryptosystems by utilizing an escrow service that takes deposits from participantsand uses them to discourage participants from colluding. We show how such anescrow can be realized over Ethereum.Our framework illustrates how threshold cryptosystems might be applicablein decentralized-permissionless settings, whereas the classic model for thresholdcryptography is only applicable in trusted environments. The Satoshi exampleshowed that our framework is suitable also in the permissioned setting, whereeach participant represents a distinct entity.Our main contribution is to attach concrete economic costs to breaking thesecrecy and robustness of the cryptosystem. The fact that these costs are func-tions of the system’s parameters ( t, n, R, α ) achieves two goals. First, it allows Ironically, Bitcoin is not a viable option to this end... To eliminate Satoshi’s option of handing the trapdoor extension key to a friendbefore she dies, a hard limit should be added.6 David Yakira, Ido Grayevsky, and Avi Asayag system designers to tune these parameters to suit their needs, and second, per-haps more importantly, it enables users to assess the credibility of the system. Asa motivating example, we consider a set of n participants that “Shamir share” asecret. While the participants have the ability to cooperate and reveal the secretat any time, our framework economically assures that they do so only in specifictimes defined by the system designers.Our framework raises many questions. We are especially interested in the fol-lowing issues, which we leave for future work. First and foremost, in the permis-sionless setting, collusion resistance and robustness rely on the ability to supportvery large n and t and to have an open and unlimited enrollment procedure (sim-ilarly to Bitcoin hash rate). Due to the computational (group arithmetics) andcommunication complexity of Ped-DKG, it can only support a limited number ofparticipants. Future work is required to scale the number of participants—e.g.,by having several DKG groups run side by side, as proposed in [22], or use thesparse matrix approach suggested in [10].Another interesting question is how to increase the robustness of the cryp-tosystem, especially during the DKG. The low cost of failing Escrow-DKG is aweak spot in our framework which could be critical in some applications. A morepermissive complaint mechanism in the spirit of Ped-DKG (where complaintsdo not necessarily fail the DKG procedure), enhanced with slashing unjustifiedcomplaints, might be a good direction.In the context of robustness, even if enough participants have principallydecided to cooperate during the application stage (e.g., generate a thresholdsignature), the exact communication scheme between them is not considered inthis work. In rational secret sharing [20], communication protocols are consideredwith the aim that all the participants reveal the secret together. Achieving thiswould enhance the robustness of the cryptosystem, and its fairness. References
1. I. Abraham, G. Gueta, and D. Malkhi. Hot-stuff the linear, optimal-resilience,one-message BFT devil.
CoRR , abs/1803.05069, 2018.2. G. Asharov and Y. Lindell. Utility dependence in correct and fair rational secretsharing.
IACR Cryptology ePrint Archive , 2009:373, 2009.3. A. Boldyreva. Threshold signatures, multisignatures and blind signatures basedon the gap-diffie-hellman-group signature scheme. In
Public Key Cryptography ,volume 2567 of
Lecture Notes in Computer Science , pages 31–46. Springer, 2003.4. D. Boneh, B. Lynn, and H. Shacham. Short signatures from the weil pairing. In
ASIACRYPT , volume 2248 of
Lecture Notes in Computer Science , pages 514–532.Springer, 2001.5. D. Boneh and V. Shoup. A graduate course in applied cryptography. 2018.6. E. Buchman. Tendermint: Byzantine fault tolerance in the age of blockchains, Jun2016.7. V. Buterin. Ethereum: A next-generation smart contract and decentralized appli-cation platform. https://github.com/ethereum/wiki/wiki/White-Paper , 2013.8. V. Buterin. Proof of stake: How i learned to love weak subjectivity, 2014.ational Threshold Cryptosystems 179. V. Buterin and V. Griffith. Casper the friendly finality gadget.
CoRR ,abs/1710.09437, 2017.10. J. F. Canny and S. Sorkin. Practical large-scale distributed key generation. In
EUROCRYPT , volume 3027 of
Lecture Notes in Computer Science , pages 138–152. Springer, 2004.11. M. Castro and B. Liskov. Practical Byzantine fault tolerance and proactive recov-ery.
ACM Trans. Comput. Syst. , 20(4):398–461, 2002.12. S. Chatterjee and A. Menezes. On cryptographic protocols employing asymmetricpairings – the role of ψ revisited. Cryptology ePrint Archive, Report 2009/480,2009. https://eprint.iacr.org/2009/480 .13. I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable. In Financial Cryptography and Data Security , 2014.14. P. Feldman. A practical scheme for non-interactive verifiable secret sharing. In
Proceedings of the 28th Annual Symposium on Foundations of Computer Science ,SFCS ’87, pages 427–438, Washington, DC, USA, 1987. IEEE Computer Society.15. G. Fuchsbauer, J. Katz, and D. Naccache. Efficient rational secret sharing instandard communication networks.
IACR Cryptology ePrint Archive , 2008:488,2008.16. S. Galbraith, F. Hess, and F. Vercauteren. Aspects of pairing inversion.
IEEETransactions on Information Theory , 54(12):5719–5728, Dec 2008.17. R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. Revisiting the distributedkey generation for discrete-log based cryptosystems, 2003.18. R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. Secure distributed key gen-eration for discrete-log based cryptosystems.
J. Cryptology , 20(1):51–83, 2007.19. S. D. Gordon and J. Katz. Rational secret sharing, revisited.
IACR CryptologyePrint Archive , 2006:142, 2006.20. J. Y. Halpern and V. Teague. Rational secret sharing and multiparty computation:extended abstract. In
Proceedings of the 36th Annual ACM Symposium on Theoryof Computing, Chicago, IL, USA, June 13-16, 2004 , pages 623–632, 2004.21. T. Hanke. Asicboost - A speedup for bitcoin mining.
CoRR , abs/1604.00575, 2016.22. T. Hanke, M. Movahedi, and D. Williams. Dfinity technology overview seriesconsensus system. January 2018.23. D. Hankerson, A. J. Menezes, and S. Vanstone.
Guide to Elliptic Curve Cryptog-raphy . Springer-Verlag, Berlin, Heidelberg, 2003.24. H. A. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, and E. W. Felten. Arbi-trum: Scalable, private smart contracts. In
USENIX Security Symposium , pages1353–1370. USENIX Association, 2018.25. A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secureproof-of-stake blockchain protocol. In
CRYPTO (1) , volume 10401 of
Lecture Notesin Computer Science , pages 357–388. Springer, 2017.26. G. Kol and M. Naor. Games for exchanging information. In
Proceedings of the 40thAnnual ACM Symposium on Theory of Computing, Victoria, British Columbia,Canada, May 17-20, 2008 , pages 423–432, 2008.27. T. P. Pedersen. A threshold cryptosystem without a trusted party. In
Proceedingsof the 10th Annual International Conference on Theory and Application of Cryp-tographic Techniques , EUROCRYPT’91, pages 522–526, Berlin, Heidelberg, 1991.Springer-Verlag.28. Y. Qian. Randao: Verifiable random number generation. https://randao.org/whitepaper/Randao_v0.85_en.pdf , 2017.29. A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategiesin Bitcoin. In
Springer Financial Cryptography and Data Security , 2016.8 David Yakira, Ido Grayevsky, and Avi Asayag30. A. Shamir. How to share a secret.
Commun. ACM , 22(11):612–613, 1979.31. M. Stadler. Publicly verifiable secret sharing. In U. Maurer, editor,
Advancesin Cryptology — EUROCRYPT ’96 , pages 190–199, Berlin, Heidelberg, 1996.Springer Berlin Heidelberg.32. J. Teutsch and C. Reitwießner. A scalable verification solution for blockchains. https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf , 2017.33. G. Wood. Ethereum: A secure decentralised generalised transaction ledger eip-150revision (759dccd - 2017-08-07), 2017. Accessed: 2018-01-03.ational Threshold Cryptosystems 19
The full description of Ped-DKG is given below (Fig. 2). The correctness andsecrecy properties of Ped-DKG rely on a generalization of similar properties inFeldman’s VSS [14] (in which a single participant samples a polynomial anddistributes commitments and shares, and the other participants only performthe validations).
Lemma 2 (Feldman).
Feldman’s VSS satisfies the following properties:1. If the dealer P i is not disqualified during the protocol then all correct playershold shares that interpolate to a unique polynomial f i of degree t . In par-ticular, any t + 1 of these shares suffice to efficiently reconstruct the secret f i (0) .2. The protocol produces information (the public values X i,k for k = 0 , . . . , t andprivate values x i,j for j = 1 , . . . , n ) that can be used at reconstruction timeto test for the correctness of each share; thus, reconstruction is possible, evenin the presence of malicious players, from any subset of shares containing atleast t + 1 correct shares.3. The view of the adversary is independent of the secret f i (0) , and thereforesecrecy is unconditional. While the generalization to the Ped-DKG protocol seems straightforward,the attack described in [18] shows there are delicate issues to address.
Appendix B Threshold BLS-3 Signatures
Throughout the paper we describe a randomness beacon based on thresholdBLS-3 signatures. For completeness, we specify the ingredients of the proposedsignature scheme.
BLS Signatures.
In [4] the authors present a signature scheme based on theWeil pairing, which is both simple and efficient. It results in signatures whichare unique , namely, for a pair of message and public key ( m, P K ) there existsa unique signature M which passes validation. The scheme relies on the Diffie-Hellman problem and its variants. Let G = h g i be a cyclic group of order q . Weconsider the following problems: Decision Diffie-Hellman (DDH).
Let a, b, c ∈ Z q . Given a tuple ( g, g a , g b , g c ),decide whether g c = g ab . Computational Diffie-Hellman (Co-DHP).
Let a, b ∈ Z q . Given a tuple( g, g a , g b ), compute g ab .A DDH (resp.
Co-DHP ) group is a group in which the DDH (resp. Co-DHP)is hard . A
Gap Diffie-Hellman (GDH) group is one where the DDH is easy whilethe Co-DHP is hard.
Fig. 2:
Ped-DKG
1. Each player P i samples uniformly at random (and independently) t + 1 coef-ficients from Z q . These coefficients represent a random polynomial of degree t over Z q , denoted f i : f i ( z ) = a i, + a i, z + · · · + a i,t z t P i broadcasts her public commitments X i,k = g a i,k for k = 0 , . . . , t . P i com-putes the sub-shares x i,j = f i ( j ) for j = 1 , . . . , n and privately sends x i,j toplayer P j .2. Each player P j verifies the sub-shares she received from the other players bychecking g x i,j = t Y k =0 (cid:0) X i,k (cid:1) j k for i = 1 , . . . , n .If a check fails for some index i , P j broadcasts a complaint against P i .3. In the case of a complaint against P i by P j , P i reveals the sub-share x i,j (via the public broadcast communication channel). If any of the revealedsub-shares fail the above equation, P i is excluded from the set QUAL (i.e.,disqualified). If more than t players complain against P i , she is also disquali-fied (as t + 1 sub-shares reveal f i by interpolation). From the assumption onthe broadcast channel, the set QUAL is defined uniquely among the correctparticipants.4. The global secret x itself cannot be computed by any player, but is equalto x = P i ∈ QUAL a i, = f (0). The public key g x can be calculated by anyparticipant as Q i ∈ QUAL X i, = g f (0) .Additionally, the secret key share of player P j is x j = f ( j ) = P i ∈ QUAL x i,j ,which only P j can compute. The corresponding public key g x j however, canbe calculated from the public commitments published in (1) (using Lagrangeinterpolation). BLS utilizes GDH groups to design a signature scheme in which signing andverifying signatures is efficient: let G = h g i be a GDH group, and x ∈ Z q be thesecret key, assumed to be known to the signer alone. Define X = g x to be thepublic key known to all. To sign a message m ∈ G , the signer simply raises m to the power x , such that the signed message is M = m x . Since DDH is easy in G , anyone can verify that M is really m x , by solving DDH ( g, X, m, M ) (notethat m = g y for some unknown y ∈ Z q ). On the other hand, forging a signatureis infeasible since it amounts to solving the Co-DHP in G . Pairings.
One way to construct GDH groups is by using pairings —efficientlycomputable maps admitting two useful properties:
Definition 1 (Pairing).
Let G , G and G T be groups. A pairing e : G × G → G T is a bilinear non-degenerate map. Pairings give rise to GDH groups: if e is symmetric, i.e., G = G , and G is aCo-DHP group, then G is immediately a GDH group [4]. The BLS construction ational Threshold Cryptosystems 21 uses a concrete symmetric pairing of a Co-DHP group over an elliptic curve . Thischoice results in sufficient security as well as in relatively short representation.A later work on pairings [12] established the fact that asymmetric pairings canpreform better in both these aspects. Asymmetric pairings.
In case G = G the pairing is said to be either of type-2 (if there is an efficiently computable isomorphism Ψ : G → G ) or of type-3 (if there is no such Ψ ). The authors of [12] define BLS-3—a variant of theBLS scheme which utilizes type-3 pairings. This allows using groups with muchshorter representation, while maintaining sufficient security . The essential dif-ference between BLS and BLS-3 is the underlying hardness assumption, whichis a variant of Co-DHP, fit to the asymmetric setting: Co-DHP * . Let G = h g i , G = h g i be two cyclic groups of the same primeorder q . Given h, g , g x ∈ G and g , g x ∈ G (where x ∈ Z q ), compute h x ∈ G .Typically in the type-3 setting, G computations are easier to execute [12].For this reason, messages in the BLS-3 scheme come from G —so that signatures(exponentiation of m ∈ G ) could be computed easily. Moreover, it makes senseto have the public keys come from G , since a public key only needs to be com-puted once (during key generation). In the DKG however, many computationsshould be made in G . Threshold BLS signatures.
In [3], Boldyreva proposes a general methodfor adapting various signatures schemes to the threshold setting. She specificallyillustrates how to use the Ped-DKG protocol to turn BLS to a threshold signaturescheme.
Appendix C Escrow-DKG over Ethereum
C.1 Ethereum background
The Ethereum blockchain, sometimes referred to as a “world computer”, isa public blockchain in the Proof-of-Work (PoW) paradigm that maintains aglobal state under consensus. Digital transactions, issued by users, are collectedin blocks which in turn are included to the blockchain periodically (throughmining). Smart contracts are arbitrary programs, deployed to the Ethereumblockchain, and compiled to the Ethereum Virtual Machine (EVM). Transac-tions invoke smart contract execution and consume “gas” (which is a metricsystem to asses the amount of “work” operations require), in order to changethe Ethereum global state.We highlight two main Ethereum capabilities: Ethereum as an escrow servicethat can follow a complex set of rules, and Ethereum as a public broadcastchannel. In particular, a precompiled contract for computing a specific asymmetric pairingwas included in the Ethereum Virtual Machine, as we elaborate in App. C.2 David Yakira, Ido Grayevsky, and Avi Asayag
Ethereum as escrow.
A smart contract over Ethereum can easily act as anescrow service: its state allows storing a set of users along with their balances;and it can incorporate rules that determine when and how these balances arereleased back to the users. An escrow service over Ethereum has the advantage ofthat its corresponding escrow agent is completely abstract—there is no trustedentity that controls the escrow and can be subverted. As long as the Ethereumblockchain is viewed as a reliable system, with honest majority of hash power,the escrow cannot diverge from its prescribed set of rules.Evidently, a sophisticated escrow service can incentivize rational users to actaccording to some predetermined notion of “correct” or desired behavior.
Communication over Ethereum.
The Ethereum blockchain may serve asa tamper-resistant, publicly-available and censorship-resistant “blackboard”.Tamper-resistance means that once a record has been included in the blockchain(sufficiently long ago), altering it is practically impossible. Public-availabilityguarantees anyone has permission to read data from the blockchain. Finally,censorship-resistance means that for a reasonable fee, anyone can write arbi-trary data (of reasonable size) to the Ethereum blackboard within a reasonabledelay (that depends on the fee paid). These three qualities make Ethereum agreat broadcast communication channel. Specifically, we assume it takes at most δ blocks to get a transaction included in a block. Additionally, by using public-key encryption (specifically, ElGamal encryption [5]), Ethereum can be utilizedas a private communication channel. C.2 Eth-DKG
We now turn to specify
Eth-DKG —Escrow-DKG adapted to run efficiently overthe Ethereum blockchain. The modifications essentially concern two aspects:employing specific elliptic curve groups, and minimizing on-chain resource con-sumption by incorporating interactive proofs for complaint arbitration.
Precompiled contracts.
Computing general pairings and group arithmeticsis costly, and executing many such computations over Ethereum would be in-feasible. Fortunately, a precompiled contract that allows computing a specificasymmetric pairing e : G × G → G T (see [33], App. E) was incorporated intothe EVM (in the Byzantium hard fork), along with several other precompiledcontracts allowing to perform inexpensive G group arithmetics.There is still another problem to circumvent in the context of group arith-metics in Eth-DKG. Since the public key resides in G (see App. B), oper-ations in Eth-DKG should be performed over G . However, the precompiledcontracts only allow for efficient computations in G . To tackle this limitation,participants commit to their polynomial over both , G and G , by publishing X ui,k = g a i,k u (for u = 1 , X i,k , X i,k are ( G , G ) -consistent if their discrete logvalues (with respect to g and g ) are the same. It can be shown that, as long ational Threshold Cryptosystems 23 as G and G are cyclic groups, X i,k , X i,k are ( G , G )-consistent if and onlyif e ( g , X i,k ) = e ( X i,k , g ) (see [16]).To verify that the sub-shares match the G commitments, the smart contractwould first verify that the G commitments are consistent with the sub-shares(using the precompiled contracts for G group arithmetics) and then that allpairs X i,k , X i,k are ( G , G )-consistent (using the precompiled contract for pair-ing computation). Optimistic off-chain approach.
To reduce on-chain communication to min-imum, after enrollment participants are instructed to send all public and pri-vate data via off-chain channels. In the optimistic scenario, enrollment is theonly on-chain transaction. P i ’s enrollment transaction would contain additionalinformation— Dig i := Digest (cid:0) { X i,k } , { X i,k } (cid:1) , in order to make sure that shesends the same commitments ( { X i,k } , { X i,k } (cid:1) to all participants.In order to retain the ability to arbitrate complaints over Ethereum, all off-chain communication is delivered with authentication so that the smart contractcan verify the identity of the sender. This would allow using off-chain messagesas evidence when complaints are filed to the contract. Undelivered off-chain communication.
In case P j did not receive a trans-action from P i off-chain, she can submit a missing data transaction . If the datais public in nature, P i is asked to publish it over Ethereum. If the data is pri-vate, P i encrypts it using P j ’s public encryption key γ ξ j and then submits it tothe smart contract (this is the reason for including γ ξ j in the enrollment trans-action). If the data is too large to be written on-chain, we propose to use theEVM memory which is much cheaper in terms of gas (but is not persistent).This could prove that indeed, some data, in the right size (but not necessarilythe required data), was delivered. Then, if still needed, a regular complaint (thatwrites only a limited amount of data on-chain, as exemplified in App. C.3 withthe interactive sub-share complaint) can be filed.Fig. 3 gives a full description of the Eth-DKG protocol. To keep the descrip-tion concise, we assume the reader is familiar with Escrow-DKG (see Fig. 1). C.3 Interactive complaints over Ethereum
The arbitration of certain complaints requires complex computation that doesnot scale well with t and n . In this section we demonstrate a general approach toreduce on-chain arbitration costs via interactive protocols. Such protocols allowto shift the “heavy-lifting” from Ethereum to the users that are in dispute.In high level, a communication-computation trade-off is being exploited—instead of performing an Ω ( n ) computation on-chain, the parties engage in an O (log( n ))-phase long interactive protocol that isolates “the core of the dispute”and consumes O (1) on-chain resources per phase. We give a specific interac-tive protocol for cm ′ ( j, i ), the sub-share complaint, and compare between naive Fig. 3:
Eth-DKG enrollment transactions on-chain tx ′ ( i ) = h ∆, γ ξ i , Dig i i This is the only transaction (excluding complaints) in Eth-DKG which is senton-chain.2 Pubic commitments. Every participant P i sends (off-chain) to all other par-ticipants P j her commitments transaction tx ′ ( i ) = [ { X i,k } tk =0 , { X i,k } tk =0 ]If some P j received tx ′ ( i ) that does not match Dig i she can file a com-plaint cm ′ ( j, i ). If some pair of commitments ( X i,k , X i,k ) are not ( G , G )-consistent, P j can file a complaint cm ′ ( j, i, k ) a .3 Sub-shares. Every participant P i sends (over a private communication chan-nel) to all other participants P j her corresponding sub-share transaction tx ′ ( i, j ) = [ x i,j ]4 Sub-shares verification. Every participant P j locally verifies the sub-sharessent to her are consistent with the G commitments she received, namelythat for all i , g x i,j = t Y k =0 ( X i,k ) j k If the equality for some i ′ does not hold, she can file a complaint cm ′ ( j, i ′ ).If no complaints were filed during the course of the protocol, Eth-DKG issaid to have completed successfully (the deposits are kept for the applicationstage). Note that the public key of the scheme is g x , and is computed by everyparticipant locally. If needed, anyone may publish the public key on-chain.In case of a complaint during the course of the protocol, the smart contractperforms the arbitration and the protocol fails (it may be relaunched). Undelivered communication.
In case P j did not receive tx ′ l ( i ) (for l ∈ { , } )in time, she can request P i to publish it on-chain by submitting a special alert tothe smart contract. This alert initiates a special phase of on-chain communication.During this phase P i is required to submit the missing transaction to the smartcontract—if the missing data is public ( l = 2) she submits tx ′ ( i ) as is; otherwise,if it is private ( l = 3), she submits tx ′′ ( i, j ) = [ ENC ( x i,j , γ ξ j )]. If P i still fails tosubmit her on-chain transaction in time, any participant P m may file a complaint cm ′ ( m, i, l ) against her. a Note that these complaints would require submitting data on-chain and mightinvoke interactive arbitration, as exemplified in App. C.3.ational Threshold Cryptosystems 25 arbitration and the interactive arbitration in terms of gas consumption. We em-phasize that all Ω ( n ) complaints can be arbitrated in the spirit of this approach.Consider the case where participant j received from participant i the sub-share x i,j and the commitments X i,k for k = 0 , . . . , t (all signed by i ). Participant j then performs the following verification: g x i,j = t Y k =0 (cid:0) X i,k (cid:1) j k (1)In the case of failure, j submits a complaint transaction against i : cm ′ ( j, i ).This initiates a dispute stage between j (the “prover”) and i (the “challenger”),where the contract takes the role of the arbitrator.Settling the dispute naively would require j to submit to the contract both, i ’s commitments and the sub-share x i,j . Then, the contract would verify equa-tion 1 and determine whether the complaint was just. However, this approachconsumes storage and computation linearly in t and would be unsustainable overEthereum. Moreover, we put special attention on elliptic curve operations [23]which are extremely expensive—while a sustainable arbitration procedure mightconsume O ( log ( t )) on-chain resources, it should however reduce elliptic curvecomputations to minimum. We propose the interactive approach in Fig. 4 whichsatisfies the above requirements (in particular, it requires only O (1) elliptic curvecomputations). Claim.
Given that equation 1 does not hold and that the prover j follows herinstructions in Fig. 4, then her complaint is ruled just. Conversely, if the equa-tion does hold and the challenger i follows her instructions in Fig. 4, then j ’scomplaint is ruled unjust.Before heading to the proof, we note that the repetitive procedure in step2 employs a binary search between the parties to find where they first disagreein the right-hand side computation of equation 1. By the end of step two, theparties’ dispute is reduced to one of the following cases:1. Case 3.(a) illustrates the scenario in which the parties agree on some ζ ( l )but disagree on ζ ( l + 1) for 0 ≤ l ≤ t −
1. Then, the contract calculates ζ ( l + 1) from ζ ( l ) and X i,l +1 (where the latter is supplied to the contract by j and must be signed by i ). If the value ζ ( l + 1) that the contract calculatedconflicts with ζ i ( l + 1) then the complaint is ruled just. Otherwise, it is ruledunjust.2. Case 3.(b) illustrates the scenario in which the parties disagree on ζ (0).Then, if j supplies the contract with X i, , signed by i , which conflicts with ζ i (0) then the complaint is ruled just. Otherwise, it is ruled unjust.3. Case 3.(c) illustrates the scenario in which the parties agree on ζ ( t ). Then, if j supplies the contract with x i,j , signed by i , where g x i,j conflicts with ζ i ( t )then the complaint is ruled just. Otherwise, it is ruled unjust. Fig. 4:
Interactive sub-share complaint
Let j be the prover and i be the challenger.(a) As a preparatory step each of the parties computes locally: ζ ( m ) = m Y k =0 (cid:0) X i,k (cid:1) j k for m = 0 , . . . , t We denote by ζ i ( ∗ ) and ζ j ( ∗ ) the values i and j compute respectively.(b) The dispute phase progresses in rounds, where in each round, i and j interactby submitting transactions to the contract in turns a . The contract’s state isinitialized: l ← − h ← t + 1. While h − l > m = l + (cid:6) h − l (cid:7) .(b) i submits to the contract ζ i ( m ). The contract updates: last ← ζ i ( m ).(c) j submits to the contract the bit β where: β = ( ‘ agree ‘ if ζ i ( m ) = ζ j ( m )‘ disagree ‘ otherwiseIf β = ‘ agree ‘, the contract updates: highest agree ← last , l ← m .Otherwise, the contract updates: lowest disagree ← last , h ← m .(c) Once the stopping condition is met, h = l + 1, and there are three possiblecases:i. If l > − h < t + 1, j submits to the contract X i,l +1 , signed by i .The contract verifies: highest agree · ( X i,l +1 ) j l +1 = lowest disagree ii. If l = − j submits to the contract X i, , signed by i . The contractverifies: lowest disagree = X i, iii. If h = t + 1, j submits to the contract x i,j , signed by i . The contractverifies: highest agree = g x i,j For each of the above cases, if the equality holds the complaint is ruledunjust, otherwise it is ruled just. a If one of them, in her turn, fails to submit a valid transaction within a prede-termined time (block height), she forfeits the dispute and loses her deposit.
Proof.
First assume equation 1 does hold but j complains. We show that thecomplaint is ruled unjust. During step 2, j must admit one of the followingstrategies:1. If j at some point agrees and at another point disagrees, then we are incase 3.(a), and from the assumption that i follows her instructions correctly, ζ i ( l ) = Q lk =0 (cid:0) X i,k (cid:1) j k , j must supply the contract with X i,l +1 (from the ational Threshold Cryptosystems 27 assumption that equation 1 holds). Indeed, since ζ i ( l + 1) = Q l +1 k =0 (cid:0) X i,k (cid:1) j k the contract would compute ζ ( l + 1) = ζ i ( l + 1) and rule that the complaintis unjust.2. If j always disagrees, then we are in case 3.(b) and from the assumption that i follows her instructions correctly, ζ i (0) = X i, . j must supply the contractwith X i, (from the assumption that equation 1 holds). Indeed, since ζ i (0)does not conflict with X i, the contract rules that the complaint is unjust.3. If j always agrees, then we are in case 3.(c) and from the assumption that i follows her instructions correctly and that equation 1 holds, ζ i ( t ) = g x i,j . j must supply the contract with x i,j and the contract computes g x i,j . Indeed,since ζ i ( t ) does not conflict with g x i,j the contract rules the complaint unjust.In the other direction, we show that if equation 1 does not hold and j com-plains, then the complaint is ruled just. During step 2, i must admit one of thefollowing strategies:1. If i always submits ζ ( m ) then j will always agree and step 2 ends in case3.(c). From the assumption that the equation 1 does not hold, once j submits x i,j and the contract computes g x i,j , it finds a mismatch with ζ ( t ) and rulesthat the complaint is just.2. If i at some point submits ζ i ( m ) = ζ ( m ) then step 2 ends in case 3.(a)or 3.(b). If i always submits ζ i ( m ) = ζ ( m ) then eventually, she submits ζ i (0) = X i, . When j submits X i, the contract rules the complaint as just.Otherwise, If i submits some ζ i ( m ) = ζ ( m ) then the interactive protocolwould find some 0 ≤ m ∗ ≤ t − ζ i ( m ∗ ) = ζ ( m ∗ ) and ζ i ( m ∗ + 1) = ζ ( m ∗ + 1). When j submits X i,m ∗ +1 the contract rules the complaint as just. ⊓⊔ We turn to analyze the computational complexity of the interactive disputeprotocol. As mentioned before, the repetitive procedure in step 2 performs abinary search over t + 1 values thus the dispute takes O (log( t )) rounds. At everyround each of the parties submits to the contract a constant amount of dataand the contract performs a constant amount of computations. Together withthe final step, where constant computations are performed, we conclude thatthe overall complexity of the dispute phase is O (log( t )) in time and space. Wefurther emphasize that elliptic curve computations occur only in step 3, henceour protocol requires only O (1) such computations in total.In Fig. 5 we show the actual gas costs of the two approaches to arbitrate thesub-share complaint—the interactive approach and the naive on-chain approach.The results are taken from a prototype implementation of the two arbitrationprocedures.We note that currently Ethereum’s block gas limit is approximately 8Mgas. Hence the naive approach would be practically infeasible to run in a smartcontract for any threshold values that are greater than t = 150. In contrast, theinteractive approach can handle very high threshold values, e.g., for t = 100 , As for September 2018.8 David Yakira, Ido Grayevsky, and Avi Asayag1 10 100 1 ,
000 10 ,
000 100 , . . . . · threshold t ga s c o s t prover (interactive)challenger (interactive)prover (naive) Fig. 5: Sub-share complaint arbitration gas costs. Two approaches are presented:a single round (naive) arbitration; an interactive multi-round arbitration.
Appendix D Incentive driven multi-round leader election
In Bitcoin, miners invest money in mining hardware, electricity and maintenancein order to participate in an ongoing PoW lottery. When elected, miners have theright to mint new bitcoins. While the mining game has proved to attract manyminers, it suffers two main problems. First, it was shown that miners, followingselfish mining and block withholding strategies [13,29], could bias the lottery totheir benefit, if they control enough of the hash power. This incentivizes minersto collude and form large mining pools. In a situation where 51% of the miningpower is in the hands of colluding miners, they can ensure 100% of the rewardsto themselves. The second problem is that mining is not a ”fair” game. Ideally,a miner’s probability of winning the lottery would be proportional to the moneythey invested. With variations in mining hardware, electricity costs and softwareadvancements like AsicBoost [21], the mining landscape in Bitcoin is far fromideal.We propose a multi-round leader election protocol, in which the leader inround r is elected according to a secret value S r , which is kept hidden until round r and is revealed only at the beginning of the round. Similarly to our lotteryexample, S r is the unique threshold signature of S r − . The leader is electedamong a set of candidates, which are also the ones producing the signature.At the start of the protocol they all engage in Escrow-DKG to generate theappropriate keys (recall that in Escrow-DKG participants are required to makea deposit to the escrow).Similarly to Bitcoin, by publishing S r the elected leader is entitled to mint ρ new coins, where in our model notations, R = ρ · e , and e is the total number ofrounds in the protocol. Once e rounds have passed, Escrow-DKG is relaunchedwith a fresh set of participants, and possibly larger deposits. This implies thatEscrow-DKG would be run over Ethereum periodically, say every week or month.It is crucial for Escrow-DKG to support a very large number of participants, n ational Threshold Cryptosystems 29 (so that it is unfeasible for one entity to control too many DKG participants).The S r s would be included in Ethereum blocks according to some predeterminedschedule (say every 40 th block). Once a new S r has been published, the electedleader would propose a sidechain block, hash-referencing the Ethereum blockthat contains S r . Obviously, the leader would also hash-chain the previous blockin the sidechain.While chain splits are definitely possible, at this point we will not elaborateas to how they might be resolved. We will say that chain splits can be addressedby following the longest chain rule, or other chain selection rules dictated byByzantine agreement protocols (e.g., PBFT [11], Tendermint [6], Casper FFG [9],or Hot-stuff [1]). We shall also say that in order to incentivize participants tofollow the chain selection rule, its logic should be enforced by the Ethereumsmart contract that serves as escrow .Chain rules aside, t + 1 colluding parties would be able to reveal the S r s inadvance and could translate this information to disproportionate rewards. Thisis also true in Bitcoin as mentioned earlier. There are a few advantages to ourapproach though. First, t can be tuned. Specifically, t could be larger than n/ S r prior to its prescribed Ethereumheight, makes the system trustworthy as long as no entity is controlling t +12 DKG participants. This would be a realistic assumption if anyone that wishedto do so could enrol to Escrow-DKG, and the total deposit, ∆ · n , would be highenough (relative to R ).Unlike in Bitcoin, in our proposal, the probability of each DKG participant tobe elected leader is equal. The only way to increase one’s probability, and thusalso her fraction of rewards, is to buy more DKG participants. Our protocolinduces a fair lottery—with a linear relationship between the sum invested andthe expectancy of rewards. Moreover, breaking this linear relationship comeswith a known and clear price tag .This scheme relies on a super-scalable DKG and the need to reconstructthreshold signatures with very large t s—this would be computationally inten-sive and would require significant communication among the participants. Oneapproach to circumvent this problem could borrow from Dfinity [22]—use manyparallel independent DKG protocols run side by side. Another approach, pre-sented in [10], generalizes on the traditional SSS-based DKG approach withindependent linear equations dictated by a matrix. Using adequate sparse ma-trices yields in highly a scalable DKG procedure (in which reconstruction has anegligible probability of failing, even if enough participants try to reconstruct). Long-range attacks could be addressed by the “social consensus” approach [8].27