SMT proof checking using a logical framework

Abstract

Producing and checking proofs from SMT solvers is currently the most feasible method for achieving high confidence in the correctness of solver results. The diversity of solvers and relative complexity of SMT over, say, SAT means that flexibility, as well as performance, is a critical characteristic of a proof-checking solution for SMT. This paper describes such a solution, based on a Logical Framework with Side Conditions (LFSC). We describe the framework and show how it can be applied for flexible proof production and checking for two different SMT solvers, clsat and cvc3. We also report empirical results showing good performance relative to solver execution time.

Appendices

Appendix A: Typing rules for code

The completely standard type-computation rules for code terms are given in Fig. 21. Code terms are monomorphically typed. We write N for any arbitrary precision integer, and use several arithmetic operations on these; others can be easily modularly added. Function applications are required to be simply typed. In the typing rule for pattern matching expressions, patterns P must be of the form c or (c x ₁ ⋯ x _m ), where c is a constructor, not a bound variable (we do not formalize the machinery to track this difference). In the latter case, ctxt(P)={x ₁:T ₁,…x _n :T _n }, where c has type Πx ₁:T ₁.⋯x _n :T _n .T. We sometimes write (do C ₁ C ₂) as an abbreviation for (let x C ₁ C ₂), where $x\not\in \hbox{\texttt{FV}}(C_{2})$.

Fig. 21

Typing rules for code terms. Rules for the built-in rational type are similar to those for the integer type, and so are omitted

Appendix B: Helper code for resolution

The helper code called by the side condition program resolve of the encoded resolution rule R is given in Figs. 22 and 23. We can note the frequent uses of match, for decomposing or testing the form of data. The program eqvar of Fig. 22 uses variable marking to test for equality of LF variables. The code assumes a datatype of Booleans tt and ff. It marks the first variable, and then tests if the second variable is marked. Assuming all variables are unmarked except during operations such as this, the second variable will be marked iff it happens to be the first variable. The mark is then cleared (recall that markvar toggles marks), and the appropriate Boolean result returned. Marks are also used by dropdups to drop duplicate literals from the resolvent.

Fig. 22

Variable and literal comparison

Fig. 23

Operations on clauses

Appendix C: Small example proof

Figure 24 shows a small QF_IDL proof. This proof derives a contradiction from the assumed formula

The proof begins by introducing the variables x, y, and z, and the assumption (named f) of the formula above. Then it uses CNF conversion rules to put that formula into CNF. CNF conversion starts with an application of the start rule, which turns the hypothesis of the input formula $(\mathsf{th\_hold}\ \phi)$ to a proof of the partial clause $(\mathsf{pc\_hold}\ (\phi;))$. The dist_pos, mentioned also in Sect. 4.3 above, breaks a conjunctive partial clause into conjuncts. The decl_atom_pos proof rule introduces new propositional variables for positive occurrences of atomic formulas. The new propositional variables introduced this way are v0, v1, and v2, corresponding to the atomic formulas (let us call them ϕ ₀, ϕ ₁, and ϕ ₂) in the original assumed formula, in order. The decl_atom_pos rule is similar to rename (discussed in Sect. 4.3 above), but it also binds additional meta-variables of type (atom v ϕ) to record the relationships between variables and abstracted formulas. So for example, a0 is of type (atom v0 ϕ ₀ ). The clausify rule turns the judgements of partial clauses with the empty formula sequence $(\mathsf{pc\_holds}\ (;c))$ to the judgements of pure propositional clauses (holds c). Here, this introduces variables x0, x1, and x2 as names for the asserted unit clauses ϕ ₀, ϕ ₁, and ϕ ₂, respectively.

Fig. 24

A small QF_IDL proof

After CNF conversion is complete, the proof derives a contradiction from those asserted unit clauses and a theory clause derived using assume_true (see Sect. 4.4) from a theory contradiction. The theory contradiction is obtained with idl_trans and idl_contra (Sect. 5.1).