Leader election Sample Clauses

Leader election. With these notations, we introduce the leader election algorithm which will be a subroutine of RBA. Let Mq denote the set of initial messages that the node q receives from all the nodes (including q itself). The node q verifies the VRF value yj, πj in Mq and sets Uq to be the set of nodes whose VRF values are valid. Then, q computes A = argmin y . the commit message, q enters Step 4, at which q waits for the forward conditions. ∈ ∪ {⊥}

Leader election. The leader election of HBA is the same as RBA.

Leader election. After the completion of the leader nomination phase as a result of the completion of n t parties’ proposal promotions, parties run a leader election protocol using a threshold coin primitive [8] to elect the leader of this view uniformly at random. At the end of the view, parties adopt the “progress” from the leader’s proposal promotion instance, and discard information from other instances. - View-change. Parties broadcast their updated state from the leader’s proposal promotion instance and/or output values and update their cross-view variables as appropriate. Since proposal promotion is similar to a HotStuff view, the guarantees provided by the leader nomination stage are the same as that of a HotStuff view. The leader election phase elects a unique leader at random – this stage guarantees (i) with 2/3 probability, a leader whose proposal promotion completed is elected, and (ii) an adaptive adversary cannot stall progress (since a leader is elected in hindsight). Finally, in the view-change phase, every party broadcasts the “quorum certificates” from the elected leader’s proposal promotion instance to all other parties. Since the protocol uses > 2n/3-sized quorums, if a party is locked (resp. committed) on a given value in a view, there are > 2n/3 parties who hold a key (resp. lock), out of which > n/3 are guaranteed to be honest parties. If a party waits for > 2n/3 view-change messages, due to a simple quorum intersection argument, it will receive a key (resp. lock) from at least one of the parties. This ensures no conflicting value can be proposed in subsequent views, thus ensuring safety. On the other hand, liveness is guaranteed when a party who has completed its proposal promotion instance is chosen as the leader. Since a leader is chosen after the leader nomination stage, a party who has completed proposal promotion is elected with probability > 2/3.

Leader election. This section describes the construction of a verifiable leader election, which is related to the idea of a weak common coin and proposal election. With constant probability all honest parties output an honest leader from VLE, but in other cases parties might disagree on the leader. In both cases, every party’s output must be an asynchronously validated leader according to an asynchronous va- lidity predicate validate. Every honest party starts the protocol believing that it is a valid leader, i.e. with validatei(i) = 1. Since the predicate is consistent, hon- est parties will eventually agree that other honest parties are also valid leaders. In addition, parties can verify each other’s output with a verification protocol, VLEVerify. In the constant probability event described above, in which a single honest leader is elected, this is the only leader that will pass verification in the VLEVerify protocol. Our construction uses techniques inspired by synchronous weak leader election [21] and cryptographic proposal election [3]. The protocol proceeds in 5 rounds described below: Round 1: In the first round, every party shares n random values using a packed AVSS protocol, one for each party. Parties then participate in the packed AVSS instances with every party as dealer. Round 2: In the second round, after completing the Share protocol for t + 1 dealers, party i broadcasts an “attach” message with the set dealersi for which it completed the share protocol. After receiving such a message from party j with a set dealersj, i checks that it also completed the Share protocol for the dealers in dealersj and waits until it considers j to be valid according to validatei. That is, it checks that j is a valid leader that has committed to a random value, which is the sum of the j’th secrets shared by the dealers in dealersj. Round 3: In the third round, i waits to see that n t parties committed to their random values and then inputs the set of those parties, attachedi, to the Gather protocol. It does so with an asynchronous validity predicate checking that each party in attachedi is a valid candidate that actually committed to a random secret and. Round 4: After completing the Gather protocol, i outputs a set of parties that it considers to be viable candidates who can be chosen as leaders and output from the VLE protocol. In order to be able to choose a single leader, i broadcasts a “candidates” message with that set of candidates, asking for parties to help reconstruct...