Can Coq be used (easily) as a model checker?

Question

As the title says, can Coq be used as a model checker? Can I mix model checking with Coq proving? Is this usual? Google talks about a \"µ-calculus\", does anyone have experience

Answer 1

To complement the existing answer by @Pekka, µ-calculus is a notation for talking about fixpoints, which represent solutions to reachability problems.

• An example of a least fixpoint (μ) is the largest set of states that can be reached starting from somewhere (e.g., from the first line of a program). It is a "least" fixpoint, because of being the smallest among possibly other fixpoints. It is obtained by starting with the empty set, and adding states until reaching a fixpoint. Under certain conditions, existence of a fixpoint is ensured by the Knaster-Tarski theorem.

• An example of a greatest fixpoint (ν) is the largest set that we can remain inside w/o violating some safety requirement. It is a "greatest" fixpoint, because it is obtained by starting from the collection of all states (so, from above in the partial order of sets defined by the subset relation), and iteratively restricting it, until we reach a fixpoint. Greatest fixpoints are dual to least fixpoints, thus the same theorem applies for existence and uniqueness. Think of graph search as another example.

By alternating the type of fixpoints in a μ-calculus formula, we can express temporal behavior like: "I want you to keep going back and forth between two locations", or "I want the server to keep eventually responding to each request it gets".

Then, we can model check (with an enumerative or symbolic model checker) whether the property we described is implied by a system we have designed.

• SPIN is an enumerative model checker: it stores each state it explores in a hash table, and includes some algorithms for recognizing that it doesn't need to enumerate all the states, but can treat some of them as representative to other states (from the perspective of the property being verified, those states are equivalent, so it suffices reasoning about one of them only). Those methods are called partial order reduction.

• NuSMV is a symbolic model checker. It still searches the states of a system, but it doesn't represent them one by one in memory. Instead, it keeps tracks of sets of states, representing those sets as binary decision diagrams. These are data structures that can remain small, even when they represent sets with 10**24 states. There's guarantee though for that. Unfortunately, they can still blow up in size, and sadly this is so for almost all Boolean functions (so, almost all sets that we may want to represent), as Claude Shannon has proved.

The tools above are designed and used for verification. There is also an approach called synthesis. After studying both, it may seem confusing whether there is really any difference between them. At a first encounter, one may think that models and formulae are what make a difference. However, that is deceptive: models and formulae are interchangeable as description methods, and can also be mixed.

The difference between verification and synthesis is in alternation of quantifiers:

• verification has uniform quantification (all universal, usually)
• synthesis has alternating quantification: it involves nested existential and universal quantifiers.

Of course, one may verify also a quantified formula, for example \forall x: \exists y: f(x, y). Isn't this just verification? Well, it is, demonstrating that there isn't any mathematical difference at the heart of the matter, between synthesis and verification. Traditionally, one encounters mostly the above cases of how quantification appears in what problems are considered as synthesis, and what problems are considered as verification.

The main real difference between synthesis and verification is how we use the result from checking whether a formula is true:

• In verification, we already have the implementation of the system that we want, and we check that it satisfies some desired properties. If not, we are going to (manually) try to fix the implementation, and then check again.

• In synthesis, there are some parts of the final system that we haven't yet specified completely in detail. We let that detail be selected by the tool we use. In other words, the tool eliminates the existential quantifiers in a way that will make the formula true, and tells us what it did, so that we will complete the system that way, ensuring that formula is true.

An example of a synthesis tool in C is gr1c, another example in Python is omega. There are several other tools.

However you approach a problem, at least make sure that you write what the plan is, that you write a specification.

One of the best books on these subjects is Leslie Lamport's Specifying systems. And to convince that various representations are faces of the same thing, consider reading Computer science and state machines.