Formal verification of a leader election protocol in process algebra

Fredlund, Lars–Åke; Groote, Jan Friso; Korver, H.P.

doi:10.1016/s0304-3975(96)00256-3

Cited by 22 publications

(17 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As a result, this proof strategy reduced a large part of algebraic protocol verification to the checking of a number of elementary facts concerning the data parameters that occur in implementation and specification. One important example of application of this method was given by Fredlund, Groote and Korver [FGK97] who presented a formal description and formal proofs of correctness of the Dolev, Klawe and Rodeh's leader election algorithm: a round-based algorithm that has been designed for a network with a unidirectional ring topology. In each round, every active process exchanges messages only with its neighbors and the number of electable processes decreases until the last process left declares itself the leader.…”

Section: Discussionmentioning

confidence: 99%

Distributed Consensus, revisited

2007

View full text Add to dashboard Cite

We provide a novel model to formalize a well-known algorithm, by Chandra and Toueg, that solves Consensus among asynchronous distributed processes in the presence of a particular class of failure detectors (3S or, equivalently, Ω), under the hypothesis that only a minority of processes may crash. The model is defined as a global transition system that is unambigously generated by local transition rules. The model is syntax-free in that it does not refer to any form of programming language or pseudo code. We use our model to formally prove that the algorithm is correct. IntroductionIn the field of Distributed Algorithms, a widely-used computation model is based on asynchronous communication between a fixed number n of connected processes. No timing assumptions are made, neither on communications nor on local actions of processes. Often, processes are assumed to be subject to crash-failure: once crashed, they do not recover.In this paper, we focus on distributed programming and coordination problems in the area of asynchronous models. In particular we are interested in (1) how the problems are typically specified, (2) how algorithmic solutions to such problems are described, and (3) how the solutions are shown to be correct with respect to their specification. In our opinion, specifications, solutions and correctness arguments are often presented at a too informal level. The offered amount of detail is not sufficient to fully convince the reader (especially an outsider to the field) of the validity of the arguments: a particular reader who wants to verify the correctness of some proofs often has to prove by herself substantial parts or entire sub-results, for which only informal arguments were given. In contrast, at the core of this paper, we propose a rigorous method to formally describe problems, algorithmic solutions and their respective correctness proofs at a fine-grained level of detail. The method builds upon a largely syntax-free modeling of algorithms as executable transitions systems. It is exemplified on the well-known problem of Distributed Consensus (or shortly: Consensus).Specification. Usually, distributed programming problems are specified in terms of (often temporal) properties of admissible executions. Such an execution, also called system run, represents a (potentially infinite) computation, starting from some initial state, and describing the global behavior of a system as a sequence of actions and configurations according to some discrete time-line. An algorithm is an artifact that generates system runs. Often, some characteristics of components are given with respect to actions that do or do not happen in system runs. For example, a process is called correct in a given run, if it does not crash in that run. A solution to a problem is an algorithm that only generates system runs that respect the required properties. In the case of Consensus, a correct algorithm should only originate system runs that satisfy the following three properties: * The original publication is available at www....

show abstract

Section: Discussionmentioning

confidence: 99%

Distributed Consensus, revisited

2007

View full text Add to dashboard Cite

show abstract

“…We find descriptions along this line in verifications of the bakery protocol [GK94], Milner's scheduler [KS94], a leader election protocol [FGK97], grid protocols [BHP97], and a summing protocol [GMS97].…”

Section: Introductionmentioning

confidence: 89%

“…A lot of effort went into the specification and (manual) verification of various interactive systems [BG94a, GMS97, KS94, Lut97, KRR98, BBG97, GvdP96,FGK97]. When doing so, we developed a particular methodology of verification, culminating in the cones and foci technique [GS95], which enabled an increase in the order of magnitude of systems that could be analysed.…”

Section: Introductionmentioning

confidence: 99%

Confluence for process verification

Groote

Sellink

1996

Theoretical Computer Science

View full text Add to dashboard Cite

This chapter addresses the question how to verify distributed and communicating systems in an effective way from an explicit process algebraic standpoint. This means that all calculations are based on the axioms and principles of the process algebras. The first step towards such verifications is to extend process algebra (ACP) with equational data types which adds required expressive power to describe distributed systems. Subsequently, linear process operators, invariants, the cones and foci method, the composition of many similar parallel processes, and the use of confluence are explained, as means to verify increasingly complex systems. As illustration, verifications of the serial line interface protocol (SLIP) and the IEEE 1394 tree identify protocol are included.

show abstract

“…This section presents a brief overview of standard techniques that are used in these verifications. For verifications in the specification language µCRL [114] that use one or more of these techniques, see [56,98,111,140,186] Expansion. A basic technique in protocol verification is expansion [47] of the merge operator.…”

Section: Verification Techniquesmentioning

confidence: 99%