Method and case study of model checking concurrent systems that use unbounded timestamps

Transcription

1 2017 IEEE 22nd Pacific Rim International Symposium on Dependable Computing Method and case study of model checking concurrent systems that use unbounded timestamps Shinya Nakano Graduate School of Information Science and Technology Osaka University Osaka, Japan Tatsuhiro Tsuchiya Graduate School of Information Science and Technology Osaka University Osaka, Japan Abstract Parallel and distributed algorithms, including those for fault tolerance, often use timestamps to coordinate the behaviors of processes. These algorithms are hard to correctly design and often subject to subtle design faults. Model checking, which is a state exploration-based verification method, has been very successful in finding design faults in many practical systems. However model checking of timestamp-based algorithms is difficult when the values of timestamps are not bounded, because then the state space is infinite. This paper addresses the problem of infinite state space by proposing a data abstraction technique for timestamps. This technique transforms the infinitestate algorithm to a finite-state abstract model which simulates the original algorithm. The applicability of this approach is demonstrated through a case study Lamport s bakery algorithm is verified in the absence and presence of process failures. Index Terms model checking, data abstraction, timestamp, bakery algorithm, SPIN I. INTRODUCTION Parallel and distributed algorithms, including those for fault tolerance, often use timestamps to coordinate the behaviors of processes. These algorithms are proven to be hard to correctly design and often subject to subtle design faults. Model checking, which is a state exploration-based verification method, has been very successful in finding design faults in many practical systems. However applying model checking to timestamp-based algorithms is difficult when the values of timestamps are not be bounded, in which case the state space is infinite. This paper addresses the problem of infinite state space by proposing a data abstraction technique for timestamps. The key observation behind the proposed technique is that the behaviors of the algorithm mainly depend on the equality or inequality of different timestamps but do not depend on their values themselves. This observation leads to a simple abstraction that represents the vector of unbounded timestamps by that of small integers that maintains the same ordering. As a result the abstraction yields a finite state abstract model which simulates the original algorithm. As a motivating example, let us consider a simplified version of Lamport s bakery algorithm [1] (Algorithm 1). The purpose Algorithm 1 Simplified bakery algorithm (i =0, 1) 1: variables 2: t i (shared), tmp i (local) 3: initialization 4: t i := 0; tmp i := 0 5: task 6: while true do 7: tmp i := t 1 i +1 8: t i := tmp i 9: wait until (t 1 i =0 tmp i <t 1 i (tmp i = t 1 1 i =0)) 10: critical section 11: t i := 0 of the algorithm is to coordinate two concurrent processes i = 0, 1 to achieve mutual exclusion. The variables t 0 and t 1 are shared by the two processes, as tmp 0 and tmp 1 are local to each process. In the algorithm, all the four variables are used to store timestamps. When the two processes compete for the critical section, the process i that has a smaller timestamp t i is permitted to enter the critical section. The timestamps can be arbitrarily large when the two processes are continuously trying to enter the critical section. Therefore it is not possible to explore all possible states of this simple algorithm using a finite state model checker, which is the kind of model checker that is most widely used. We propose an abstraction technique that can be used to transform a timestamp-based algorithm into an algorithm that has no unbounded timestamps. We show that the behavior of the transformed algorithm over-approximates that of the original algorithm. In other words, the abstract algorithm contains all behaviors of the original algorithm. This makes it possible to verify the original algorithm by model checking the finite-state algorithm. II. MODEL We represent the algorithm under verification as a guarded command program. This is because guarded command programs allow more rigorous treatment than pseudocode without introducing a complex operational semantics. A guarded command program (or program for short) consists of a finite set of state variables and a finite set of guarded commands. A state variable is either a finite variable that has a finite domain or a timestamp variable which takes any non-negative integer /17 $ IEEE DOI /PRDC

2 finite variables pc i {1, 2, 3, 4} timestamp variables t i,tmp i initialization pc i := 1,t i := 0,tmp i := 0 commands pc i =1 tmp i := t 1 i +1,pc i := 2 pc i =2 t i := tmp i,pc i := 3 pc i =3 (t i 1 =0 tmp i <t i 1 (tmp i = t 1 1 i =0)) pc i := 4 pc i =4 t i := 0,pc i := 1 Fig. 1. Guarded-command program for simplified bakery algorithm (i =0, 1) value. We denote the timestamp variables by ts i,i=1,..., N N is the total number of timestamp variables. A guarded command is a pair of a guard and an action, denoted as guard action A guard is either an atomic state formula, which is defined below, or any Boolean combination of atomic state formulae. We define an atomic state formula as either of: 1) An arbitrary Boolean-valued expression over finite variables; 2) ts i ts j is either of <, >,, or =; and 3) ts i =0and ts i 0. An action is a set of substitutions to state variables. The substituted value to a finite state variable cannot depend on the values of the timestamp variables. We also assume that at most one timestamp can be updated in any action. We permit substitution to a timestamp variable ts i only if it is either of the following forms: Reset) ts i := 0 Set) ts i := ts j (i j) Set and increment) ts i := ts j +1 (Possibly i = j, in which case this corresponds to an increment of ts i.) Pseudocode can be translated into guarded command code by introducing a state variable that works as a program counter. Figure 1 shows the program that represents Algorithm 1 pc i is the program counter variable for process i. The behavior of the system is represented as a state transition system (S, T, s init ) : S: a set of states. S D 1... D F N N 0 D i is the domain of the ith finite variable, F is the number of finite variables, and N 0 is the set of non-negative integers. T S S: a set of transitions. A transition is an ordered state pair (s, s ) such that there is some command such that its guard is true with respect to state s and applying its action to s yields the next state s. s init S: the initial state. In a state transition system, a path from state s 1 S is an infinite sequence of states s 1 s 2... such that 1) (s i,s i+1 ) T for any i 1, or 2) there exists some e 1 such that (s i,s i+1 ) T for any 1 i e 1, no commands are enabled at s e, and s i = s e for any i e. The second case is necessary to treat finite and infinite behaviors in a uniform way. (Technically, the second case defines stutter extension.) III. TIMESTAMP ABSTRACTION A. Abstract Program The basic idea of the proposed abstraction technique is as follows. When the program has a total of N timestamp variables, we map the value of a timestamp to an integer in {0,..., N} to represent their order in size and zeroness. We denote this mapping by h : N N 0 {0,..., N} N N 0 is a set of non-negative integers. Let h i ( ) denote the ith element of h( ). We define h( ) as follows. 0 ts i =0 h i (ts 1,..., ts N )= j ts i 0and ts i is the jth smallest element in {ts i (1 i N) ts i 0} For example, we have: h(10, 0, 12) = (1, 0, 2) h(10, 10, 10) = (1, 1, 1) Now we show how to translate the program under verification into another program that has no timestamp variables. Figure 2 shows the abstract program that is derived from the one shown in Figure 1. In the translation, a guarded command guard action of the original program is replaced with one or two guarded commands a-guard a-action. We call the new program the abstract program of the given program. In the resulting abstract program, each timestamp variable ts i is replaced with a finite state variable which abstracts ts i based on h( ). As a result, the state space of the abstract program becomes finite. We call an abstract timestamp. Case 0) There is no update on timestamps in action. In this case a-action is identical to action. The guard a-guard is derived from the guard of the original algorithm simply by replacing ts j with ats j. Case 1) The action contains ts i := 0. In this case the substitution ts i := 0 is replaced with (ats 1,..., ats N ) := RST atsi (ats 1,..., ats N ). RST atsi is defined as follows. RST atsi (ats 1,.., ats n )=h(ats 1,.., ats n) ats k = { atsk k i 0 k = i The guard a-guard is derived as in Case 0. Case 2) The action contains ts i := ts j. In this case the substitution ts i := ts j is replaced with (ats 1,..., ats N ):= 262

3 SET atsj (ats 1,..., ats N ). SET atsj (ats 1,..., ats N ) is defined as follows. SET atsj (ats 1,.., ats n )=h(ats 1,.., ats n) { ats atsk k i k = ats j k = i The guard a-guard is derived as in Cases 0 and 1. Case 3) The action contains ts i := ts j +1. This case is the most difficult to deal with. For example, (ats 1,ats 2,ats 3 )= (1, 2, 3) could represent (ts 1,ts 2,ts 3 ) = (10, 20, 30) or (19, 20, 30). Then suppose that an action increments ts 1. This results in (ats 1,ats 2,ats 3 ) = (1, 2, 3) or (1, 1, 2). Hence, unlike the above cases, two new commands are necessary. The action of the first guarded command is obtained by replacing the substitution ts i := ts j +1 in action with (ats 1,..., ats N ):=INC1 atsj (ats 1,..., ats N ). INC1 atsj is defined as follows. INC1 atsj (ats 1,..., ats N )=h(ats 1,..., ats N ) ats k k i at k at j ats k = ats j +1 k = i ats k +1 k i at k >at j This function represents the situation the updated value of ts i is still smaller than the timestamps that were greater than ts j before the increment. Note that this situation occurs only if ts j is not the greatest among all the timestamp variables, that is, ats j < max 1 i N { }. As a result, the guard a-guard is different in the above cases: It is a conjunction of guard with ts i replaced with and < max 1 i N { }. The action of the second one is obtained by replacing ts i := ts j +1 with (ats 1,..., ats N ):=INC2 atsj (ats 1,..., ats N ). INC2 atsj is defined as follows. INC2 atsj (ats 1,.., ats N )=h(ats 1,.., ats N ) { ats atsk k i k = ats j +1 k = i The guard of the command is derived as in the above three cases. B. Simulation relation Let M denote the transition system of the original program. and M that of the abstract program. We define M just as M but limit atomic state formulae for M to those that can be obtained from those for M by replacing ts i with. For example, >ats j is an atomic state formula for M (this corresponds to atomic state formula ts i >ts j for M); but =1is not, because ts i =1is not an atomic state formula for M. Also we identify an atomic state formula for M with its corresponding one for M. Given M =(S, T, s init ) and M =(S,T,s init ), a relation H S S is a simulation relation between M and M iff for all (s, s ) H, the following conditions hold. finite variables pc i {1, 2, 3, 4}; at i,atmp i {0, 1, 2, 3, 4} initialization pc i := 1,at i := 0,atmp i := 0 commands pc i =1 at i 1 < max{at 0,at 1,atmp 0,atmp 1} (at 0,at 1,atmp 0,atmp 1):=INC1 at i 1 atmp i ( ),pc i := 2 pc i =1 (at 0,at 1,atmp 0,atmp 1):=INC2 at i 1 atmp i ( ),pc i := 2 pc i =2 (at 0,at 1,atmp 0,atmp 1):=SET atmp i at i ( ),pc i := 3 pc i =3 (at i 1 =0 atmp i <at i 1 (atmp i = at 1 1 i =0)) pc i := 4 pc i =4 (at 0,at 1,atmp 0,atmp 1):=RST ati ( ),pc i := 1 Fig. 2. Abstract program for simplified bakery algorithm (1) a AP, a is true with respect to s iff so is with respect to s, AP is the set of atomic state formulae. (2) For each state s 1 such that (s, s 1 ) T, there exists a state s 1 with the property that (s,s 1) T and (s 1,s 1) H. (3) If no state s 1 exists such that (s, s 1 ) T, then no state s 1 exists such that (s,s 1) T or there exists a state s 1 with the property that (s,s 1) T and (s, s 1) H. We say that M simulates M, denoted M M, if there exists a simulation relation H S S such that (s init,s init ) H. We also say that paths π = s 1 s 2... in M and π = s 1s 2... in M correspond iff (s i,s i ) H for every i 1. In [2], it is shown that if M M and (s, s ) H, then every path starting from s in M has a corresponding path starting from s in M. In other words, M is an overapproximation of M. As a result, if a formula in LTL, a wellknown temporal logic, is true with respect to M, then it is also true with respect to M. This means that it is possible to model check the given program by model checking the abstract program if M M. Let H be the relation over S and S that is induced by h( ). That is, (s, s ) H iff v i = v i for all 1 i F and = h i (ts 1,..., ts N ) for all 1 i N, v i is the ith finite variable of the original program and v i is the finite variable of the abstract program that corresponds to v i. Then we can show that M M with this H. The outline of the proof is as follows. Condition (1) holds by the definition of atomic state formulae. Condition (2) holds due to the argument in Section III-A every command of the original program is substituted by one or two commands that yield all possible next states. If no command is enabled at s, then no command of the abstract program is enabled at s such that (s, s ) H; thus Condition (3) is also met. IV. CASE STUDY We applied the proposed technique to model checking of Lamport s bakery algorithm, which is a classical mutual exclusion algorithm for concurrent systems. Algorithm 2 shows the pseudocode of the algorithm for n processes (processes 0,..., n 1). Unlike other algorithms then known, the bakery 263

4 Algorithm 2 Bakery algorithm (i =0, 1,..., n 1) 1: variables 2: choosing i, number i 3: initialization 4: choosing i := false; number i := 0; 5: task 6: while true do 7: choosing i := true 8: number i := 1 + max{number 0,..., number n 1} 9: choosing i := false 10: for j =0, 1,..., n 1 do 11: wait until choosing j = false 12: wait until (number j =0) (number i < number j) (number i = number j 13: critical section 14: number i := 0 i<j)) algorithm was new in that it can tolerate failures of processes with the assumptions that if the process i fails during executing the critical section, it exits the critical section immediately and that variables choosing i and number i will be eventually reset to zero and false. Variables choosing i and number i are read by all processes but are written only by process i. The variables number i are timestamp variables which have no upper bound on their values. We used the SPIN model checker, a well-known finite state model checker [3]. The input language of SPIN is called Promela and has a C-like syntax. Figures 3 and 4 show snippets of the Promela program that implements the algorithm using the proposed abstraction technique. We wrote the Promela program so that at most one read or write can occur for shared variables choosing i and number i in every atomic step. This fine-grained atomicity requires each process to own a local timestamp variable that temporarily stores the value of number i for some i. Thus there are a total of 2n timestamp variables in the Promela program. All the 2n timestamps are represented by array number: number[i] and number[i+n] represent variable number i and the local timestamp variable for process i. Constants N and NN are set to n and 2n, respectively. Figures 3 shows how RST atsi ( ), SET atsj ( ), INC1 atsj ( ) and INC2 atsj ( ) are implemented in Promela. Note that as Promela has a rigorous operational semantics, a Promela program can be transformed into a guarded command program or vice versa. In this code, canonicalize() works just as does h( ) in the definitions of the four functions in Section III-A. (The code for canonicalize() is omitted.) For code brevity, the inc(i) part, which implements INC1 atsj ( ) and INC2 atsj ( ), takes a single argument i, because the algorithm performs no substitution of the form ts i := ts j +1 except for number i := tmp i +1 tmp i is the local timestamp for process i. Lines are used to determine whether the condition ats j < max 1 i N { } holds or not (see Case 3 in Section III-A). If this condition holds, then either INC1 atsj ( ) (lines 36 43) and INC2 atsj ( ) (lines 44 49) can be applied to update the abstract timestamps. Otherwise, only INC2 atsj ( ) can be applied (lines 52 57). Figure 4 shows the code that implements the main while loop of the algorithm. The provided construct (provided (...)) was only used to model process failures and removed when verifying failure-free runs. We model checked the algorithm against two properties expressed in LTL as follows. Mutual exclusion: (num cs 1) Progress of process n 1: (choosing n 1 = true in cs n 1 = true) Here num cs is an auxiliary variable that counts the number of processes that are executing the critical section. in cs n 1 is also an auxiliary variable that represents whether process n 1 is in the critical section or not. We used a Linux workstation with Xeon E CPU and 128 GB memory. No property violation was detected by model checking the program. This result was expected because the correctness of the bakery algorithm was proven several times [4], [5], [6], [7]. Statics, including state space size and time usage, are summarized in Tables I(a) and I(b). Next we verified whether these properties hold or not in the presence of process failures. To do so we first modeled the process failures using the technique proposed in [8]. For each process we added a new state variable halt i to represent whether the process has halted or not. The occurrence of a failure is modeled by a non-deterministic step which sets halt i to true. In a guarded command program, this could be represented by the following command: halt i = false halt i := true When halt i = true, no steps can occur for process i, except for those resetting choosing i and number i. In Figure 4, the provided construct is used to disable all normal steps when halt i = true (line 23). Figure 5 shows how a failure of process id is modeled in our Promela program. After a process i failed (line 8), choosing i and number i are eventually reset (lines 14 15). We wrote the program so that every process except process n 1 can fail at any time. Tables I(c) and I(d) show the performance figures measured when process failures were considered. Although model failures increased time consumption, verification was completed for up to three processes. No property violations were detected, again. However, in the process of writing the Promela program, we encountered a subtle programming error that manifests only at the very moment when the shared variables number i and choosing i are reset in order to handle the failure of process i. This error was found because the violation of mutual exclusion was detected as a result of model checking the program. This design error could not have been detected using traditional approaches to finding errors, such as testing, suggesting the usefulness of model checking for hunting subtle design errors in failure handling procedures. V. RELATED WORK Abstraction has been extensively studied as a powerful means to overcome the large state space occurring in model 264

5 1: shared variables 2: bool choosing[n]; 3: byte number[nn]; 4: hidden byte rankarr[nn]; 5: task 6: inline set(i, j) { 7: for(k: 0.. 2*N-1) { 8: if 9: ::k!=i-> number[k] = number[k]; 10: ::k==i-> number[k] = number[j]; 11: fi; 12: } 13: canonicalize(); 14: } 15: inline rst(i) { 16: for(k: 0.. 2*N-1) { 17: if 18: ::k!=i-> number[k] = number[k]; 19: ::k==i-> number[k] = 0; 20: fi; 21: } 22: canonicalize(); 23: } 24: inline inc(i) { 25: set(i, i+n); 26: bool eq = false; 27: for(k: 0.. 2*N-1) { 28: if 29: :: k!= i && number[i] < number[k] -> eq = true; break; 30: :: else -> skip; 31: fi; 32: } 33: if 34: :: eq == true -> 35: if 36: :: for(k:0..2*n-1) { 37: if 38: :: k!= i && number[k] <= number[i] -> number[k] = number[k]; 39: ::k==i-> skip; 40: :: k!= i && number[k] > number[i] -> number[k] = number[k] + 1; 41: fi; 42: } 43: number[i] = number[i] + 1; 44: :: for(k:0..2*n-1) { 45: if 46: ::k!=i-> number[k] = number[k]; 47: :: k == i-> number[k] = number[k] + 1; 48: fi; 49: } 50: fi; 51: :: eq == false -> 52: :: for(k:0..2*n-1) { 53: if 54: ::k!=i-> number[k] = number[k]; 55: :: k == i-> number[k] = number[k] + 1; 56: fi; 57: } 58: fi; 59: canonicalize(); 60: } 1: variables 2: bool eq; 3: byte l, k; //loop variable 4: task 5: inline max(id) { 6: byte index; 7: atomic { rst(id+n); } 8: for(index : 0.. N-1) { 9: if 10: :: atomic { number[id + N] < number[index] -> set(id+n, index); } 11: :: atomic { j==n-> cs[id] = true; in cs++; } 12: fi; 13: } 14: } 15: inline decision() { 16: byte j=0; 17: do 18: :: j < N && choosing[j] == false -> atomic { set(id+n, id); } 19: atomic { (number[j] == 0) (number[j] > number[id + n]) ((number[j] == number[id+n]) && j >= id); j++; 20: ::j==n-> break; 21: od; 22: } 23: proctype P(byte id) provided (halt[id] == false) { 24: Non-Critical: 25: choosing[id] = true; 26: Wait: 27: max(id); 28: atomic { inc(id); } 29: decision(); 30: CriticalSection: 31: atomic { rst(id); } 32: goto Non-Critical; 33: } Fig. 4. Promela implementation of Bakery algorithm s main loop 1: shared variables 2: bool halt[n], cs[n]; 3: byte in cs; 4: variables 5: byte l, k; //loop variable 6: task 7: proctype F(byte id) { 8: atomic { halt[id] == false -> halt[id] = true; } 9: atomic { 10: if 11: :: cs[id] == true -> cs[id] = false; in cs--; 12: :: else -> skip; 13: fi; 14: choosing[id] = false; 15: rst(id); 16: } 17: } Fig. 5. Promela implementation of failure process Fig. 3. Promela implementation of RST, SET and INC 265

6 TABLE I PERFORMANCE FIGURES (a) Mutual exclusion verification in failure-free case # States E+08 # Transitions E+09 Elapsed time [sec] E+04 *1: number of global system states stored *2: number of transitions explored (b) Progress verification in failure-free case # States NA # Transitions NA Elapsed time [sec] NA (c) Mutual exclusion verification in presence of process failures # States NA # Transitions NA Elapsed time [sec] NA (d) Progress verification in presence of process failures # States NA # Transitions NA Elapsed time [sec] NA checking of practical systems. The equivalence between M and M such that M M with respect to ACTL*, a temporal logic which subsumes LTL, is proven by Clarke et al. in their seminal work [2]. To our knowledge, the works that study timestamp abstraction include [9], [10], [11], [12]. In [10] and [11] we used timestamp abstraction for model checking of consensus algorithms. Consensus algorithms are distributed algorithms that make the set of processes reach an unanimous decision in spite of process or communication faults. In these previous studies, timestamp abstraction was used without rigorous proof, since the correctness was rather clear because, for example, increment of timestamp was not dealt with. As shown in Section III increment is the most intricate to deal with among the three operations that we discussed in this paper. In [12] an access control mechanism for secure information sharing was model checked using a similar abstraction technique to [10], [11]. The work that is most related to our work of this paper is the one by Derepas et al [9]. They model checked a replicationbased fault tolerant distributed system with timestamp abstraction. In the system under verification, increment of a timestamp by one is not used, as an assignment to the value that is greater than any other timestamps can occur. They provided a proof that an abstract model for the system bisimulates the original infinite-state model, which means that the two models are equivalent with respect to a large class of temporal logic, such as CTL*. As in [10], [11], [12], increment of timestamp is not considered in [9]. transition systems. The feasibility of the proposed technique was demonstrated by applying the technique to verification of the classical bakery algorithm. Using SPIN, an explicit state model checker, together with the proposed abstraction technique allowed us to check that mutual exclusion and fault tolerance hold in all possible states. An obvious direction of future work is to apply the proposed technique to model checking of various algorithms. In particular, we are interested in verification of fault-tolerant distributed algorithms, such as consensus algorithms. Currently we are working on model checking of the leader election part of RAFT [13], which is a relatively new consensus algorithm. This part of the algorithm uses unbounded timestamps and thus the proposed technique can be made use of in its verification. REFERENCES [1] L. Lamport, A new solution of Dijkstra s concurrent programming problem, Commun. ACM, vol. 17, no. 8, pp , Aug [Online]. Available: [2] E. M. Clarke, O. Grumberg, and D. E. Long, Model checking and abstraction, ACM transactions on Programming Languages and Systems (TOPLAS), vol. 16, no. 5, pp , [3] G. J. Holzmann, The SPIN Model Checker. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., [4] L. Lamport, A new approach to proving the correctness of multiprocess programs, ACM Trans. on Progr. Languages and Syst., vol. 1, no. 1, pp , Jan [Online]. Available: [5] D. Rosenzweig, E. Börger, and Y. Gurevich, Specification and validation methods, E. Börger, Ed. New York, NY, USA: Oxford University Press, Inc., 1995, ch. The Bakery Algorithm: Yet Another Specification and Verification, pp [6] K. Ogata and K. Futatsugi, Formal analysis of the bakery protocol with consideration of nonatomic reads and writes, in Proc. 10th International Conference on Formal Engineering Methods (ICFEM 2008). Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp [7] W. H. Hesselink, Mechanical verification of lamport s bakery algorithm, Science of Computer Programming, vol. 78, no. 9, pp , [Online]. Available: [8] A. Arora and M. Gouda, Closure and convergence: A foundation of fault-tolerant computing, IEEE Transactions on Software Engineering, vol. 19, no. 11, pp , [9] F. Derepas, P. Gastin, and D. Plainfossé, Avoiding state explosion for distributed systems with timestamps, in International Symposium of Formal Methods Europe. Springer, 2001, pp [10] T. Tsuchiya and A. Schiper, Model checking of consensus algorithms, in Proc. 26th Symp. on Reliable Distributed Systems (SRDS), Beijing, China, Oct. 2007, pp [11] T. Noguchi, T. Tsuchiya, and T. Kikuno, Safety verification of asynchronous consensus algorithms with model checking, in Proc. of 18th Pacific Rim International Symposium on Dependable Computing (PRDC 12). Niigata, Japan: IEEE CS Press, Nov. 2012, pp [12] W. Zhao, J. Niu, and W. H. Winsborough, Refinement-based design of a group-centric secure information sharing model, in Proceedings of the Second ACM Conference on Data and Application Security and Privacy, ser. CODASPY 12. New York, NY, USA: ACM, 2012, pp [Online]. Available: [13] D. Ongaro and J. Ousterhout, In search of an understandable consensus algorithm, in 2014 USENIX Annual Technical Conference (USENIX ATC 14), 2014, pp VI. CONCLUSION AND FUTURE WORK We proposed an approach to model checking of systems that use unbounded timestamps. The proposed abstraction technique can reduce the model checking problem of infinite state transition systems to the problem of model checking finite 266