Other tree automata completion tools

We briefly present two other completion tools: one encoding the completion into horn clauses and an other one into pure rewriting. Surprisingly, though the two encodings were independently defined, they are very similar. They rely on the slicing of both left and right-hand sides of rewrite rules.

Tree automata completion by horn clauses

The first technique, proposed by (Gallagher and Rosendahl, 2008), is based on an encod- ing of both tree automata and term rewriting systems into Horn clauses. The rewriting symbol → used for rewriting and tree automata is encoded by a binary first order predi- cate _ → _. A tree automaton transition f (q1, . . . , qn) → q is represented by the horn

clause (f (q1, . . . , qn) → q) ← true. A rewrite rule plus(s(x), y) → s(plus(x, y)) will

be replaced by the following horn clauses:

(1) (plus(X, Y ) → q(X, Y )) ← (s(X) → Q1), (plus(Q1, Y ) → Q)

(2) (s(q(X, Y )) → Q) ← (s(X) → Q1), (plus(Q1, Y ) → Q)

Now, let us explain how application of horn clauses on an initial tree automaton models completion. Assume that the tree automaton contains the following transitions:

plus(q1, q2) → q0

s(q3) → q1

encoded by the facts (unit horn clauses)

(3) (plus(q1, q2) → q0) ← true

(4) (s(q3) → q1) ← true

Using the clauses (1) and (2) representing the TRS and the facts (3) and (4), we can thus deduce the following facts. Using clause (1) (resp. (2)) with X = q3, Q1 = q1

Y = q2and Q = q0, we obtain the fact (5) (resp. (6)):

(5) (plus(q3, q2) → q(q3, q2)) ← true

(6) (s(q(q3, q2)) → q0) ← true

which is exactly the set of transitions that would have been obtained using completion and normalization with a new state named q(q3, q2). However, like for completion the

construction of the least Herbrand model is unlikely to terminate. The approach developed in (Gallagher and Rosendahl, 2008) computes an approximation using state-of-the-art static analysis tools for logic programs, i.e. the Bddbddb tool (Whaley et al., 2004). This results into a very efficient completion tool as shown in the table Figure 4.5. However, as for other static analysis tools (see Section 2.3.2) the approximation precision is fixed. This is different from what can be done using normalization rules or equations.

Tree automata completion by rewriting

The second technique, proposed in (Balland et al., 2008), encodes completion into the Tom rewriting tool (Tom, 2009). The encoding of tree automata uses a special variadic symbol sons for representing sets of terms. For instance, the set of tree automata transitions {f (q1, q2) → q, g(q) → q} is represented using a constant q that is associated to the term

sons(f (q1, q2), g(q)). Then, as in the previous work, left-hand sides of rewrite rules are

sliced as follows. Given f (x, g(y)) → f (g(x), g(y)) a rewrite rule, its sliced encoding is g(y) → C1(y)

f (x, C1(y)) → C2(x, y)

Taking advantage of Tom’s matching algorithm on variadic symbols, those rules can be replaced by the following set of Tom’s rules:

(1) g(y) → C1(y)

(2) f (x, sons(_∗, C1(y), _∗)) → C2(x, y)

(3) C2(x, y) → f (g(x), g(y))

Now, we briefly explain how completion works. Let q = sons(f (q1, q2)) and q2 =

sons(g(q3)) be the initial tree automaton. Rule (1) can be applied on the term q2that be-

comes: q2= sons(g(q3), C1(q3)). Hence, rule (2) can be applied on term q because q can

be unfolded as sons(f (q1, sons(g(q3), C1(q3))) and the term f (x, sons(_∗, C1(y), _∗))

matches the subterm at position 1. such that x = q1 and y = q3. Hence, q becomes

sons(f (q1, q2), C2(q1, q3). The next rewriting step consists in rewriting C2(q1, q3) into

f (g(q1), g(q3)). Like in usual tree automata completion, this term needs to be normal-

ized first by introducing new terms (in place of the new states of completion), i.e. terms q4= sons(g(q1)). Hence q becomes sons(f (q1, q2), C2(q1, q3), f (q4, q2).

Comparison of the efficiency of the different completion techniques

The two encodings presented above lead to very efficient implementation of completion. We here give a comparison of the overall performances of the different tools implementing completion on some typical examples. In the table Figure 4.5, the automaton size is given as (number of transitions / number of states) except for the bddbddb-based tool whose number of transitions is unknown. The benchmarks were done on different computers but with very similar characteristics: dual core computers with 4GByte RAM. Comparison of the Tom- based and Bddbddb-based implementation can only done on the NSPK, View-Only and Combinatory examples because these are the only examples present in both papers.

The Combinatory example is a tiny TRS whose completion produces a large number of substitutions. Let R = {g(f (x1), h(h(h(x2, x3), x4), x5)) → u(x1, x2, x3, x4, x5)}

and A be the tree automaton whose transition set is the following: {nil → qh, f (qa1) →

qf, g(qf, qh) → qg}∪{t → qt, h(qh, qt) → qh| t ∈ {ai, bi, ci, di| i = 1, . . . , 5}}. For the

variables x1, x3, x4and x5there are twenty possible instantiations during the completion.

The variables x1and x2take only and respectively the values qa1 and qh. So, there are 20

3

transitions to compute by completion.

The NSPK example, i.e. Needham-Schroeder public key protocol is partially described in Section 5.1.2. This is, in fact, the version of the protocol corrected by G. Lowe (Lowe,

Combinatory NSPK View-Only Java prog. 1 Java prog. 2

TRS size (nb of rules) 1 13 15 279 303

Initial Automaton size 43 / 23 14 / 4 21 / 18 26 / 49 33 / 33

Timbuk 2.2:

Final Automaton size 8043 / 23 151 / 16 730 / 74 1127 / 334 751 / 335

Time (secs) 51.1 19.7 6420 25266 37387

Timbuk 3.0:

Final Automaton size 8043 / 23 259 / 104 353 / 100

Time (secs) 60.1 3.1 2452

Tom-based tool:

Final Automaton size 8043 / 23 171 / 21 938 / 89 1974 / 637 1611 / 672

Time (secs) 5.9 5.9 150 360 303

Bddbddb-based tool:

Final Automaton size ? / 25 ? / 183 ? / 97

Time (secs) 0.008 2.9 3.3

Figure 4.5: Benchmarks on three completion implementations

1996b) and used in (Genet and Klay, 2000). The View-Only example is another crypto- graphic protocol composing the Smartright system SmartRight (2001) designed by Thom- son, see Section 5.1.3. Finally, Java Prog examples are TRS obtained by translation of Java bytecode applications as detailed in Section 5.2.

From this table, it is clear that the Bddbddb-based tool by (Gallagher and Rosendahl, 2008) is the most efficient one. What needs to be remarked, however, is that it does not tackle the same objective. Indeed, the approximation it computes is fully automatic and built-in the tool. As a consequence, if the approximation is too coarse, there is no way to refine it so as to prove the property. It is the case, for instance, for the NSPK and View-Only examples where the approximation computed by the Bddbddb-tool does not permit to prove the expected property whereas approximation computed by Timbuk and the Tom-based tool do. On all results computed by Timbuk 2.2 the expected properties were proved. It is also the case for Timbuk 3.0 except for the View-only example where only one of the numerous security has been proved (secrecy of so-called control words) using approximation equations.