Reliable Broadcast Clause Samples
The Reliable Broadcast clause establishes a protocol to ensure that messages sent within a network are delivered to all intended recipients accurately and consistently. In practice, this clause typically requires that once a message is broadcast by a sender, all honest participants in the system will either all receive the message or none will, and that the content of the message remains unchanged during transmission. This mechanism is crucial for preventing miscommunication or data loss in distributed systems, thereby ensuring that all parties operate with the same information and reducing the risk of inconsistencies or disputes.
Reliable Broadcast. We now describe the reliable broadcast service, which is a straightforward extension of the broadcast protocol proposed by Bracha [6]. A process begins by broadcasting its message to everyone. Every process that receives the message directly, echoes it, along with a signature. Every process that receives − + − 𝑛 𝑡0 distinct ECHO messages, sends a READY message. And if a process receives 𝑡0 1 distinct READY messages, it also sends a READY message. Finally, if a process receives 𝑛 𝑡0 distinct READY messages, then it delivers it. − + − The key difference from [6] is that, as in the binary value consensus protocol, we construct ledgers to justify the mes- sages we send. Specifically, when a process sends a READY message, if it has received 𝑛 𝑡0 distinct ECHO messages, each of which is signed, it packages them into a ledger, and forwards that with its READY message. Alternatively, if a process sends a READY message because it received 𝑡0 1 distinct READY messages, then it simply copies an existing (valid) ledger. Either way, if a process 𝑝𝑖 sends a READY mes- sage for value 𝑣 which was sent by process 𝑝 𝑗 , then it has stored a ledger containing 𝑛 𝑡0 signed ECHO messages for − − As before, two ledgers conflict if they justify two different values 𝑣 and 𝑣 ′, both supposedly sent by the same process 𝑝 𝑗 . In that case, one ledger contains 𝑛 𝑡0 signed ECHO message for 𝑣 and the other contains 𝑛 𝑡0 signed ECHO message for + + −
Reliable Broadcast. Reliable broadcast allows a sender to consistently distribute a message to a set of parties. In contrast to full-fledged broadcast (and by analogy to reliable consensus), reliable broadcast does not require termination. Definition 4 (Reliable broadcast) Let Π be a protocol executed by parties P1, . . . , Pn, where a designated sender P∗ initially holds input v∗, and parties terminate upon generating output. Π is an ƒ -secure reliable broadcast protocol if the following hold when at most ƒ parties are corrupted: • Validity: if P∗ is honest at the start of the protocol, then every honest party out- puts v∗. • Consistency: either no honest party terminates, or all honest parties output the same value. It is easy to obtain a reliable broadcast protocol ΠRBC (cf. Figure 2) from reliable consensus: the sender P∗ simply signs its message and sends it to all parties, who then run reliable consensus on what they received. In addition to the setup for the underlying reliable consensus protocol, ΠRBC assumes P∗ has a public/private key pair (pk∗, sk∗) with pk∗ known to all other parties.
Reliable Broadcast. Below we include the definition of Reliable Broadcast [9, 10]. Simi- larly to [20], we make the concrete running time and simultaneous termination properties explicit, as they will be used to keep the honest parties synchronized if the network is synchronous.
4.1. Let Π be a protocol where a designated party 𝑆 (called the sender) holds a value 𝑣𝑆 , and every party 𝑃 may output a value 𝑣𝑃 . We consider the following properties, where 𝑡 denotes the number of corrupted parties involved: •
Reliable Broadcast. The goal of Reliable-Broadcast is to simulate a broadcast channel using the underlying point-to-point message passing system. In Byzantine Agreement protocols, each process initiates a series of Reliable-Broadcasts. Call mp,ℓ the ℓth message broadcast by process p.
Theorem 1. If a good process p initiates the Reliable-Broadcast of mp,ℓ, then all good processes q eventually accept mp,ℓ. Now suppose a bad process p does so and some good q accepts mp,ℓ. Then all other good q′ will eventually accept mp,ℓ, and no good q′ will accept any other m′p,ℓ =/ mp,ℓ. Moreover, all good processes accept mp,ℓ−1 before mp,ℓ, if ℓ > 1. The property that mp,ℓ is only accepted after mp,ℓ−1 is accepted is sometimes called FIFO broadcast. This property is explicitly used in the Iterated-Blackboard algorithm outlined in Section 2.2. See Appendix A.1 for a proof of Theorem 1. Algorithm 1 Reliable-Broadcast(p, ℓ) 1: if ℓ > 1 then wait until mp,ℓ−1 has been accepted.
Reliable Broadcast. Reliable broadcast allows a sender to consistently distribute a message to a set of parties. In contrast to full-fledged broadcast (and by analogy to reliable consensus), reliable broadcast does not require termination.
Reliable Broadcast. Our Reliable Broadcast protocol is based on the protocol by Momose and Ren in [19], adapted to the hybrid network setting. In a nutshell, the idea is that at each step of the protocol, the parties wait for at least Δ time. When the network is synchronous, this ensures that 1) for an honest sender, all parties simultaneously obtain output after a fixed number 2 Composing protocols with probabilistic termination is known to pose several challenges. See [6, 7, 17] for a nice discussion. ▇▇▇▇▇ ▇▇▇▇▇▇, ▇▇▇▇-▇▇ ▇▇▇-▇▇▇▇▇, and ▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ of rounds, and 2) for a corrupted sender, the parties output at times that differ in at most Δ time. Moreover, when the network is asynchronous, security is retained. Initially, each party marks the time when it starts executing the protocol in 𝜏start. At the same time, the sender sends its signed value to all the parties. If the network is synchronous, any message is delivered within Δ time. Hence, the honest parties wait until time 𝜏start + Δ to ensure that, if the sender is honest, every honest party has received the sender’s message before taking any further step. Then, at time 𝜏start + Δ, the honest parties forward this signed value to all the parties. Hence, by time 𝜏start + 2 · Δ, any inconsistent messages sent by a dishonest sender in the first step are observed. Detecting such consistencies is the key in tolerating a higher number of corruptions. Then, if the sender is honest, each honest party sends a signed vote message at time 𝜏start + 2 · Δ, meaning that each honest party should always expect 𝑛 − 𝑡𝑠 vote messages by time at least 𝜏start + 3 · Δ in order to make a decision and output a value. On the other hand, if the sender is corrupted, a party 𝑃 that receives 𝑛 − 𝑡𝑠 vote messages cannot be certain that every honest party has received enough vote messages as well, hence 𝑃 forwards the signed votes to all the honest parties. If this is the case, the signed votes are received after at most Δ time by every honest party. A party can safely terminate as soon as it receives and forwards the 𝑛 − 𝑡𝑠 signed votes, hence, if the sender is honest, at time 𝜏start + 3 · Δ. Note that, if the sender is corrupted, the honest parties may output much later than time 𝜏start + 3 · Δ. In this case, the only guarantee is that once the first honest party outputs, every honest party outputs the same value within Δ time. If the network is asynchronous, once an honest party outputs a value, every honest party is guaranteed to eventuall...
Reliable Broadcast. We recall the definition of Reliable Broadcast. We make explicit the concrete running time and simultaneous termination properties, since they will be required when the network is synchronous.
Reliable Broadcast. Reliable broadcast allows a sender to consistently distribute a message to a set of parties. In contrast to full-fledged broadcast, reliable broadcast does not require termination. Definition 4 (Reliable broadcast) Let Π be a protocol executed by parties P1, . . . , Pn, where a designated sender P∗ initially holds input v∗, and parties terminate upon generating output. Π is an f -secure reliable broadcast protocol if the following hold if at most f parties are corrupted: • Validity: if P∗ is honest at the start of the protocol, then every honest party outputs v∗. • Consistency: either no honest party terminates, or all honest parties output the same value. It is easy to obtain reliable broadcast ΠRBC from reliable consensus: the sender simply signs its message and sends it to all parties, who then run reliable consensus on what they received. The communication complexity is O(κn), the same as for reliable consensus. We formally describe a reliable broadcast protocol ΠRBC in Figure 2. Protocol ΠRBC The sender is P∗ with secret key sk∗.
1. P∗ does: compute σ = Signsk∗ (v), erase sk∗, and send (v, σ) to all parties.
2. Upon receiving a pair (v, σ) such that Vrfypk∗ (v, σ) = 1, input v to the reliable consensus protocol ΠRC.
3. Upon receiving output v from ΠRC, output v and terminate. Theorem 5 Let 0 < s < 1/3 and f ≤ (1 − 2s)n/3. Then ΠRBC is a f-secure reliable broadcast protocol with expected communication complexity O(Iκn), where I is the size of the sender’s input. The expected size of the setup is O(κ ). We prove Theorem 5 by separately considering validity and consistency. Lemma 6 ΠRBC is f-valid. Proof Assume that the sender Ps is honest at the start of the execution and sends the messages at Step 1. Then, all honest parties eventually receive a pair (v, σ) with a valid signature from the sender. Note that no other valid pair is received even if Ps is adaptively corrupted, due to the fact that Ps erases its secret key before sending. As a result, every honest party starts a reliable consensus protocol with input v and by validity of reliable consensus, every honest party outputs v and terminates.