From Consensus to Atomic Broadcast: Time-Free Byzantine-Resistant Protocols without Signatures

Abstract

This paper proposes a hierarchy of three Byzantine-resistant protocols aimed to be used in practical distributed systems: multi-valued consensus, vector consensus and atomic broadcast. These protocols are designed as successive transformations from one to another. The first protocol, multi-valued consensus, is implemented on top of a randomized binary consensus. The protocols share a set of important structural properties. Firstly, they do not use signatures obtained with public-key cryptography, a well-known performance bottleneck in this kind of protocols. Secondly, they are time-free, i.e., they make no synchrony assumptions, since these assumptions are often vulnerable to subtle but effective attacks. Thirdly, they have no leaders, thus avoiding the cost of detecting corrupt processes. Fourthly, they have optimal resilience, i.e., they tolerate f = n−1 3 out of a total of n processes. The multi-valued consensus protocol terminates in a constant expected number of rounds, while the vector consensus and atomic broadcast protocols have time complexities O(f). * This work was partially supported by the FCT through project POSI/CHS/39815/2001 (COPE) and the Large-Scale Informatic Systems Laboratory (LASIGE). 1 We follow the recent literature that uses interchangeably the terms 'Byzantine faults' and 'intrusions', or 'Byzantine-resistant' and 'intrusion-tolerant'. However, papers like [25, 21] consider accidental Byzantine faults, which are different from malicious Byzantine faults, i.e., intrusions. These latter faults should not be assumed to happen independently.

Byzantine Consensus with Unknown Participants

“…Notice that these properties establish a communication primitive with specification similar to the usual reliable broadcast [4,5,15]. Nonetheless, the proposed primitive ensures the delivery to all correct processes reachable in the system.…”

“…However, the protocol presented in this paper uses an underlying classical Byzantine consensus that could be implemented over an eventually synchronous system [14] (e.g., Byzantine Paxos [9]) or over a completely asynchronous system (e.g., using a randomized consensus protocol [5,15,16]). Thus, our protocol requires the same level of synchrony required by the underlying classical Byzantine consensus protocol.…”

“…Most of the studies about consensus found in the literature consider a static known set of participants in the system (e.g., [1,3,4,5,17,19]). Recently, some works which [7] crash pattern FT-CUP crash k-OSR f + 1 2 f + 1 k node-disjoint asynchronous + ♦S [8] paths BFT-CUP Byzantine k-OSR 2 f + 1 3 f + 1 k node-disjoint same of the underlying (this paper) paths consensus protocol deal with a partial knowledge about the system composition have been proposed.…”

“…The consensus problem [1,2,3,4,5], and more generally the agreement problems, form the basis of almost all solutions related to the development of reliable distributed systems. Through these protocols, participants are able to coordinate their actions in order to maintain state consistency and ensure system progress.…”

Consensus in the presence of mortal Byzantine faulty processes

“…Another approach was to augment the asynchronous system with failure detectors [10,26,27]. Other approaches aim at optimizing normal case behavior [28][29][30] or consider more elaborate fault models in an effort to improve fault resilience as, for instance, Byzantine faults with recovery [31,32] or hybrid failure models [33][34][35].…”