DOCSLIB.ORG

Distributed Consensus Revised

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Distributed Consensus Revised UCAM-CL-TR-935 Technical Report ISSN 1476-2986 Number 935 Computer Laboratory Distributed consensus revised Heidi Howard April 2019 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 https://www.cl.cam.ac.uk/ c 2019 Heidi Howard This technical report is based on a dissertation submitted September 2018 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Pembroke College. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: https://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Distributed consensus revised Heidi Howard Summary We depend upon distributed systems in every aspect of life. Distributed consensus, the abil- ity to reach agreement in the face of failures and asynchrony, is a fundamental and powerful primitive for constructing reliable distributed systems from unreliable components. For over two decades, the Paxos algorithm has been synonymous with distributed consensus. Paxos is widely deployed in production systems, yet it is poorly understood and it proves to be heavyweight, unscalable and unreliable in practice. As such, Paxos has been the subject of extensive research to better understand the algorithm, to optimise its performance and to mitigate its limitations. In this thesis, we re-examine the foundations of how Paxos solves distributed consensus. Our hypothesis is that these limitations are not inherent to the problem of consensus but instead specific to the approach of Paxos. The surprising result of our analysis is a substantial weakening to the requirements of this widely studied algorithm. Building on this insight, we are able to prove an extensive generalisation over the Paxos algorithm. Our revised understanding of distributed consensus enables us to construct a diverse family of algorithms for solving consensus; covering classical as well as novel algorithms to reach consensus where it was previously thought impossible. We will explore the wide reaching implications of this new understanding, ranging from pragmatic optimisations to production systems to fundamentally novel approaches to consensus, which achieve new tradeoffs in performance, scalability and reliability. Acknowledgments First, and foremost, I would like to sincerely thank my advisor, Jon Crowcroft, for his tireless enthusiasm and support since our paths first crossed six years ago. Without his encouragement, I would not have believed it possible for to me to pursue a PhD. It takes a village to raise a child and it takes a research group to raise a graduate student. Since my first steps into the world of research, the Systems Research Group (SRG) at the Computer Lab has been my home. I am indebted to my mentor, Richard Mortier, for his counsel and patience, particularly during the longer than expected final stretch of my PhD. I am also indebted to Tim Harris for insightful feedback on this thesis which substantially helped toward improving the clarity and readability. I am thankful for the friendship of my former fellow students, Natacha Crooks, Malte Schwarzkopf, Matthew Grosvenor, Shehar Bano and my current fellow students, Krittika D'Silva, Zahra Tarkhani, Mohibi Hussain and Marco Caballero. In addition to those already mentioned, I am sincerely grateful to my friends beyond the SRG, especially Laura Scriven, Shreedipta Mitra and Jeunese Payne, for keeping me sane over the years. I am grateful to my colleague Martin Kleppmann for our discussions on distributed systems during key points of this PhD. I am deeply grateful to my 2nd supervisor, Anil Madhavapeddy, for adopting me into the OCaml labs community and regularly feeding me. Over the years, I have enjoyed many lively lunchtime discussions and trips to the food park with Gemma Gordon, David Allsopp and my office mates, KC Sivaramakrishnan and Stephen Dolan. I am also thankful to my former colleagues, Mindy Preston and Amir Chaudhry for their companionship during their time with me at the computer lab. I have been extremely privileged to work with Dahlia Malkhi, my mentor in the field of distributed systems. Thanks are also due to the friends, new and old, who kept me company during my time in California; Nick Spooner, Diego Ongaro, Jenny Wolochow and Igor Zablotchi. Without you all my time away from Cambridge could have been very lonely. Last but not least, I'd like to thank my husband, Olly Andrade, for the joy you have brought to my life over the last seven years as well as the countless hours spend proofreading this thesis. This thesis is dedicated to my father, Daniel Howard, who raised me and supported me throughout my life but sadly passed away after a short battle with cancer before the completion of this PhD. Contents 1 Introduction ..................................... 13 1.1 State of the art . 14 1.2 Historical background . 14 1.3 Motivation . 16 1.4 Approach . 17 1.5 Contributions . 18 1.5.1 Publications . 19 1.5.2 Follow up research . 19 1.6 Scope & limitations . 19 2 Consensus & Classic Paxos ........................... 21 2.1 Preliminaries . 21 2.1.1 Single acceptor algorithm . 23 2.2 Classic Paxos . 27 2.2.1 Proposer algorithm . 29 2.2.2 Acceptor algorithm . 31 2.3 Examples . 32 2.4 Properties . 38 2.5 Non-triviality . 39 2.6 Safety . 39 2.7 Progress . 45 2.8 Summary . 47 3 Known revisions .................................. 49 3.1 Negative responses (NACKs) . 49 3.2 Bypassing phase two . 52 3.3 Termination . 55 3.4 Distinguished proposer . 59 3.5 Phase ordering . 60 3.6 Multi-Paxos . 60 3.7 Roles . 61 3.8 Epochs . 62 3.9 Phase one voting for epochs . 63 5 3.10 Proposal copying . 65 3.11 Generalisation to quorums . 68 3.12 Miscellaneous . 69 3.13 Summary . 73 4 Quorum intersection revised .......................... 75 4.1 Quorum intersection across phases . 75 4.1.1 Algorithm . 76 4.1.2 Safety . 76 4.1.3 Examples . 78 4.2 Quorum intersection across epochs . 78 4.2.1 Algorithm . 81 4.2.2 Safety . 81 4.2.3 Examples . 83 4.3 Implications . 85 4.3.1 Bypassing phase two . 86 4.3.2 Co-location of proposers and acceptors . 86 4.3.3 Multi-Paxos . 88 4.3.4 Voting for epochs . 90 4.4 Summary . 90 5 Promises revised .................................. 91 5.1 Intuition . 91 5.2 Algorithm . 92 5.3 Safety . 92 5.4 Examples . 94 5.5 Summary . 96 6 Value selection revised .............................. 97 6.1 Epoch agnostic algorithm . 97 6.1.1 Safety . 101 6.1.2 Progress . 104 6.1.3 Examples . 105 6.2 Epoch dependent algorithm . 106 6.2.1 Safety . 108 6.2.2 Progress . 109 6.3 Summary . 111 7 Epochs revised ................................... 113 7.1 Epochs from an allocator . 114 7.2 Epochs by value mapping . 115 6 7.3 Epochs by recovery . 118 7.3.1 Intuition . 118 7.3.2 Algorithm . 120 7.3.3 Safety . 122 7.3.4 Progress . 125 7.3.5 Examples . 126 7.4 Hybrid epoch allocation . 134 7.4.1 Multi-path Paxos using allocator . 135 7.4.2 Multi-path Paxos using value-based allocation . 136 7.4.3 Multi-path Paxos using recovery . 136 7.5 Summary . 137 8 Conclusion ...................................... 141 8.1 Motivation . 141 8.2 Summary of contributions . 142 8.3 Implications of contributions . 143 8.3.1 Greater flexibility . 143 8.3.2 New progress guarantees . 144 8.3.3 Improved performance . 145 8.3.4 Better clarity . 146 Bibliography ...................................... 147 7 List of Figures 2.1 Single acceptor algorithm (Alg. 1,2) . 25 2.2 Classic Paxos with serial proposers, p1 then p2 (Alg. 3,4) ..
Load more

Recommended publications
  • Understanding Distributed Consensus
    What’s Live? Understanding Distributed Consensus∗ Saksham Chand Yanhong A. Liu Computer Science Department, Stony Brook University, Stony Brook, NY 11794, USA {schand,liu}@cs.stonybrook.edu Abstract Distributed consensus algorithms such as Paxos have been studied extensively. They all use the same definition of safety. Liveness is especially important in practice despite well-known theoretical impossibility results. However, many different liveness proper- ties and assumptions have been stated, and there are no systematic comparisons for better understanding of these properties. This paper systematically studies and compares different liveness properties stated for over 30 prominent consensus algorithms and variants. We introduce a precise high- level language and formally specify these properties in the language. We then create a hierarchy of liveness properties combining two hierarchies of the assumptions used and a hierarchy of the assertions made, and compare the strengths and weaknesses of algorithms that ensure these properties. Our formal specifications and systematic comparisons led to the discovery of a range of problems in various stated liveness proper- ties, from too weak assumptions for which no liveness assertions can hold, to too strong assumptions making it trivial to achieve the assertions. We also developed TLA+ spec- ifications of these liveness properties, and we use model checking of execution steps to illustrate liveness patterns for Paxos. 1 Introduction arXiv:2001.04787v2 [cs.DC] 21 Jun 2021 Distributed systems are pervasive, where processes work with each other via message passing. For example, this article is available to the current reader owing to some distributed system. At the same time, distributed systems are highly complex, due to their unpredictable asyn- chronous nature in the presence of failures—processes can fail and later recover, and messages can be lost, delayed, reordered, and duplicated.
    [Show full text]
  • Distributed Consensus: Performance Comparison of Paxos and Raft
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Distributed Consensus: Performance Comparison of Paxos and Raft HARALD NG KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Distributed Consensus: Performance Comparison of Paxos and Raft HARALD NG Master in Software Engineering of Distributed Systems Date: September 10, 2020 Supervisor: Lars Kroll (RISE), Max Meldrum (KTH) Examiner: Seif Haridi School of Electrical Engineering and Computer Science Host company: RISE Swedish title: Distribuerad Konsensus: Prestandajämförelse mellan Paxos och Raft iii Abstract With the growth of the internet, distributed systems have become increasingly important in order to provide more available and scalable applications. Con- sensus is a fundamental problem in distributed systems where multiple pro- cesses have to agree on the same proposed value in the presence of partial failures. Distributed consensus allows for building various applications such as lock services, configuration manager services or distributed databases. Two well-known consensus algorithms for building distributed logs are Multi-Paxos and Raft. Multi-Paxos was published almost three decades before Raft and gained a lot of popularity. However, critics of Multi-Paxos consider it difficult to understand. Raft was therefore published with the motivation of being an easily understood consensus algorithm. The Raft algorithm shares similar characteristics with a practical version of Multi-Paxos called Leader- based Sequence Paxos. However, the algorithms differ in important aspects such as leader election and reconfiguration. Existing work mainly compares Multi-Paxos and Raft in theory, but there is a lack of performance comparisons in practice. Hence, prototypes of Leader- based Sequence Paxos and Raft have been designed and implemented in this thesis.
    [Show full text]
  • 42 Paxos Made Moderately Complex
    Paxos Made Moderately Complex ROBBERT VAN RENESSE and DENIZ ALTINBUKEN, Cornell University This article explains the full reconfigurable multidecree Paxos (or multi-Paxos) protocol. Paxos is by no means a simple protocol, even though it is based on relatively simple invariants. We provide pseudocode and explain it guided by invariants. We initially avoid optimizations that complicate comprehension. Next we discuss liveness, list various optimizations that make the protocol practical, and present variants of the protocol. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Syst- ems—Network operating systems; D.4.5 [Operating Systems]: Reliability—Fault-tolerance General Terms: Design, Reliability Additional Key Words and Phrases: Replicated state machines, consensus, voting ACM Reference Format: Robbert van Renesse and Deniz Altinbuken. 2015. Paxos made moderately complex. ACM Comput. Surv. 47, 3, Article 42 (February 2015), 36 pages. DOI: http://dx.doi.org/10.1145/2673577 1. INTRODUCTION Paxos [Lamport 1998] is a protocol for state machine replication in an asynchronous environment that admits crash failures. It is useful to consider the terms in this 42 sentence carefully: —A state machine consists of a collection of states, a collection of transitions between states, and a current state. A transition to a new current state happens in response to an issued operation and produces an output. Transitions from the current state to the same state are allowed and are used to model read-only operations. In a deterministic state machine, for any state and operation, the transition enabled by the operation is unique and the output is a function only of the state and the operation.
    [Show full text]
  • CS5412: Lecture II How It Works
    CS5412 Spring 2016 (Cloud Computing: Birman) 1 CS5412: PAXOS Lecture XIII Ken Birman Leslie Lamport’s vision 2 Centers on state machine replication We have a set of replicas that each implement some given, deterministic, state machine and we start them in the same state Now we apply the same events in the same order. The replicas remain in the identical state To tolerate ≤ t failures, deploy 2t+1 replicas (e.g. Paxos with 3 replicas can tolerate 1 failure) How best to implement this model? CS5412 Spring 2016 (Cloud Computing: Birman) Two paths forwards... 3 One option is to build a totally ordered reliable multicast protocol, also called an “atomic broadcast” protocol in some papers To send a request, you give it to the library implementing that protocol (for cs5412: probably Vsync). Eventually it does upcalls to event handlers in the replicated application and they apply the event In this approach the application “is” the state machine and the multicast “is” the replication mechanism Use “state transfer” to initialize a joining process if we want to replace replicas that crash CS5412 Spring 2016 (Cloud Computing: Birman) Two paths forwards... 4 A second option, explored in Lamport’s Paxos protocol, achieves a similar result but in a very different way We’ll look at Paxos first because the basic protocol is simple and powerful, but we’ll see that Paxos is slow Can speed it up... but doing so makes it very complex! The basic, slower form of Paxos is currently very popular Then will look at faster but more complex reliable multicast options (many of them...) CS5412 Spring 2016 (Cloud Computing: Birman) Key idea in Paxos: Quorums 5 Starts with a simple observation: Suppose that we lock down the membership of a system: It has replicas {P, Q, R, ..
    [Show full text]
  • State Machine Replication Is More Expensive Than Consensus
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Dagstuhl Research Online Publication Server State Machine Replication Is More Expensive Than Consensus Karolos Antoniadis EPFL, Lausanne, Switzerland karolos.antoniadis@epfl.ch Rachid Guerraoui EPFL, Lausanne, Switzerland rachid.guerraoui@epfl.ch Dahlia Malkhi VMware Research, Palo Alto, USA [email protected] Dragos-Adrian Seredinschi EPFL, Lausanne, Switzerland dragos-adrian.seredinschi@epfl.ch Abstract Consensus and State Machine Replication (SMR) are generally considered to be equivalent prob- lems. In certain system models, indeed, the two problems are computationally equivalent: any solution to the former problem leads to a solution to the latter, and vice versa. In this paper, we study the relation between consensus and SMR from a complexity perspect- ive. We find that, surprisingly, completing an SMR command can be more expensive than solving a consensus instance. Specifically, given a synchronous system model where every instance of consensus always terminates in constant time, completing an SMR command does not necessar- ily terminate in constant time. This result naturally extends to partially synchronous models. Besides theoretical interest, our result also corresponds to practical phenomena we identify em- pirically. We experiment with two well-known SMR implementations (Multi-Paxos and Raft) and show that, indeed, SMR is more expensive than consensus in practice. One important im- plication of our result is that – even under synchrony conditions – no SMR algorithm can ensure bounded response times. 2012 ACM Subject Classification Computing methodologies → Distributed algorithms Keywords and phrases Consensus, State machine replication, Synchronous model Digital Object Identifier 10.4230/LIPIcs.DISC.2018.7 Related Version A full version of the paper is available at [4], https://infoscience.epfl.ch/ record/256238.
    [Show full text]
  • A History of the Virtual Synchrony Replication Model Ken Birman
    A History of the Virtual Synchrony Replication Model Ken Birman Introduction A “Cloud Computing” revolution is underway, supported by massive data centers that often contain thousands (if not hundreds of thousands) of servers. In such systems, scalability is the mantra and this, in turn, compels application developers to replicate various forms of information. By replicating the data needed to handle client requests, many services can be spread over a cluster to exploit parallelism. Servers also use replication to implement high availability and fault‐tolerance mechanisms, ensure low latency, implement caching, and provide distributed management and control. On the other hand, replication is hard to implement, hence developers typically turn to standard replication solutions, packaged as sharable libraries. Virtual synchrony, the technology on which this article will focus, was created by the author and his colleagues in the early 1980’s to support these sorts of applications, and was the first widely adopted solution in the area. Viewed purely as a model, virtual synchrony defines rules for replicating data or a service that will behave in a manner indistinguishable from the behavior of some non‐replicated reference system running on a single non‐faulty node. The model is defined in the standard asynchronous network model for crash failures. This turns out to be ideal for the uses listed above. The Isis Toolkit, which implemented virtual synchrony and was released to the public in 1987, quickly became popular. In part this was because the virtual synchrony model made it easy for developers to use replication in their applications, and in part it reflected the surprisingly good performance of the Isis protocols.
    [Show full text]
  • A Formal Treatment of Lamport's Paxos Algorithm
    A Formal Treatment of Lamport’s Paxos Algorithm Roberto De Prisco Nancy Lynch Alex Shvartsman Nicole Immorlica Toh Ne Win October 10, 2002 Abstract This paper gives a formal presentation of Lamport’s Paxos algorithm for distributed consensus. The presentation includes a state machine model for the complete protocol, a correctness proof, and a perfor- mance analysis. The correctness proof, which shows the safety properties of agreement and validity, is based on a mapping to an abstract state machine representing a non-distributed version of the protocol. The performance analysis proves latency bounds, conditioned on certain timing and failure assumptions. Liveness and fault-tolerance correctness properties are corollaries of the performance properties. This work was supported in part by the NSF ITR Grant CCR-0121277. Massachusetts Institute of Technology, Laboratory for Computer Science, 200 Technology Square, NE43-365, Cambridge, MA 02139, USA. Email: [email protected]. Department of Computer Science and Engineering, 191 Auditorium Road, Unit 3155, University of Connecticut, Storrs, CT 06269 and Massachusetts Institute of Technology, Laboratory for Computer Science, 200 Technology Square, NE43-316, Cam- bridge, MA 02139, USA. Email: [email protected]. Massachusetts Institute of Technology, Laboratory for Computer Science, 200 Technology Square, NE43-???, Cambridge, MA 02139, USA. Email: [email protected]. Massachusetts Institute of Technology, Laboratory for Computer Science, 200 Technology Square, NE43-413, Cambridge, MA 02139, USA. Email: [email protected]. 1 Introduction Overview: Lamport’s Paxos algorithm [1] has at its core a solution to the problem of distributed consen- sus. In that consensus algorithm, the safety properties—agreement and validity—hold in all executions.
    [Show full text]
  • Consensus on Transaction Commit
    Consensus on Transaction Commit Jim Gray and Leslie Lamport Microsoft Research 1 January 2004 revised 19 April 2004 MSR-TR-2003-96 Abstract The distributed transaction commit problem requires reaching agreement on whether a transaction is committed or aborted. The classic Two-Phase Commit protocol blocks if the coordinator fails. Fault-tolerant consensus algorithms also reach agreement, but do not block whenever any majority of the processes are working. The Paxos Commit algorithm runs a Paxos consensus algorithm on the commit/abort decision of each participant to obtain a transaction commit protocol that uses 2F + 1 coordinators and makes progress if at least F + 1 of them are working. Paxos Commit has the same stable-storage write delay, and can be implemented to have the same message delay in the fault-free case, as Two-Phase Commit, but it uses more messages. The classic Two-Phase Commit algorithm is obtained as the special F = 0 case of the Paxos Commit algorithm. Contents 1 Introduction 1 2 Transaction Commit 2 3 Two-Phase Commit 4 3.1 The Protocol . 4 3.2 The Cost of Two-Phase Commit . 6 3.3 The Problem with Two-Phase Commit . 6 4 Paxos Commit 7 4.1 The Paxos Consensus Algorithm . 7 4.2 The Paxos Commit Algorithm . 10 4.3 The Cost of Paxos Commit . 12 5 Paxos versus Two-Phase Commit 14 6 Transaction Creation and Registration 16 6.1 Creation . 16 6.2 Registration . 17 7 Conclusion 18 A The TLA+ Specifications 21 A.1 The Specification of a Transaction Commit Protocol .
    [Show full text]
  • Consensus on Transaction Commit
    Consensus on Transaction Commit Jim Gray and Leslie Lamport Microsoft Research 1 January 2004 revised 19 April 2004, 8 September 2005, 5 July 2017 MSR-TR-2003-96 This paper appeared in ACM Transactions on Database Systems, Volume 31, Issue 1, March 2006 (pages 133-160). This version should differ from the published one only in formatting, except that it corrects one minor error on the last page. Copyright 2005 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or [email protected]. Abstract The distributed transaction commit problem requires reaching agreement on whether a transaction is committed or aborted. The classic Two-Phase Commit protocol blocks if the coordinator fails. Fault-tolerant consensus algorithms also reach agreement, but do not block whenever any majority of the processes are working. The Paxos Commit algorithm runs a Paxos consensus algorithm on the commit/abort decision of each participant to obtain a transaction commit protocol that uses 2F + 1 coordinators and makes progress if at least F +1 of them are working properly.
    [Show full text]
  • In Search of Lost Time
    In Search of Lost Time Bernadette Charron-Bost1, Martin Hutle2, and Josef Widder3 1 CNRS / Ecole polytechnique, Palaiseau, France 2 EPFL, Lausanne, Switzerland 3 TU Wien, Vienna, Austria Abstract Dwork, Lynch, and Stockmeyer (1988) and Lamport (1998) showed that, in order to solve Consensus in a distributed system, it is sufficient that the system behaves well during a finite period of time. In sharp contrast, Chandra, Hadzilacos, and Toueg (1996) proved that a failure detector that, from some time on, provides \good" information forever is necessary. We explain that this apparent paradox is due to the two-layered structure of the failure detector model. This structure also has impacts on comparison relations between failure detectors. In particular, we make explicit why the classic relation is neither reflexive nor extends the natural history-wise inclusion. Altough not technically difficult, the point we make helps understanding existing models like the failure detector model. Keywords: distributed computing { failure detectors { asynchronous system { Consensus 1 Introduction The aim of the paper is to deepen the understanding of one of the most classical model in distributed computing, namely the failure detector model by Chandra and Toueg [2]. Roughly speaking, in the failure detector approach, a distributed system is represented by two layers: a layer that corresponds to the system itself | formally defined in terms of processes, automata, and communication links | that runs in a totally asynchronous mode, and a second layer consisting of the failure detector | defined with respect to time | accessible to the processes at any time. From a modeling perspective, this two-layered approach radically changed from the classic approaches (e.g., [3, 4, 7]) where the timing behavior of a system is restricted in order to circumvent fundamental impossibility results [5].
    [Show full text]
  • The Impact of RDMA on Agreement [Extended Version]
    The Impact of RDMA on Agreement [Extended Version] Marcos K. Aguilera Naama Ben-David Rachid Guerraoui VMware CMU EPFL [email protected] [email protected] [email protected] Virendra Marathe Igor Zablotchi Oracle EPFL [email protected] [email protected] ABSTRACT traditional shared memory, which is often assumed to be reliable1. Remote Direct Memory Access (RDMA) is becoming widely avail- In this paper, we show that the additional power of RDMA more able in data centers. This technology allows a process to directly than compensates for these challenges. read and write the memory of a remote host, with a mechanism to Our main contribution is to show that RDMA improves on the fun- control access permissions. In this paper, we study the fundamental damental trade-off in distributed systems between failure resilience power of these capabilities. We consider the well-known problem and performance—specifically, we show how a consensus protocol of achieving consensus despite failures, and find that RDMA can can use RDMA to achieve both high resilience and high performance, improve the inherent trade-off in distributed computing between fail- while traditional algorithms had to choose one or another. We illus- ure resilience and performance. Specifically, we show that RDMA trate this on the fundamental problem of achieving consensus and allows algorithms that simultaneously achieve high resilience and capture the above RDMA capabilities as an M&M model [3], in high performance, while traditional algorithms had to choose one which processes can use both message-passing and shared-memory. or another. With Byzantine failures, we give an algorithm that only We consider asynchronous systems and require safety in all exe- cutions and liveness under standard additional assumptions (e.g., requires = ≥ 25% ¸ 1 processes (where 5% is the maximum number of faulty processes) and decides in two (network) delays in common ex- partial synchrony).
    [Show full text]
  • Leaderless Byzantine Paxos
    Leaderless Byzantine Paxos Leslie Lamport Microsoft Research Appeared in Distributed Computing: 25th International Symposium: DISC 2011, David Peleg, editor. Springer-Verlag (2011) 141{142 Minor correction: 27 December 2011 Leaderless Byzantine Paxos Leslie Lamport Microsoft Research Abstract. The role of leader in an asynchronous Byzantine agreement algorithm is played by a virtual leader that is implemented using a syn- chronous Byzantine agreement algorithm. Agreement in a completely asynchronous distributed system is impossible in the presence of even a single fault [5]. Practical fault-tolerant \asynchronous" agreement algorithms assume some synchrony assumption to make progress, maintaining consistency even if that assumption is violated. Dependence on syn- chrony may be explicit [4], or may be built into reliance on a failure detector [2] or a leader-election algorithm. Algorithms that are based on leader election are called Paxos algorithms [6{8]. Byzantine Paxos algorithms are extensions of these algorithms to tolerate malicious failures [1, 9]. For Byzantine agreement, reliance on a leader is problematic. Existing algo- rithms have quite convincing proofs that a malicious leader cannot cause incon- sistency. However, arguments that a malicious leader cannot prevent progress are not so satisfactory. Castro and Liskov [1] describe a method by which the system can detect lack of progress and choose a new leader. However, their method is rather ad hoc. It is not clear how well it will work in practice, where it can be very difficult to distinguish malicious behavior from transient communication errors. The first Byzantine agreement algorithms, developed for process control ap- plications, did not require a leader [10].
    [Show full text]