This paper explores the good-case latency of Byzantine fault-tolerant broadcast, motivated by the real-world latency and performance of practical state machine replication protocols. The good-case latency measures the time it takes for all non-faulty parties to commit when the designated broadcaster is non-faulty. We provide a complete characterization of tight bounds on good-case latency, in the authenticated setting under synchrony, partial synchrony and asynchrony. Some of our new results may be surprising, e.g., 2-round PBFT-style partially synchronous Byzantine broadcast is possible if and only if ≥ 5 − 1, and a tight bound for good-case latency under /3 < < /2 under synchrony is not an integer multiple of the delay bound. CCS CONCEPTS• Theory of computation → Distributed algorithms; • Security and privacy → Distributed systems security.

No abstract

No abstract

No abstract

This paper explores the problem good-case latency of Byzantine fault-tolerant broadcast, motivated by the real-world latency and performance of practical state machine replication protocols. The good-case latency measures the time it takes for all non-faulty parties to commit when the designated broadcaster is non-faulty. We provide a complete characterization of tight bounds on good-case latency, in the authenticated setting under synchrony, partial synchrony and asynchrony. Some of our new results may be surprising, e.g., 2-round PBFT-style partially synchronous Byzantine broadcast is possible if and only if 𝑛 ≥ 5𝑓 − 1, and a tight bound for good-case latency under 𝑛/3 < 𝑓 < 𝑛/2 under synchrony is not an integer multiple of the delay bound. INTRODUCTIONByzantine fault-tolerant broadcast is a fundamental problem in distributed computing. In Byzantine broadcast (BB) or Byzantine reliable broadcast (BRB), there is a designated broadcaster that sends its input value to all parties, and all non-faulty parties must deliver the same value. Moreover, if the broadcaster is non-faulty, then the delivered value must be broadcaster's input. BB requires all non-faulty parties to eventually terminate, while BRB relaxes the condition to only require termination when the broadcaster is honest or if a non-faulty party terminates.One of the most important practical applications of broadcast is to implement Byzantine fault-tolerant state machine replication (BFT SMR), which ensures all non-faulty replicas agree on the same sequence of client inputs to provide the client with the illusion of a single non-faulty server. Most of the practical solutions for BFT SMR are based on the Primary-Backup paradigm. In this approach, in each view, one replica is designated to be the leader, and is in charge of a view to drive decisions, until replaced by the leader of the next view due to malicious behavior or bad network connection. The Primary-Backup approach for SMR exposes deep connections to broadcast. Each view in BFT SMR is similar to an instance of broadcast where with the leader taking on a similar role as the broadcaster 1 , and hence an efficient broadcast protocol can be converted to an SMR protocol with similar efficiency guarantees. Due to the importance of BFT SMR and the recent interest in permissioned blockchains, improving the latency of the BFT SMR and understanding its fundamental latency limit have been a research focus for several decades [2,4,11,20,23,26].However, there exists a mismatch between theoretical studies on broadcast latency and practical SMR systems.Most of the theoretical studies focused on the worst-case latency of broadcast. For Byzantine broadcast, the worst-case number of rounds required is 𝑓 + 1 to tolerate 𝑓 faults [18]. As 𝑓 is typically assumed to be linear in 𝑛, any BB protocol will inevitably have a poor worst-case latency as 𝑛 increases. However, in contrast, practical BFT SMR systems care more about the good-case, in which a stable non-faulty leader stays in charge and drives consensus on many de...