1 Introduction
Petri nets [45], also known as vector addition systems [23], [18, cf. Section 5.1], [20], are a long established model of concurrency with extensive applications in modelling and analysis of hardware [7, 28], software [17, 6, 21] and database [5, 4] systems, as well as chemical [1], biological [44, 2] and business [50, 36] processes (the references on applications are illustrative). The central algorithmic problem for Petri nets is reachability: whether from the given initial configuration there exists a sequence of valid execution steps that reaches the given final configuration.
There are several presentations of Petri nets, and a number of variants of their reachability problem, all of which are equivalent. One simple way to state the problem is: given a finite set of integer vectors in dimensional space and two dimensional vectors and of nonnegative integers, does there exist a walk from to such that it stays within the nonnegative orthant, and its every step modifies the current position by adding some vector from ?
Brief History of the Problem.
Over the past half century, the complexity of the Petri nets reachability problem has remained unsettled. The late 1970s and the early 1980s saw the initial burst of activity. After an incomplete proof by Sacerdote and Tenney [47], decidability of the problem was established by Mayr [39, 40], whose proof was then simplified by Kosaraju [24]. Building on the further refinements made by Lambert in the 1990s [25], there has been substantial progress over the past ten years [29, 30, 31], culminating in the first upper bound on the complexity [32], recently improved to Ackermannian [33].
In contrast to the progress on refining the proof of decidability and obtaining an upper bound on the complexity, Lipton’s landmark result that the Petri nets reachability problem requires exponential space [37] has remained the state of the art on lower bounds for over 40 years. Moreover, in conjunction with an apparent tightness of Lipton’s construction, this has led to the conjecture that the problem is ExpSpacecomplete becoming common in the community.^{1}^{1}1For an interesting post by Lipton about his exponential space hardness result, we refer the reader to https://rjlipton.wordpress.com/2009/04/08/anexpspacelowerbound/.
Main Result and Its Significance.
We show that the Petri nets reachability problem is not elementary, more precisely that it is hard for the class Tower of all decision problems that are solvable in time or space bounded by a tower of exponentials whose height is an elementary function of the input size [49, Section 2.3]. We see this result as important for several reasons:

It narrows significantly the gap to the best known upper bound [33] in terms of the Ackermannian function, which is among the slowestgrowing functions that dominate all primitive recursive functions.

It implies that a plethora of problems from formal languages [9], logic [22, 11, 10, 8], concurrent systems [16, 14], process calculi [42], linear algebra [19] and other areas (the references are again illustrative), that are known to admit reductions from the Petri nets reachability problem, are also not elementary; for more such problems and a wider discussion, we refer to Schmitz’s recent survey [48].
Petri Nets and Exponential Space Hardness.
Before we present the main ideas involved in the proof of the nonelementary lower bound for the reachability problem, let us introduce some key aspects of Petri nets by recalling the crux of Lipton’s construction for the exponential space hardness.
Minsky machines, which can be thought of as deterministic finitestate machines equipped with several registers, are one of the classical universal models of computation [43, Chapter 14]. The registers, which are called counters, store natural numbers (initially ) and can be manipulated by only two simple operations: increments (), and conditionals that either jump if a counter is zero or decrement it otherwise (if then goto else ). With appropriate restrictions, the halting problem for Minsky machines is complete for various time and space complexity classes. Lipton’s proof proceeds by reducing from the following ExpSpacecomplete problem (cf. [15, Theorems 3.1 and 4.3]): given a Minsky machine of size with counters, does it halt after a run in which the counters remain bounded by ?
Petri nets can be construed as similar to Minsky machines, but with two important differences. Firstly, Petri nets can increment a counter always, and can decrement a counter if positive, but cannot test whether a counter is zero. Secondly, Petri nets are nondeterministic. Thus, a decrement of a counter either succeeds and the run continues (if the counter was positive), or fails and the current nondeterministic branch is blocked (if the counter was zero). It is the lack of zero tests that makes decidable [40] the reachability problem: given a Petri net and a subset of its counters, does it halt in a configuration where all the counters from the subset are zero?
To construct a Petri net that simulates the given Minsky machine of size as long as its counters are bounded by , the main task is therefore checking that such a counter is zero. Lipton observed that it suffices to introduce a counter , set up and maintain the invariant , and implement a macro Dec that decrements and increments (i.e., performs the code ) exactly times. That is because the code Dec Dec (where, in the latter instance of the macro, and are swapped) then checks that counter is zero: it either succeeds and leaves and unchanged if was zero (i.e. was ), or fails otherwise.
Lipton’s construction meets that goal inductively, by setting up pairs of counters such that and implementing a macro Dec that decrements a counter and increments its complement exactly times, for . Doing it for is easy. To step from to , consider the following code, where the loops are repeated nondeterministic numbers of times:
looploopDecDec .
Assuming that and are zero at the start, there is a unique nondeterministic branch that runs the code completely (without getting blocked): it repeats the outer loop times with the final Dec both checking that equals (i.e. equals zero) and resetting it to zero, and in each iteration similarly the inner loop is repeated also times. Hence, by squaring , the code decrements the counter and increments the counter exactly times, as required for an implementation of Dec .
Obtaining the Tower Lower Bound.
To prove that the Petri nets reachability problem requires a tower of exponentials of time and space, we have to tackle two major obstacles:

The fact that Lipton’s construction applies also to the coverability problem, which has an ExpSpace upper bound [46], means that a construction that achieves a lower bound beyond ExpSpace cannot follow the same pattern. For example, we cannot hope to implement a macro whose unique complete execution performs some given counter operations exactly a triply exponential number of times.

It has been known for many years how Petri nets can compute various functions weakly, in the sense that the result may be nondeterministically either correct or smaller [41, 34]^{2}^{2}2In their article, Mayr and Meyer establish that the containment problem between finite sets of reachable configurations of two given Petri nets is ‘the first uncontrived decidable problem which is not primitive recursive’.. Most notably, for all natural numbers , Grzegorczyk’s function [38] is computable weakly by a Petri net of size . However, even supposing that we have means of simulating zero tests of several counters bounded by some , it has been unknown how to compute exactly a value exponential in without using extra counters.
To overcome the ExpSpace barrier, we devise a novel construction for simulating zero tests of counters bounded by some : instead of relying on an ability to repeat some counter operations exactly times, it assumes that a pair of counters have been set to sufficiently large values whose ratio is exactly , and it ensures that the simulations of zero tests are correct by testing that one of the two auxiliary counters is zero in the final configuration of the reachability problem instance.
In overcoming the second obstacle, surprisingly a central role is played by the simple identity . We devise a gadget, so called the factorial amplifier, that sets two counters and to arbitrarily large values such that as follows. After initialising both counters to a same value, the main loop uses some extra machinery and a constant number of auxiliary counters to attempt to multiply and by each of the fractions and (respectively) for . Since the multiplications are implemented by repeated additions and subtractions, and since the factorial amplifier cannot zerotest counters that are not bounded by , we have that the resulting values of and are not necessarily correct. Nevertheless, the construction (and here an appropriate intertwining of the operations on and in the main loop is key) is such that the computation is correct if and only if the final value of is at least (and thus exactly) times the initialised one. Then has necessarily been divided by , yielding the ratio between counters and as required.
Organisation of the Paper.
After the preliminaries in Section 2, our scheme for simulating zero tests of bounded counters is developed in Section 3, and the factorial amplifier for setting up arbitrarily large pairs of Petri net counters with ratio is programmed in Section 4.
In Section 5, we put the pieces together to obtain the main result, and then also show how the construction can be refined to establish that, for each positive integer , we have ExpSpacehardness (tower of exponentials of height ) of the reachability problem already for Petri nets with counters.
The last refinement (to counters) is mostly relegated to the appendix available online.
2 Counter Programs
Proving the main result of this paper, namely that solving the Petri nets reachability problem requires a tower of exponentials of time and space, involves some intricate programming. For ease of presentation, instead of working directly with Petri nets or vector addition systems, our primary language will be imperative programs that operate on variables which are called counters, and that range over the naturals (i.e. the nonnegative integers).
To streamline the main constructions and proofs, it will be useful to allow the programs to have two types of counters:
 tested counters

are bounded by a fixed positive integer and may be tested for equality with the end points of their range, i.e. and ;
 untested counters

are unbounded and the testing commands may not be applied to them.
We remark that the availability of the testing commands will not make counter programs more expressive than Petri nets, because the finiteness of the range of tested counters means that their values can be seen as components of net places (or of states in vector addition systems). However, such an enumerative translation involves a blow up proportional to the bound .
Concretely, a counter program is a sequence of commands, each of which is of one of the following five kinds:
(increment counter ) (decrement counter ) goto or (jump to either line or line ) zero? (continue if counter equals ), max? (continue if counter equals ),
except that the last command is of the form:
halt if (terminate provided all the listed counters are zero).
Note that the two types of counters are not declared explicitly: without loss of generality, a counter is regarded as tested (and thus has the range ) if and only if it occurs in a zero? or max? command in the program.
We use a shorthand halt when no counter is required to be zero at termination.
To illustrate how the available commands can be used to express further constructs, addition and substraction of a natural constant can be written as consecutive increments and decrements (respectively). As another illustration, conditional jumps if then goto else which feature in common definitions of Minsky machines can be written as:
where goto is a shorthand for the deterministic jump goto or .
We emphasise that counters (both tested and untested) are not permitted to have negative values. In the example we have just seen, that is why the decrement in line 4 works also as a nonzero test.
Two more remarks may be useful. Firstly, our notion of counter programs only serves as a convenient medium for presenting both Petri nets and Minsky machines with bounded counters, and the exact syntax is not important; we were inspired here by Esparza’s presentation [13, Section 7] of Lipton’s lower bound [37]. Secondly, although the halt if commands could be expressed by zero tests followed by just halt, having them as atomic commands makes it possible to require untested counters to be zero at termination. The latter feature makes untested counters correspond to Petri net counters, which are unbounded, and can be zero tested only at the start and finish of runs by specifying initial and final configurations in instances of the reachability problem.
2.1 Runs and Computed Relations
A run of a program from an initial valuation of all its counters is a run in which all values of all counters are at least , all values of all tested counters are at most , and the max tests are interpreted as checks for equality with .
We say that such a run is halted if and only if it has successfully executed its halt command (which is necessarily the program’s last); otherwise, the run is either partial or infinite. Observe that, due to a decrement that would cause a counter to become negative, or due to an increment that would exceed the bound of a tested counter, or due to an unsuccesful zero or max test, or due to an unsuccessful terminal check for zero, a partial run may be maximal because it is blocked from further execution. Moreover, due to nondeterministic jumps, the same program from the same initial valuation may have various runs in each of the three categories: halted runs, maximal partial runs, and infinite runs. We are mostly going to be interested in final counter valuations that are reached by halted runs.
We regard a run as complete if and only if it is halted and its initial valuation assigns zero to every counter. Let be some (not necessarily all) of the counters in the program. We say that the relation computed in by a program is the set of all tuples such that the program has a complete run whose final valuation assigns to every counter the natural number .
We may consider the same program with more than one bound for its tested counters. When the bound is clear, or when it is not important because there are no tested counters, we may write simply ‘run’ and ‘computed’ instead of ‘run’ and ‘computed’ (respectively).
2.2 Examples
Example 1.
Consider the following program, where is a natural constant, and we observe that all the counters are untested:
It repeats the block of three commands in lines 3–4 some number of times chosen nondeterministically (possibly zero, possibly infinite) and then halts provided counter is zero. Replacing the two jumps by more readable syntactic sugar, we may write this code as:
1:2:loop3:4:5:halt if .
It is easy to see that there is a unique complete run (and there are no infinite runs), in which the loop is iterated exactly times. Thus, the relation computed in is the set with the single tuple . ∎
Example 2.
We shall need to reason about properties of counter valuations at certain points in programs. As an example which will be useful later for simulating tested counters by untested ones, consider a fixed positive integer and assume that
(1) 
holds in a run at the entry to (i.e., just before executing) the program fragment
loop.
The number of times the loop has been iterated by a run that also exits (i.e., completes executing) the program fragment is nondeterministic, so let us denote it by . It is easy to see that property (1) necessarily also holds at the exit, since:

the sum is maintained by each iteration of the loop,

we have that , and

counters and have been decreased by and (respectively).
Continuing the example, if we additionally assume that the exit counter valuation satisfies , then we deduce that:

necessarily ,

also held at the entry, and

and at the entry, and their values at the exit are swapped.
We have thus seen two small arguments, one based on propagating properties of counter valuations forwards through executions of program fragments, and the other backwards. Both kinds will feature in the sequel. ∎
2.3 Petri Nets Reachability Problem
It is well known that Petri nets [45], vector addition systems [23], and vector addition systems with states [18, cf. Section 5.1], [20] are alternative presentations of the same model of concurrent processes, in the sense that between each pair there exist straightforward translations that run in polynomial time and preserve the reachability problem; for further details, see e.g. the recent survey [48, Section 2.1].
Since counter programs without tested counters can be seen as presentations of vector addition systems with states, where the latter are required to start with all vector components zero and to finish with vector components zero as specified by the halt command, the Petri nets reachability problem can be stated as:
 Input

A counter program without tested counters.
 Question

Does it have a complete run?
We remark that restricting further to programs where no counter is required to be zero finally (i.e., where the last command is just halt) turns this problem into the Petri nets coverability problem. In the terminology of vector addition systems with states, the latter problem is concerned with reachability of just a state, with no requirement on the final vector components. Lipton’s ExpSpace lower bound [37] holds already for the coverability problem, which is in fact ExpSpacecomplete [46].
2.4 A TowerComplete Problem
Let us write for the iterate of factorial, so that .
To prove that the Petri nets reachability problem is not elementary, we shall provide a lineartime reduction from the following canonical problem. It is complete for the class Tower of all decision problems that are solvable in time or space bounded by a tower of exponentials whose height is an elementary function of the input size [49, Section 2.3], with respect to elementary reductions.
 Input

A counter program of size , without untested counters.
 Question

Does it have a complete run?
For confirming that this problem is Towercomplete, we refer to [49, Section 4.1] and [49, Section 4.2] for the robustness of the class with respect to the choices of the fastgrowing function hierarchy (here based on the factorial operation) and of the computational model (here nondeterministic Minsky machines), respectively.
3 Simulating Tests
We now introduce our central notion of amplifier for a ratio, and define a special operator for composing them with programs. Provided the ratio of the amplifier is the same as the bound of the program’s tested counters, the resulting composition will be an equivalent program in which those counters have become untested. That is accomplished through eliminating the original program’s zero and max tests by simulating them and using the amplifier to check that the simulations are correct, where a price to pay is introducing an extra untested counter for each of the original tested ones.
The amplifiers themselves may have tested counters. An amplifier whose tested counters are bounded by and whose ratio is a larger number , called a amplifier by , can then be seen, in conjunction with the composition operator, as a means for transforming programs whose tested counters are bounded by into equivalent programs whose tested counters are bounded by . In the special case when the amplifier has no tested counters, the same will be true of the resulting programs.
Another feature, which will be key in Section 5, is that more powerful amplifiers will be obtainable by composition: applying the operator to a amplifier by , and amplifier by , will produce a amplifier by .
3.1 Construction
Suppose that:

and are positive integers;

is a amplifier by , i.e. a program such that the relation it computes in counters is

is a program.
Example 3.
As an example to be used later, when is sufficiently small to write consecutive increments explicitly, it is very easy to code an amplifier by :
1: set to constant2:3:loop4:5:halt.
Observe that this amplifier does not have any tested counters and so, for every positive integer , it is a amplifier by . ∎
Under the stated assumptions, we now define a construction of a program which computes any relation that is computed by . The idea is to turn each tested counter of into an untested one through supplementing it by a new counter and ensuring that the invariant is maintained, so that zero tests of can be replaced by loops that times increment and then times decrement , and similarly for max tests. Counter provided by is employed to initialise each complement counter , whereas and are used to ensure that if is zero at the end of the run then all the loops in the simulations of the zero and max tests iterated times as required. Concretely, the program is constructed as follows:

counters are renamed if necessary so that no counter occurs in both and ;

letting , …, be the tested counters of , new counters , …, are introduced and the following code is inserted at the beginning of :
loop(we shall show that complete runs necessarily iterate this loop times, i.e. until counter becomes zero);

every command in is replaced by two commands
; 
every command in is replaced by two commands
; 
every zero? command in is replaced by the following code:
looploop(we shall show that complete runs necessarily iterate each of the two loops times, i.e. they check that equals through checking that equals by transferring from to and then back);

every max? command in is replaced analogously, i.e. by the code as for zero? but with the increments and decrements of and swapped;

letting (respectively, ) be the counters that are required to be zero at termination of (respectively, ), the code of consists of the code of concatenated with the code of modified as stated, both without their halt commands, and ending with the command
halt if .
We remark that simulating zero tests of counters bounded by some using transfers from and to their complements is a wellknown technique that can be found already in Lipton [37]; the novelty here is the cumulative verification of such simulations, through decreasing appropriately the two counters and whose ratio is , and checking that is zero finally.
3.2 Correctness
Correctness.
The next proposition states that the construction of is correct in the sense that its computed relations in counters of are the same as those computed by . (We shall treat any renamings of counters in step (i) of the construction as implicit.) In one direction, the proof proceeds by observing that can simulate faithfully any complete run of . In the other direction we argue that although some of the loops introduced in steps (v) and (vi) may iterate fewer than times and hence erroneously validate a test, the ways in which counters and are set up by and used in the construction ensure that no such run can continue to a complete one. Informally, as soon as a loop in a simulation of a test iterates fewer than times, the equality turns into the strict inequality which remains for the rest of the run, preventing counter from reaching zero.
Proposition 1.
For every valuation of counters of , it occurs after a complete run of if and only if it occurs after a complete run of .
Proof.
The ‘if’ direction is straightforward: from a complete run of with a total of zero and max tests, obtain a complete run of with the same final valuation of counters of by

running to termination with , , and all of equal to , where the latter counters will remain untouched for the rest of the run and hence satisfy the requirement to be zero finally (cf. step (vii) of the construction),

iterating the loop in step (ii) times to initialise each complement counter to , which also subtracts and from and (respectively) as well as decreases to , and
For the ‘only if’ direction, consider a complete run of . Extracting from it a complete run of with the same final valuation of counters of is easy once we show that, for each simulation of a zero? or max? command by the code in step (v) or (vi) of the construction, the values of at the start and at the finish of the code are or (respectively).
Firstly, by step (vii) and the fact that counters are not used after executing the part of code from , we have that the values of , and that have been provided by satisfy and . After the code in step (ii) we therefore have that for all . Recalling the reasoning in Example 2 and arguing forwards through the run, we infer that
is an invariant that is maintained by the rest of the run.
Now, due to step (vii) again, is zero finally, and so the inequality is finally an equality. Therefore, is zero finally as well. Recalling again the reasoning in Example 2 and arguing backwards through the run, we conclude that in fact has been maintained and that, for each simulation of a zero? or max? command, each of the two loops has been iterated exactly times, and hence the values of at its start and at its finish have been as required. Also, the loop introduced in step (ii) has been iterated times, and is zero finally. ∎
4 Factorial Amplifier
This section is the technical core of the paper. It provides a single program called the factorial amplifier which is, for any positive integer , a amplifier by . Together with the composition operator from Section 3, we shall then have all the tools needed for obtaining our main result in Section 5: chains of compositions of with itself will yield amplifiers by ratios which are towers of exponentials.
4.1 A simple program
As a warm up for the presentation of the main program and the proof of its correctness, let us consider a simpler program specified in Algorithm I. Two macros are used to aid readability, and we now expand them, noting that hidden within them is another counter :
 :

To subtract the current value of counter , we employ the auxiliary counter to which the value of is transferred and then transferred back. At the start of the code, is assumed to be zero, and the same is guaranteed at the finish.
loopzero?loopzero?  :

This is very similar, except for the extra increment of .
loopzero?loopzero?
Program has untested counters , and , and tested counters and . Assuming that the bound for the tested counters is a positive integer , the program does the following:

initialises and to some positive integer chosen nondeterministically, which will be kept unchanged in counter until the final loop;

in each iteration of the main loop, uses counter to attempt to multiply counter by the fraction ;

by the final loop and the terminal check that counter is zero, halts provided the value of is at least (in which case it will be exactly ).
The first and easier part of the exercise is to show that, for any positive , there exists a complete run of that initialises and to , then multiplies exactly by all the fractions for , and finally checks that equals .
The second part is to show the converse, i.e. that any complete run of is of that form. As a hint, we remark that this is the case because as soon as a multiplication of by a fraction does not complete accurately (because either the first inner loop does not decrease to exactly zero, or the second inner loop does not decrease to exactly zero), it will not be possible to repair that error in the rest of the run, in the sense that the value of at the end of the main loop will necessarily be strictly smaller than and thus it will be impossible to complete the run. We also remark that this vitally depends on the fact that all the fractions are greater than .
4.2 Amplifiers
The definition of in Algorithm II is presented at a high level for readability. In addition to the two macros for subtracting and adding presented in the previous subsection, one further macro is used:
 loop at most times body:

To express this construct, we employ the auxiliary counter to which the value of is transferred and then transferred back. Provided is zero at the start, the body is indeed performed at most times.
looploopbody
Observe that the untested counters of program are , , , , , , and , and the tested ones are and (counter is hidden in the macros).
4.3 Correctness
Before proving that, for any positive integer , the program is a amplifier by , which is the main technical argument in the paper, we provide some intuitions:

the counter is used to preserve the value of at the end of the main loop, since is modified in the final loop;

the counter acts as the auxiliary counter for both and , so there is no need to have as well;

the counter is initialised to the same positive integer as , and , whereas the counter is initialised to ;

at the start of any iteration of the main loop in a complete run, the invariant will hold, and so the first inner loop will divide by accurately;

in order for the last inner loop to transfer fully to and , the middle two inner loops will necessarily multiply by accurately;

at the end of the main loop, , and will have values , and (respectively), and in particular is necessarily divisible by .
Lemma 2.
For any positive integer , the program is a amplifier by , i.e. the relation it computes in counters is
Proof.
We shall be considering runs of whose initial valuation assigns zero to every counter, and which are either halted or blocked at the halt command because is not zero. In particular, any such run will have completed the main loop, which runs for . Hence, we can introduce the following notations for counter values during the iteration of the loop, where is any of the counters , , , , , :
 :
 :
It will also be convenient to write for the value of at the start of the first iteration of the main loop. We emphasise that these notations are relative to the run under consideration, which for readability is not written explicitly.
The proof works for any positive integer and consists of two parts, that establish the two inclusions between the relation computed by in counters and the relation in the statement of the lemma.
The first part, where we assume , and , and argue that has a complete run whose final values of counters are exactly , is the easier part.
Claim 1.
For any divisible by , the program has a complete run which satisfies the equalities in Table 1.
Proof of Claim 1.
Such a run can be built by iterating each inner nondeterministic loop the maximum number of times. Namely, during iteration of the main loop:
The divisibility of by ensures that all divisions in the statement of the claim yield integers.
To see that the run thus obtained can be completed, observe that from the equalities in Table 1 it follows that
In particular, at the start of the final loop (at line 21), counter equals counter and hence has value , and counter has value . Iterating the final loop times therefore reduces (and ) to zero as required. ∎
To obtain as the final values of counters , we apply Claim 1 with .
We now turn to the remaining second part of the proof of the lemma, where we consider any complete run and need to show that the final values of counters satisfy , and .
Claim 2.
For all , we have:

;

if and only if ;

.
Proof of Claim 2.
Straightforward calculation based on . ∎
Let denote the value of counters , , and at the start of the main loop.
Claim 3.
The equalities in Table 1 for the values of counters and are satisfied.
Proof of Claim 3.
First, recall that at the start of the final loop (at line 21) counters and are equal, and by Claim 2 they have value at most . Since counter has value at that point and the run is complete, it must actually be the case that the value of here equals . By Claim 2 again, we infer that for all , we indeed have:
Claim 4.
We have that is divisible by and that the equalities in Table 1 for the values of counters , , and are satisfied.
Proof of Claim 4.
That is divisible by will follow once we establish the equalities for the values of and , since they involve dividing by .
For the rest of the claim, we argue inductively, where the hypothesis is that the equalities for the values of , , and are satisfied for all indices less than . Consequently, recalling Claim 3, we have that
(2) 
Consider the iteration of the main loop. We infer from Claim 3 that the commands in line 10 must have been performed times. Hence, as the values of counters and remain unchanged until line 11, using equation (2) we deduce that the commands in line 8 must have been performed times, and we have:
Also by Claim 3, the commands in line 18 must have been performed times. From what we have just shown, that number equals , and so we conclude that indeed:
As in the first part, we now conclude that the final values of counters are , and in particular . ∎
5 Main Result
As already indicated, the bulk of the work for our headline result, namely Towerhardness of the reachability problem for Petri nets, is showing how to construct an amplifier without tested counters and for a ratio which is a tower of exponentials. Most of the pieces have already been developed in Sections 3 and 4, and here we put them together to obtain a lineartime construction (although any elementary complexity of the reduction would suffice for the Towerhardness).
Lemma 3.
An amplifier by without tested counters is computable in time .
Proof.
Theorem 4.
The Petri nets reachability problem is Towerhard.
Proof.
We reduce in linear time from the Towercomplete halting problem for counter programs of size with all counters tested and bounded by (cf. Section 2).
Corollary 5.
For any positive integer , the Petri nets reachability problem with counters is ExpSpacehard.^{3}^{3}3We remark that, in the terminology of the classical definition of Petri nets [45], the number of places will be due to extra places for encoding the control of counter programs.
Proof.
We reduce in linear time from the ExpSpacecomplete halting problem for counter programs of size with counters, which are all tested and bounded by (cf. [15, Theorems 3.1 and 4.3]).
Lemma 6.
For every , an amplifier by without tested counters is computable in time , such that:

it has untested counters,

counters are required to be zero by the terminal halt command,

out of the counters not appearing in the halt command are zero at termination of every complete run of the amplifier.
According to the last condition, the nine counters are forced to be zero at termination of every complete run, without being tested to be so.
Given a counter program of size with counters, which are all tested and bounded by , the reduction builds the composite program where the amplifier is given by Lemma 6, analogously as in the proof of Theorem 4. In order to keep the number of counters in not greater than , we reuse out of the counters not appearing in the halt command of (and forced to be zero at termination of ) for simulation of the three counters of . ∎
6 Concluding Remarks
We have focussed on presenting clearly the result that the Petri nets reachability problem is not elementary, leaving several arising directions for future consideration. The latter include investigating implications for the reachability problem for fixeddimension flat vector addition systems with states (cf. [35, 3, 12]).
Acknowledgements
We thank Alain Finkel for promoting the study of onedimensional Petri nets with a pushdown stack, and Matthias Englert, Piotr Hofman and Radosław Piórkowski for working with us on open questions about those systems. The latter efforts led us to discovering the nonelementary lower bound presented in this paper.
We are also grateful to Marthe Bonamy, Artur Czumaj, Javier Esparza, Marcin Pilipczuk, Michał Pilipczuk, Sylvain Schmitz and Philippe Schnoebelen for helpful comments.
References
 Angeli et al. [2011] David Angeli, Patrick De Leenheer, and Eduardo D. Sontag. Persistence results for chemical reaction networks with timedependent kinetics and no global conservation laws. SIAM Journal of Applied Mathematics, 71(1):128–146, 2011. URL https://doi.org/10.1137/090779401.
 Baldan et al. [2010] Paolo Baldan, Nicoletta Cocco, Andrea Marin, and Marta Simeoni. Petri nets for modelling metabolic pathways: a survey. Natural Computing, 9(4):955–989, 2010. URL https://doi.org/10.1007/s1104701091806.
 Blondin et al. [2015] Michael Blondin, Alain Finkel, Stefan Göller, Christoph Haase, and Pierre McKenzie. Reachability in twodimensional vector addition systems with states is PSPACEcomplete. In LICS, pages 32–43. IEEE Computer Society, 2015. URL https://doi.org/10.1109/LICS.2015.14.
 Bojańczyk et al. [2009] Mikołaj Bojańczyk, Anca Muscholl, Thomas Schwentick, and Luc Segoufin. Twovariable logic on data trees and XML reasoning. J. ACM, 56(3):13:1–13:48, 2009. URL http://doi.acm.org/10.1145/1516512.1516515.
 Bojańczyk et al. [2011] Mikołaj Bojańczyk, Claire David, Anca Muscholl, Thomas Schwentick, and Luc Segoufin. Twovariable logic on data words. ACM Trans. Comput. Log., 12(4):27:1–27:26, 2011. URL http://doi.acm.org/10.1145/1970398.1970403.
 Bouajjani and Emmi [2013] Ahmed Bouajjani and Michael Emmi. Analysis of recursively parallel programs. ACM Trans. Program. Lang. Syst., 35(3):10:1–10:49, 2013. URL http://doi.acm.org/10.1145/2518188.
 Burns et al. [2000] Frank P. Burns, Albert Koelmans, and Alexandre Yakovlev. WCET analysis of superscalar processors using simulation with coloured Petri nets. RealTime Systems, 18(2/3):275–288, 2000. URL https://doi.org/10.1023/A:1008101416758.
 Colcombet and Manuel [2014] Thomas Colcombet and Amaldev Manuel. Generalized data automata and fixpoint logic. In FSTTCS, volume 29 of LIPIcs, pages 267–278. Schloss Dagstuhl, 2014. URL https://doi.org/10.4230/LIPIcs.FSTTCS.2014.267.
 CrespiReghizzi and Mandrioli [1977] Stefano CrespiReghizzi and Dino Mandrioli. Petri nets and Szilard languages. Information and Control, 33(2):177–192, 1977. URL https://doi.org/10.1016/S00199958(77)905587.
 Decker et al. [2014] Normann Decker, Peter Habermehl, Martin Leucker, and Daniel Thoma. Ordered navigation on multiattributed data words. In CONCUR, volume 8704 of LNCS, pages 497–511. Springer, 2014. URL https://doi.org/10.1007/9783662445846_34.
 Demri et al. [2016] Stéphane Demri, Diego Figueira, and M. Praveen. Reasoning about data repetitions with counter systems. Logical Methods in Computer Science, 12(3), 2016. URL https://doi.org/10.2168/LMCS12(3:1)2016.
 Englert et al. [2016] Matthias Englert, Ranko Lazić, and Patrick Totzke. Reachability in twodimensional unary vector addition systems with states is NLcomplete. In LICS, pages 477–484. ACM, 2016. URL http://doi.acm.org/10.1145/2933575.2933577.
 Esparza [1998] Javier Esparza. Decidability and complexity of Petri net problems — an introduction. In Lectures on Petri Nets I, volume 1491 of LNCS, pages 374–428. Springer, 1998. URL https://doi.org/10.1007/3540653066_20.
 Esparza et al. [2017] Javier Esparza, Pierre Ganty, Jérôme Leroux, and Rupak Majumdar. Verification of population protocols. Acta Inf., 54(2):191–215, 2017. URL https://doi.org/10.1007/s0023601602723.
 Fischer et al. [1968] Patrick C. Fischer, Albert R. Meyer, and Arnold L. Rosenberg. Counter machines and counter languages. Mathematical Systems Theory, 2(3):265–283, 1968. URL https://doi.org/10.1007/BF01694011.
 Ganty and Majumdar [2012] Pierre Ganty and Rupak Majumdar. Algorithmic verification of asynchronous programs. ACM Trans. Program. Lang. Syst., 34(1):6:1–6:48, 2012. URL http://doi.acm.org/10.1145/2160910.2160915.
 German and Sistla [1992] Steven M. German and A. Prasad Sistla. Reasoning about systems with many processes. J. ACM, 39(3):675–735, 1992. URL http://doi.acm.org/10.1145/146637.146681.
 Greibach [1978] Sheila A. Greibach. Remarks on blind and partially blind oneway multicounter machines. Theor. Comput. Sci., 7:311–324, 1978. URL https://doi.org/10.1016/03043975(78)900208.
 Hofman and Lasota [2018] Piotr Hofman and Sławomir Lasota. Linear equations with ordered data. In CONCUR, volume 118 of LIPIcs, pages 24:1–24:17. Schloss Dagstuhl, 2018. URL https://doi.org/10.4230/LIPIcs.CONCUR.2018.24.
 Hopcroft and Pansiot [1979] John E. Hopcroft and JeanJacques Pansiot. On the reachability problem for 5dimensional vector addition systems. Theor. Comput. Sci., 8:135–159, 1979. URL https://doi.org/10.1016/03043975(79)900410.
 Kaiser et al. [2014] Alexander Kaiser, Daniel Kroening, and Thomas Wahl. A widening approach to multithreaded program verification. ACM Trans. Program. Lang. Syst., 36(4):14:1–14:29, 2014. URL http://doi.acm.org/10.1145/2629608.
 Kanovich [1995] Max I. Kanovich. Petri nets, Horn programs, linear logic and vector games. Ann. Pure Appl. Logic, 75(1–2):107–135, 1995. URL https://doi.org/10.1016/01680072(94)00060G.
 Karp and Miller [1969] Richard M. Karp and Raymond E. Miller. Parallel program schemata. J. Comput. Syst. Sci., 3(2):147–195, 1969. URL https://doi.org/10.1016/S00220000(69)800115.
 Kosaraju [1982] S. Rao Kosaraju. Decidability of reachability in vector addition systems (preliminary version). In STOC, pages 267–281. ACM, 1982. URL http://doi.acm.org/10.1145/800070.802201.
 Lambert [1992] JeanLuc Lambert. A structure to decide reachability in Petri nets. Theor. Comput. Sci., 99(1):79–104, 1992. URL https://doi.org/10.1016/03043975(92)90173D.
 Lazić and Schmitz [2015] Ranko Lazić and Sylvain Schmitz. Nonelementary complexities for branching VASS, MELL, and extensions. ACM Trans. Comput. Log., 16(3):20:1–20:30, 2015. URL http://doi.acm.org/10.1145/2733375.
 Lazić and Totzke [2017] Ranko Lazić and Patrick Totzke. What makes Petri nets harder to verify: Stack or data? In Concurrency, Security, and Puzzles — Essays Dedicated to Andrew William Roscoe on the Occasion of His 60th Birthday, volume 10160 of LNCS, pages 144–161. Springer, 2017. URL https://doi.org/10.1007/9783319510460_8.
 Leroux et al. [2015] Hélène Leroux, David Andreu, and Karen GodaryDejean. Handling exceptions in Petri netbased digital architecture: From formalism to implementation on FPGAs. IEEE Trans. Industrial Informatics, 11(4):897–906, 2015. URL https://doi.org/10.1109/TII.2015.2435696.
 Leroux [2010] Jérôme Leroux. The general vector addition system reachability problem by Presburger inductive invariants. Logical Methods in Computer Science, 6(3), 2010. URL https://doi.org/10.2168/LMCS6(3:22)2010.
 Leroux [2011] Jérôme Leroux. Vector addition system reachability problem: a short selfcontained proof. In POPL, pages 307–316. ACM, 2011. URL http://doi.acm.org/10.1145/1926385.1926421.
 Leroux [2012] Jérôme Leroux. Vector addition systems reachability problem (A simpler solution). In Turing100, volume 10 of EPiC Series in Computing, pages 214–228. EasyChair, 2012. URL http://www.easychair.org/publications/paper/106497.
 Leroux and Schmitz [2015] Jérôme Leroux and Sylvain Schmitz. Demystifying reachability in vector addition systems. In LICS, pages 56–67. IEEE Computer Society, 2015. URL https://doi.org/10.1109/LICS.2015.16.
 Leroux and Schmitz [2019] Jérôme Leroux and Sylvain Schmitz. Reachability in vector addition systems is primitiverecursive in fixed dimension. In LICS, 2019. URL https://arxiv.org/abs/1903.08575.
 Leroux and Schnoebelen [2014] Jérôme Leroux and Philippe Schnoebelen. On functions weakly computable by Petri nets and vector addition systems. In RP, volume 8762 of LNCS, pages 190–202. Springer, 2014. URL https://doi.org/10.1007/9783319114392_15.
 Leroux and Sutre [2004] Jérôme Leroux and Grégoire Sutre. On flatness for 2dimensional vector addition systems with states. In CONCUR, volume 3170 of LNCS, pages 402–416. Springer, 2004. URL https://doi.org/10.1007/9783540286448_26.
 Li et al. [2017] Yuliang Li, Alin Deutsch, and Victor Vianu. VERIFAS: A practical verifier for artifact systems. PVLDB, 11(3):283–296, 2017. URL http://www.vldb.org/pvldb/vol11/p283li.pdf.
 Lipton [1976] Richard J. Lipton. The reachability problem requires exponential space. Technical Report 62, Yale University, 1976. URL http://cpsc.yale.edu/sites/default/files/files/tr63.pdf.
 Löb and Wainer [1970] Martin H. Löb and Stanley S. Wainer. Hierarchies of numbertheoretic functions. I. Archiv für mathematische Logik und Grundlagenforschung, 13(1–2):39–51, 1970. URL https://doi.org/10.1007/BF01967649.
 Mayr [1981] Ernst W. Mayr. An algorithm for the general Petri net reachability problem. In STOC, pages 238–246. ACM, 1981. URL http://doi.acm.org/10.1145/800076.802477.
 Mayr [1984] Ernst W. Mayr. An algorithm for the general Petri net reachability problem. SIAM J. Comput., 13(3):441–460, 1984. URL https://doi.org/10.1137/0213029.
 Mayr and Meyer [1981] Ernst W. Mayr and Albert R. Meyer. The complexity of the finite containment problem for Petri nets. J. ACM, 28(3):561–576, 1981. URL http://doi.acm.org/10.1145/322261.322271.
 Meyer [2009] Roland Meyer. A theory of structural stationarity in the picalculus. Acta Inf., 46(2):87–137, 2009. URL https://doi.org/10.1007/s002360090091x.
 Minsky [1967] Marvin L. Minsky. Computation: finite and infinite machines. PrenticeHall, Inc., 1967. URL https://dl.acm.org/citation.cfm?id=1095587.
 Peleg et al. [2005] Mor Peleg, Daniel L. Rubin, and Russ B. Altman. Research paper: Using Petri net tools to study properties and dynamics of biological systems. JAMIA, 12(2):181–199, 2005. URL https://doi.org/10.1197/jamia.M1637.
 Petri [1962] Carl Adam Petri. Kommunikation mit Automaten. PhD thesis, Universität Hamburg, 1962. URL http://edoc.sub.unihamburg.de/informatik/volltexte/2011/160/.
 Rackoff [1978] Charles Rackoff. The covering and boundedness problems for vector addition systems. Theor. Comput. Sci., 6:223–231, 1978. URL https://doi.org/10.1016/03043975(78)900361.
 Sacerdote and Tenney [1977] George S. Sacerdote and Richard L. Tenney. The decidability of the reachability problem for vector addition systems (preliminary version). In STOC, pages 61–76. ACM, 1977. URL http://doi.acm.org/10.1145/800105.803396.
 Schmitz [2016a] Sylvain Schmitz. The complexity of reachability in vector addition systems. SIGLOG News, 3(1):4–21, 2016a. URL http://doi.acm.org/10.1145/2893582.2893585.
 Schmitz [2016b] Sylvain Schmitz. Complexity hierarchies beyond elementary. TOCT, 8(1):3:1–3:36, 2016b. URL http://doi.acm.org/10.1145/2858784.
 van der Aalst [2015] Wil M. P. van der Aalst. Business process management as the “killer app” for Petri nets. Software and System Modeling, 14(2):685–691, 2015. URL https://doi.org/10.1007/s1027001404242.
Appendix A Proof of Lemma 6
.
Proof.
Let be the program obtained from a trivial amplifier by (cf. Example 3):
1:2:3:loop4:5:halt.
and let be the factorrial amplifier from Lemma 2. By Proposition 1 and Lemma 2, we know that the composite program:
is an amplifier by without tested counters. By expanding the composition operations (cf. Section 3) and renaming counters explicitly (the counters of are indexed by , and counters of the th program , for , are indexed by ), we obtain the following form of :
halt if
where is the program fragment of with the halt command removed, and is the program fragment defined in Algorithm III (without the boxed commands, which will be used later to simplify the program) making use of the following macros depending on . We omit the iszero and iszero macros which are defined analogously to ismax (cf. Section 3), and , , and macros which are defined analogously to (cf. Section 4.1).
 setup :
 ismax :
 :

(cf. Section 4.1)
loopiszeroloop
Comments
There are no comments yet.