Shifting gears: changing algorithms on the fly to expedite Byzantine agreement

Bar-Noy, Amotz; Dolev, Danny; Dwork, Cynthia; Strong, H. Raymond

doi:10.1145/41840.41844

Cited by 86 publications

(78 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, we are going to prove that the problem of deciding in uniform consensus is indeed reducible to the one of stopping in consensus. 2 For that, consider a consensus algorithm A in which each correct process eventually reaches a halting state; A can be transformed into an algorithm B = T (A) which is identical to A, except that each process postpones its decision until it halts (the decision value in B is thus the same as in A).…”

Section: A Lower Bound For Early Stopping Consensusmentioning

confidence: 99%

“…We claim that p j needs only t rounds to determine whether p i has failed or not in sending messages at the first round of a run in which at most t − 1 processes crash. For this purpose, we use a strategy known as exponential information gathering (EIG, for short) introduced in [2]. The basic structure used by EIG algorithms is a labelled tree, whose paths from the root represents chains of processes along which some values are propagated.…”

Section: The Edauc and Tree T Algorithmsmentioning

confidence: 99%

See 1 more Smart Citation

Uniform consensus is harder than consensus

Charron-Bost¹,

Schiper²

2004

Journal of Algorithms

104

View full text Add to dashboard Cite

We compare the consensus and uniform consensus problems in synchronous systems. In contrast to consensus, uniform consensus is not solvable with byzantine failures. This still holds for the omission failure model if a majority of processes may be faulty. For the crash failure model, both consensus and uniform consensus are solvable, no matter how many processes are faulty. In this failure model, we examine the number of rounds required to reach a decision in the consensus and uniform consensus algorithms. We show that if uniform agreement is required, one additional round is needed to decide, and so uniform consensus is also harder than consensus for crash failures. This is based on a new lower bound result for the synchronous model that we state for the uniform consensus problem. Finally, an algorithm is presented that achieves this lower bound.

show abstract

Section: A Lower Bound For Early Stopping Consensusmentioning

confidence: 99%

Section: The Edauc and Tree T Algorithmsmentioning

confidence: 99%

Uniform consensus is harder than consensus

Charron-Bost¹,

Schiper²

2004

Journal of Algorithms

104

View full text Add to dashboard Cite

show abstract

“…Our third case study is the well-known EIGByz f [1,15] algorithm, which decides after f + 1 rounds and is designed for synchronous system models. Encoding EIGByz f in the HO model is straightforward.…”

Section: Verifying a Synchronous Algorithmmentioning

confidence: 99%

“…In such a system, every process receives the correct message from at least the non-faulty processes at every round, and therefore the predicate G is satisfied. The standard correctness proof for EIGByz f [1,15] assumes that N > 3f , and therefore N − f > N +f 2 . Since moreover, for any r ∈ N, we obviously have…”

Section: Verifying a Synchronous Algorithmmentioning

confidence: 99%

Formal Verification of Consensus Algorithms Tolerating Malicious Faults

Charron-Bost

Debrat

Merz

2011

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Consensus is the paradigmatic problem in fault-tolerant distributed computing: it requires network nodes that communicate by message passing to agree on common value even in the presence of (benign or malicious) faults. Several algorithms for solving Consensus exist, but few of them have been rigorously verified, much less so formally. The Heard-Of model proposes a simple, unifying framework for defining distributed algorithms in the presence of communication faults. Algorithms proceed in communication-closed rounds, and assumptions on the faults tolerated by the algorithm are stated abstractly in the form of communication predicates. Extending previous work on the case of benign faults, our approach relies on the fact that properties such as Consensus can be verified over a coarse-grained, round-based representation of executions. We have encoded the Heard-Of model in the interactive proof assistant Isabelle/HOL and have used this encoding to formally verify three Consensus algorithms based on synchronous and asynchronous assumptions. Our proofs give some new insights into the correctness of the algorithms, in particular with respect to transient faults.

show abstract

“…To show that the above functionality is not realized by known protocols, we observe that known broadcast protocols have the following pattern: At the beginning of the protocol the sender p s sends his input x s to the players in P \ {p s }; in a second phase the players try to establish a consistent view on the sender's input. Clearly all protocols which start by the sender sending his input to everybody and then invoke a consensus protocol on the received value, e.g., [CW89,BGP89,BDDS92], are of the above type. However, even the protocols where the second phase is not a self-contained consensus protocol, e.g., the broadcast protocols from [DS82,PW92], also follow the above paradigm.…”

Section: Perfect Security (No Setup)mentioning

confidence: 99%

Adaptively Secure Broadcast

Hirt

Zikas

2010

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract.A broadcast protocol allows a sender to distribute a message through a point-to-point network to a set of parties, such that (i) all parties receive the same message, even if the sender is corrupted, and (ii) this is the sender's message, if he is honest. Broadcast protocols satisfying these properties are known to exist if and only if t < n/3, where n denotes the total number of parties, and t denotes the maximal number of corruptions. When a setup allowing signatures is available to the parties, then such protocols exist even for t < n.Since its invention in [LSP82], broadcast has been used as a primitive in numerous multi-party protocols making it one of the fundamental primitives in the distributed-protocols literature. The security of these protocols is analyzed in a model where a broadcast primitive which behaves in an ideal way is assumed. Clearly, a definition of broadcast should allow for secure composition, namely, it should be secure to replace an assumed broadcast primitive by a protocol satisfying this definition. Following recent cryptographic reasoning, to allow secure composition the ideal behavior of broadcast can be described as an ideal functionality, and a simulation-based definition can be used.In this work, we show that the property-based definition of broadcast does not imply the simulation-based definition for the natural broadcast functionality. In fact, most broadcast protocols in the literature do not securely realize this functionality, which raises a composability issue for these broadcast protocols. In particular, we do not know of any broadcast protocol which could be securely invoked in a multi-party computation protocol in the secure-channels model. The problem is that existing protocols for broadcast do not preserve the secrecy of the message while being broadcasted, and in particular allow the adversary to corrupt the sender (and change the message), depending on the message being broadcasted. For example, when every party should broadcast a random bit, the adversary could corrupt those parties who intend to broadcast 0, and make them broadcast 1.More concretely, we show that simulatable broadcast in a model with secure channels is possible if and only if t < n/3, respectively t ≤ n/2 when a signature setup is available. The positive results are proven by constructing secure broadcast protocols.

show abstract

Shifting gears: changing algorithms on the fly to expedite Byzantine agreement

Cited by 86 publications

References 5 publications

Uniform consensus is harder than consensus

Uniform consensus is harder than consensus

Formal Verification of Consensus Algorithms Tolerating Malicious Faults

Adaptively Secure Broadcast

Contact Info

Product

Resources

About