Protocol Execution. thresh-gossip The byzantine agreement protocol πBA is parameterized by a bound f on the corrupt public keys seen by an honest party, and a maximum message size L. The protocol is defined in the 5- graded PKI model, and makes use of the 5-graded f -faulty threshold gossip protocol π(5,f) (Protocol 3) and the 3-round gradecast protocol πgradecast (Protocol 2). Each protocol iteration proceeds as follows: Round -1 (preround): (Executed only a single time) • If Pi is active: Pi invokes the 5-graded πthresh-gossip with T-GradeGoss(sid||preround, −1, Sin), informing everybody of its set Sin.
Protocol Execution. Hereunder we are ready to present the detailed protocol description (as illustrated in Algorithm 4). Specifically, an Dumbo-MVBA instance with identifier id proceeds as:
1. Dispersal phase (line 1-2, 13-18). The n parties activate n concurrent instances of the provable dispersal PD subprotocol. Each party Pi is the designated sender of a particular PD instance PD[ id, i ], through which i can disperse the coded fragments of its input vi across the network.
2. Finish phase (line 3, 19-35). This has a three-round structure to allow all parties consistently quit PD instances. It begins when a sender produces the done proof for its PD instance and multicasts done to all parties through a Done message, and finishes when all parties receive a Finish message attesting that at least 2ƒ + 1 PD instances has been “done”. In addition, once receiving valid Finish, a party invokes abandon() to explicitly quit from all PD instances.
3. Elect-ID phase (line 5). Then all parties invoke the coin scheme Election, such that they obtain a common pseudo-random number l over [n]. The common coin l represents the identifier of a pair of (PD[ id, l ], RC[ id, l ]) instances.
4. Recast-vote phase (line 6-9, 36-39). Upon obtaining the coin l, the parties attempt to agree on whether to invoke the RC[ id, l ] instance or not. This phase has to cope with a major limit of RC subprotocol, that the RC[ id, l ] instance requires all parties to invoke it to reconstruct a com- mon value. To this end, the recast-vote phase is made of a two-step structure. First, each party multicasts its locally recorded lock[l] through RcBallotPrepare message, if the PD[ id, l ] instance actually delivers lock[l]; otherwise, it multicasts through RcBallotPrepare mes- sage. Then, each party waits for up to 2ƒ + 1 RcBallotPrepare from distinct parties, if it sees valid lock[l] in these messages, it immediately activates ABA[ id, l ] with input 1, other- wise, it invokes ABA[ id, l ] with input 0. The above design follows the idea of biased validated binary agreement presented by Xxxxxx et al. in [10], and ABA[ id, l ] must return 1 to each party, when ƒ + 1 honest parties enter the phase with valid lock[l].
5. Recast phase (line 10-12). When ABA[⟨id, l⟩] returns 1, all honest parties would enter this phase and there is always at least one honest party has delivered the valid lock regarding RC[⟨id, l⟩]. As such, the parties can always invoke the corresponding RC[⟨id, l⟩] instance to reconstruct a common value ...
