Reaching Consensus for Asynchronous Distributed Key Generation
Ittai Abraham, Philipp Jovanovic, Mary Maller, Sarah Meiklejohn, Gilad Stern, Alin Tomescu
aa r X i v : . [ c s . D C ] F e b Reaching Consensus for Asynchronous Distributed Key Generation
ITTAI ABRAHAM,
VMware Research, Israel
PHILIPP JOVANOVIC,
University College London, United Kingdom
MARY MALLER,
Ethereum Foundation, United Kingdom
SARAH MEIKLEJOHN,
University College London, United Kingdom and Google, United Kingdom
GILAD STERN,
The Hebrew University in Jerusalem, Israel
ALIN TOMESCU,
VMware Research, USA
We give a protocol for Asynchronous Distributed Key Generation (A-DKG) that is optimally resilient (can withstand π < π faultyparties), has a constant expected number of rounds, has Λ π ( π ) expected communication complexity, and assumes only the existenceof a PKI. Prior to our work, the best A-DKG protocols required Ξ© ( π ) expected number of rounds, and Ξ© ( π ) expected communication.Our A-DKG protocol relies on several building blocks that are of independent interest. We deο¬ne and design a Proposal Election(PE) protocol that allows parties to retrospectively agree on a valid proposal after enough proposals have been sent from diο¬erentparties. With constant probability the elected proposal was proposed by a non-faulty party. In building our PE protocol, we design a
Veriο¬able Gather protocol which allows parties to communicate which proposals they have and have not seen in a veriο¬able manner.The ο¬nal building block to our A-DKG is a
Validated Asynchronous Byzantine Agreement (VABA) protocol. We use our PE protocolto construct a VABA protocol that does not require leaders or an asynchronous DKG setup. Our VABA protocol can be used moregenerally when it is not possible to use threshold signatures.
In this work we study
Decentralized Key Generation in the
Asynchronous setting (A-DKG). Our protocol works inthe authenticated model, assumes a Public Key Infrastructure (PKI), obtains optimal resilience (i.e., tolerates π < π malicious parties), and terminates in π ( ) expected rounds using just Λ π ( π ) expected words , where a word can containa constant number of values and cryptographic signatures. Previously, the best protocol for A-DKG with optimalresilience is by Kokoris-Kogias, Malkhi, and Spiegelman [28] and it requires Ξ© ( π ) expected number of rounds and Ξ© ( π ) expected number of words.A DKG protocol allows a set of π parties to collectively generate a public key such that its corresponding secret key issecret-shared between all π parties. Actions that require the secret key such as decrypting or signing can be performedby any π + π or fewer. Unlike in secret sharing protocols, there is no trusted dealer. Twokey applications of DKGs are threshold encryption and threshold signature schemes. Threshold encryption can be usedto restrict employeesβ access to databases or to decrypt election results. Threshold signatures can be used to implementrandom beacons [31], reduce the complexity of consensus algorithms [3], or more recently to outsource managementof secrets on a public blockchain to multiple, semi-trusted authorities [27]. One of the challenges in constructing aDKG is that there might be multiple DKG transcripts that would pass veriο¬cation, and parties must agree on whichDKG transcript to eventually use in their application. This ultimately boils down to a consensus problem in whichno preprocessing is possible. In this work, we are interested in improving the consensus layer of DKG protocols. We Authorsβ addresses: Ittai Abraham, VMware Research, Herzliya, Israel; Philipp Jovanovic, University College London, London, United Kingdom; MaryMaller, Ethereum Foundation, London, United Kingdom; Sarah Meiklejohn, University College London, London, United Kingdom, Google, London,United Kingdom; Gilad Stern, The Hebrew University in Jerusalem, Jerusalem, Israel; Alin Tomescu, VMware Research, Palo Alto, CA, USA. Abraham et al.are careful to avoid the use of any primitive that requires reaching agreement on the output of a DKG (e.g., thresholdsignatures) in order to instantiate our consensus algorithm.Kate, Huang, and Goldberg [25] observed in an inο¬uential paper that many DKGs are unsuitable for use over theInternet due to their reliance on synchrony assumptions and time-outs. Unstable communication channels are commonover the Internet and it is hard to be certain that all players in the system will have seen all messages before moving ontothe next round. Kate et al. [25] presented a weakly-synchronous DKG with π ( π ) complexity. However, their solutionrelies heavily on leaders who may be adaptively targeted, and they still require time-outs to distinguish optimisticscenarios from worst-case scenarios. Recently Kokoris-Kogias et al. [28] presented a fully asynchronous solution whichis leaderless and has π ( π ) expected communication complexity. The actions of honest parties in their protocol areevent-driven and there are no timeouts.In this work, we are able to improve on the results of Kokoris-Kogias et al. We design a fully asynchronous consensusalgorithm for reaching agreement on the outcome of a DKG that is leaderless and has Λ π ( π ) complexity. Our solutionis secure under the presence of Byzantine adversaries that may corrupt fewer than π parties. Our results are achievedwithout the use of binary agreements, which is one of the reasons why we are able to improve complexity. We see thisas an important improvement in the design of DKGs that are suitable for use over the Internet as well as a small steptowards removing the βslowβ connotation from the word βasynchronousβ. Our primary contributions are as follows: β’ Assuming a PKI setup, we present a protocol for solving Asynchronous Distributed Key Generation, that isresilient to π < π Byzantine parties, and runs in expected π ( ) rounds, where the non-faulty parties send anexpected Λ π ( π ) words. β’ We present a new
Validated Asynchronous Byzantine Agreement (VABA) protocol that uses a PKI but does not use a DKG. Our new VABA protocol can reach agreement on inputs of size π words, in π ( ) expected rounds,using just Λ π ( ππ + π ) expected words, and is resilient to an adversary controlling at most π < π parties. OurVABA protocol is the key building block in obtaining our A-DKG. β’ We deο¬ne and instantiate a new primitive which we call a
Proposal Election (PE) protocol. Our proposal electionallows us to avoid relying on leaders. Roughly speaking, in Proposal Election, every party inputs some externallyvalid value and, with constant probability, all parties output the same value that was proposed by a non-faultyparty. Our Proposal Election runs in π ( ) rounds and Λ π ( π ) words and is the key building block in obtainingour VABA protocol. β’ We deο¬ne and instantiate an extension of the Gather primitive by Canetti and Rabin [1, 17, 21] to a
Veriο¬ableGather protocol. Our veriο¬able gather protocol guarantees the existence of some core set, such that all partiesoutput some veriο¬able super set of this core. To limit the adversary, only outputs that contains this core passveriο¬cation. Our veriο¬able gather is the key building block in obtaining our proposal election.
We obtain our A-DKG using a combination of two advances. The ο¬rst is a recent
Aggregatable Publicly Veriο¬able SecretSharing (APVSS) scheme by Gurkan et al. [23] that uses a PKI. The second is a
Validated Asynchronous ByzantineAgreement (VABA) protocol (as deο¬ned by Cachin, Kursawe, Petzold, and Shoup [14]) that uses a PKI but does not useeaching Consensus for Asynchronous Distributed Key Generation 3a DKG, which is new to this paper. Without a DKG, all previous constant expected time agreement protocols had torely on a weak abstraction (that has a constant probability of error) of coin tossing: Feldman and Micali for synchrony[20] and Canetti and Rabin for asynchrony [17]. Our work is also based on this paradigm of using a weak buildingblock. At ο¬rst sight it may seem that π ( π ) words is the best one can hope for in this paradigm. To obtain an A-DKGwith expected Λ π ( π ) word complexity, we identify three barriers, which this work overcomes using novel techniques. First barrier: aggregate many secret sharings.
Even in synchronous settings, the weak coin of [20] requires π + π β π of the parties. If each secret requires a separate Veriο¬able Secret Sharing (VSS) invocation,we get Ξ© ( π | π ππ |) word complexity where | π ππ | is the word complexity of VSS. Since VSS, whether asynchronous ornot, requires | π ππ | = Ξ© ( π ) words [5, 19], we get Ξ© ( π ) just to attach enough secrets to enough parties. To overcomethis barrier we use an Aggregatable PVSS [23], which allows to attach Ξ© ( π ) secrets to Ξ© ( π ) parties using just π ( π ) Reliable Broadcasts [11, 16] of π ( π ) -sized APVSS transcripts for a total of Λ π ( π ) word complexity. Second barrier: Weak Common Coin is too weak.
Suppose every party can have a random secret sharing attached toit using a total of Λ π ( π ) words. In the classic Binary Asynchronous Byzantine Agreement protocol, these secrets aretranslated to a weak binary common coin and this coin is used to break ties in case that not all parties have the sameinput. The challenge for a VABA protocol aiming for π ( ) expected time is the need to randomly elect an externallyvalid proposal with constant probability. Using a weak common coin to do this election seems challenging. Considerthe case where the externally valid inputs are π ( π ) bits long. We do not know of any way to elect a valid proposalwith constant probability using a weak common coin (for example, one could use log π coins to elect a leader, but dueto the constant error probability this will have an error probability that is polynomially close to one).We suggest a new approach that bypasses the weak coin abstraction. Instead, we proceed to extend the Gatherprimitive of Canetti and Rabin [1, 17, 21] to a Veriο¬able Gather protocol. Recall that a Gather protocol does not solveconsensus but instead guarantees the existence of some core set, such that all parties output some super set of thiscore. Roughly speaking, the goal of our new Veriο¬able Gather primitive is to introduce a veriο¬cation protocol toessentially force the adversary to also only output super sets of this core (in the sense that other outputs will not passthe veriο¬cation).We show how to combine Veriο¬able Gather with random secret sharing [28] and an eο¬cient Reliable Broadcast[11, 12, 16] to obtain a new primitive we call Proposal Election. Roughly speaking, in Proposal Election, every partyinputs some externally valid value, and with constant probability, all parties output the same value that was proposedby a non-faulty party. Our Proposal Election runs in π ( ) rounds and Λ π ( π ) words.Conceptually, our Proposal Election abstraction can be viewed as the validated (multi-valued) generalization ofthe weak common coin approach. Technically, our Proposal Election (PE) exposes a new validation abstraction thateο¬ciently enables electing a common externally valid value with constant probability. Crucially, parties can also verifythat other parties provide the uniquely elected value if the election process succeeded. This signiο¬cantly limits theadversaryβs behaviour and forces it to essentially act honestly or remain silent. Third barrier: eο¬cient VABA, using PE.
Our ο¬nal challenge for asynchronous DKG is obtaining a VABA protocol formessages of size π (where π = Ξ ( π ) words, is the size of a PVSS) using PE at a cost of just Λ π ( ππ + π ) = Λ π ( π ) wordsper view and just π ( ) expected views (due to the constant success probability of PE), where each view consists of justa constant number of rounds. There are two natural approaches. The ο¬rst is to use known optimally resilient validatedmulti-valued techniques from known VABA protocols. Unfortunately, the known VABA protocols of Cachin, Kursawe, Abraham et al.and Shoup [15] and Abraham, Malkhi, and Spiegelman [3] require a DKG where all parties agree on the output (exceptfor negligible error) and do not seem to work with the constant error probability of PE. The work of Cachin et al. [13]uses an existing DKG to refresh to a new DKG using Ξ© ( π ) words. The work of Lidong et al. [33] suggest a refreshprotocol with exponentially high communication complexity.The second natural approach is to use binary agreement techniques. Indeed, the application of Brachaβs consensustechnique [11] (with our PE protocol) requires Ξ© ( π ) invocations of Reliable Broadcast per bit, for a total of Ξ© ( ππ ) = Ξ© ( π ) words when π = Ξ© ( π ) (and this solution only obtains weak validity).We overcome this third barrier with a new consensus protocol called No Waitinβ HotStuο¬ (NWH). As its nameimplies, NWH is a new member of the HotStuο¬ family of consensus protocols [3, 4, 29, 32] which obtains Λ π ( π + ππ ) expected words and π ( ) expected rounds in the asynchronous setting, using PE, and without relying on a DKG.Intuitively, in each view of NWH, a new invocation of PE is used as a "virtual leader". For safety, NWH uses the by-now-standard Key-Lock-Commit paradigm of HotStuο¬ [3, 32]. The main novelty of NWH is in its liveness guaranteesand its ability to change view in asynchrony in a constant number of asynchronous rounds even if the "virtual leader"acts maliciously. NWH obtains liveness in full asynchrony using our PEβs properties and a new mechanism that forcesparties (even malicious parties) to essentially send only validated responses. In case of a non-faulty "virtual leader",the PE properties guarantee that all non-faulty parties see the same output from the leader and that this input was aninput of a non-faulty party. In this case, the NWH protocol forces the faulty parties to essentially only act as omission-faulty (hence a decision is guaranteed to be reached in such a view). In case of a faulty "virtual leader", the PE propertiesguarantee that all non-faulty parties eventually see some output from the leader (might not be the same), and the NWHprotocol guarantees that only a safe decision will be made or, if none can be reached, eventually a view change willoccur. The combination of NWH with the constant probability of success for PE guarantee termination in an expectedconstant number of asynchronous rounds. NWH manages to obtain these safety and liveness properties to obtaina VABA protocol for messages of size π words with Λ π ( ππ + π ) expected message complexity and π ( ) expectedrounds. A Note on Adaptive Adversaries.
All our results hold for a static adversary. However, we note that given an aggregat-able PVSS scheme that is secure against adaptive adversaries, our VABA protocol and therefore our A-DKG protocolwould also be secure against adaptive adversaries. This is the same type of reduction as in [3, 15] where the protocolis adaptivly secure if its underlying cryptographic primitives are adaptivly secure. The PVSS scheme of [23] is onlyproved security in the static model. Obtaining an adaptively-secure aggregatable PVSS remains an open question.
Our work assumes a PKI and obtains a Validated ABA protocol. However, many of our techniques can be seen as (non-trivial) extensions of the work done in the information theoretic model (where there are private channels, but no PKInor any computational bounds on the adversary). In the information theoretic model, the natural validity property isweaker and it is natural to focus on the binary case. Any solution for consensus in the asynchronous model must haveinο¬nite executions [22]. Ben-Or [8] showed how randomization can be used to obtain a ο¬nite expected running timeand Bracha [11] showed how to do this with optimal resilience. Reducing the expected number of rounds to a constantwas obtained by Canetti and Rabin [17]. They provide the ο¬rst ABBA with optimal resilience and constant expectedtime. It requires at least Ξ© ( π ) words in expectation (possibly more, but we did not verify). This was improved byPatra, Choudhary, and Rangan [30] to expected Λ π ( π ) words for ABBA. The protocols of Canetti and Rabin [17], theireaching Consensus for Asynchronous Distributed Key Generation 5extensions and those that rely on cryptographic assumptions all have a non-zero probability of non-termination. Inthe information theoretic setting it is possible to eο¬ciently solve Asynchronous Binary Byzantine Agreement (ABBA) with optimal resilience and zero probability of non-termination [2], and this can be done with just Λ π ( π ) expectedwords and π ( π ) rounds [6].The veriο¬able weak proposal election primitive is an extension of the idea of a weak common coin, which wasintroduced in the synchronous setting by Feldman and Micali[20]. A weak common coin is a primitive simulating acommon shared randomness source. The coin is weak in the sense that with some probability the parties might notagree on the value. Feldman later extended this result to the asynchronous setting [21]. Katz and Koo improve on thesynchronous result [26].A DKG can be viewed as a speciο¬c form of a Multi-Party Computation (MPC) protocol. In that sense, the work ofBen-Or et al. [9] obtains perfect security for π > π and the work of Ben-Or et al. [10] obtains statistical securityand optimal resilience of π > π . Both protocols use ABBA as a building block and have very high word complexity.Modern MPC protocols in the asynchronous model use a DKG [7, 18, 24], so they could beneο¬t from the results of ourwork. This work deals with protocols for π parties with point-to-point communication channels. The network is assumed tobe asynchronous, which means that there is no bound on message delay, but all messages must arrive in ο¬nite time. Theprotocols below are designed to be secure against a Byzantine adversary controlling up to π < π parties. This work usesseveral cryptographic assumptions as "prefect" black-boxes, meaning we assume that an adversary cannot break them.As described in [3, 14, 15], with high probability all protocols require polynomially many uses of the cryptographicprimitives, so the protocols remain secure in the face of a computationally bounded adversary with all but a negligibleprobability. As described in the introduction, the protocols themselves are secure against adaptive adversaries givenan instantiation of the cryptographic primitives which is secure against such an adversary. However, currently thereare no known adaptively secure instantiations for all of the primitives we require. Similar to the protocols of [3, 15],the protocols presented can be seen as reductions from one task to another that preserve security against adaptiveadversaries. A Reliable Broadcast is an asynchronous protocol with a designated dealer . The dealer has some input value π fromsome known domain M and each party may output a value in M . A Reliable Broadcast protocol has the followingproperties assuming all nonfaulty parties participate in the protocol: β’ Validity.
If the dealer is nonfaulty, then every nonfaulty party that completes the protocol outputs the dealerβsinput value, π . β’ Agreement.
If two nonfaulty parties output some value, then itβs the same value. β’ Termination.
If the dealer is nonfaulty, then all nonfaulty parties complete the protocol and output a value.Furthermore, if some nonfaulty party completes the protocol, every nonfaulty party completes the protocol.A
Validated Reliable Broadcast protocol is a Reliable Broadcast protocol variant where each party has access to a com-mon validate function, validate : M β { , } . We say that π β M is externally valid if validate ( π ) =
1. In a Validated Abraham et al.Reliable Broadcast protocol, the dealer has an externally valid input. A Validated Reliable Broadcast protocol has thefollowing additional property: β’ External Validity.
If a nonfaulty party outputs a value, then this value is externally valid.See Appendix A for a Reliable Broadcast protocol and a Validated Reliable Broadcast protocol with word complexityof Λ π ( π + ππ ) , where π is the number of words in any value in M . Gather is a natural multi-dealer extension of Reliable Broadcast where every party is also a dealer. The output of agather protocol is a gather-set . A gather-set consists of at least π β π pairs ( π, π₯ ) , such that π β [ π ] , π₯ β M , and eachindex π appears at most once. For any given gather-set π , we deο¬ne its index-set πΌππππππ ( π ) = { π |β( π, π₯ ) β π } to bethe set of indices that appear in π .Intuitively speaking, the goal of Gather is to have some common core gather-set such that all parties output asuper-set of this core. Note that a Gather protocol does not solve consensus and diο¬erent parties may output diο¬erentsuper-sets of the core. For Veriο¬able Gather , the goal is to limit the power of the adversary to generate inconsistentoutputs. Intuitively, for any gather-set produced by the adversary, if it passes some veriο¬cation protocol , it must alsobe a super-set of the common core.Formally, a veriο¬able gather protocol consists of a pair of protocols ( Gather , Verify ) and takes as input an externalvalidity function validate which all parties have access to. For Gather , each party π β [ π ] has an externally valid input π₯ π . Each party may decide to output a gather-set π π . After outputting the gather-set, parties must continue to updatetheir local state according to the Gather protocol in order for the veriο¬cation protocol to continue working.The properties of
Gather (assuming all nonfaulty start): β’ Binding Core.
Once the ο¬rst nonfaulty party outputs a value from the
Gather protocol there exists a coregather-set π β such that if a nonfaulty party π outputs the gather set π π , then π β β π π . β’ Internal Validity. If ( π, π₯ ) β π β and π is nonfaulty at the time the ο¬rst nonfaulty party completed the Gather protocol, then π₯ is the input of party π in Gather . β’ Termination of Output.
All nonfaulty parties eventually output a gather-set.The
Verify protocol receives an index-set πΌ and outputs a gather-set π such that πΌππππππ ( π ) = πΌ . It performs twoactions at once: it veriο¬es that the index set includes the indices of the binding core, and recovers the gather-set onlyfrom the indices and the internal state of the verifying party. This allows parties to send relatively small index-setsinstead of large gather-sets over the network. The veriο¬cation protocol limits the adversary to a very narrow set ofbehaviours, so that any veriο¬able gather-set must contain the Binding core gather-set π β . A party π can check anyindex-set πΌ , which we denote by executing Verify π ( πΌ ) . If the execution of Verify π ( πΌ ) terminates and outputs a value, wesay that π has veriο¬ed the index-set πΌ .The termination properties of Verify (given that all nonfaulty start
Gather ): β’ Completeness.
For any two nonfaulty parties π, π , if π outputs π π from Gather , then for every nonfaulty π , Verify ( πΌππππππ ( π π )) eventually terminates with the output π π . β’ Agreement on Veriο¬cation.
For any two nonfaulty π, π , and any index-set πΌ , if Verify π ( π ) terminates with theoutput π then Verify π ( πΌ ) eventually terminates with the output π .The correctness properties of the Verify protocol:eaching Consensus for Asynchronous Distributed Key Generation 7 β’ Agreement.
All nonfaulty parties agree on values with common indexes. For any two nonfaulty π, π , and anyindex-sets
πΌ, π½ , if
Verify π ( πΌ ) terminates with the output π and Verify π ( π½ ) terminates with the output π , and ( π, π₯ ) β π, ( π, π¦ ) β π , then π₯ = π¦ . β’ Includes Core. If Verify π ( πΌ ) terminates with the output π , then the gather-set π contains the binding coregather-set π β (as deο¬ned in the Binding Core property of Gather ). β’ External Validity. If Verify π ( πΌ ) terminates with the output π for some nonfaulty π , then for each ( π, π₯ ) β π ,the value π₯ is externally valid.Observe that the Includes Core and Completeness properties say that not only do all nonfulaty output a gather-setthat includes the core but that any gather-set that passes veriο¬cation contains the core π β . A perfect proposal election would allow each party to input a proposal and then have all parties output one commonrandomly elected proposal.
Proposal Election (PE) is an asynchronous protocol that tries to capture this spirit but obtainsweaker properties. Intuitively, there is only a constant probability that the output of PE is one common randomlyelected proposal coming from a nonfaulty proposer. As in the Veriο¬able Gather (VG) protocol, we also add a veriο¬cationprotocol. Crucially, in the good event mentioned above, the only value that passes veriο¬cation is this common electedproposal. In the remaining cases, the adversary can control the output and even cause diο¬erent parties to have diο¬erentoutputs. However, even in these cases we force the adversary to allow all parties to eventually output some verifyingvalue. This PE is weak enough to be eο¬ciently implementable and we will later show that it is strong enough to enablean eο¬cient constant expected round VABA protocol.As in VG, we assume a domain M and we are externally given a function validate that given any message π₯ β M can check the external validity of π₯ . A Proposal Election protocol consists of a pair of protocols ( PE , Verify ) . Eachnonfualty party π starts with an externally valid input π₯ π to PE . The output of the PE protocol is a pair ( π₯, π ) where π₯ β M and π is a proof used in the Verify protocol. We model these protocols as having some ideal write-once state π₯ β . We assume β₯ is not externally valid and let π₯ β β M βͺ {β₯} . Intuitively, if π₯ β β β₯ then the output of all parties willbe π₯ β , but when π₯ β = β₯ then the adversary can cause diο¬erent parties to output diο¬erent verifying values. β’ πΌ - Binding . For any adversary strategy, with probability πΌ , π₯ β is set to an input of a party that behaved in anonfaulty manner when it started the PE protocol.In addition, the PE protocol has a natural termination property (assuming all nonfaulty start): β’ Termination of Output.
All nonfaulty parties eventually output a pair ( π₯, π ) .A party π can check any pair of proposal and proof, ( π₯, π ) , which we denote by executing Verify π ( π₯, π ) . If theexecution of Verify π ( π₯, π ) terminates, we say that π has veriο¬ed π₯ . If the binding value π₯ β is not β₯ , then the only valuefor which the verify protocol can terminate is π₯ β . This limits the adversary to essentially either either reporting π₯ β , orremaining silent. The termination properties of Verify (given that all nonfaulty start PE ): β’ Completeness.
For any two nonfaulty π, π , the output ( π₯, π ) of party π from PE will eventually be veriο¬ed byparty π , i.e. Verify π ( π₯, π ) eventually terminates. β’ Agreement on Veriο¬cation.
For any two nonfaulty π, π , and any value π₯ and proof π , if Verify π ( π₯, π ) terminatesthen Verify π ( π₯, π ) eventually terminates.Finally, the correctness properties of Verify : Abraham et al. β’ Binding Veriο¬cation. If π₯ β β β₯ then for every nonfaulty party π , and every ( π₯, π ) , if Verify π ( π₯, π ) terminatesthen π₯ = π₯ β . β’ External Validity. If Verify π ( π₯, π ) terminates then the value π₯ is externally valid.We note that in the computational setting all these properties hold with all but negligible probability. In a Validated Asynchronous Byzantine Agreement protocol, there is some external validity function that every partyhas access to. Each nonfaulty party π starts with some externally valid input π₯ π and on termination must output a value.A Validated Asynchronous Byzantine Agreement protocol has the following properties (assuming all nonfaulty start): β’ Agreement.
All nonfaulty parties that complete the protocol output the same value. β’ Validity.
If a nonfaulty party outputs a value then it is externally valid. β’ πΌ -Quality. With probability πΌ , the output value is chosen as one of the inputs π₯ π (party π was nonfualty whenit started the protocol). β’ Termination.
Except for a negligible probability, all nonfaulty parties terminate in a ο¬nite (in fact constant)expected number of rounds.
This work introduces a novel distributed consensus algorithm which uses several cryptographic tools as black-boxes.In Section 7 we discuss how these tools can be instantiated with respect to tools that currently exist in the literature andevaluate the eο¬ciency of our protocol with respect to these tools. The instantiations of the cryptographic abstractionsin this paper are all assumed from prior work, with the exception of an ADKG protocol, which we deο¬ne in this sectionand construct in Section 6.
A distributed key generation algorithm is a method to generate public keys forthreshold systems without a trusted third party. It is assumed that the aggregation and veriο¬cation algorithms keepstate consisting of each partyβs public key. A DKG consists of the following algorithms. β’ DKGSh ( sk π ) β¦β dkgshare : A probabilistic algorithm run by Party π that takes as input a secret key and outputsa DKG share . The share also contains a description of the party who sent it. β’ DKGShVerify ( pk π , dkgshare ) β¦β { , } : A deterministic algorithm run by Party π that returns 1 if it is convincedthat the DKG share of Party π is valid. β’ DKGAggregate (D) β¦β dkg : An algorithm run by Party π that takes as input a set D containing at least 2 π + DKG transcript . β’ DKGVerify ( dkg ) β¦β { , } : A deterministic algorithm that returns 1 if and only if the DKG transcript containsDKG shares that pass veriο¬cation from at least 2 π + π parties are corrupted, a threshold scheme under the DKG retains all properties of the standard schemeeaching Consensus for Asynchronous Distributed Key Generation 9under the key generation algorithm. For the sake of this paper we only formally deο¬ne security preservation for ourthreshold veriο¬able random function and instead refer to [23] for a full deο¬nition of security preservation. Definition 1.
An Asynchronous Distributed Key Generation protocol has the following properties: β’ Security Preservation.
A threshold scheme under the DKG retains all the properties of the standard scheme underthe key generation algorithm, provided no more than π parties are corrupted. β’ Correctness.
We have that:
DKGShVerify ( pk π , DKGSh ( sk π )) = Assume that every dkgshare π β D is such that DKGShVerify ( pk π , dkgshare π ) = . Then DKGVerify ( DKGAggregate (D)) = . An asynchronous DKG, which is the topic of this paper, is an interactive protocol allowing all parties to output thesame aggregated DKG transcript. Since the network is asynchronous, it is also important to make sure that the partieseventually complete the protocol. Therefore, an
π΄π·πΎπΊ protocol has the following two properties if all nonfaulty partiesparticipate in it: β’ Agreement.
All parties that terminate output the same DKG , dkg , such that
DKGVerify ( dkg ) = β’ Termination.
All nonfaulty parties eventually terminate.
A threshold veriο¬able random function (VRF) is an algorithm such that ( π + ) parties can compute the output of the random function π on some input, but π cannot. A threshold VRF mustbe unbiasable ( π parties cannot guess even a single bit of the outcome), and robust ( π + ( DKGSh , DKGShVerify , DKGAggregate , DKGVerify ) deο¬ned above, a threshold VRF consists of thefollowing algorithms: β’ π ( vrf _ dkg ,π ) β¦β { , } π : A deterministic function that takes in a DKG transcript (which implicitly deο¬nes asecret key) and a message, and outputs a binary string. We have that π cannot be computed by less than π + β’ EvalSh ( vrf _ dkg , sk π ,π ) β¦β ( π π ( π ) , π π ) : A probabilistic algorithm run by Party π that takes as input a DKGtranscript, a secret key, and a message and returns an evaluation share and a proof share . Here π π is used todenote that this is a share of π ( π ) as opposed to the full evaluation (likewise π π ). The share also contains adescription of the party who sent it. β’ EvalShVerify ( vrf _ dkg , pk π , π, π π ( π ) , π π ) β¦β { , } : A deterministic algorithm run by Party π that takes as inputa VRF-DKG transcript, a public key, a message, an evaluation share, and a proof share from Party π and returns0 / β’ Eval ( vrf _ dkg ,π, F ) β¦β ( π ( vrf _ dkg ,π ) , π ) : An algorithm that takes as input a DKG transcript, a message, anda set F that contains evaluation and proof shares from π + β’ EvalVerify ( vrf _ dkg ,π, π ( vrf _ dkg ,π ) , π ) β¦β { , } : A deterministic algorithm that takes as input a DKG tran-script, a message, a function evaluation and a proof. It outputs 0 / Definition 2.
A Threshold Veriο¬able Random Function has the following properties: β’ Unbiasability.
The function π ( vrf _ dkg , π ) is distributed uniformly at random over all verifying DKGs and themessage space M . Let vrf _ dkg be an aggregated DKG transcript such that DKGVerify ( vrf _ dkg ) = . Then as longas no nonfaulty party computes EvalSh ( vrf _ dkg ,π ) , then the adversary cannot guess a single bit of π ( vrf _ dkg , π ) . β’ Uniqueness.
For each vrf _ dkg ,π , there is a single value π£ = π ( vrf _ dkg ,π ) such that there exists π with EvalVerify ( vrf _ dkg , π, π£, π ) = . β’ Correctness.
We have that:
EvalShVerify ( vrf _ dkg , pk π , π, EvalSh ( vrf _ dkg , sk π ,π )) = Assume that every ( π π ( vrf _ dkg ,π ) , π π ) β F is such that EvalShVerify ( vrf _ dkg , pk π , π, π π ( vrf _ dkg , π ) , π π ) = .Then EvalVerify ( vrf _ dkg ,π, Eval ( vrf _ dkg ,π, F )) = . Unbiasability also assumes that no honest party has sent a reconstruction share for vrf _ dkg . We have chosen not toexplicitly state this in the deο¬nition because we have omitted a description of a reconstruction algorithm for the DKG.When the purpose of the DKG is to generate a public key for a threshold VRF, no reconstruction takes place. A vector commitment is used to bind a party to a vector, such that they can later provablyreveal any position in the vector. A vector commitment consists of the following algorithms. β’ Commit ( π£ ) β¦β π : Takes as input a vector π£ and outputs a commitment π . β’ OpenProve ( π, π£, π ) β¦β π : Takes as input a commitment π to a vector π£ and an evaluation point π . Outputs a proofthat the π th entry of π£ is π£ π . β’ OpenVerify ( π, π£ π , π, π ) β¦β / π , an opening π£ π , anevaluation point π and a proof π . It outputs 1 if it is convinced that the π th entry of the vector committed in π is π£ π and 0 otherwise.In this work we only require the vector commitment to satisfy binding i.e. that an adversary cannot open a commit-ment to more than one value at any evaluation point. It does not necessarily need to be hiding. β’ Correctness. β vectors π£ , β positions π , we have OpenVerify ( Commit ( π£ ) , π£ π , π, OpenProve ( π, π£, π )) = . β’ Binding.
No adversary can compute a commitment π , an evaluation point π , two values π£ π and π€ π with π£ π β π€ π ,and two proofs π π£ and π π€ such that OpenVerify ( π, π£ π , π, π π£ ) = OpenVerify ( π, π€ π , π, π π€ ) = . As part of our proposal election protocol we require a βreliable gatherβ. Throughout the protocol, parties reliablybroadcast values, which are later used to choose a winning proposal from among them. Ideally, we would like theparties to agree on an exact set of parties and broadcasted values in order to make sure that they all elect a valuefrom the same set. However, exactly agreeing on the set is non-trivial and potentially expensive. Therefore we slightlyrelax our requirements: there exists some core πΆ of size π β π or greater such that the output of every nonfaulty partyeaching Consensus for Asynchronous Distributed Key Generation 11contains πΆ . Furthermore, we would like parties to be able to prove that they βacted correctlyβ and included πΆ in theiroutput.Throughout the protocol, parties broadcast messages using the Reliable Broadcast protocol π π΅ and validated broad-cast messages using the Validated Reliable Broadcast protocol π π π΅ . In a slightly inaccurate high-level view, the protocoltakes place in three rounds. In the beginning, all parties broadcast their inputs and wait to receive π β π broadcasts fromother parties. After receiving those broadcasts, they broadcast sets of tuples containing values and the parties who sentthem in the previous round. They then wait to receive π β π such sets, checking if the sets report the correct values.After receiving π β π of those sets, every party broadcasts the union of all of the reported sets. Finally, after receiving π β π such unions and checking that the reported sets are correct, every party outputs the union of those sets. However,when dealing with large inputs, broadcasting sets of π ( π ) values can be an unnecessarily expensive operation. In orderto avoid this overhead, parties only actually broadcast their values in the ο¬rst round. In any subsequent round, partiesonly refer to the broadcasted value by the party who sent the relevant broadcast, requiring only one word per value.More accurately the protocol can be broken into three rounds: Round 1:
In the ο¬rst round, party π validated broadcasts its input value π₯ π and waits to receive π β π valid valuesfrom all parties. Party π stores the parties from whom it received broadcasts in a set π π , and tuples of the form ( π, π₯ π ) indicating that it received the value π₯ π from π in a set π π . Round 2:
After receiving π β π values, each π broadcasts π π , which we think of as sets of the values π₯ π referencedonly by the party who sent each value. Party π then waits to receive π β π π sets from other parties, and accepts sucha message after seeing that it received a value from each party in π . After accepting a message with the set π from π , π adds π to π π . We think of π π as containing all of the π sets received from diο¬erent parties, while it actually onlyreferences each set by the party who sent it. Round 3:
Finally, once π π is of size π β π , π broadcasts π π as well and waits to receive π β π such sets. Similarly to before, π only accepts a message with a set π if it accepted all of the π messages it refers to. After accepting a set π π , π explicitlycomputes the union of all of the π sets π π is referring to in the following manner: π π = Γ π β π π π π , and stores ( π,π π ) in π π .Once π accepts π β π diο¬erent messages containing π sets and updates π π , it outputs π π which contains tuples of valuesand the parties who sent them. It is important to note that when outputting π π it contains all of the element in all ofthe sets referred to by any accepted π set, because parties wait to receive all relevant information before accepting a π or an π set. Every party continues updating its internal state even after outputting a value.In the veriο¬cation protocol for an index-set πΌ , party π checks whether π includes all of the values referred to byat least π β π of the π sets that it received and accepted. In the following discussion we show that there exists someindex π β that is included in at least π + π sets broadcasted by parties. Since every party waits to receive π setsfrom at least π β π parties before terminating, it will see at least one with that index, and thus include π π β in its output.This is true for any nonfaulty party, so π π β can serve as a common-core in the output of all nonfaulty parties. Similarly,when verifying an index-set πΌ , π makes sure that it contains the values referenced by the π sets received from at least π β π parties, and thus also includes π π β in it. Afterwards, the values corresponding to each index can easily be returnedbecause they have been previously received by broadcast.2 Abraham et al. Algorithm 1
Gather π ( π₯ π ) π π β β , π π β β , π π β β , π π β β validated broadcast h , π₯ π i with external validity function returning 1 on h π‘, π i iο¬ validate ( π ) = upon receiving h , π₯ π i from π , do π π β π π βͺ {( π, π₯ π )} , π π β π π βͺ { π } if | π π | = π β π then broadcast h , π π i upon receiving h , π π i from π such that (cid:12)(cid:12) π π (cid:12)(cid:12) β₯ π β π , do upon π π β π π , do π π β π π βͺ { π } if | π π | = π β π then broadcast h ,π π i β² π sets reference π sets upon receiving h ,π π i from π such that (cid:12)(cid:12) π π (cid:12)(cid:12) β₯ π β π , do upon π π β π π , do β² relevant π sets and values are received π π β π π βͺ {( π, Γ π β π π π π )} β² save all parties in the π sets referenced by π π if | π π | = π β π then output π π , but continue updating internal sets and sending messages Algorithm 2
GatherVerify π ( πΌ ) upon (cid:12)(cid:12)(cid:8) π |β( π,π π ) β π π ,π π β πΌ (cid:9)(cid:12)(cid:12) β₯ π β π β§ πΌ β π π , do π β {( π, π₯ ) β π π | π β πΌ } output π and terminate Lemma 1.
Assume some nonfaulty party completed the protocol. There exists some π β such that at least π + partiessent broadcasts of the form h ,π i with π β β π . Proof.
Assume some nonfaulty party completed the protocol. Before completing the protocol, it found that | π π | β₯ π β π , and thus it received π β π broadcasts of the form h ,π π i such that (cid:12)(cid:12) π π (cid:12)(cid:12) β₯ π β π . Let πΌ be the set of parties who sentthose broadcasts. Now assume by way of contradiction that every index π appears in at most π of the broadcasted sets π π such that π β πΌ . Since there are a total of π possible values, this means that the total number of elements in all setsis no greater than ππ . On the other hand, there are π β π such sets, each containing π β π elements or more, resultingin at least ( π β π ) elements overall. Combining these two observations: ( π β π ) β€ πππ β ππ + π β€ πππ β ππ + π β€ π > π , and thus: 0 β₯ π β ππ + π = π β π Β· ( π ) + π > π β π + π = π β₯ π β such that for at least π + h ,π i broadcastssent, π β β π . (cid:3) Lemma 2.
If for some nonfaulty party π ( π,π π ) β π π , then π received a h , π₯ π i broadcast from every π β π π such that validate ( π₯ π ) = . Proof.
Observe some ( π, π π ) β π π and π β π π . Before adding ( π,π π ) to π π , π saw that π π β π π . This means that forevery π β π π , π ο¬rst received a h , π π i broadcast from π such that π π β π π . By deο¬nition, π π = Γ π β π π π π and thus π π β π π .Before adding π to π π , π must have received a h , π₯ π i validated broadcast checking that validate ( π₯ π ) =
1, completingthe proof. (cid:3)
Theorem 1.
The pair ( Gather , GatherVerify ) is a veriο¬able reliable gather protocol resilient to π < π Byzantineparties.
Proof.
Each property is proven separately.
Termination of Output.
Assume that validate ( π₯ π ) = π and that all nonfaulty parties partici-pate in the Gather protocol. The ο¬rst thing they do is send a h , π₯ π i message using a validated broadcast. By assumption, validate ( π₯ π ) = π , and thus every nonfaulty π receives the broadcast and updates π π and π π . Afterreceiving a h , π₯ π i message from every nonfaulty π , | π π | = π β π , so party π sends the message h , π π i . Afterwards,every nonfaulty party receives h , π π i from every nonfaulty π . Note that since π sent π π , it must have received a h , π₯ π i validated broadcast from every π β π π . The message was received by validated broadcast, so π eventually receives thesame message and adds π to π π as well. Therefore π eventually sees that π π β π π and adds π to π π . Finally, after π β π such updates, π broadcasts π π . Using similar arguments, every nonfaulty party eventually adds some tuple of the form ( π,π π ) to π π for every nonfaulty π . Then π sees that | π π | = π β π and outputs some value. A nonfaulty party π onlyadds pairs of the form ( π, π₯ ) to π π after receiving a validated broadcast of the form h , π₯ i from party π . This messagewas received by validated broadcast, so validate ( π₯ ) =
1, and thus π₯ β M as well. Every party can send only one suchbroadcast, and thus at all times throughout the protocol, π π consists of pairs ( π, π₯ ) such that π β [ π ] and π₯ β M andthe index π appears in π π at most once. In other words, π π is a gather-set throughout the protocol, including when π outputs the set π = π π . Completeness.
Assume some nonfaulty party π completes the Gather protocol and outputs π π . Before adding ( π, π₯ π ) to π π and π to π π , party π ο¬rst receives a h , π₯ π i validated broadcast from π . Every nonfaulty π eventually receives thesame broadcast and adds ( π, π₯ π ) to π π and π to π π as well. Therefore, eventually π π β π π for every nonfautly π . Beforeadding π to π π , π receives a broadcast h , π π i such that π π β π π and | π π | β₯ π β π . Since every nonfaulty π eventuallyreceives the same broadcast and π π β π π , π also adds π to π π . Using similar arguments, before adding ( π,π π ) to π π , π receives a broadcast h ,π π i such that π π β π π and | π π | β₯ π β π . Party π eventually receives the same message, seesthat the π π β π π β π π and | π π | β₯ π β π , and then computes π π using the exact same π sets π used when computingthe set, because all values were received by broadcast. Therefore at that point π adds ( π,π π ) to π π . Now, at the time π outputs a value from the Gather protocol, it sees that | π π | β₯ π β π , and outputs π π . From Lemma 2, at that time forevery ( π,π π ) β π π and π β π π , π received some h , π₯ π i broadcast from party π and thus π β π π . In other words, forevery ( π,π π ) β π π , π π β π π . At all times in the protocol, πΌππππππ ( π π ) = π π because an index π is added to π π at the sametime a tuple ( π, π₯ ) is added to π π . This means that if we observe πΌππππππ ( π π ) , which equals π π at the time π output π π ,for every ( π,π π ) β π π , π π β π π = πΌππππππ ( π π ) . Combining those two observations, every nonfaulty party π eventuallysees that for every ( π,π π ) β π π β π π , π π β πΌππππππ ( π π ) . At the time π outputs a value from the Gather protocol,4 Abraham et al. | π π | β₯ π β π so there are eventually π β π such tuples in π π as well. Furthermore, πΌππππππ ( π π ) = π π β π π , which means π eventually proceeds to the next line. At that time, π computes π = {( π, π₯ ) β π π | π β πΌππππππ ( π π )} . As stated above, π π equals π π at the time π output π π from the Gather protocol, and
πΌππππππ ( π π ) equals π π at that time. When π sees that πΌππππππ ( π π ) β π π , it has already received a validated broadcast h , π₯ π i from every party π β πΌππππππ ( π π ) and added ( π, π₯ π ) to π π . π π is a gather-set at all times, so this is the same tuple that π added to its output from the GatherVerify protocol, π . This is the same broadcast π received, so it added the same tuple ( π, π₯ π ) to π π before outputting π π . In otherwords, π added the same tuple ( π, π₯ π ) to π that π added to its output π π . Party π only adds tuples of the form ( π, π₯ π ) if π β πΌππππππ ( π π ) , so those are all the tuples in π . Agreement on Veriο¬cation.
Assume that some nonfaulty party π completes protocol GatherVerify π ( πΌ ) on an index-set πΌ and outputs a set π , and that all nonfaulty parties participate in the Gather protocol. At the time π completedthe protocol, πΌ β π π and |{ π |β( π,π π ) β π π ,π π β πΌ }| β₯ π β π . Let π be some nonfaulty party that runs the protocol GatherVerify π ( πΌ ) . Before π added some element ( π, π₯ π ) to π π and π to π π , it received a validated broadcast of the mes-sage h , π₯ π i from π . From the Termination and Correctness properties of the Validated Reliable Broadcast protocol, π eventually receives that message from π as well and thus ( π, π₯ π ) β π π and π β π π as well. In other words, eventually π π β π π and π π β π π . Before adding an element π to π π , π received a broadcast of a set π π from π such that | π π | β₯ π β π and π π β π π . From the Termination and Correctness properties of the Reliable Broadcast protocol, π eventually receives thesame message from π . As shown above, eventually π π β π π , and at that time π adds π to π π as well. Therefore, eventually π π β π π . Using similar arguments, if there exists some ( π,π π ) in π π , then eventually π adds some element ( π,π β² π ) to π π as well. From the Correctness property of the Reliable Broadcast protocol, π and π receive the same sets π π from allparties, and thus when computing π π and π β² π , they both do so with the same values. This in turn means that they addthe same tuple ( π,π π ) to their π π and π π sets and thus eventually π π β π π as well. Combining all of those observations,eventually πΌ β π π β π π . In addition, for every ( π,π π ) β π π such that π π β πΌ , eventually ( π,π π ) β π π as well. Since thereare at least π β π such tuples in π π , there are eventually π β π such tuples in π π as well. When both of those conditionshold, π proceeds to the next line of the GatherVerify protocol. When π completed the protocol, it saw that πΌ β π π andthus it received a h , π₯ π i from every π β πΌ , and added a tuple ( π, π₯ π ) to π π . Using the same reasoning, π received broad-casts from the same parties, and from the Agreement property of the validated reliable broadcast protocol, it receivedthe same messages and added the same tuples to π π . In other words, π computed π using the same values as π , so itoutput the same set π . Agreement.
Let π, π be two nonfaulty parties and
πΌ, π½ be two sets such that
GatherVerify π ( πΌ ) and GatherVerify π ( π½ ) eventually terminate with the outputs π and π respectively. Since GatherVerify terminates in both cases, πΌ β π π , π½ β π π .From the way π calculates π and π calculates π , π β π π and π β π π . Observe a pair of tuples ( π, π₯ ) β π β π π , ( π, π¦ ) β π β π π . Party π only adds ( π, π₯ ) to π π after receiving a broadcast of h , π₯ i from π , and party π adds the tuple ( π, π¦ ) to π π after receiving a broadcast of h , π¦ i from π . From the Agreement property of the validated reliable broadcast protocol,each party can only broadcast one message of the form h , π₯ i to all parties, and thus π₯ = π¦ . Binding Core.
Assume the ο¬rst nonfaulty party that completes the
Gather protocol is π β , and observe the index π β as deο¬ned in Lemma 1. Party π β only adds a tuple ( π,π π ) to π π β after receiving a h ,π π i message from party π .Before completing the protocol, π β received π β π such broadcasts, and from Lemma 1, π + h ,π π i such that π β β π π . Therefore for some ( π,π π ) β π π β , π β β π π . Note that π π β π π β , so π β β π π β .Before adding π β to π π β , π β received a h , π π β i broadcast from party π β such that π π β β π π β and | π π β | β₯ π β π . Similarly,before adding π β π π β to π π β , π β ο¬rst receives a h , π₯ β π i broadcast from π . Let the binding-core π β be deο¬ned as follows:eaching Consensus for Asynchronous Distributed Key Generation 15 π β = n ( π, π₯ β π )| π β π π β o , i.e. pairs consisting of a party in π π β and the value that π β received from that party via broadcast.Clearly | π β | β₯ π β π because | π π β | β₯ π β π . The fact that π β is a subset of every nonfaulty partyβs output from theprotocol is a direct corollary of the Completeness and Includes Core properties of the Gather protocol.
Internal Validity.
Let π β be the ο¬rst nonfaulty party that completed the Gather protocol, as deο¬ned in the BindingCore property. Let π be some party that was nonfaulty at that time such that there exists a tuple ( π, π₯ ) β π β . Let π β bedeο¬ned as it is in the Binding Core property and Lemma 1. By deο¬nition, if ( π, π₯ ) β π β , then π is in the set π π β that π β received from party π β . As shown in the Binding core property, at the time that π β completed the Gather protocol, italready received a h , π₯ β π i message from party π , and π₯ is deο¬ned to be π₯ β π . Now, since π was nonfaulty at that time, itbroadcasted the message h , π₯ π i , with π₯ π being its input to the protocol. Therefore, π₯ = π₯ π as required. Include Core.
Let π be some nonfaulty party and πΌ be some index set such that GatherVerify π ( πΌ ) terminates withthe output π . Party π found that (cid:12)(cid:12)(cid:8) π |β( π,π π ) β π π ,π π β πΌ (cid:9)(cid:12)(cid:12) β₯ π β π . As discussed above, party π only adds ( π,π π ) to π π after receiving a h ,π π i message from π . Let π β be deο¬ned as it is in Lemma 1 and in the Binding Core property. Seeingas there are at least π + h ,π i with π β β π and π β π parties π such that ( π,π π ) β π π and π π β πΌ , for at least one of those parties π β β π π . By deο¬nition, π π = Γ π β π π π π , and thus π π β β π π β πΌ .Therefore, for every π β π π β β πΌ , party π adds a tuple ( π, π₯ ) to its output π . Finally, π β π π , and π only adds ( π, π₯ ) to π π after receiving a h , π₯ i broadcast from π . Let π β be the ο¬rst nonfaulty party that completed the Gather protocol asdeο¬ned in the Binding Core property. Since π β π π β , π β received a h , π₯ β π i broadcast from π , so it must be the case that π₯ = π₯ β π as deο¬ned in the Binding Core Property. In other words, for every π β π π β , ( π, π₯ β π ) β π , and thus π β β π . External Validity.
Assume that for some nonfaulty π , GatherVerify π ( πΌ ) terminates. When π completed protocol itoutputs {( π, π₯ ) β π π | π β πΌ } β π π Party π adds ( π, π₯ ) to π π only after receiving a validated broadcast of h , π₯ i from π checking that validate ( π₯ ) = (cid:3) In this section we construct a veriο¬able weak proposal election, which is related to the idea of a weak common coin.With constant probability all nonfaulty parties output the proposal of a nonfaulty party, but in other cases parties mightoutput diο¬erent values. The protocol is also externally validated, meaning that every partyβs output is externally valid.In addition, the protocol is veriο¬able. Like in the case of the Veriο¬able Gather protocol, this means that parties can proveto each other that the value they output is indeed a viable output from the protocol. In the case that a single nonfaultypartyβs input is chosen, this means that this is the only value that will verify. Our construction uses techniques inspiredby Katz and Kooβs synchronous weak leader election [26]. They use veriο¬able secret sharing in order to determine theleader through a random coin whose value can only be obtained at the end of the protocol i.e. after reconstruction.We extend their results to the asynchronous setting by making use of a threshold veriο¬able random function (VRF)instantiated using a (local) DKG. There is a VRF public key associated to every player, and this public key is entirelydetermined by that player (provided it contains suο¬cient secret key shares). Parties cannot trivially reach consensusabout a single DKG because they do not know if there are DKG transcripts that have been received by other parties,but not by them.The protocol proceeds in four rounds and pseudocode is provided in Algorithm 3. In the ο¬rst round, every partysends a VRF-DKG share to every other party. If some party wishes their proposal to be considered it must input apair consisting of their proposal and an aggregated VRF-DKG transcript into the
Gather protocol. This essentiallyforces parties to commit to those values because only one tuple of the form ( π, ( prop π , vrf _ dkg π )) may appear in any6 Abraham et al.of the outputs from Gather for any given π . After outputting the gather set π from the Gather protocol, every partybroadcasts
πΌππππππ ( π ) , which is the set of indices with tuples in π . After receiving an index-set for which GatherVerify terminates with the output π , parties send VRF evaluation shares for all tuples in π , if they havenβt done so earlier.Note that at this time all of the tuples in π have already been committed to because of the Agreement property of the Gather protocol. After receiving π β π evaluation shares for each of the tuples in the output from the Gather protocol,every party evaluates the VRF at the appropriate values, and chooses the proposal with the highest corresponding VRFevaluation. We think of the PE protocol as succeeding if the maximal evaluation corresponds to a tuple in the bindingcore that corresponds to a value input by a nonfaulty party. As will be shown below, this happens with a constantprobability, and when that happens all parties output the corresponding proposal.The protocol proceeds in a few conceptual rounds described below:
Round 1:
In Round 1, each party samples and sends a VRF-DKG share for every other party. The VRF will later beused to assign a number to each party. Party π waits to receive π β π valid contributions from all other parties. It thenaggregates these VRF-DKG contributions into a verifying VRF-DKG transcript vrf _ dkg π . Round 2:
In Round 2 party π calls the Gather protocol providing its original input prop π and the aggregated VRF-DKGtranscript vrf _ dkg π as input. From the properties of the Gather protocol, each party will eventually output a set oftuples ( π, ( prop π , vrf _ dkg π )) indicating that π input the pair prop π and vrf _ dkg π to the protocol. Round 3:
After outputting a gather-set from the
Gather protocol, parties can start calculating the number assignedto each party. Ideally, each party would send the gather-set they output from the protocol to all other parties, andthey will help in evaluating all of the relevant values. However, having another all-to-all communication round whereparties send sets of π ( π ) tuples containing π ( π ) words each would incur an overhead of π ( ππ ) words to be sent.Instead of doing that, every party only broadcasts the indices of tuples in its gather-set, which we think of as a requestto start evaluating the VRF for each index. Round 4:
After receiving an index-set πΌ , every nonfaulty party calls the GatherVerify protocol on the set, and waitsto output the tuples corresponding to those indices. After that happens parties send their evaluation share for eachtuple they havenβt seen yet. This is done by maintaining a set start _ eval which stores all of the seen tuples. Whena party completes the GatherVerify protocol with the output π , it ο¬rst sends an evaluation share for every tuple in π \ start _ eval , and only then updates start _ eval to contain π .Crucially, the proposal and aggregated VRF-DKG transcript are sent together, and parties start sending the VRFevaluation shares only after seeing the relevant aggregated VRF-DKG transcript included in a gather-set received asoutput from the GatherVerify . By sending the proposal and VRF-DKG transcript together, parties have to commit totheir values before knowing which partyβs proposal is going to "win" the election. From the properties of the
Gather protocol, once a tuple ( π, ( prop π , vrf _ dkg π )) is in a gather-set output from GatherVerify , no other party ever outputsa gather-set from
GatherVerify with a diο¬erent tuple corresponding to the index π . By sending evaluation shares onlythen, nonfaulty parties guarantee that the faulty parties committed to their aggregated VRF-DKG transcript beforeknowing what number it evaluates to. This guarantees that those evaluations cannot be biased by the faulty parties.After receiving enough evaluation shares to compute π ( vrf _ dkg π , h π i) for every ( π, ( prop π , vrf _ dkg π )) in their out-put from the Gather protocol, party π chooses the index β with the maximal value π ( vrf _ dkg β , h β i) and outputs prop β .eaching Consensus for Asynchronous Distributed Key Generation 17In addition, π outputs the indices of parties in their gather-set as proof.Intuitively, every party outputs a gather-set from the Gather protocol which determines the VRF evaluations takeninto consideration. If the VRF evaluation with the maximal value among all outputs from the
Gather protocol corre-sponds to a tuple ( β β , ( prop β β , vrf _ dkg β β )) in the binding core of the Gather protocol that was input by a nonfaultyparty, then all nonfaulty parties will see that evaluation and pick prop β β as their output. Since the evaluations are sam-pled uniformly in an unbiased manner, this means that every party has the same probability of having the maximalevaluation being associated with it. When counting the number of nonfaulty parties with tuples in the common core,we ο¬nd that the probability of the aforementioned event is at least . This mechanism also allows to check whether agiven proposal could have been the correct output from the PE protocol. In order to convince a nonfaulty party that avalue is a correct output from the PE protocol, it is enough to provide oneβs output from the Gather protocol. Partieswill then be able to check if that is a verifying gather-set and if the correct proposal was elected based on that output.Instead of actually using the whole gather-set as proof, only the indices of tuples in it are sent as proof in order toreduce communication. If the maximal evaluation is associated with a tuple in the binding-core, then only gather-setscontaining that tuple will verify, which means that only prop β β as deο¬ned above will verify. Veriο¬cation:
The veriο¬cation algorithm is given in Algorithm 5. As stated above, in order for a value π₯ to verify witha proof π , parties require the indices of the gather-set with which it was computed. They then check if the index-setveriο¬es, if all the relevant tuples have been previously received, and if the evaluation of the VRF has been computedat all relevant points. If all of those conditions hold, parties then make sure that π₯ is the proposal with the maximalassociated VRF evaluation. The following lemmas show that the start _ eval and evals sets of diο¬erent parties are eventually consistent with eachother. Lemma 3.
If all nonfaulty parties participate in the PE protocol, and some nonfaulty party π outputs the set π π fromthe Gather protocol, then for every nonfaulty π eventually π π β start _ eval π . Furthermore, if for two nonfaulty parties π, π , ( π, ( prop π , vrf _ dkg π )) β start _ eval π and ( π, ( prop β² π , vrf _ dkg β² π )) β start _ eval π , then ( prop π , vrf _ dkg π ) = ( prop β² π , vrf _ dkg β² π ) . Proof.
If some nonfaulty party output π π from the gather protocol, then it broadcasts h πππππππ , πΌππππππ ( π π )i . Ev-ery nonfaulty π receives that message, calls GatherVerify ( πΌππππππ ( π π )) and from the Completeness property of the Gather protocol, eventually outputs π π . After that time, π performs some local computations and updates start _ eval π to start _ eval π βͺ π π .Now observe two nonfaulty parties π, π such that ( π, ( prop π , vrf _ dkg π )) β start _ eval π and ( π, ( prop β² π , vrf _ dkg β² π )) β start _ eval π . Before adding ( π, ( prop π , vrf _ dkg π )) to start _ eval π , π output some set π from GatherVerify with ( π, ( prop π , vrf _ dkg π )) β π . Similarly, before adding ( π, ( prop β² π , vrf _ dkg β² π )) to start _ eval π , π output some set π from GatherVerify with ( π, ( prop β² π , vrf _ dkg β² π )) β π . Therefore, ( prop π , vrf _ dkg π ) = ( prop β² π , vrf _ dkg β² π ) from the Agreement property ofthe Gather protocol. (cid:3)
Lemma 4. If ( π, ( prop π , vrf _ dkg π )) β start _ eval π for some nonfaulty π , then eventually for every nonfaulty π , thereexists a tuple ( π, π ( vrf _ dkg π , h π i)) β evals π . Furthermore, if ( π, evaluation π ) β evals π for some nonfaulty π , then thereexists some tuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π such that evaluation π = π ( vrf _ dkg π , h π i) . Algorithm 3 PE π ( prop π ) dkg _ shares π β β , π π β β , β π β [ π ] eval _ shares π [ π ] β β , ππ£πππ π β β , start _ eval π β β ( share π, , . . . , share π,π ) $ ββ DKGSh ( sk π ) , . . . , DKGSh ( sk π ) for every π β [ π ] send h dkg , share π,π i to π upon receiving the ο¬rst h dkg , share π,π i from π message such that DKGShVerify ( pk π , share π,π ) = do dkg _ shares π β dkg _ shares π βͺ { share π,π } if (cid:12)(cid:12) dkg _ shares π (cid:12)(cid:12) = π β π then vrf _ dkg π β DKGAggregate ( dkg _ shares π ) call Gather π ( prop π , vrf _ dkg π ) with the external validity function checkValidity upon Gather π outputting the set π = {( π, ( prop π , vrf _ dkg π ))} , do β² continue updating state according to Gather π π β π πΌ π β πΌππππππ ( π π ) = { π |β( π, ( prop π , vrf _ dkg π )) β π π } broadcast h πππππππ , πΌ π i upon receiving the ο¬rst h πππππππ , πΌ π i message from π , do upon GatherVerify π ( πΌ π ) terminating with output π π and Gather outputting some value, do for all ( π, prop π , vrf _ dkg π ) β π π \ start _ eval π do ( eval _ share π,π , π π,π ) β EvalSh ( vrf _ dkg π , sk π , h π i) send h ππ£ππ, π, eval _ share π,π , π π,π i to every party start _ eval π β start _ eval π βͺ π π upon receiving the ο¬rst h ππ£ππ, π, eval _ share π,π , π π,π i broadcast from π for any given π , do upon β( π, ( prop π , vrf _ dkg π )) β start _ eval π , do if EvalShareVerify ( vrf _ dkg π , pk π , h π i , eval _ share π,π , π π,π ) = then eval _ shares π [ π ] β eval _ shares [ π ] βͺ {( eval _ share π,π , π π,π )} if | eval _ shares π [ π ]| = π β π then ( evaluation π , π π ) β Eval ( vrf _ dkg π , h π i , eval _ shares π [ π ]) evals π β eval _ share π βͺ {( π, evaluation π )} upon β( π, ( vrf _ dkg π , prop π )) β π π β( π, evaluation π ) β evals π and π π β β , do β β ππππππ₯ π { evaluation π |( π, ( prop π , vrf _ dkg π )) β π π } β² i.e. β has the maximal evaluation β π π β πΌππππππ ( π π ) = { π |β( π, ( prop π , vrf _ dkg π )) β π π } output ( prop β , π π ) , but continue updating internal sets and sending messages Algorithm 4 checkValidity ( prop , vrf _ dkg ) if validate ( prop ) = DKGVerify ( vrf _ dkg ) = then return else return Algorithm 5
PEVerify π ( π₯, π ) upon β π β π β( π, evaluation π ) β evals π β§ β( π, ( prop π , vrf _ dkg π )) β start _ eval π , do upon GatherVerify π ( π ) terminating, do β β ππππππ₯ π { evaluation π | π β π } if π₯ = prop β then terminate eaching Consensus for Asynchronous Distributed Key Generation 19 Proof. If ( π, ( prop π , vrf _ dkg π )) β start _ eval π , then π added that tuple after receiving some broadcast h πππππππ , πΌ i for which GatherVerify π ( πΌ ) terminated with an output π such that ( π, ( prop π , vrf _ dkg π )) β π . From the Termi-nation and Agreement properties of the broadcast protocol, every other nonfaulty π eventually receives the samemessage. From the Agreement on Veriο¬cation property of the Gather protocol, eventually π outputs the same π from GatherVerify π ( πΌ ) , and then adds ( π, ( prop π , vrf _ dkg π )) to start _ eval π . A tuple ( π, ( prop π , vrf _ dkg π )) is addedto start _ eval π only after already sending h ππ£ππ, π, eval _ share π,π , π π,π½ i , so all nonfaulty parties send such a message forevery ( π, ( prop π , vrf _ dkg π )) β start _ eval π . Therefore, for every ( π, ( prop π , vrf _ dkg π )) β start _ eval π , every nonfaultyparty π receives a a message h ππ£ππ, π, eval _ share π,π , π π,π i from every nonfaulty π , and sees that ( π, ( prop π , vrf _ dkg π )) β start _ eval π . Since a nonfaulty π computed the share correctly, EvalShareVerify ( vrf _ dkg π , pk π , h π i , eval _ share π,π , π π,π ) =
1. Party π then adds the tuple ( eval _ share π,π , π π,π ) to eval _ shares π . After adding such a tuple for every nonfaulty party, π sees that (cid:12)(cid:12) eval _ shares π [ π ] (cid:12)(cid:12) = π β π , it computes π ( vrf _ dkg π , h π i) , π π using Eval and adds the tuple ( π, π ( vrf _ dkg π , h π i)) to evals π .Now, let ( π, evaluation π ) β evals π for some nonfaulty π . Before adding that tuple to evals π , party π saw that β( π, ( prop π , vrf _ dkg π )) β start _ eval π and added π β π shares to eval _ shares π [ π ] . It then computed ( evaluation π , π π ) = Eval ( vrf _ dkg π , h π i , eval _ share π [ π ]) and added ( π, evaluation π ) to evals π . From the deο¬nition of the VRF, evaluation π = π ( vrf _ dkg π , h π i) . (cid:3) Corollary 2.
Let π, π be two nonfaulty parties such that ( π, evaluation π ) β evals π and ( π, evaluation β² π ) β evals π . Then evaluation π = evaluation β² π . Proof.
From Lemma 4, there exists a tuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π such that evaluation π = π ( vrf _ dkg π , h π i) . Similarly, there exists a tuple ( π, ( prop β² π , vrf _ dkg β² π )) β start _ eval π such that evaluation β² π = π ( vrf _ dkg β² π , h π i) . FromLemma 3, ( prop π , vrf _ dkg π ) = ( prop β² π , vrf _ dkg β² π ) , so evaluation π = evaluation β² π . (cid:3) Theorem 3.
The pair ( PE , PEVerify ) is a veriο¬able weak proposal election protocol resilient to π < π parties with πΌ = . Proof.
Each property is proven separately.
Termination of Output.
If all nonfaulty parties participate in the PE protocol, then they all send a h πππ, share π,π i message to every other party, with share π,π being generated using DKGSh . Every nonfaulty party π eventually re-ceives at least π β π shares from the nonfaulty parties such that DKGShVerify ( pk π , share π,π ) = share π,π to dkg _ shares π . After that, π sees that (cid:12)(cid:12) dkg _ shares π (cid:12)(cid:12) = π β π , it aggregates those shares into vrf _ dkg π , and inputs ( prop π , vrf _ dkg π ) to the Gather protocol. From the Correctness property of the DKG,
DKGVerify ( vrf _ dkg π ) =
1, be-cause vrf _ dkg π is an aggregation of π β π verifying DKG shares. By assumption, all nonfaulty parties have externallyvalid inputs (i.e. for every nonfaulty π , validate ( prop π ) = π checkValidity ( prop π , vrf _ dkg π ) = Gather protocol, every nonfaulty party π eventually outputs some set π π from the protocol. From Lemma 3, every nonfaulty party π eventually has π π β start _ eval π . In addition, from Lemma 4,for every ( π, ( prop π , vrf _ dkg π )) β π π β start _ eval π eventually there exists a tuple ( π, evaluation π ) β evals π . At thatpoint, π preforms some local computations and outputs a value from the protocol. Completeness.
Assume some nonfaulty party π outputs the value π₯ and proof π from PE . The way π computes π is by taking its output from the Gather protocol, π π , and computing π = πΌππππππ ( π π ) . Observe some nonfaulty party π that calls PEVerify π ( π₯, π ) . From Lemma 3, eventually π π β start _ eval π , so for every π β π = πΌππππππ ( π π ) thereexists some tuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π . From Lemma 4, eventually for every such π , there also existsa tuple ( π, evaluation π ) β evals π . Therefore eventually π proceeds past the ο¬rst condition of PEVerify . Afterwards,0 Abraham et al. π calls GatherVerify π ( π ) . By deο¬nition π = πΌππππππ ( π π ) , so GatherVerify π ( π ) eventually terminates because of theCompleteness property of the Gather protocol. Before terminating, π also saw that for every π β π there existed atuple ( π, evaluation π ) β evals π . It then computed the index β with the maximal evaluation β and output prop β . FromCorollary 2, π has the same tuples ( π, evaluation π ) β evals π so it computes the same β . Similarly, from Lemma 3, when π checks if π₯ = prop β it does so with the tuple ( π, ( prop π , vrf _ dkg π )) β π π β start _ eval π , and thus from the way π computes π₯ , π sees that π₯ is indeed prop β . Note that Lemma 3 and Corollary 2 also imply that the start _ eval and evals sets have only one tuple of the form ( π, ( prop π , vrf _ dkg π )) for any given π , meaning that the values above are uniqueand well-deο¬ned. πΌ - Binding.
At the time the ο¬rst nonfaulty party completes the
Gather protocol, there exists a binding-set π β oftuples ( π, ( prop π , vrf _ dkg π )) that must be included in any output of the GatherVerify protocol. Now, observe all ofthe sets π which are the output of GatherVerify π for any nonfaulty π throughout the rest of the protocol, and let ππ’π‘ππ’π‘π = Γ π be the set of all tuples ( π, ( prop π , vrf _ dkg π )) in those sets. From the Agreement property of the Gather protocol, for any given π β [ π ] there can be no more than one such tuple ( π, ( prop π , vrf _ dkg π )) β ππ’π‘ππ’π‘π . Furthermore,from the External Validity property of the Gather protocol, checkValidity ( prop π , vrf _ dkg π ) = π , andthus DKGVerify ( vrf _ dkg π ) =
1. In other words, every such vrf _ dkg π is an aggregation of correct shares from at least π + vrf _ dkg π contains shares from at least one nonfaulty party, before somenonfaulty party sends its evaluation share of vrf _ dkg π , the value π ( vrf _ dkg π , h π i) is distributed uniformly and inde-pendently from the view of the adversary or any single nonfaulty party. That is true because of the Unbiasabilityproperty of the threshold veriο¬able random function. No nonfaulty party π sends its evaluation share of any of the ag-gregated VRF-DKGs vrf _ dkg π (or their respective non-aggregated shares) before completing the GatherVerify protocoland outputting a set π from GatherVerify π such that ( π, ( prop π , vrf _ dkg π )) β π . At that point, ( π, ( prop π , vrf _ dkg π )) is already set and every nonfaulty party that outputs a set π from GatherVerify that contains a tuple with the index π ,does so with the tuple ( π, ( prop π , vrf _ dkg π )) . Combining the fact that no nonfaulty party sends an evaluation share for ( π, ( prop π , vrf _ dkg π )) before outputting a gather-set containing it from GatherVerify , and that before that happens thevalue is distributed uniformly and independently from the adversaryβs view, π ( vrf _ dkg π , h π i) is distributed uniformlyand independently for every ( π, ( prop π , vrf _ dkg π )) β ππ’π‘ππ’π‘π . In particular, each one of those values has the sameprobability of being the maximal one, regardless of the adversaryβs actions.Now, if β β = ππππππ₯ π { π ( vrf _ dkg π , h π i)|( π, ( prop π , vrf _ dkg π )) β ππ’π‘ππ’π‘π } for some ( β β , ( prop β β , vrf _ dkg β β )) β π β ,and party β β is nonfaulty at the time the ο¬rst nonfaulty party completes the Gather protocol, deο¬ne π₯ β to be prop β β ,otherwise deο¬ne π₯ β = β₯ . Note that π β is at least of size π β π , so at least π β π of the parties π such that there exists a tuple ( π, ( prop π , vrf _ dkg π )) β π β are nonfaulty at the time the ο¬rst nonfaulty party completes the Gather protocol. From theInternal Validity property of the
Gather protocol, for any party π that was nonfaulty at the time the ο¬rst nonfaulty partycompleted the Gather protocol, the tuple ( π, ( prop π , vrf _ dkg π )) includes the values prop π and vrf _ dkg π that π input tothe protocol. Each one of those parties has a π probability of having the maximal value, and thus the probability that π₯ β is the input of one of the parties that was nonfaulty at that time is at least π β ππ β₯ ( π + ) Β· π = + π . Clearly,since they are nonfaulty at that time, they must have also acted in a nonfaulty manner when starting the PE protocol.This analysis ignores the probability of two parties having the same maximal value. The probability of this event canbe bounded by π π since there are 2 π diο¬erent possible values for outputs of π . For the probability to remain at least eaching Consensus for Asynchronous Distributed Key Generation 21even when taking the possibility of a collision into consideration, it is enough that the security parameter is at least3 log ( π ) . Agreement on Veriο¬cation
Let π, π be two nonfaulty parties and π₯, π be two values such that
PEVerify π ( π₯, π ) terminates. The ο¬rst thing π does in PEVerify is wait until β π β π , there exists a tuple ( π, evaluation π ) β evals π and atuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π . Party π only updated its start _ eval π set after receiving a broadcast of the form h πππππππ , πΌ i and seeing that GatherVerify π ( πΌ ) terminates and outputs the set π . When that happens, π updates start _ eval π to be start _ eval π βͺ π . From the Termination and Agreement properties of the broadcast protocol, π eventually receivesthe same message. It then runs GatherVerify π ( πΌ ) and eventually outputs the same set π because of the Agreementon Veriο¬cation property of Gather . Afterwards, it also updates start _ eval π to be start _ eval π βͺ π . In other words, forevery ( π, ( prop π , vrf _ dkg π )) β start _ eval π , eventually ( π, ( prop π , vrf _ dkg π )) β start _ eval π as well. From Lemma 4,eventually for every π β π there also exists a tuple ( π, evaluation β² π ) β evals π . Recall that there also exists a tuple ( π, evaluation π ) β evals π , and evaluation π = evaluation β² π because of Corollary 2. By Lemma 3 and Corollary 2, π and π only have one such tuple in their respective start _ eval and evals sets, and thus all of the calculations in the rest ofthe protocol are well deο¬ned. Before terminating, π called GatherVerify π ( π ) , which eventually terminated. From theAgreement on Veriο¬cation property of the Gather protocol,
GatherVerify π ( π ) also eventually terminates. Afterwards, π and π perform the same deterministic non-interactive computation which only depends on the values in evals and start _ eval . Weβve shown that π and π have the same values in the relevant tuples, so since π eventually completed the PEVerify protocol, so does π . Binding Veriο¬cation. If π₯ β as deο¬ned in the πΌ -Binding property equals β₯ , the property trivially holds. Assume that π₯ β β β₯ and that PEVerify π ( π₯, π ) terminates for some nonfaulty π . Before PEVerify terminated, π checked that for every π β π there exists a tuple ( π, evaluation π ) β evals π and a tuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π . From Lemma 4if ( π, evaluation π ) β evals π then there exists a tuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π such that π ( vrf _ dkg π , h π i) = evaluation π , and from Corollary 2 there is only one tuple with the index π in evals π . Combining these observations, forevery π β π , there exists a tuple ( π, ( prop π , vrf _ dkg π )) β start _ eval π and a tuple ( π, π ( vrf _ dkg π , h π i)) β evals π (and noother tuple with the index π ).Afterwards, π calls GatherVerify π ( π ) , which eventually terminates with an output π such that πΌππππππ ( π ) = π . Inaddition, from the Includes Core property of the Gather protocol, π β β π , and thus πΌππππππ ( π β ) β πΌππππππ ( π ) = π .Now, note that π only adds a tuple ( π, ( prop π , vrf _ dkg π )) to start _ eval π if it outputs a gather-set from GatherVerify that includes ( π, ( prop π , vrf _ dkg π )) , and thus start _ eval π β ππ’π‘ππ’π‘π . By deο¬nition, β β is the index with the maximalevaluation π ( vrf _ dkg π , h π i) among all tuples ( π, ( prop π , vrf _ dkg π )) β ππ’π‘ππ’π‘π . Also, by deο¬nition, β β β πΌππππππ ( π β ) β π . Therefore, when π computes β = ππππππ₯ π { evaluation π | π β π } , it sees that the index corresponding to the maximalsuch value must be β β , and so it checks that π₯ = prop β β for the tuple ( β β , ( prop β β , vrf _ dkg β β )) β start _ eval π . As discussedabove, this is the same ( β β , ( prop β β , vrf _ dkg β β )) tuple in ππ’π‘ππ’π‘π , so prop β β = π₯ β . Party π eventually terminated, andthus it found that π₯ = prop β β = π₯ β , as required. External Validity.
Observe some nonfaulty party π , value π₯ and proof π such that PEVerify π ( π₯, π ) terminates. Since PEVerify terminates, π must have found that π₯ = prop β for some ( β, ( prop β , vrf _ dkg β )) β start _ eval π . Party π onlyupdates start _ eval π by adding all elements in π π after GatherVerify π outputs the set π π . From the External Validityproperty of the Gather protocol, for every ( π, ( prop π , vrf _ dkg π )) β π π , checkValidity ( prop π , vrf _ dkg π ) =
1, which inturn means that validate ( prop π ) =
1. This is true for prop β as well. (cid:3) We present a new primary-backup based consensus protocol for the asynchronous model:
No Waitinβ Hotstuο¬ ( NWH ).As the name suggests, many of the techniques and inspiration for this protocol originated in HotStuο¬ [32]. Unlikebasic HotStuο¬ which requires eventual synchrony,
NWH obtains liveness using the PE protocol described in Section 4,and thus avoids depending on a leader. The purpose of NWH is to determine whether or not the PE protocol wassuccessful, and if not to allow parties to repeat the PE until consensus is reached. Recall that with probability πΌ (inthis implementation πΌ = ), all parties output the input of a party that was nonfaulty when starting PE . On the otherhand, with probability 1 β πΌ , the parties might output the value that a faulty party input, or even diο¬erent values fromdiο¬erent parties. Using NWH we can amplify our constant probability of agreement to an overwhelming probabilityof agreement.
NWH proceeds in virtual rounds called βviewsβ, which are attempts to achieve consensus on the output of the PE protocol. NWH uses a βKey-Lock-Commitβ paradigm that helps maintain safety and liveness.
Key:
Parties set a local key ο¬eld that indicates that no other value was committed to in previous rounds. Thekeys help maintain liveness: if at any point some party sets a lock in a view where no commitment takes place,then they will eventually see a key from that view (or a later view), that will convince them to participate in thecurrent view.A key consists of three values: πππ¦ , which is a view number, πππ¦ _ π£ππ which is a value and π , which is a proofthat the key was set correctly in that view. Lock:
Before committing to a value in a given view, parties will wait to hear that enough other parties haveset a lock on the same value in that view. Before parties set a lock in a given view, they make sure that enoughother parties have set a local key ο¬eld that indicates that no other value was committed to in previous rounds.Parties that are locked on a value wonβt be willing to participate in any later view with a diο¬erent value. Theywill ignore the lock if and only if enough proof, in the form of a key from a later view, is provided that nocommitment actually took place in the view where the lock was set. This mechanism helps in guaranteeing thesafety of decision values. If a commitment took place, then there will be a large number of nonfaulty partiesthat are locked on that value. Those parties wonβt be willing to participate in views with diο¬erent values, whichwill prevent any party from setting a key in a later view with a diο¬erent value. This in turn will guarantee thatno party will be able to provide erroneous proof that the locks can be opened.A lock looks much like a key and consists of three values: ππππ , which is a view number, ππππ _ π£ππ which is avalue and π , which is a proof that the lock was set correctly in that view. Commit:
If a nonfaulty party commits to a value no other nonfaulty party ever commits to another value. Thelocking mechanism guarantees that nonfaulty parties cannot commit to diο¬erent values. In order to help otherparties terminate, nonfaulty parties send commit messages to all other parties with proof that the commitmentis correct and that they can terminate and output the same value.Algorithm 6 formally describes
NWH . It relies on three protocols: viewChange (Algorithm 8) for the ο¬rst round ofinteraction in each view and the PE protocol, and on processMessages (Algorithm 10) and processFaults (Algorithm 9)for all subsequent rounds in each view.Almost all the work takes place in processMessages (Algorithm 10), in which parties process ππβπ , πππ¦ and ππππ messages. Algorithms 7 and 9 are utilities for processing ππππππ‘ , πππππ and πππ’ππ£ππππ‘π messages if they are receivedand either terminating or continuing to the next view if needed.eaching Consensus for Asynchronous Distributed Key Generation 23Finally, the algorithms for checking that πππ¦ , ππππ and ππππππ‘ messages are correct are provided in Algorithms 11,12 and 13 respectively. This is done by checking that the provided proof contains signatures from π β π parties on amessage from the previous round. For example a correct πππ¦ message must contain π β π signatures on ππβπ messagesfrom the same view with the same value. Keys and locks are considered automatically correct if they are from beforethe ο¬rst view. In addition, when checking if a key is correct, parties also check that the keyβs value is externally valid.Below we provide an overview of each of the rounds. The parties proceed in 5 rounds. The general idea is thatparties will ο¬rst conο¬rm that they all agree on the output of the PE protocol, set a lock to the output and conο¬rm thatthey are all locked, commit to the lock and terminate. If at any point they see that the PE failed, then they move ontoa new view and announce that they are doing so (with proof). Round 1:
The ο¬rst round in each view begins with a viewChange protocol. The viewChange protocol determineswhich keys parties input into the PE protocol. To begin, send the current key to all other parties in a π π’ππππ π‘ message.Upon receiving π β π keys, choose the key from the most recent view and input it to the PE protocol. Round 2:
The second round proceeds diο¬erently depending on which messages parties receive. This is the roundwhere parties determine whether the PE was successful or not. β’ Upon receiving a value output from another party from the PE protocol, if that value is correct then echo thatmessage to all other parties. β’ If that value is incorrect then send a πππππ message and proof to all other parties, including a proof that thevalue was the output from the PE protocol and that it is incorrect and proceed to the next view. The PE protocoluses an external-validity function that guarantees that all outputs are well-formed and provide correct proofsof their keys. However, checking whether the message should be accepted using the local ππππ ο¬elds cannotbe modeled as an external validity function, since it is dependent on the running partyβs local state. Therefore, πππππ messages inform other parties that the PE protocol output a key which was insuο¬cient to open the local ππππ , and include the local ππππ ο¬elds with proofs that they have been correctly set. If the PE protocol wassuccessful then the output values should always be correct and open any lock. β’ Upon receiving a correct πππππ message and proof, send the πππππ message to all parties and proceed to thenext view. β’ Upon receiving ππβπ messages with two diο¬erent correct values and proofs that they were outputs of the PE protocol, send an πππ’ππ£ππππ‘π message and proof to all parties, and proceed to the next view. If the PE protocolwas unsuccessful then there could be two parties with diο¬erent correct values, and thus the next view will benecessary to reach agreement. β’ Upon receiving an πππ’ππ£ππππ‘π message with diο¬erent values and correct proofs, forward that message, andproceed to the next view.
Round 3:
In this round parties are conο¬rming that they believe that the PE protocol terminated successfully. Uponreceiving π β π ππβπ messages, update the πππ¦ ο¬eld before sending a πππ¦ message to all parties. Round 4:
Upon receiving π β π πππ¦ messages, update the ππππ ο¬eld before sending a ππππ message to all parties. Settinga ππππ is the main way the protocol guarantees safety. As will be stated in the next round, before committing to a value,every party waits to see that at least π β π parties set their locks. This guarantees that at least π + ππβπ phase in anyfuture view. This in turn will make sure that no correct key is set in later views that might allow one of those sentinelsto open their lock. Crucially, before setting a lock, every party makes sure that at least π + PE protocol, all nonfaulty parties will hear of the current value and will be capable of opening any older ππππ anonfaulty party might have. Round 5:
If a single honest party begins the ο¬nal round then the protocol will eventually terminate. There are twomeans of termination: either you see that enough parties are locked, or you see that one other party is (correctly)committed. Upon receiving π β π ππππ messages, send a ππππππ‘ message to all parties and terminate. Upon receivinga ππππππ‘ message with proof that it was sent after receiving enough ππππ messages, forward that message to all otherparties and terminate. Algorithm 6
NWH ( π₯ π ) πππ¦ π β , πππ¦ _ π£ππ π ββ₯ , πππ¦ _ ππππ π ββ₯ ππππ π β , ππππ _ π£ππ π ββ₯ , ππππ _ ππππ π π ββ₯ π£πππ€ π β continually run checkTermination () while true do ππ’π _ π£πππ€ β π£πππ€ π as long as ππ’π _ π£πππ€ = π£πππ€ π , run delay any message from any view π£ such that π£ > π£πππ€ π call viewChange ( π£πππ€ ) β² perform ο¬rst lines in viewChange before continuing to next line continually run processMessages ( π£πππ€ ) and processFaults ( π£πππ€ ) In the
NWH protocol, it is important to note that we explicitly run the checkTermination protocol before line 7,but the processMessages and processFaults protocols after it. This means that the checkTermination protocol al-ways runs in the background, whereas once ππ’π _ π£πππ€ β π£πππ€ π party π stops processing messages from ππ’π _ π£πππ€ in processMessages and processFaults (and thus donβt update their πππ¦ or ππππ ο¬elds according to messages receivedin older views). Algorithm 7 checkTermination () upon receiving the ο¬rst h ππππππ‘, π£, π ππππππ‘ , π£πππ€ i message from π , do if commitCorrect ( π£πππ€, π£, π ππππππ‘ ) = then send h ππππππ‘, π£, π ππππππ‘ , π£πππ€ i to every party π β [ π ] output π£ and terminate Our main theorem for demonstrating the security of
NWH is given in Theorem 4 where we show correctness, validity,termination and quality. The proof of this theorem relies on several lemmas.Correctness depends on Lemma 6 where we show that whenever there exists a correct commitment, nonfaultyparties will not send ππβπ messages with values that are inconsistent with this commitment in future views. The proofeaching Consensus for Asynchronous Distributed Key Generation 25
Algorithm 8 viewChange ( π£πππ€ ) π π’ππππ π‘ππππ β β β² π π’ππππ π‘ππππ is a multiset send h π π’ππππ π‘,πππ¦ π , πππ¦ _ π£ππ π , πππ¦ _ ππππ π π , π£πππ€ i to every party π β [ π ] upon receiving the ο¬rst h π π’ππππ π‘, π, π£, π πππ¦ , π£πππ€ i message from party π , do if keyCorrect ( π, π£, π πππ¦ ) = π < π£πππ€ then π π’ππππ π‘ππππ β π π’ππππ π‘ππππ βͺ {( π, π£, π πππ¦ )} if | π π’ππππ π‘ππππ | = π β π then ( π, π£, π πππ¦ ) β ππππππ₯ ( π,π£,π πππ¦ ) β π π’ππππ π‘ππππ { π } β² break ties arbitrarily if π = then ( π, π£, π πππ¦ ) β ( , π₯ π , β₯) call PE π,π£πππ€ (( π, π£, π πππ¦ )) with the external validity function keyCorrect Algorithm 9 processFaults ( π£πππ€ ) upon receiving the ο¬rst h πππππ,π, π£, π πππ¦ , π πππππ‘πππ , π, ππ£, π ππππ , π£πππ€ i message from π , doif lockCorrect ( π, ππ£, π ππππ ) = π£πππ€ β€ π β¨ π < π thenupon PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminating, do send h πππππ, π, π£, π πππ¦ , π πππππ‘πππ , π, ππ£, π ππππ , π£πππ€ i to every party π β [ π ] π£πππ€ π β π£πππ€ π + upon receiving the ο¬rst h πππ’ππ£ππππ‘π, π, π£, π πππ¦ , π πππππ‘πππ , π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π£πππ€ i message from π , doif ( π, π£, π πππ¦ ) β ( π β² , π£ β² , π β² πππ¦ ) thenupon PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) and PEVerify π,π£πππ€ (( π β² , π£ β² , π β² πππ¦ ) , π β² πππππ‘πππ ) terminating, do send h πππ’ππ£ππππ‘π, π, π£, π πππ¦ , π πππππ‘πππ , π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π£πππ€ i to every party π β [ π ] π£πππ€ π β π£πππ€ π + πππ¦ and ππππ ο¬elds are always correct, and thus will be accepted when received in any message. Lemma 10proves that whenever all non-faulty parties begin a view with valid inputs, the protocol has a constant probability ofterminating. The proof depends on 9 which argues that nonfaulty parties will not get successfully blamed for theirhonest inputs. The proof also depends on the correctness lemmas and Lemma 7. Validity follows from Correctness andthe external validity of the PE . Quality follows from Termination and the πΌ -Binding property of the PE .We start by deο¬ning what it means for a key, lock, or commit to be correct. Definition 3. A πππ¦ message of the form h πππ¦, π£, π, π, π£πππ€ i is said to be correct if keyCorrect ( π£πππ€, π£, π ) = . Simi-larly, a ππππ message of the form h ππππ, π£, π, π, π£πππ€ i is said to be correct if lockCorrect ( π£πππ€, π£, π ) = . Finally, a ππππππ‘ message of the form h ππππππ‘, π£, π, π£πππ€ i is said to be correct if commitCorrect ( π£πππ€, π£, π ) = . In addition, the value ofeach such message is said to be the ο¬eld π£ . The following two lemmas help prove that the protocol maintains safety conditions. By that we mean that if somenonfaulty party commits to a value, then there will be π + ππβπ messages to proceed to late stages of the protocol.6 Abraham et al. Algorithm 10 processMessages ( π£πππ€ ) ππβπππ β β , πππ¦π β β , πππππ β β upon PE π,π£πππ€ outputting ( π, π£, π πππ¦ ) , π πππππ‘πππ , do β² continue updating state according to PE π,π£πππ€ if π£πππ€ > π β₯ ππππ π then π β sign ( π π π , h ππβπ, π£, π£πππ€ i) send h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π, π£πππ€ i to every party π β [ π ] else send h πππππ,π, π£, π πππ¦ , π πππππ‘πππ , ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π π , π£πππ€ i to every party π β [ π ] π£πππ€ π β π£πππ€ π + upon receiving the ο¬rst h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π, π£πππ€ i message from π , do if verifySignature ( ππ π , h ππβπ, π£, π£πππ€ i , π ) = then upon PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminating, do if β( π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π β² , π β² ) β ππβπππ π .π‘. ( π, π£, π πππ¦ ) β ( π β² , π£ β² , π β² πππ¦ ) then send h πππ’ππ£ππππ‘π, π, π£, π πππ¦ , π πππππ‘πππ , π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π£πππ€ i to every party π β [ π ] π£πππ€ π β π£πππ€ π + else ππβπππ β ππβπππ βͺ ( π, π£, π πππ¦ , π πππππ‘πππ , π, π ) if | ππβπππ | = π β π then π πππ β {( π, π )|( π, π£, π πππ¦ , π πππππ‘πππ , π, π ) β ππβπππ } πππ¦ π β π£πππ€, πππ¦ _ ππππ π π β π πππ , πππ¦ _ π£ππ π β π£ π β sign ( π π π , h πππ¦, π£, π£πππ€ i) send h πππ¦, π£, π πππ , π, π£πππ€ i to every party π β [ π ] upon receiving the ο¬rst h πππ¦, π£, π πππ¦ , π, π£πππ€ i message from π , do if verifySignature ( ππ π , h πππ¦, π£, π£πππ€ i , π ) = keyCorrect ( π£πππ€, π£, π πππ¦ ) = then πππ¦π β πππ¦π βͺ {( π, π )} if | πππ¦π | = π β π then ππππ π β π£πππ€, ππππ _ ππππ π π β πππ¦π , ππππ _ π£ππ π β π£ π β sign ( π π π , h ππππ, π£, π£πππ€ i) send h ππππ, π£, ππππ _ ππππ π π , π, π£πππ€ i to every party π β [ π ] upon receiving the ο¬rst h ππππ, π£, π ππππ , π, π£πππ€ i message from π , do if verifySignature ( ππ π , h ππππ, π£, π£πππ€ i , π ) = lockCorrect ( π£πππ€, π£, π ππππ ) = then πππππ β πππππ βͺ {( π, π )} if | πππππ | = π β π then send h ππππππ‘, π£, πππππ , π£πππ€ i to every party π β [ π ] output π£ and terminateAlgorithm 11 keyCorrect ( π£πππ€, π£, π πππ¦ ) if validate ( π£ ) = thenreturn if π£πππ€ = thenreturn if (cid:12)(cid:12) { π |β( π, π ) β π πππ¦ } (cid:12)(cid:12) β₯ π β π and β( π, π ) β π πππ¦ verifySignature ( ππ π , h ππβπ, π£, π£πππ€ i , π ) = thenreturn elsereturn Algorithm 12 lockCorrect ( π£πππ€, π£, π ππππ ) if π£πππ€ = thenreturn if |{ π |β( π, π ) β π ππππ }| β₯ π β π and β( π, π ) β π πππ¦ verifySignature ( ππ π , h πππ¦, π£, π£πππ€ i , π ) = thenreturn elsereturn Algorithm 13 commitCorrect ( π£πππ€, π£, π ππππππ‘ ) if |{ π |β( π, π ) β π ππππππ‘ }| β₯ π β π and β( π, π ) β π πππ¦ verifySignature ( ππ π , h ππππ, π£, π£πππ€ i , π ) = thenreturn elsereturn Lemma 5.
If two messages from a given π£πππ€ are correct, they both have the same value π£ . In addition, if a nonfaultyparty sends a πππ¦ , a ππππ or a ππππππ‘ message, then that message is correct. Proof.
First, observe two correct key messages h πππ¦, π£, π, π, π£πππ€ i and h πππ¦, π£ β² , π β² , π β² , π£πππ€ i . Since the messagesare correct, keyCorrect ( π£πππ€, π£, π ) =
1, which means that π contains π β π pairs of the form ( π, π ) with diο¬erentvalues π β [ π ] such that verifySignature ( ππ π , h ππβπ, π£, π£πππ€ i , π ) =
1. In other words, π contains signatures from π β π parties on the message h ππβπ, π£, π£πππ€ i . Similarly, π β² contains signatures from π β π parties on the message h ππβπ, π£ β² , π£πππ€ i . Every nonfaulty party sends only one such signature in each view to all parties in an ππβπ message.Now, since 2 ( π β π ) = π + ( π β π ) β₯ π + π +
1, there are at least π + π and π β² , and out of those parties at least one is nonfaulty. That nonfaulty party sends only one such message,so π£ = π£ β² . Now, before sending a πππ¦ message, a nonfaulty party π ο¬nds that | ππβπππ | β₯ π β π . Party π only addsa tuple ( π, π£, π πππ¦ , π πππππ‘πππ , π, π ) to ππβπππ after receiving the ο¬rst h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π, π£πππ€ i message from π such that verifySignature ( ππ π , h ππβπ, π£, π£πππ€ i , π ) = PEVerify (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates. Since PEVerify terminated, keyCorrect ( π, π£, π πππ¦ ) =
1, and thus validate ( π£ ) =
1. Otherwise the ο¬rst condition in keyCorrect wouldbe true and the output would be 0 instead. If at any point π sees that two such tuples would be added with diο¬erentvalues π£ β π£ β² , π sends an πππ’ππ£ππππ‘π message instead and doesnβt send a πππ¦ message. Therefore, when sending amessage h πππ¦, π£, π, π£πππ€ i it does so with π containing π β π pairs of the form ( π, π ) with diο¬erent values π such that verifySignature ( ππ π , h ππβπ, π£, π£πππ€ i , π ) = validate ( π£ ) =
1, and thus the message is correct.Now observe two messages h ππππ, π£, π, π, π£πππ€ i and h ππππ, π£ β² , π β² , π β² , π£πππ€ i such that lockCorrect ( π£πππ€, π£, π ) = lockCorrect ( π£πππ€, π£ β² , π β² ) =
1. Similarly to the case above, π contains signatures from at least π β π parties on themessage h πππ¦, π£, π£πππ€ i . Out of those π β π parties, at least π + π sends onlyone such signature per view in a πππ¦ message, and as stated above each πππ¦ message sent by a nonfaulty party iscorrect. Since the πππ¦ message is correct, its value is the same as the value of all correct πππ¦ messages sent in π£πππ€ .Therefore, comparing the two values π£ and π£ β² to the value of all correct πππ¦ messages π£ β²β² , it must be the case that π£ = π£ β²β² = π£ β² . In addition, before sending a message h ππππ, π£, π, π, π£πππ€ i , a nonfaulty party π ο¬nds that | πππ¦π | β₯ π β π .Party π only add a pair ( π, π ) to πππ¦π after receiving the ο¬rst correct h πππ¦, π£, π, π, π£πππ€ i message from party π such that verifySignature ( ππ π , h πππ¦, π£, π£πππ€ i , π ) =
1. As shown above, all correct πππ¦ messages in a given π£πππ€ have the samevalue π£ , so at that point in time πππ¦π contains π β π tuples with signatures on the message h πππ¦, π£, π£πππ€ i , and thus π βs ππππ message is correct as well. The exact same arguments can be made for showing that ππππππ‘ messages have the same8 Abraham et al.value π£ , and that if a nonfaulty party sends a ππππππ‘ message in line 33 then the message is correct. Finally, if a nonfaultyparty sends the message h ππππππ‘, π£, π, π£πππ€ i message in line 3, then it ο¬rst veriο¬ed that commitCorrect ( π£πππ€, π£, π ) = (cid:3) Lemma 6.
If some party sends a h ππππππ‘, π£, π, π£πππ€ i message such that commitCorrect ( π£πππ€, π£, π ) = , then for any π£πππ€ β² β₯ π£πππ€ there exist π + nonfaulty parties that never send an h ππβπ, π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ π β² , π£πππ€ β² i message with π£ β² β π£ . Proof.
We will prove inductively that for any π£πππ€ β² β₯ π£πππ€ , there must exist π + π£πππ€ β² = π£πππ€ . Since some party sends a h ππππππ‘, π£, π, π£πππ€ i message such that lockCorrect ( π£πππ€, π£, π ) = π contains π β π tuples ( π, π ) with diο¬erent values π β [ π ] such that verifySignature ( ππ π , h ππππ, π£, π£πππ€ i , π ) =
1. Outof those parties at least one was nonfaulty. A nonfaulty party π only sends such a signature π in a ππππ message.Before sending a ππππ message, π receives π β π correct πππ¦ messages, and at least one of those was sent by a nonfaultyparty π . From Lemma 5, all of those messages contained the same value π£ . Before sending that πππ¦ message, π found that | ππβπππ | β₯ π β π . Party π only adds a tuple to ππβπππ after receiving the ο¬rst ππβπ message from each party. Before addinga tuple ( π, π£, π πππ¦ , π πππππ‘πππ , π, π ) to ππβπππ , π veriο¬es that there does not exist a tuple ( π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π β² , π β² ) in ππβπππ with π£ β π£ β² . If such a tuple exists, π ο¬nds that the condition in line 12 is true and it sends an πππ’ππ£ππππ‘π messageinstead. Since it didnβt do so, all π β π echo messages it received had the same value π£ that π sent in its πππ¦ message.Out of those π β π messages, at least π + ππβπ message to all parties in each view, and thus those π + ππβπ message with any value π£ β² β π£ in π£πππ€ .Assume the claim holds for every π£πππ€ β²β² such that π£πππ€ β² > π£πππ€ β²β² β₯ π£πππ€ . Since lockCorrect ( π£πππ€, π£, π ) = π contains π β π tuples ( π, π ) with diο¬erent values π β [ π ] such that verifySignature ( ππ π , h ππππ, π£, π£πππ€ i , π ) = π β π parties, at least π + π only sends such a signature π ina ππππ message. In addition, before sending a ππππ message, every one of those parties sets its ππππ π ο¬eld to π£πππ€ .Let the set of those nonfaulty parties be πΌ . It is important to note that the ο¬eld ππππ π only grows throughout theprotocol, so every one of the parties π β πΌ has ππππ π β₯ π£πππ€ from that point on. Now assume by way of contradic-tion that some party π β πΌ sent an h ππβπ, π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ π β² , π£πππ€ β² i message with π£ β² β π£ . Before doing that, itoutput ( π β² , π£ β² , π β² πππ¦ ) , π β² πππππ‘πππ in PE π,π£πππ€ such that π£πππ€ > π β² β₯ ππππ π β₯ π£πππ€ . From the Completeness and Exter-nal Validity properties of the PE protocol, keyCorrect ( π β² , π£ β² , π β² πππ¦ ) =
1, so π β² πππ¦ contains π β π pairs ( π, π ) such that verifySignature ( ππ π , h ππβπ, π£ β² , π β² i , π ) =
1. As discussed above, each nonfaulty party only sends such a signature in anecho message in view π β² . However, π£πππ€ β² > π β² β₯ π£πππ€ , so by assumption there exist π + π β² . Any set of π β π parties that sent the relevant signatures must have at least one party in commonwith the π + (cid:3) The following lemmas show that the system retains liveness and makes progress. This is done in two parts. First ofall, the ο¬rst two lemmas show that if some party doesnβt terminate in a given view, it eventually reaches the next view.The next two lemmas then show that if in any view the binding value of the PE protocol is set to be the input of aparty that was nonfaulty when calling the protocol, then if all parties reach that view they terminate in it as well. Theaforementioned event takes place with constant probability, so these two ideas can be combined to show that someparty eventually terminates with high probability. This is done by showing that until this happens, parties advanceeaching Consensus for Asynchronous Distributed Key Generation 29through diο¬erent views, and in each one they have a constant probability of terminating. It is then left to show thatonce the ο¬rst nonfaulty party completes the protocol, eventually all nonfaulty parties do as well. Definition 4.
A nonfaulty party π is said to reach a π£πππ€ if at any point its local π£πππ€ π ο¬eld equals π£πππ€ . Similarly, anonfaulty party π is said to be in π£πππ€ if its local π£πππ€ π ο¬eld equals π£πππ€ at that time. Lemma 7.
Let π₯ π be the input of a nonfaulty party π . If validate ( π₯ π ) = , then at any point in the protocol keyCorrect ( πππ¦ π ,πππ¦ _ π£ππ π , πππ¦ _ ππππ π π ) = . In addition, lockCorrect ( ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π π ) = at all times in the protocol. Proof. If π hasnβt updated its local πππ¦ π , πππ¦ _ π£ππ π , πππ¦ _ ππππ π ο¬elds, then πππ¦ π = πππ¦ _ π£ππ π = π₯ π and πππ¦ _ ππππ π π = β₯ .By assumption validate ( π₯ π ) =
1, so keyCorrect ( πππ¦ π , πππ¦ _ π£ππ π , πππ¦ _ ππππ π _ π ) doesnβt return 0 when checking whetherthe value is externally valid and returns 1 when checking if πππ¦ =
0. If π updated its local πππ¦ π , πππ¦ _ π£ππ π , πππ¦ _ ππππ π π ο¬elds in some π£πππ€ β² , then after doing so it sent the message h πππ¦, π£, π πππ¦ , π, π£πππ€ β² i , where π£ = πππ¦ _ π£ππ π , π πππ¦ = πππ¦ _ ππππ π π and π£πππ€ β² = πππ¦ π . From Lemma 5, the message is correct which means that keyCorrect ( πππ¦ π , πππ¦ _ π£ππ π , πππ¦ _ ππππ π π ) =
1. Similarly, if π hasnβt updated its ππππ π , ππππ _ π£ππ π and ππππ _ ππππ π π ο¬elds, then ππππ π = lockCorrect ( ππππ π , ππππ _ π£ππ π ,ππππ _ ππππ π π ) =
1. On the other hand, if π updated these local ο¬elds, then it sent the message h ππππ, π£, π ππππ , π, π£πππ€ i afterwards with π£ = ππππ _ π£ππ π , π ππππ = ππππ _ ππππ π π and π£πππ€ β² = ππππ π . From Lemma 5, the message is correct and thus lockCorrect ( ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π π ) = (cid:3) Lemma 8.
If every nonfaulty party π has an input π₯ π such that validate ( π₯ π ) = , all nonfaulty parties participate in theprotocol, and no nonfaulty party terminates during any π£πππ€ β² such that π£πππ€ β² < π£πππ€ , then all nonfaulty parties reach π£πππ€ . Proof.
We will prove the claim inductively on π£πππ€ . First, all nonfaulty parties start in π£πππ€ =
1. Now observe some π£πππ€ > h ππππππ‘, π£, π, π£πππ€ β² i message in line 33 for any π£πππ€ β² < π£πππ€ . If somenonfaulty party did send such a message in line 33, then it did so in π£πππ€ β² , and terminated immediately afterwards,contradicting the conditions of the lemma. By the induction hypothesis, all nonfaulty parties reach π£πππ€ β
1. If somenonfaulty party π sends the message h πππππ,π, π£, π πππ¦ , π πππππ‘πππ , ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π π , π£πππ€ β i in line 7, it in-crements π£πππ€ π from π£πππ€ β π£πππ€ . Party π only sends such a message if it outputs ( π, π£, π πππ¦ ) , π πππππ‘πππ in PE π,π£πππ€ and ο¬nds that π£πππ€ β β€ π β¨ π < ππππ π . Every nonfaulty party π that receives that message sees that the same conditionholds in the processFaults algorithm. From Lemma 7, π also sees that lockCorrect ( ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π π ) = PE , eventually PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates. At thatpoint π forwards the message to all parties and advances π£πππ€ π from π£πππ€ β π£πππ€ . In addition, if π sends a h πππππ,π, π£, π πππ¦ , π πππππ‘πππ , π, ππ£, π ππππ , π£πππ€ β i message in line 4, it ο¬rst received the same message and found that lockCorrect ( π, ππ£, π ππππ ) =
1, and that π£πππ€ β β€ π β¨ π < ππππ π . Furthermore, at some point, PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) ,π πππππ‘πππ ) terminates. After sending the message, π increments π£πππ€ π . Every nonfaulty π that receives the messagesees that the same conditions hold. From the Agreement on Veriο¬cation property of PE π eventually also sees that PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates, and increments π£πππ€ π .On the other hand, if at any point π sends an πππ’ππ£ππππ‘π message with two sets of values π, π£, π πππ¦ , π πππππ‘πππ and π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ in line 13, then it ο¬rst received two ππβπ messages h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π£πππ€ β i and h ππβπ, π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π£πππ€ β i such that ( π, π£, π πππ¦ ) β ( π β² , π£ β² , π β² πππ¦ ) . That is because π only sends such a message after trying to add a tuple ( π, π£, π πππ¦ , π πππππ‘πππ , π, π ) to ππβπππ and ο¬nding that there exist some tuple ( π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ , π β² , π β² ) with ( π, π£, π πππ¦ ) β ( π β² , π£ β² , π β² πππ¦ ) . Party π only reaches that point in the algorithm after ο¬nding that PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) PEVerify π,π£πππ€ (( π β² , π£ β² , π β² πππ¦ ) , π πππππ‘πππ ) terminated. Every nonfaulty party π that receives the message also sees that ( π, π£, π πππ¦ ) β ( π β² , π£ β² , π β² πππ¦ ) in the processFaults algorithm. From the Agreement on Veriο¬cation property of PE , eventu-ally PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) and PEVerify π,π£πππ€ (( π β² , π£ β² , π β² πππ¦ ) , π πππππ‘πππ ) terminate as well. At that point, π forwards the message and advances π£πππ€ π from π£πππ€ β π£πππ€ . In addition, if some party π sends an πππ’ππ£ππππ‘π mes-sage in line 9, it ο¬rst receives the same message with the values π, π£, π πππ¦ , π πππππ‘πππ and π β² , π£ β² , π β² πππ¦ , π β² πππππ‘πππ such that ( π, π£, π πππ¦ ) β ( π β² , π£ β² , π β² πππ¦ ) and at some point PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) and PEVerify π,π£πππ€ (( π β² , π£ β² , π β² πππ¦ ) , π β² πππππ‘πππ ) terminate. After sending the message, π increments π£πππ€ π . Every nonfaulty π that receives the message sees that thesame conditions hold, and from the Agreement on Veriο¬cation property eventually sees that PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) and PEVerify π,π£πππ€ (( π β² , π£ β² , π β² πππ¦ ) , π β² πππππ‘πππ ) terminate, and increments π£πππ€ π as well.Now it is left to show that there exists some nonfaulty party that sends either a πππππ message or an πππ’ππ£ππππ‘π message. Assume by way of contradiction no nonfaulty party sends either one of those messages. Every nonfaultyparty π starts π£πππ€ β viewChange ( π£πππ€ β ) and sending h π π’ππππ π‘, π, π£, π πππ¦ , π£πππ€ β i to all parties with π = πππ¦ π , π£ = πππ¦ _ π£ππ π and π πππ¦ = πππ¦ _ ππππ π π . Every nonfaulty party receives that message, and from Lemma 7, keyCorrect ( π, π£, π πππ¦ ) = π has πππ¦ π β₯ π£πππ€ β π would only update πππ¦ π to some value π£πππ€ β² β₯ π£πππ€ β π£πππ€ β² . After receiving those messages, allnonfaulty parties add an element to π π’ππππ π‘ππππ and then ο¬nd that | π π’ππππ π‘ππππ | = π β π , at which point they performsome local computation and participate in PE π,π£πππ€ β . Nonfaulty parties only add a tuple ( π, π£, π πππ¦ ) to π π’ππππ π‘ππππ if keyCorrect ( π, π£, π πππ¦ ) =
1, so the same holds for the value they input to PE π,π£πππ€ β . In other words, all nonfaulty partiesparticipate in PE with externally valid inputs, so from the Termination of Output property of PE , they eventually outputsome value. Observe some nonfaulty π that outputs ( π, π£, π πππ¦ ) , π πππππ‘πππ from PE π,π£πππ€ β . Since π doesnβt send a πππππ message, it sends an h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π, π£πππ€ β i message with π = sign ( π π π , h ππβπ, π£, π£πππ€ β i) . This mustmean that π£πππ€ β > π β₯ ππππ π , because otherwise π would have sent a πππππ message. Every nonfaulty party receivesthat message and sees that verifySignature ( ππ π , h ππβπ, π£, π£πππ€ i , π ) = π is π βs signature on that message. Fromthe Completeness property of PE , for every nonfaulty π eventually PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates,at which point π checks the conditions for sending an πππ’ππ£ππππ‘π message in line 12. By assumption, party π doesnβtsend an πππ’ππ£ππππ‘π message, so it adds an element to ππβπππ . After adding such an element for every nonfaulty party, π sees that | ππβπππ | β₯ π β π and it sends a πππ¦ message. From Lemma 5, every πππ¦ message sent by a nonfaulty party iscorrect. A nonfaulty party also adds a signature π for the message h πππ¦, π£, π£πππ€ β i to every πππ¦ message. Thereforeevery nonfaulty party receives those messages and adds at least π β π elements to πππ¦π . Following similar logic everynonfaulty party then sends a ππππ message, and every nonfaulty party adds at least π β π elements to πππππ . At thatpoint, every nonfaulty party sends a ππππππ‘ message in π£πππ€ β (cid:3) Lemma 9.
If a nonfaulty party π inputs ( π, π£, π πππ¦ ) to PE π,π£πππ€ , then no party sends a message h πππππ, π, π£, π πππ¦ , π πππππ‘πππ ,π, ππ£, π ππππ , π£πππ€ i such that lockCorrect ( π, ππ£, π ππππ ) = and π£πππ€ β€ π or π < π . Proof.
Assume by way of contradiction some party π sends such a message. First of all, note that π only adds a tuple ( π, π£, π πππ¦ ) to π π’ππππ π‘ππππ if π < π£πππ€ . Then, when choosing the tuple with the maximal π , it chooses one with π < π£πππ€ .Every nonfaulty party inputs a tuple ( π, π£, π πππ¦ ) with π β₯
0, and thus if π = π β₯ π . Otherwise, π sent a message withsome π >
0. Now, if lockCorrect ( π, ππ£, π ππππ ) =
1, then π ππππ contains π β π pairs ( π, π ) with diο¬erent values π β [ π ] such that verifySignature ( ππ π , h πππ¦, ππ£, π i , π ) =
1. Out of those signatures, at least π + πΌ . Nonfaulty parties only send such a signature in πππ¦ messages. Before sending aeaching Consensus for Asynchronous Distributed Key Generation 31 πππ¦ message, each one of the parties π β πΌ sets its local πππ¦ π ο¬eld to π . Note that nonfaulty parties only increase theirlocal πππ¦ π ο¬elds, so from this point on, πππ¦ π β₯ π for every π β πΌ . Now, before π inputs ( π, π£, π πππ¦ ) to PE π,π£πππ€ , it seesthat | π π’ππππ π‘ππππ | β₯ π β π . Party π only adds elements to π π’ππππ π‘ππππ after receiving the ο¬rst h π π’ππππ π‘, π, π£, π πππ¦ , π£πππ€ i message from each party. Therefore, π adds tuples to π π’ππππ π‘ππππ as a result of receiving such a message from at least π β π parties. There are π + πΌ , and π received π π’ππππ π‘ messages from π β π diο¬erent parties, so at least oneof the parties from which it received π π’ππππ π‘ messages is in πΌ . Let π β πΌ be that party. Party π sends its local ο¬elds πππ¦ π , πππ¦ _ π£ππ π and πππ¦ _ ππππ π π in its π π’ππππ π‘ message. As shown above, πππ¦ π β₯ π , so when computing which valueto input to PE π,π£πππ€ , π has at least one tuple ( π, π£, π πππ¦ ) β π π’ππππ π‘ππππ such that π β₯ π . When choosing which value toinput, π takes the tuple with the largest value π , so its choice ( π, π£, π πππ¦ ) must have π β₯ π , completing the proof. (cid:3) Lemma 10.
If all nonfaulty parties start π£πππ€ and every nonfaulty π has input π₯ π such that validate ( π₯ π ) = , then withconstant probability all nonfaulty parties terminate during π£πππ€ . Proof.
If at any point some nonfaulty party terminates, it must have sent a ππππππ‘ message to all parties. FromLemma 5 that message is correct, so all nonfaulty parties receive the message and terminate as well. From this pointon we will not deal some of the parties terminating early in π£πππ€ and some not terminating at all. The ο¬rst thing thata nonfaulty party does in π£πππ€ is calling viewChange and sending a π π’ππππ π‘ message to every party with the localο¬elds πππ¦ π , πππ¦ _ π£ππ π and πππ¦ _ ππππ π π . From Lemma 7, keyCorrect ( πππ¦ π , πππ¦ _ π£ππ π , πππ¦ _ ππππ π π ) =
1. Therefore, when anonfaulty party π receives that message, it adds a tuple to π π’ππππ π‘ππππ . After receiving such a message from everynonfaulty party, π ο¬nds that | π π’ππππ π‘ππππ | β₯ π β π , and it starts participating in PE π,π£πππ€ after choosing a tuple from π π’ππππ π‘ππππ as an input. Before a nonfaulty party sends a πππππ or an πππ’ππ£ππππ‘π message it must either output a valuefrom PE π,π£πππ€ , or ο¬nd that PEVerify π,π£πππ€ terminates for some value. Both of those things only happen after completing PE π,π£πππ€ . In other words, all nonfaulty parties participate in PE and wait for it to terminate before any of them proceed tothe next view. Before adding a tuple ( π, π£, π πππ¦ ) to suggestions, every nonfaulty π checks that keyCorrect ( π, π£, π πππ¦ ) = PE protocol with inputs they chose from π π’ππππ π‘ππππ , their input isexternally valid. Combining those two observations, from the Termination of Output property of PE , all nonfaultyparties eventually output some value when running PE . Now the lemma is proven by proving a closely related claim.If in π£πππ€ the binding value π₯ β of PE as deο¬ned in the πΌ -Binding property of the PE protocol is the input of some partythat acted in a nonfaulty manner when it started the PE protocol, then all parties terminate during π£πππ€ . From the πΌ -Binding property of PE this event happens with probability πΌ ( πΌ = in our implementation), so all parties terminateduring π£πππ€ with a constant probability.If the the binding value is indeed the input of a party that acted in a nonfaulty manner when it started PE , then fromthe Binding Veriο¬cation property of PE there is exactly one tuple ( π, π£, π πππ¦ ) for which it is possible that PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates for a nonfaulty π . This prevents a nonfaulty party from sending an πππ’ππ£ππππ‘π message in line 13 becauseonly tuples with those values could be in ππβπππ . In addition, this prevents a nonfaulty π from sending an πππ’ππ£ππππ‘π mes-sage in line 9 because then if the tuples ( π, π£, π πππ¦ ) and ( π β² , π£ β² , π β² πππ¦ ) are diο¬erent, PEVerify π,π£πππ€ would not terminatefor at least one of the tuples. If the aforementioned event take place, from the Completeness and Binding Veriο¬cationproperties of PE every nonfaulty party outputs the tuple ( π, π£, π πππ¦ ) , with some proof π πππππ‘πππ , such that ( π, π£, π πππ¦ ) was the input of a nonfaulty party π to PE . We would now like to show that no nonfaulty party π sends a πππππ mes-sage in π£πππ€ . Before sending a πππππ message in line 7, π makes sure that π£πππ€ β€ π β¨ π < ππππ π . Also, from Lemma 7, lockCorrect ( ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π π ) =
1. This means that if π sends a h πππππ, π, π£, π πππ¦ , π πππππ‘πππ , π, ππ£, π ππππ , π£πππ€ i message in line 7 it does so with π£πππ€ β€ π β¨ π < ππππ π and lockCorrect ( ππππ π , ππππ _ π£ππ π , ππππ _ ππππ π ) =
1. Since2 Abraham et al. ( π, π£, π πππ¦ ) was some nonfaulty partyβs input to the PE protocol, this contradicts Lemma 9. Similarly, no nonfaultyparty π sends a πππππ message in line 4, because before doing so it checks that the same conditions hold and that PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates. As stated above, PEVerify only terminates on the tuple ( π, π£, π πππ¦ ) which is some nonfaulty partyβs input to PEVerify , reaching the same contradiction.Nonfaulty parties only proceed to π£πππ€ + πππππ or an πππ’ππ£ππππ‘π message, so no nonfaultyparty proceeds to π£πππ€ +
1. Since no nonfaulty party sends a πππππ message, each one sends an h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π,π£πππ€ i message after completing the PE π,π£πππ€ call, with π being a signature on the message h ππβπ, π£, π£πππ€ i . When receiv-ing the message, every nonfaulty party π sees that π is indeed a signature on h ππβπ, π£, π£πππ€ i . Then, from the Complete-ness property of PE , PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) eventually terminates. Since π doesnβt send an πππ’ππ£ππππ‘π message in π£πππ€ , it then adds a tuple to ππβπππ . After such a tuple is added for every nonfaulty party, π sees that | ππβπππ | = π β π and it sends a message h πππ¦, π£, π πππ¦ , π, π£πππ€ i to all parties with π being a signature on h πππ¦, π£, π£πππ€ i .From Lemma 5, that message is correct. Therefore, when receiving that message, every nonfaulty party sees that themessage is correct and that π is a signature on h πππ¦, π£, π£πππ€ i , and adds a pair ( π, π ) to πππ¦π . After adding such a pair forevery nonfaulty party, π has | πππ¦π | = π β π and it sends a ππππ message. Using identical arguments, eventually everynonfaulty party sends a ππππππ‘ message and terminates if it hasnβt done so earlier. (cid:3) Theorem 4.
Protocol
NWH is a Validated Asynchronous Byzantine Agreement protocol resilient to π < π Byzantineparties.
Proof.
Each property is proven individually.
Correctness.
If some nonfaulty party outputs the value π£ in π£πππ€ , it ο¬rst sends a h ππππππ‘, π£, π, π£πππ€ i message. Let π£πππ€ be the ο¬rst view (i.e. the one with the lowest value) such that some nonfaulty party sends a h ππππππ‘, π£, π, π£πππ€ i message. First of all, from Lemma 5, nonfaulty parties only send correct ππππππ‘ messages, so h ππππππ‘, π£, π, π£πππ€ i isa correct ππππππ‘ message. Now observe some message h πππ¦, π£ β² , π β² , π β² , π£πππ€ β² i such that keyCorrect ( π£πππ€ β² , π£ β² , π β² ) = π£πππ€ β² β₯ π£πππ€ . Since keyCorrect ( π£πππ€ β² , π£ β² , π β² ) = π β² contains π β π pairs ( π, π ) with diο¬erent values π β [ π ] suchthat verifySignature ( ππ π , h ππβπ, π£ β² , π£πππ€ β² i , π ) =
1. Nonfaulty parties only send such a signature π in an ππβπ message.From Lemma 6, in any π£πππ€ β² β₯ π£πππ€ there exist π + ππβπ message with anyvalue π£ β² β π£ . Out of the π β π parties whose signatures are in π β² , at least one is from one of the π + ππβπ message with any value π£ β² β π£ in π£πππ€ β² . Therefore, it must be the case that π£ β² = π£ . Now, assume somenonfaulty party π sends a ππππππ‘ message in π£πππ€ β² . Before doing so it receives π β π correct ππππ messages, at least oneof which was sent by a nonfaulty party. Before sending that ππππ message, the nonfaulty party receives π β π correct πππ¦ messages. As discussed above, that key message has the value π£ . From Lemma 5, π sends a correct ππππππ‘ messagebecause it is nonfaulty, and every correct ππππππ‘ message sent in π£πππ€ β² has the same value π£ . Finally, after sendingthe ππππππ‘ message, π outputs π£ and terminates. Therefore, all nonfaulty parties that output some value must outputthe value π£ . Validity.
If some nonfaulty party π outputs a value π£ , it ο¬rst sends a h ππππππ‘, π£, π, π£πππ€ i message. As discussed in theproof of the Correctness property, at least π β π parties sent πππ¦ messages in π£πππ€ with the value π£ as well. At least one ofthose parties is nonfaulty. Party π only sends a h πππ¦, π£, π, π i message after receiving an h ππβπ, π, π£, π πππ¦ , π πππππ‘πππ , π, π£πππ€ i message such that PEVerify π,π£πππ€ (( π, π£, π πππ¦ ) , π πππππ‘πππ ) terminates. From the External Validity property of PE , thismeans that keyCorrect ( π, π£, π πππ¦ ) =
1. Now, if validate ( π£ ) = keyCorrect ( π, π£, π πππ¦ ) =
0, so it must be the case that validate ( π£ ) = Termination.
If at any point a nonfaulty party terminates it sends a h ππππππ‘, π£, π, π£πππ€ i message. From Lemma 5the message is correct, so all nonfaulty parties eventually receive the message and terminate as well. Now assumethat every nonfaulty party π has an input π₯ π such that validate ( π₯ π ) = π£πππ€ , and assume no nonfaulty party terminated during π£πππ€ β² for any π£πππ€ β² < π£πππ€ . In thatcase, from Lemma 8 all nonfaulty parties eventually reach π£πππ€ . Then, from Lemma 10, with constant probability allnonfaulty parties terminate during π£πππ€ . In order for a nonfaulty party not to terminate by π£πππ€ , that constant proba-bility event must not have happened in each one of the previous views. The nonfaulty parties run the PE protocol withindependent randomness in each view and thus for any adversaryβs strategy, there is an independent constant prob-ability of terminating in each view. Therefore, the probability of reaching a given view decreases exponentially withthe view number and thus approaches 0 as π£πππ€ grows. In other words, all nonfaulty parties almost-surely terminate. Quality.
Assume some nonfaulty party completed the protocol, otherwise the claim holds trivially. This means thatit at least completed the PE protocol in π£πππ€ =
1. From the πΌ -Binding property of PE , with probability πΌ or greater thebinding value is the input of some party that behaved in a nonfaulty manner when starting PE . Let π be that party and ( π, π£, π ) be its input to the protocol. Using the same arguments as the ones made in Lemma 10, in that case no nonfaultyparty sends a πππππ or an πππ’ππ£ππππ‘π message during π£πππ€ . Then, following similar logic to the one in Lemma 10, everynonfaulty party that hasnβt committed due to a message from an earlier view eventually terminates after sending a ππππππ‘ message with the value π£ proposed by party π . No party can commit due to a message from an earlier viewbecause there is no earlier view. Therefore, every nonfaulty party that participates in π£πππ€ and outputs a value from PE ,terminates and outputs the value π£ that π proposed. Before sending its proposal, π sees that | π π’ππππ π‘ππππ | = π β π . Party π only adds a tuple to π π’ππππ π‘ππππ after receiving the ο¬rst h π π’ππππ π‘, π, π£, π, π£πππ€ i message from each party π β [ π ] . Eachof those tuples must have π < π£πππ€ =
1. At that point no nonfaulty party updated its πππ¦ π , πππ¦ _ π£ππ π and πππ¦ _ ππππ π π ο¬elds, so they send messages with π =
0. Since at least one of the π β π messages was sent by a nonfaulty party, thereexists some ( π, π£, π ) β π π’ππππ π‘ππππ such that π =
0, and as shown above there is no such tuple with π >
0. Therefore,when computing its input to PE π, , π sees that the tuple with maximal π in π π’ππππ π‘ππππ has π =
0. Party π then uses ( , π₯ π , β₯) as input to PE , with π₯ π being its input to the NWH protocol. As shown above, with constant probability allnonfaulty parties that start π£πππ€ output π₯ π , completing the proof. (cid:3) The protocol is a simple reduction from a Validated Asynchronous Byzantine Agreement protocol to an AsynchronousDistributed Key Generation protocol. Parties start oο¬ by sending each other DKG shares. After receiving such a sharefrom at π β π parties, every party aggregates the shares, and inputs the aggregated DKG transcript into the NWH protocol. The protocol is called with an external validity function checking whether a DKG transcript is valid. Aftercompleting the
NWH protocol with some output dkg , all parties complete the
ADKG protocol, outputting the samevalue. From the properties of the
NWH protocol, all parties eventually output the same DKG transcript, and since itmust be externally valid, that transcript veriο¬es.
Theorem 5.
Protocol
ADKG is an Asynchronous Distributed Key Generation protocol resilient to π < π Byzantineparties.
Proof.
Each property is proven individually.4 Abraham et al.
Algorithm 14
ADKG π π βππππ β β β² π βππππ is a multiset for all π β [ π ] do share π,π β DKGSh ( sk π ) send h share π,π i to party π upon receiving the ο¬rst h π βπππ π,π i message from π , do if DKGShVerify ( pk π , share π,π ) = then π βππππ β π βππππ βͺ { π βπππ π,π } if | π βππππ | = π β π then prop β DKGAggregate ( π βππππ ) call NWH with input prop and external validity function
DKGVerify upon
NWH terminating with output dkg , do output dkg and terminateSecurity Preservation. We see that if ( DKGSh , DKGShVerify , DKGAggregate , DKGVerify ) satisο¬es security preser-vation with regard to a concurrent adversary for some threshold application, then ADKG also satisο¬es security preser-vation for the same application. Indeed, should our adversary expect to receive an honest DKG share at any point inthe protocol, then this can be modelled as an adversary making concurrent requests to a
DKGSh oracle.
Correctness.
Follows immediately from the correctness of ( DKGSh , DKGShVerify , DKGAggregate , DKGVerify ) . Agreement.
If two nonfaulty parties π, π complete the protocol with the outputs dkg , dkg β² , then they ο¬rst completedthe NWH protocol with that same output. By the Agreement property of the
NWH protocol, dkg = dkg β² . Furthermore,from the Validity property of the NWH protocol,
DKGVerify ( dkg ) = Termination.
If all nonfaulty parties participate in the protocol, they all send a share of a DKG to all parties. Everynonfaulty party π then receives a message h share π,π i from every nonfaulty party π , sees that DKGShVerify ( pk π , share π,π ) = π βππππ . After adding such a value for every nonfaulty party, π sees that | π βππππ | = π β π , it aggregatesthe shares to a single proposal, and starts participating in NWH with that proposal. Note that prop is an aggregation of π β π shares share π,π such that DKGShVerify ( pk π , share π,π ) =
1, and thus
DKGShVerify ( prop ) =
1. All nonfaulty partiesuse
DKGVerify as their external validity function, so every nonfaulty party has an externally valid input. Therefore,from the Termination property of
NWH , all parties almost-surely complete
NWH , output some value, and terminate. (cid:3)
In this section we make suggestions as to which cryptography algorithms to instantiate our Broadcast, Gather, Pro-posal Election, No Waitinβ HotStuο¬, and A-DKG protocols with. We then analyse the eο¬ciency of our protocols underthe suggested cryptography algorithms. Unlike in the introduction we will keep track of a cryptographic security pa-rameter π which is the number of bits required to ensure the cryptographic algorithm is secure against computationaladversaries. All our protocols rely on the use of an asynchronous broadcast protocol. We can instantiate a broadcast protocol for amessage of π words where the total number of words sent in all messages is π ( π log ( π ) π + π Β· π ) .eaching Consensus for Asynchronous Distributed Key Generation 35We suggest the use of the a broadcast protocol by Cachin and Tessaro [16] described in Appendix A which relieson a vector commitment. For the vector commitment we consider using Merkle-Trees. Merkle trees have commitmentsize π = π ( π ) , opening proof size π = π ( log ( π ) π ) , and concretely are very fast to prove and verify. Theoretically it ispossible to reduce the opening proof size down to π ( ) using SNARKs, but this comes at the cost of a trusted setup andconcretely high proving time. The protocol requires a constant number of rounds (3 overall). The following theoremis proven in Appendix A.2. Theorem 6.
To broadcast a message π of size π , the total number of words sent in all messages is π ( π Β· ( π + π ) + π Β· π ) words, where π is the number of words in a commitment and π is the number of words in a proof. The
Gather protocol from Section 3 relies solely on the existence of a broadcast protocol. We instantiate
Gather suchthat the total number of words sent overall is π ( ππ log π + ππ ) .We use the broadcast protocol evaluated in Section 7.1 which has complexity π ( π ) = π ( π log ( π ) π + π Β· π ) . Usingthe result from Theorem 7: π ( ππ ( π )) = π ( π log ( π ) π + π Β· π ) . The implementation in this paper requires 3 broadcast rounds, and each one of those requires a constant number ofrounds. Therefore, overall the
Gather protocol requires a constant number of rounds.
Theorem 7.
If protocol
Gather is run with inputs of size π then π ( ππ ( π )) words are sent overall where π ( π ) is thecomplexity of a broadcast for π words. Proof.
Overall in the protocol, each party broadcasts its input once and vectors of size π = π ( π ) twice. There are π ( π ) such broadcasts throughout the protocol, so overall the number of words sent is π ( ππ ( π )) . (cid:3) The PE protocol from Section 4 relies on the existence of a gather protocol and a threshold VRF. We instantiate PE such that the total number of words send overall is π ( ππ log ( π ) + ππ ) .We use the broadcast protocol evaluated in Section 7.1 which has complexity π ( π ) = π ( π log ( π ) π + π Β· π ) . Inaddition, we use the gather protocol evaluated in Section 7.2 which has complexity π ( π ) = π ( π log ( π ) π + π Β· π ) . Forthe threshold VRF we suggest the use of the threshold VUF by Gurkan et al. [23]. In the random oracle model we canthen instantiate a threshold VRF by hashing the function evaluation. This threshold VRF has π π = π ( ππ ) sized dkg shares, π = π ( ππ ) sized dkg s, π π = π ( π ) sized evaluation shares (with their respective proofs), and π = π ( π ) sizedevaluations. Using the result from Theorem 8 π ( π Β· π π + π π π + π ( π + π ) + π ( π )) = π ( π Β· π + π ππ + π log ( π ) π + ( π + ππ ) Β· π + ππ log ( π ) + π ) = π ( ππ log ( π ) + ππ ) . The implementation in this paper requires two rounds of point-to-point messages, as well as a single
Gather roundand a single broadcast round. Both the
Gather and broadcast protocols require a constant number of rounds, so thisyields a constant-round PE protocol. Theorem 8.
If protocol PE is run with inputs of size π then π ( π Β· π π + π π π + π ( π + π ) + π ( π )) words are sent overall,where π ( π ) is the complexity of a gather for π words, π ( π ) is the complexity of a broadcast for π words, π π is the size ofthe DKG shares, π is the size of the DKGs, and π π is the size of the VRF evaluation shares (and proofs). Proof.
Every party starts the protocol by sending DKG shares of size π ( π π ) to every other party, totalling in π ( π π π ) words overall. Afterwards, all parties participate in a Gather protocol with inputs of size π ( π + π ) which requires a totalof π ( π ( π + π )) words to be sent. Following that, parties broadcast sets containing π ( π ) indices, each requiring a singleword. Overall, this requires π ( π ( π )) words to be sent. Finally, every party π sends messages with an index, an evaluationshare, and a proof to every party. This is done whenever π outputs a set π with a tuple ( π, ( prop π , vrf _ dkg π )) from the GatherVerify protocol such that ( π, ( prop π , vrf _ dkg π )) β π β start _ eval π . Immediately after sending such a message, π updates start _ eval π to contain π . As shown in Lemma 3, there is only one such tuple for every π β [ π ] in start _ eval π ,so π sends no more than π such messages. Therefore, this requires a total of π ( π ) messages, each containing π ( π π ) words. Summing all of those terms gives the result. (cid:3) The
NWH protocol from Section 5 relies on the existence of a proposal election protocol and a signature scheme. Weinstantiate
NWH such that the expected total number of words sent overall is π ( ππ log ( π ) + ππ ) . The below theoremshows that the total number of words per view is π ( ππ log ( π ) + ππ ) , and that the total expected number of views is π ( ) , resulting in an expected π ( ππ log ( π ) + ππ ) word complexity overall. The theorem also shows that each viewconsists of a constant number of rounds, resulting in a constant expected number of rounds overall.We use the PE protocol evaluated in Section 7.3 which has complexity π ( π ) = π ( ππ log ( π )+ ππ ) . For the signaturescheme we suggest the use of Schnorr signatures which have size π = π ( π ) . Using the result from: Theorem 9 π ( π π + ππ + π ( π )) = π ( π Β· π + ππ + ππ log ( π ) + ππ ) = π ( ππ log ( π ) + ππ ) . Theorem 9.
If protocol
NWH is run with inputs of size π using the PE protocol described in Section 4, then all nonfaultyparties terminate in π ( ) expected views, where each view consists of a constant number of rounds. In addition, the totalnumber of words sent in each view is π ( π π + ππ + π ( π )) where π ( π ) is the complexity of a proposal election for π ( π ) words and π is the size of the signatures. Proof.
As shown in the proof of the Termination property of the protocol, there is a constant probability πΌ that allnonfaulty parties terminate in π£πππ€ or before it for any one π£πππ€ . Note that when following the proof of the Terminationproperty, the proof of Lemma 10 can actually be used to show that with constant probability no nonfaulty party willever reach a late view. Those probabilities are independent, and thus the number of required views is described by ageometric random variable. From well known properties of such variables, the expected number of views required is πΌ , which is constant.In each view all nonfaulty parties send a constant number of all-to-all messages in the π π’ππππ π‘ , ππβπ , πππ¦ , ππππ and ππππππ‘ rounds, totalling in π ( π ) messages overall (and possibly πππππ and πππ’ππ£ππππ‘π messages). Each messagecontains π words containing a value to be agreed upon, a constant number of additional words and a constant numberof proofs. Each proof contains π ( π ) signatures and indices of parties. Note that the proof output in our implementationof the PE protocol also consists of π ( π ) indices of parties. Overall, when not counting the complexity of the PE protocol,each view in the NWH protocol requires π ( π + ( π + π π ) π ) = π ( π π + ππ ) words. Our result is obtained when weadd π ( π ) the complexity of the PE protocol.Each view consists of a round of point-to-point communication for sending π π’ππππ π‘ , ππβπ , πππ¦ , ππππ and ππππππ‘ messages (and possibly πππππ or πππ’ππ£ππππ‘π messages). In addition, all parties call the PE protocol once per view. Ineaching Consensus for Asynchronous Distributed Key Generation 37the implementation provided above, the PE protocol requires a constant number of rounds, resulting in a constantnumber of rounds per view. (cid:3) The A-DKG protocol from Section 6 relies on the existence of a Validated Asynchronous Byzantine Agreement protocoland DKG algorithms
DKGSh , DKGShVerify , DKGAggregate , DKGVerify . We instantiate A-DKG such that the expectedtotal number of words send overall is π ( ππ log ( π )) .We use the NWH protocol evaluated in Section 7.4 which has expected word complexity π£ ( π ) = π ( ππ log ( π )+ π Β· π ) and the DKG algorithms DKGSh , DKGShVerify , DKGAggregate , DKGVerify from the synchronous DKG of Gurkan etal. [23]. This DKG has π· π = π ( ππ ) sized dkg shares and π· = π ( ππ ) sized dkg s. Using the result from Theorem 9: π ( π π· π + π£ ( π· )) = π ( π Β· π + ππ log ( π ) + π Β· ( ππ )) = π ( ππ log ( π )) . The protocol requires a single round of point-to-point communication for sending DKG shares, and a single call to the
NWH protocol. Since the
NWH protocol requires a constant expected number of rounds, so does the
ADKG protocol.
Theorem 10.
If protocol
ADKG is run using the
NWH protocol described in Section 5, then all nonfaulty parties termi-nate in π ( ) expected views. In addition, the total number of words sent in each view is π ( π π· π + π£ ( π· )) where π£ ( π ) is thecomplexity of a NWH protocol for π ( π ) words, π· π is the size of the DKG shares and π· is the size of the DKGs. Proof.
In the beginning of the protocol, all parties send a DKG share of size π ( π· π ) to all parties, requiring a total of π ( π· π π ) words. The parties then call NWH with an aggregated DKG of size π ( π· ) words. The NWH protocol requiresan expected π£ ( π· ) words to be sent overall, which gives us our result. (cid:3) REFERENCES [1] Ittai Abraham, Yonatan Amit, and Danny Dolev. 2004. Optimal Resilience Asynchronous Approximate Agreement. In
Proceedings of the8th International Conference on Principles of Distributed Systems (Grenoble, France) (OPODISβ04) . Springer-Verlag, Berlin, Heidelberg, 229β239.https://doi.org/10.1007/11516798_17[2] Ittai Abraham, Danny Dolev, and Joseph Y. Halpern. 2008. An Almost-Surely Terminating Polynomial Protocol for Asynchronous ByzantineAgreement with Optimal Resilience. In
Proceedings of the Twenty-Seventh ACM Symposium on Principles of Distributed Computing (Toronto, Canada) (PODC β08) . Association for Computing Machinery, New York, NY, USA, 405β414. https://doi.org/10.1145/1400751.1400804[3] Ittai Abraham, Dahlia Malkhi, and Alexander Spiegelman. 2019. Asymptotically Optimal Validated Asynchronous Byzantine Agree-ment. In
Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing . ACM, New York, NY, USA, 337β346.https://doi.org/10.1145/3293611.3331612[4] Ittai Abraham and Gilad Stern. 2020. Information Theoretic HotStuο¬. In
OPODIS (LIPIcs, Vol. 184) . Schloss Dagstuhl - Leibniz-Zentrum fΓΌr Infor-matik, Dagstuhl, Germany, 11:1β11:16.[5] Michael Backes, Amit Datta, and Aniket Kate. 2013. Asynchronous Computational VSS with Reduced Communication Complexity. In
Topics inCryptology β CT-RSA 2013 , Ed Dawson (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 259β276.[6] Laasya Bangalore, Ashish Choudhury, and Arpita Patra. 2018. Almost-Surely Terminating Asynchronous Byzantine Agreement Revisited. In
Proceedings of the 2018 ACM Symposium on Principles of Distributed Computing (Egham, United Kingdom) (PODC β18) . Association for ComputingMachinery, New York, NY, USA, 295β304. https://doi.org/10.1145/3212734.3212735[7] Zuzana BeerliovΓ‘-TrubΓniovΓ‘ and Martin Hirt. 2007. Simple and Eο¬cient Perfectly-Secure Asynchronous MPC. In
Proceedings of the Advances inCrypotology 13th International Conference on Theory and Application of Cryptology and Information Security (Kuching, Malaysia) (ASIACRYPTβ07) .Springer-Verlag, Berlin, Heidelberg, 376β392.[8] Michael Ben-Or. 1983. Another Advantage of Free Choice (Extended Abstract): Completely Asynchronous Agreement Protocols. In
Proceedingsof the Second Annual ACM Symposium on Principles of Distributed Computing (Montreal, Quebec, Canada) (PODC β83) . Association for ComputingMachinery, New York, NY, USA, 27β30. https://doi.org/10.1145/800221.806707[9] Michael Ben-Or, Ran Canetti, and Oded Goldreich. 1993. Asynchronous Secure Computation. In
Proceedings of the Twenty-Fifth Annual ACMSymposium on Theory of Computing (San Diego, California, USA) (STOC β93) . Association for Computing Machinery, New York, NY, USA, 52β61.https://doi.org/10.1145/167088.167109 [10] Michael Ben-Or, Boaz Kelmer, and Tal Rabin. 1994. Asynchronous Secure Computations with Optimal Resilience (Extended Abstract). In
Proceed-ings of the Thirteenth Annual ACM Symposium on Principles of Distributed Computing (Los Angeles, California, USA) (PODC β94) . Association forComputing Machinery, New York, NY, USA, 183β192. https://doi.org/10.1145/197917.198088[11] Gabriel Bracha. 1984. An Asynchronous [(n - 1)/3]-Resilient Consensus Protocol. In
Proceedings of the third annual ACM symposium on principlesof distributed computing . Association for Computing Machinery, New York, NY, USA, 154β162. https://doi.org/10.1145/800222.806743[12] Gabriel Bracha. 1987. Asynchronous Byzantine Agreement Protocols.
Inf. Comput.
75, 2 (1987), 130β143.[13] Christian Cachin, Klaus Kursawe, Anna Lysyanskaya, and Reto Strobl. 2002. Asynchronous Veriο¬able Secret Sharing and Proactive Cryptosystems.In
Proceedings of the 9th ACM Conference on Computer and Communications Security (Washington, DC, USA) (CCS β02) . Association for ComputingMachinery, New York, NY, USA, 88β97. https://doi.org/10.1145/586110.586124[14] Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. 2001. Secure and Eο¬cient Asynchronous Broadcast Protocols. In
Advances inCryptology β CRYPTO 2001 , Joe Kilian (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 524β541.[15] Christian Cachin, Klaus Kursawe, and Victor Shoup. 2005. Random Oracles in Constantinople: Practical Asynchronous Byzantine Agreement UsingCryptography.
Journal of Cryptology
18, 3 (01 Jul 2005), 219β246. https://doi.org/10.1007/s00145-005-0318-0[16] ChristianCachin and Stefano Tessaro.2005. Asynchronous Veriο¬able Information Dispersal.In
Distributed Computing, 19th International Conference,DISC 2005, Cracow, Poland, September 26-29, 2005, Proceedings . Springer Berlin Heidelberg, Berlin, Heidelberg, 503β504.[17] Ran Canetti and Tal Rabin. 1993. Fast Asynchronous Byzantine Agreement with Optimal Resilience. In
Proceedings of the Twenty-Fifth Annual ACMSymposium on Theory of Computing (San Diego, California, USA) (STOC β93) . Association for Computing Machinery, New York, NY, USA, 42β51.https://doi.org/10.1145/167088.167105[18] Ashish Choudhury and Arpita Patra. 2015. Optimally Resilient Asynchronous MPC with Linear Communication Complexity. In
Proceedings of the2015 International Conference on Distributed Computing and Networking (Goa, India) (ICDCN β15) . Association for Computing Machinery, New York,NY, USA, Article 5, 10 pages. https://doi.org/10.1145/2684464.2684470[19] Danny Dolev and Ruediger Reischuk. 1982. Bounds on information exchange for Byzantine Agreement. In
Proceedings of theο¬rst ACM SIGACT-SIGOPS symposium on Principles of distributed computing - PODC ' . ACM Press, New York, NY, USA, 132β140.https://doi.org/10.1145/800220.806690[20] Pesech Feldman and Silvio Micali. 1997. An Optimal Probabilistic Protocol for Synchronous Byzantine Agreement. SIAM J. Comput.
26, 4 (1997),873β933.[21] Paul Neil Feldman. 1988.
Optimal algorithms for Byzantine agreement . Ph.D. Dissertation. Massachusetts Institute of Technology.[22] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. 1985. Impossibility of distributed consensus with one faulty process.
Journal of theACM
32, 2 (April 1985), 374β382. https://doi.org/10.1145/3149.214121[23] Kobi Gurkan, Philipp Jovanovic, Mary Maller, Sarah Meiklejohn, Gilad Stern, and Alin Tomescu. 2021. Aggregatable Distributed Key Generation.Cryptology ePrint Archive, Report 2021/005. https://eprint.iacr.org/2021/005.[24] Martin Hirt, Jesper Buus Nielsen, and Bartosz Przydatek. 2008. Asynchronous Multi-Party Computation With Quadratic Communication. In
Automata, Languages and Programming β ICALP 2008 (Lecture Notes in Computer Science, Vol. 5126) , Luca Aceto, Magnus M. Halldorsson, andAnna Ingolfsdottir (Eds.). Springer-Verlag, Berlin, Heidelberg, 473β485.[25] Aniket Kate, Yizhou Huang, and Ian Goldberg. 2012. Distributed Key Generation in the Wild. Cryptology ePrint Archive, Report 2012/377.https://eprint.iacr.org/2012/377.[26] Jonathan Katz and Chiu-Yuen Koo. 2006. On Expected Constant-Round Protocols for Byzantine Agreement.
Electron. Colloquium Comput. Complex.
13, 028 (2006).[27] Eleftherios Kokoris-Kogias, Enis Ceyhun Alp, Linus Gasser, Philipp Jovanovic, Ewa Syta, and Bryan Ford. 2018.CALYPSO: Private Data Management for Decentralized Ledgers. Cryptology ePrint Archive, Report 2018/209. To appear in VLDB 2021.[28] Eleftherios Kokoris Kogias, Dahlia Malkhi, and Alexander Spiegelman. 2020. Asynchronous Distributed Key Generation for Computationally-Secure Randomness, Consensus, and Threshold Signatures.. In
Proceedings of the 2020 ACM SIGSAC Conference on Computer and CommunicationsSecurity (CCSβ20) . Association for Computing Machinery, New York, NY, USA, 1751β1767. https://doi.org/10.1145/3372297.3423364[29] Yuan Lu, Zhenliang Lu, Qiang Tang, and Guiling Wang. 2020. Dumbo-MVBA: Optimal Multi-Valued Validated Asynchronous Byzantine Agreement,Revisited. In
Proceedings of the 39th Symposium on Principles of Distributed Computing (Virtual Event, Italy) (PODC β20) . Association for ComputingMachinery, New York, NY, USA, 129β138. https://doi.org/10.1145/3382734.3405707[30] Arpita Patra, Ashish Choudhary, and Chandrasekharan Pandu Rangan. 2009. Simple and Eο¬cient Asynchronous Byzantine Agreement withOptimal Resilience. In
Proceedings of the 28th ACM Symposium on Principles of Distributed Computing (Calgary, AB, Canada) (PODC β09) . Associationfor Computing Machinery, New York, NY, USA, 92β101. https://doi.org/10.1145/1582716.1582736[31] Ewa Syta, Philipp Jovanovic, Eleftherios Kokoris-Kogias, Nicolas Gailly, Linus Gasser, Ismail Khoο¬, Michael J. Fischer, and Bryan Ford. 2017.Scalable Bias-Resistant Distributed Randomness. In (San Jose, CA).[32] Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham. 2019. HotStuο¬: BFT Consensus with Linearity and Respon-siveness. In
Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing (Toronto ON, Canada) (PODC β19) . Association forComputing Machinery, New York, NY, USA, 347β356. https://doi.org/10.1145/3293611.3331591[33] Lidong Zhou, Fred B. Schneider, and Robbert Van Renesse. 2005. APSS: Proactive Secret Sharing in Asynchronous Systems.
ACM Trans. Inf. Syst.Secur.
8, 3 (Aug. 2005), 259β286. https://doi.org/10.1145/1085126.1085127 eaching Consensus for Asynchronous Distributed Key Generation 39
A BACKGROUND: RELIABLE BROADCAST FOR ASYNCHRONOUS SYSTEMS
Throughout our agreement protocol we shall use a reliable broadcast method by Cachin and Tessaro [16] which applieserror correcting codes to Bracha broadcast [12]. The broadcast protocol has communication complexity
O ( π log ( π ) +| π | π ) for π the total number of participants and | π | the size of the message. It can tolerate up to π < π Byzantineadversaries and works in the asynchronous setting.
A.1 Construction
The protocol is extremely similar to Brachaβs famous reliable broadcast protocol [12]. In Brachaβs protocol, the dealerο¬rst sends a message h π£πππ’π,π i to all parties. After receiving the ο¬rst message from the dealer, every nonfaulty party re-sponds with an h ππβπ,π i message. Then, after receiving π β π h ππβπ,π i messages, the parties respond with a h πππππ¦,π i message. In addition, if some party receives π + h πππππ¦,π i messages and it did not send a ready message yet, it alsosends a h πππππ¦,π i message. Finally, after receiving π β π h πππππ¦,π i messages, every party outputs π and terminates.Unfortunately, when sending a large message π , every message sent by the parties contains all of π , yieldinglarge communication costs. Cachin et al. βs clever approach to reducing the communication costs was employing errorcorrection codes in the form of Reed-Solomon encoding. Instead of just sending the message π = ( π , . . . , π β ) , thedealer treats the message as coeο¬cients of a polynomial π ( π₯ ) = Γ βπ = π π Β· π₯ π . Then for every nonfaulty party π thedealer computes a set π π of β β + π + β values on the polynomial π ( π₯ ) . Then the dealer commits to to the vector π = ( π π , . . . , π π ) , and sends each party π the commitment πππ , the set π π , and a proof π π that the π βth element in thecommitted vector is π π . Then, similarly to Brachaβs protocol, after receiving a message and checking that the proofis correct, every party sends an echo message with the same information. Now, after receiving π β π echo messageswith the same commitment and correct proofs, every nonfaulty party π should send a ready message with the samecommitment, with a set π π values and with a proof π π . However, π might not have received the set π π and the proof π π , so in order to be able to compute those values, it interpolates the points in π + ( π, π¦ π ) toa polynomial π of degree β or less, checks that the commitment is indeed a commitment to a vector π = ( π , . . . , π π ) such that each π π is a set of β β + π + β points on the polynomial π ( π₯ ) , and then computes the set of points π π that it shouldhave received, as well as a proof π π that the π βth element in the committed vector is π π for each one of its points. Afterdoing that, π sends a ready message with all of that information to all parties. The exact same procedure takes placewhen sending a ready message after receiving π + π β π ready messages, every nonfaulty party interpolatesthe corresponding points to a polynomial π , computes its coeο¬cients π , . . . ,π β , and outputs the message π β² = ( π , . . . ,π β ) . Lemma 11.
When a nonfaulty party tries to interpolate β + pairs in either the set ππβπππ [ πππ ] or πππππππ [ πππ ] , thereare indeed β + pairs in those sets. Furthermore, for any nonfaulty party, if ( π₯, π¦ ) , ( π₯ β² , π¦ β² ) β ππβπππ [ πππ ] or ( π₯, π¦ ) , ( π₯ β² , π¦ β² ) β πππππππ [ πππ ] , then either π₯ β π₯ β² or ( π₯, π¦ ) = ( π₯ β² , π¦ β² ) . Proof.
The proof only deals with the set ππβπππ [ πππ ] . The exact same arguments can be made for πππππππ [ πππ ] . Anonfaulty party tries to interpolate β + ππβπππ [ πππ ] when it ο¬nds that | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π β₯( π + ) Β· π , for π = β β + π + β . Substituting π : | ππβπππ [ πππ ]| β₯ ( π + ) Β· β β + π + β β₯ ( π + ) Β· β + π + = β +
1. For the second partof the lemma, a nonfaulty party only adds elements of the form (( π β ) Β· π + π, π π,π ) to ππβπππ [ πππ ] such that π β [ π ] after receiving an echo message from party π . However, for any pair π, π β² β N such that π β π β² and π, π β² β [ π ] , it cannotbe the case that ( π β ) Β· π + π = ( π β² β ) Β· π + π β² because the distance between ( π β ) Β· π and ( π β² β ) Β· π is at least π . (cid:3) Algorithm 15
RB Code for party i: ππβπππ [ πππ ] β β , πππππππ [ πππ ] β β for each possible commitment πππ π β β β + π + β if π = π then deο¬ne the β -degree polynomial π as follows: π ( π₯ ) = Γ βπ = π π Β· π₯ π β π β [ π ] π π β ( π (( π β ) Β· π + ) , . . . , π ( π Β· π )) π β ( π , . . . , π π ) πππ β Commit ( π ) for all π β [ π ] do π π β OpenProve ( π, π ) send party π the message h π£πππ’π, πππ, π π , π π i upon receiving the ο¬rst message of the form h π£πππ’π,πππ, π π , π π i from π s.t. | π π | = π , do if OpenProve ( πππ, π π , π, π π ) = then send h ππβπ, πππ, π π , π π i to every party upon receiving the ο¬rst h ππβπ, πππ, π π , π π i messages from π s.t. (cid:12)(cid:12) π π (cid:12)(cid:12) = π , do if OpenVerify ( πππ, π π , π, π π ) = then let π π = ( π π, , . . . , π π,π ) ππβπππ [ πππ ] β ππβπππ [ πππ ] βͺ {(( π β ) Β· π + π, π π,π )} π β[ π ] if π hasnβt sent a ready message and | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π then interpolate β + ππβπππ [ πππ ] to a polynomial π β² β π β [ π ] π β² π β ( π β² (( π β ) Β· π + ) , . . . , π β² ( π Β· π )) π β² β ( π β² , . . . , π β² π ) if Commit ( π β² ) = πππ then π π β OpenProve ( π β² , π ) send h πππππ¦,πππ, π β² π , π π i to every party upon receiving the ο¬rst h πππππ¦, πππ, π π , π π i messages from π s.t. (cid:12)(cid:12) π π (cid:12)(cid:12) π , do if OpenVerify ( πππ, π π , π, π π ) = then let π π = ( π π, , . . . , π π,π ) πππππππ [ πππ ] β πππππππ [ πππ ] βͺ {(( π β ) Β· π + π, π π,π )} π β[ π ] if π hasnβt sent a ready message and | πππππππ [ πππ ]| β₯ ( π + ) Β· π then interpolate β + πππππππ [ πππ ] to a polynomial π β² β π β [ π ] π β² π β ( π β² (( π β ) Β· π + ) , . . . , π β² ( π Β· π )) π β² β ( π β² , . . . , π β² π ) π π β OpenProve ( π β² , π ) send h πππππ¦,πππ, π β² π , π π i to every party if | πππππππ [ πππ ]| β₯ ( π β π ) Β· π then interpolate β + πππππππ [ πππ ] to a polynomial π β² let π β² π be the π β² π‘β coeο¬cient in π β² and let π β² = ( π β² , . . . , π β² β ) output π β² and terminate Lemma 12.
If two nonfaulty parties π, π send the messages h πππππ¦,πππ, π π , π π i and h πππππ¦, πππ β² , π π , π π i , then πππ = πππ β² . Proof.
Let π β² , π β² be the ο¬rst nonfaulty parties that sent messages with the values πππ, πππ β² respectively. Since π β² is the ο¬rst nonfaulty party to send such a message, it couldnβt have received a h πππππ¦,πππ, π π , π π i message fromany party other than the π faulty parties before sending such a message. The only other way for π β² to send such aeaching Consensus for Asynchronous Distributed Key Generation 41message is after ο¬nding that | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π . Since π β² adds π elements to ππβπππ [ πππ ] after receiving an h ππβπ, πππ, π π , π π i from party π , this means it received such echo messages from π β π parties. Similarly, π β² receivedan h ππβπ, πππ β² , π π , π π i message from π β π parties. Since 2 ( π β π ) = π + ( π β π ) β₯ π + π + π β² and π β² received thoseready messages from at least π + πππ = πππ β² . (cid:3) Lemma 13.
Let π = β β + π + β be deο¬ned as it is in the protocol. If a nonfaulty party π sends the message h πππππ¦, πππ, π π , π π i ,then | π π | = π and OpenVerify ( πππ, π π , π, π π ) = . Proof.
Party π only sends the message h πππππ¦, πππ, π π , π π i if it ο¬nds that | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π or if it ο¬ndsthat | πππππππ [ πππ ]| β₯ ( π + ) Β· π . This can only happen as a result of receiving messages of the form h ππβπ, πππ, π π , π π i from π β π parties, or messages of the form h πππππ¦,πππ, π π , π π i from π + π updates either of its ππβπππ or πππππππ sets, it adds exactly π elements to them. If π sent the messageafter receiving π β π echo messages, then π ο¬rst interpolates β + ( π, π¦ π ) β ππβπππ [ πππ ] to a polynomial π β² , for every π β [ π ] computes π β² π = ( π (( π β ) Β· π + ) , . . . , π ( π Β· π )) , sets π β² = ( π β² , . . . , π β² π ) , and then checks that Commit ( π β² ) = πππ . It then computes π π = OpenProve ( π β² , π ) and sends the message h πππππ¦,πππ, π β² π , π π i . Note that inthat case, πππ is indeed a commitment to π β² , so OpenVerify ( πππ, π β² π , π, π π ) =
1. On the other hand, if π sent the messageafter receiving π + π that sent a h πππππ¦, πππ, π π , π π i message. No nonfaulty party has sent a ready message withthe value πππ at the time π sent the message, so it could have only received ready messages with the value πππ fromthe π faulty parties, and thus | πππππππ [ πππ ]| β€ π Β· π . This means that before sending the message, it received π β π messages of the form h ππβπ, πππ, π π , π π i , interpolated β + ππβπππ [ πππ ] set to a polynomial π β² ,for every π β [ π ] computed π β² π = ( π β² (( π β ) Β· π + ) , . . . π β² ( π Β· π )) and found that Commit (( π β² , . . . , π β² π )) = πππ . Sinceinterpolating β + β or less, this means that πππ is a commitment to π setsof π points on the polynomial π β² , which is of degree β or less. Now, before sending the ready message, π receives π + h πππππ¦, πππ, π π , π π i such that β OpenVerify ( πππ, π π , π, π π ) =
1, and thus each such π π is a set of π points on the polynomial π β² . More precisely, π π = ( π β² (( π β ) Β· π + ) , . . . , π β² ( π Β· π )) . Party π then interpolates β + ( π, π β² ( π )) β πππππππ [ πππ ] to a polynomial, and since π β² is of degree β or less, that polynomial must be π β² . Finally, π computes π β² π = ( π β² (( π β ) Β· π + ) , . . . , π β² ( π Β· π )) for every π β [ π ] , π β² = ( π β² , . . . , π β² π ) and π π = ( OpenProve ( π β² , π )) .After computing those values, π sends h πππππ¦,πππ, π β² π , π π i to all parties. Clearly, in this case (cid:12)(cid:12) π β² π (cid:12)(cid:12) = π . In addition, since πππ is a commitment to π β² , it is also the case that OpenVerify ( πππ, π β² π , π, π π ) = (cid:3) Theorem 11.
Protocol π π΅ is a reliable broadcast protocol resilient to π < π Byzantine parties.
Proof.
We will prove each property separately. In the proof, let π = β β + π + β , as deο¬ned in the protocol. Validity.
If the dealer is nonfaulty, it computes π ( π₯ ) = Γ βπ = π π Β· π₯ π , computes π π = ( π (( π β ) Β· π + ) , . . . π ( π Β· π )) for every π β [ π ] and sets π = ( π , . . . π π ) . Afterwards, the dealer computes πππ = Commit ( π ) and then for everyparty π it computes π π = OpenProve ( π, π ) , and sends π the message h π£πππ’π,πππ, π π , π π i . Every nonfaulty party π thatsends an echo message does so after receiving the previous message and sends the message h ππβπ, πππ, π π , π π i . Thenonfaulty parties send only one echo message, so every nonfaulty party receives no more than π messages of the form h ππβπ, πππ β² , π π , π π i with πππ β² β πππ . Assume by way of contradiction some nonfaulty party sends a ready message h πππππ¦,πππ β² , π β² , π β² i with πππ β² β πππ , and let π be the ο¬rst nonfaulty party that doe so. Since π is the ο¬rst nonfaultyparty to send such a message, at the time it sent the message it could have only received h πππππ¦, πππ β² , π π , π π i message2 Abraham et al.with πππ β² β πππ from the π faulty parties. Note that π can either add exactly π elements to ππβπππ [ πππ β² ] or no elementsat all after receiving each of those messages, and thus at that time | ππβπππ [ πππ β² ]| β€ π Β· π < ( π β π ) Β· π . This means π must have sent the message as a result of ο¬nding that | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π , which could only happen afterreceiving h ππβπ, πππ β² , π π , π π i messages from π β π parties. However, π β π β₯ π +
1, so at least one of those parties isnonfaulty. As discussed above, every nonfaulty party that sends an echo message sends one with the value πππ β πππ β² ,reaching a contradiction. Now observe some nonfaulty party π that completes the protocol. Before doing so, it foundthat for some πππ β² | πππππππ [ πππ β² ]| β₯ ( π β π ) Β· π . Party π adds exactly π elements to πππππππ [ πππ β² ] after receiving h πππππ¦,πππ β² , π π , π π i from some party π that passes some veriο¬cation tests. As shown above, no more than π suchmessages could have been sent for any πππ β² β πππ , in which case | πππππππ [ πππ β² ]| β€ π Β· π < ( π β π ) Β· π , so πππ β² = πππ .Any pair (( π β )Β· π + π, π π,π ) that π added to πππππππ [ πππ ] was added after ο¬nding that OpenVerify ( πππ, π π , π, π π ) = π π as ( π π, , . . . , π π,π ) . Seeing as πππ is a commitment to ( π π , . . . , π π ) , it must be the case that π π,π = π (( π β )Β· π + π ) .Now, before completing the protocol π interpolates β + ( π, π ( π )) on the polynomial π of degree β or less, andthus it computes π , then computes its coeο¬cients π , . . . ,π β , and ο¬nally outputs π = ( π , . . . ,π β ) . Agreement.
Let π , π be two nonfaulty parties that output the messages π, π β² respectively. Before outputting thosemessages, π found that for some value πππ | πππππππ [ πππ ]| β₯ ( π β π ) Β· π . This means that π received a message of theform h πππππ¦,πππ, π π , π π i from π β π parties such that for each one OpenVerify ( πππ, π π , π, π π ) =
1. The same can besaid about π having received similar messages with some value πππ β² . Since 2 ( π β π ) = π + ( π β π ) β₯ π + π + π and π received the aforementioned messages from at least π + πππ = πππ β² .Observe the ο¬rst nonfaulty party π β that sent a ready message with the commitment πππ . At that time, π β couldhave received no more than π ready messages with the commitment πππ , and as discussed in the proof of the Validityproperty, this means that | πππππππ [ πππ ]| β€ π Β· π < ( π + ) Β· π . This means that π β decided to send the message afterο¬nding that | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π , interpolated β + ( π, π¦ π ) β ππβπππ [ πππ ] to a polynomial π β² ,computed π β² π = ( π β² (( π β ) Β· π + ) , . . . , π β² ( π Β· π )) for every π β [ π ] . It then set π β² = ( π β² , . . . , π β² π ) and found that Commit ( π β² ) = πππ . Since interpolating β + β or less, this means that πππ is a commitment to π sets of π points on a polynomial of degree β or less. Now, before outputting π and π β² , π and π found that | πππππππ [ πππ ]| β₯ ( π β π ) Β· π . Again, as discussed above, this could only happen after receiving π β π messages of the form h πππππ¦,πππ, π π , π π i such that | π π | == π and OpenVerify ( πππ, π π , π, π π ) = π π is a commitmentto a vector of π points on π β² , and thus π π = ( π β² (( π β ) Β· π + ) , . . . , π β² ( π Β· π )) . Therefore, after receiving those messages,both π and π add (( π β ) Β· π + π, π β² (( π β ) Β· π + π )) to πππππππ [ πππ ] for every π β [ π ] . Those are the only values addedto the set readies, so for every ( π, π¦ π ) β πππππππ [ πππ ] , π¦ π = π β² ( π ) . Choosing any β + ( π, π¦ π ) β πππππππ [ πππ ] ,both π and π then compute the same polynomial π β² ( π₯ ) = Γ βπ = π β² π Β· π₯ π , and output the same message ( π β² , . . . ,π β² β ) . Termination.
If the dealer is nonfaulty, it computes π ( π₯ ) = Γ βπ = π π Β· π₯ π and computes π π = ( π (( π β ) Β· π + ) , . . . , π ( π Β· π )) for every party π β [ π ] . The dealer then sets π = ( π , . . . , π π ) , computes πππ = Commit ( π ) and thenfor every party π it computes π π = OpenProve ( π, π ) and sends π the message h π£πππ’π, πππ, π π , π π i . Every nonfaultyparty then receives that message, ο¬nds that (cid:12)(cid:12) π π (cid:12)(cid:12) = π and OpenVerify ( πππ, π π , π, π π ) = h ππβπ, πππ, π π , π π i message to all parties. Every nonfaulty eventually receives an h ππβπ, πππ, π π , π π i message from every nonfaulty party,ο¬nds that the same conditions hold, parses π π as ( π π, , . . . , π π,π ) and adds (( π β ) Β· π + π, π π,π ) to ππβπππ [ πππ ] forevery π β [ π ] . After doing that, every nonfaulty party π ο¬nds that | ππβπππ [ πππ ]| β₯ ( π β π ) Β· π , and if it hasnβt senta ready message yet, it interpolates β + ππβπππ [ πππ ] to a polynomial π β² and sends a ready message. Fromeaching Consensus for Asynchronous Distributed Key Generation 43Lemma 12, all of the ready messages sent by nonfaulty parties have the same value πππ , and from Lemma 13, if anonfaulty party sends a message h πππππ¦, πππ, π π , π π i then OpenVerify ( πππ, π π , π, π π ) = (cid:12)(cid:12) π π (cid:12)(cid:12) = π for every oneof those messages. Therefore, after receiving each of those messages, every nonfaulty party updates its πππππππ [ πππ ] set and adds π elements to it. After adding π such elements for every nonfaulty π , every nonfaulty party ο¬nds that | πππππππ [ πππ ]| β₯ ( π β π ) Β· π , performs some local computations, and completes the protocol.For the second part of the property, if some nonfaulty party completes the protocol it received π β π messages of theform h πππππ¦, πππ, π π , π π i with the same value πππ such that OpenVerify ( πππ, π π , π, π π ) = (cid:12)(cid:12) π π (cid:12)(cid:12) = π . Out of those π β π messages, at least π β π β₯ π + π + π elements to πππππππ [ πππ ] . After adding π elements for everyone of those π + π sees that | πππππππ [ πππ ]| β₯ ( π + ) Β· π , performs some local computations andsends a message h πππππ¦,πππ, π π , π β π i itself, if it hasnβt done so earlier. From Lemma 12, every nonfaulty party that senta ready message previously also sent one with the same value πππ . From Lemma 13, OpenVerify ( πππ, π π , π, π π ) = (cid:12)(cid:12) π π (cid:12)(cid:12) = π , so after receiving those messages, every nonfaulty party adds π elements to πππππππ [ πππ ] . Finally, after adding π elements to πππππππ [ πππ ] for every nonfaulty party, every nonfaulty party ο¬nds that | πππππππ [ πππ ]| β₯ ( π β π ) Β· π ,performs some local computations, and completes the protocol. (cid:3) A.2 Proof of Theorem 6
Proof.
Let the number of words in the message be β +
1. Throughout the protocol, the dealer starts by sending asingle message to every party containing a commitment and π ( βπ ) words and proofs. Then, every party sends at mostone echo message and one ready message containing a commitment, a proof and a set containing π ( βπ ) words. Overall,there are π ( π ) messages, each containing π words for the commitment, π words for the proof and π ( βπ ) additionalwords. This yields a total of π ( π Β· ( π + π ) + βπ Β· π ) = π ( π Β· ( π + π ) + β Β· π ) words. (cid:3) The protocol can trivially be turned into a Validated Reliable Broadcast protocol,
π π π΅ , by only having parties output π β² in line 38 after checking that validate ( π β² ) =
1. This clearly makes the additional part of the Validity property hold,and doesnβt change the rest of the proof for the Validity and Correctness properties. In the proof of the Terminationproperty, ο¬rst we can note that if some nonfaulty party were to output a message π β² when the dealer is nonfaulty,then from the Validity property it must be the case that π β² = π . This means that if the dealer does have an input π such that validate ( π ) =
1, all nonfaulty parties would reach that point in the protocol, see that validate ( π ) = π β² such that validate ( π β² ) =
1. Using the exact same arguments as the one in the proof of the Termination property, allnonfaulty parties eventually reach the end of the protocol. From the Correctness property, they reach the end of theprotocol with the same message π β² , and thus when checking if validate ( π β² ) = π β²β²