Incremental Verification of Neural Networks
Complete verification of deep neural networks (DNNs) can exactly determine
whether the DNN satisfies a desired trustworthy property (e.g., robustness,
fairness) on an infinite set of inputs or not. Despite the tremendous progress
to improve the scalability of complete verifiers over the years on individual
DNNs, they are inherently inefficient when a deployed DNN is updated to improve
its inference speed or accuracy. The inefficiency is because the expensive
verifier needs to be run from scratch on the updated DNN. To improve
efficiency, we propose a new, general framework for incremental and complete
DNN verification based on the design of novel theory, data structure, and
algorithms. Our contributions implemented in a tool named IVAN yield an overall
geometric mean speedup of 2.4x for verifying challenging MNIST and CIFAR10
classifiers and a geometric mean speedup of 3.8x for the ACAS-XU classifiers
over the state-of-the-art baselines.
Shubham Ugare, Debangshu Banerjee, Sasa Misailovic, Gagandeep Singh
# Incremental Verification of Neural Networks

###### Abstract.

Complete verification of deep neural networks (DNNs) can exactly determine whether the DNN satisfies a desired trustworthy property (e.g., robustness, fairness) on an infinite set of inputs or not. Despite the tremendous progress to improve the scalability of complete verifiers over the years on individual DNNs, they are inherently inefficient when a deployed DNN is updated to improve its inference speed or accuracy. The inefficiency is because the expensive verifier needs to be run from scratch on the updated DNN. To improve efficiency, we propose a new, general framework for incremental and complete DNN verification based on the design of novel theory, data structure, and algorithms. Our contributions implemented in a tool named IVAN yield an overall geometric mean speedup of 2.4x for verifying challenging MNIST and CIFAR10 classifiers and a geometric mean speedup of 3.8x for the ACAS-XU classifiers over the state-of-the-art baselines.

Keywords:Theoretical Verification, Robustness, Deep Neural Networks +
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal of Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal of Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal of Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal of Information Sciences

+
Footnote †: journal: Journal of Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal of Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Information Sciences

+
Footnote †: journal: Journal: Information Sciences

+
same task. Existing verifiers can be broadly classified as either complete or incomplete. Incomplete methods are more scalable but may fail to prove or disprove a trustworthiness property [11, 12, 13, 14, 15, 16, 17, 18]. A complete verifier always verifies the property if the property holds or otherwise returns a counterexample. Complete verification methods are more desirable as they are guaranteed to provide an exact answer for the verification task [1, 1, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32].

**Limitation of Existing Works:** The deployed DNNs are modified for reasons such as approximation [1, 14], fine-tuning [15], model repair [19], or transfer learning [20]. Various approximations such as quantization, and pruning slightly perturb the DNN weights, and the updated DNN is used for the same task [1, 16, 17]. Similarly, fine-tuning can also be performed to repair the network on buggy inputs while maintaining the accuracy on the original training inputs [10]. Each time a new DNN is created, expensive complete verification needs to be performed to check whether it is trustworthy. A fundamental limitation of all existing approaches for complete verification of DNNs is that the verifier needs to be run from scratch end-to-end every time the network is even slightly modified. As a result, developers still rely on test set accuracy as the main metric for measuring the quality of a trained network. This limitation of existing verifiers restricts their applicability as a tool for evaluating the trustworthiness of DNNs.

**This Work: Incremental and Complete Verification of DNNs:** In this work, we address the fundamental limitation of existing complete verifiers by presenting IVAN, the first general technique for incremental and complete verification of DNNs. An original network and its updated network have similar behaviors on most of the inputs, therefore the proofs of property on these networks are also related. IVAN accelerates the complete verification of a trustworthy property on the updated network by leveraging the proof of the same property on the original network. IVAN can be built on top of any Branch and Bound (BaB) based method. The BaB verifier recursively partitions the verification problem to gain precision. It is currently the dominant technology for constructing complete verifiers [1, 1, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32].

**Challenges:** The main challenge in building an incremental verifier on top of a non-incremental one is to determine which information to pass on and how to effectively reuse this information. Formal methods research has developed numerous techniques for incremental verification of programs, that reuse the proof from previous revisions for verifying the new revision of the program [15, 1, 16, 17, 18, 19]. However, often the program commits are local changes that affect only a small part of the big program. In contrast, most DNN updates result in weight perturbation across one or many layers of the network. This poses a different and more difficult challenge than incremental program verification. Additionally, DNN complete verifiers employ distinct heuristics for branching. A key challenge is to develop a generic method that incrementally verifies a network perturbed across multiple layers and is applicable to multiple complete verification methods, yet can provide significant performance benefits.

**Our Solution:** IVAN computes a specification tree - a novel tree data structure representing the trace of BaB - from the execution of the complete verifier on the original network. We design new algorithms to refine the specification tree to create a more compact tree. At a high level, the refinement involves reordering the branching decisions such that the decisions that worked well in the original verification are prioritized. Besides, it removes the branching decisions that worked poorly in the original verification by pruning nodes and edges in the specification tree. IVAN also improves the branching strategy in BaB for the updated network based on the observed
effectiveness of branching choices when verifying the original DNN. The compact specification tree and the improved branching strategy guide the BaB execution on the updated network to faster verification, compared to non-incremental verification that starts from scratch. IVAN yields up to 43x speedup over the baseline based on state-of-the-art non-incremental verification techniques [14, 15, 16]. It achieves a geometric mean speedup of 2.4x across challenging fully-connected and convolutional networks over the baseline. IVAN is generic and can work with various common BaB branching strategies in the literature (input splitting, ReLU splitting).

**Main Contributions:** The main contributions of this paper are:

* We present a novel, general framework for incremental and complete DNN verification by designing new algorithms and data structure that allows us to succinctly encode influential branching strategies to perform efficient incremental verification of the updated network.
* We identify a class of network modifications that can be efficiently verified by our framework by providing theoretical bounds on the amount of modifications.
* We implement our approach into a tool named IVAN and show its effectiveness over multiple state-of-the-art complete verification techniques, using distinct branching strategies (ReLU splitting and input splitting), in incrementally verifying both local and global properties of fully-connected and convolutional networks with ReLU activations trained on the popular ACAS-XU, MNIST, and CIFAR10 datasets. Our results show that for MNIST and CIFAR10 classifiers, using the ReLU splitting technique [14] IVAN yields a geometric mean speedup of 2.4x over the state-of-the-art baseline [14, 15]. For ACAS-XU, using the input splitting technique IVAN achieves a geometric mean speedup of 3.8x over RefineZono [15].

IVAN implementation is open-source, publicly available at [https://github.com/uiuc-focal-lab/IVAN](https://github.com/uiuc-focal-lab/IVAN). An extended version of this paper containing all the proofs and additional experiments is available at [https://arxiv.org/abs/2304.01874](https://arxiv.org/abs/2304.01874).

Figure 1: Workflow of IVAN from left to right. _IVAN_ takes the original network \(N\), input specification \(\phi\) and output specification \(\psi\). It is built on top of a BaB-based complete verifier that utilizes an analyzer \(A\) for the bounding, and heuristic \(H\) for branching. IVAN refines a specification tree \(T_{f}^{N}\), result of verifying \(N\), to create a compact tree \(T_{0}^{N^{a}}\) and updated branching heuristic \(H_{\Delta}\). IVAN performs faster verification of \(N^{a}\) exploiting both \(T_{0}^{N^{a}}\) and \(H_{\Delta}\).
## 2. Overview

Figure 1 illustrates the high-level idea behind the workings of IVAN. It takes as input the original neural network \(N\), the updated network \(N^{a}\), a local or global input region \(\phi\), and the output property \(\psi\). The goal of IVAN is to check whether for all inputs in \(\phi\), the outputs of networks \(N\) and \(N^{a}\) satisfy \(\psi\). \(N\) and \(N^{a}\) have similar behaviors on the inputs in \(\phi\), therefore the proofs of the property on these networks are also related. IVAN accelerates the complete verification of the property \((\phi,\psi)\) on \(N^{a}\) by leveraging the proof of the same property on \(N\).

**Neural Network Verifier:** Popular verification properties considered in the literature have \(\psi:=C^{T}Y\geq 0\), where \(C\) is a column vector and \(Y=N(X)\), for \(X\in\phi\). Most state-of-the-art complete verifiers use BaB to solve this problem. These techniques use an analyzer that computes the linear approximation of the network output \(Y\) through a convex approximation of the problem domain. This linear approximation of \(Y\) is used to perform the bounding step to show for the lower bound \(LB(C^{T}Y)\) that \(LB(C^{T}Y)\geq 0\). If the bounding step cannot prove the property, the verification problem is partitioned into subproblems using a branching heuristic \(H\). The partitioning splits the problem space allowing a more precise convex approximation of the split subproblems. This leads to gains in the precision of \(LB\) computation. Various choices for the analyzer and the branching strategies exist which represent different trade-offs between precision and speed.

IVAN leverages a specification tree representation and novel algorithms to store and transfer the proof of the property from \(N\) to \(N^{a}\) for accelerating the verification on \(N^{a}\). We show the workings of \(IVAN\) through the following illustrative example.

### Illustrative Example

We consider the two networks \(N\) and \(N^{a}\) with the same architecture as shown in Figure 2. Most practical network updates result in network weight perturbations e.g., quantization, model repair, and fine-tuning. Network \(N^{a}\) is obtained by updating (perturbing the weights) of network \(N\). These networks apply ReLU activation at the end of each affine layer except for the final layer. The weights for the affine layers are shown on the edges. We consider the verification property \((\phi,\psi)\) such that \(\phi=\{(i_{1},i_{2}):i_{1}\in[0,1]\wedge i_{2}\in[0,1]\}\) and \(\psi=(o_{1}+14\geq 0)\). Let \(\mathcal{R}=\{r_{1},r_{2},r_{3},r_{4}\}\) denote the set of ReLUs in the considered architecture. \(\mathcal{R}\) is a function of the architecture of the DNNs and is common for both \(N\) and \(N^{a}\).

**Branch and Bound:** We consider a complete verifier that uses a sound analyzer \(A\) based on the exact encoding of the affine layers and the common triangle linear relaxation (Bunel et al., 2020, 2017; Ehlers, 2017) for over-approximating the non-linear ReLU function. If due to over-approximation of

Figure 2. Example original network \(N\) and its perturbation \(N^{a}\) (blue weights). Each layer consists of a linear function followed by the ReLU activation function. \(\phi\) is the input specification and \(\psi\) is the output specification.
the ReLU function, the analyzer cannot prove or disprove the property, the verifier partitions the problem by splitting the problem domain. The analyzer is more precise if it separately analyzes the split subproblems and merges the results. There are two main strategies for branching considered in the literature, input splitting (Anderson et al., 2020; Wang et al., 2018), and ReLU splitting (Bunel et al., 2020, 2020, 2017; Ferrari et al., 2022; Palma et al., 2021). We show IVAN's effectiveness on both branching strategies in our evaluation (Section 6.1, Section 6.4). However, for this discussion, we focus on ReLU splitting which is scalable for the verification of high-dimensional inputs.

**ReLU splitting:** An unsolved problem is partitioned into two cases, where the cases assume the input \(\hat{x}_{i}\) to ReLU unit \(r_{i}\) satisfies the predicates \(\hat{x}_{i}\geq 0\) and \(\hat{x}_{i}<0\) respectively. Splitting a ReLU \(r_{i}\) eliminates the analyzer imprecision in the approximation of \(r_{i}\). When we split all the ReLUs in \(\mathcal{R}\), the analyzer is exact. Nevertheless, splitting all \(\mathcal{R}\) is expensive as it requires \(2^{|\mathcal{R}|}\) analyzer bounding calls. The state-of-the-art techniques use the heuristic function \(H\) to find the best ReLU to split at each step, leading to considerably scalable complete verification.

The branching function \(H\) scores the ReLUs \(\mathcal{R}\) for branching at each unsolved problem to partition the problem. If \(\mathcal{R}^{\prime}\subseteq\mathcal{R}\) denotes the subset of ReLUs that are not split in the current subproblem, then the verifier computes \(r=\arg\max_{\mathcal{R}^{\prime}}H\) to choose the \(r\) for the current split. \(H\) is a function of the exact subproblem that it branches and hence depends on \(\phi\), \(\psi\), the network, and the branching assumptions made for the subproblem. However, for the purpose of this running example, we consider a simple constant branching heuristic \(H\) that ranks \(H(r_{1})>H(r_{3})>H(r_{4})>H(r_{2})\) independent of the subproblem and the network. This assumption is only for the illustration of our idea, we show in the evaluation (Section 6) that IVAN can work with state-of-the-art branching heuristics (Bunel et al., 2020, 2021).

### IVAN Algorithm

**Specification Tree:** IVAN uses a rooted binary tree data structure to store the trace of splitting decisions during BaB execution. A specification split is a finer specification parameterized by the subset of ReLUs in \(\mathcal{R}\). The root node is associated with the specification \((\phi,\psi)\). All other nodes represent the specification splits obtained by splitting the problem domain recursively. Each internal node in the tree has two children, the result of the branching of the associated specification.

The split decision can be represented as a predicate. For a ReLU \(r_{i}\) with input \(\hat{x}_{i}\), let \(r_{i}^{+}\coloneqq(\hat{x}_{i}\geq 0)\) and \(r_{i}^{-}\coloneqq(\hat{x}_{i}<0)\) denote the split decisions. A split of ReLU \(r_{i}\) at node \(n\) creates two children nodes \(n_{l}\) and \(n_{r}\), each encoding the new specification splits. Each edge in the specification tree represents the split decision made at the branching step. An edge connects an internal node with its child node, and we label it with the additional predicate that is assumed by the child subproblem. A split of ReLU \(r\) at node \(n\) adds nodes \(n_{l}\) and \(n_{r}\) that are connected with edges labeled with predicates \(r_{i}^{+}\) and \(r_{i}^{-}\) respectively. If \(\varphi_{n}=(\phi^{\prime},\psi)\) is the specification split at \(n\), then \(\varphi_{n_{l}}=(\phi^{\prime}\wedge r^{+},\psi)\) and \(\varphi_{n_{r}}=(\varphi^{\prime}\wedge r^{-},\psi)\). The names of the nodes have no relation to the networks or the property, they are used for referencing a particular specification. However, the edges of the tree are tied to the network architecture through the labels. Although the specification tree is created as a trace of verification of a particular network \(N\), it is only a function of the ReLU units in the architecture of \(N\). This allows us to use the branching decisions in the specification tree for guiding the verification of any updated network \(N^{a}\) that has the same architecture as \(N\). We use \(LB_{N}(n)\) to denote the lower bound \(LB(C^{T}Y)\) obtained by the analyzer \(A\) on for the subproblem encoded by \(n\), on the network \(N\).

Figure 3 demonstrates the steps of BaB execution on \(N\). Each node represents the specification refined by BaB. We use function \(LB_{N}(n)\) to denote the \(LB(C^{T}Y)=LB(o_{1}+14)\) value obtained by the analyzer \(A\) at node \(n\). The specification is verified for the subproblem of \(n\) if the \(LB_{N}(n)\geq 0\). If \(LB_{N}(n)<0\), the analyzer returns a counterexample (CE). The CE is a point in the convex
approximation of the problem domain and it may be possible that it is spurious, and does not belong to the concrete problem domain. If the CE is not spurious, the specification is disproved and the proof halts. But, if the CE is spurious then the problem is unsolved, and it is further partitioned.

In the first step, for the specification \((\phi,\psi)\) encoded by the root node \(n_{0}\), the analyzer computes \(LB_{N}(n_{0})=-7\), which is insufficient to prove the specification. Further, the CE provided by the analyzer is spurious, and thus the analyzer cannot solve the problem. The root node \(n_{0}\) specification \((\phi,\psi)\) is split by ReLU split of \(r_{1}\) chosen by the heuristic function \(H\). Accordingly, in the specification tree, the node \(n_{0}\) is split into two nodes \(n_{1}\) and \(n_{2}\), with the specification splits \((\phi\wedge r_{1}^{+},\psi)\) and \((\phi\wedge r_{1}^{-},\psi)\) respectively. This procedure of recursively splitting the problem and correspondingly updating the specification tree continues until either all the specifications of the leaf nodes are verified, or a CE is found. In the final specification tree (\(T_{3}^{N}\) in this case), the leaf nodes are associated with the specifications that the analyzer could solve, and the internal nodes represent the specifications that the analyzer could not solve for network \(N\). For BaB starting from scratch, each node in the specification tree maps to a specification that invoked an analyzer call in BaB execution. Figure 3 presents that the verifier successfully proves the property with a specification tree containing 9 nodes. Thus, the verification invokes the analyzer 9 times and performs 4 nodes branchings for computing \(LB\).

Figure (a)a presents the specification tree for \(N^{a}\) at end of the verifying the property \((\phi,\psi)\). Although the \(LB(C^{T}Y)\) computed by the analyzer for each node specifications is different for \(N^{a}\) compared to \(N\), the final specification tree is identical for both networks. Our techniques in IVAN are motivated by our observation that the final specification tree for network \(N\) and its updated version \(N^{a}\) have structural similarities. Moreover, we find that for a DNN update that perturbs the network weight within a fixed bound, these trees are identical. We claim that there are two reasons for this: (i) the specifications that are solved by the analyzer for \(N\) are solved by the analyzer for \(N^{a}\) (specifications of the leaf nodes of the specification tree) and (ii) the specifications that are unsolved by the analyzer for \(N\) are unsolved for \(N^{a}\) (specifications of the internal nodes of the specification tree). In Section 4.4, we provide theoretical bounds on the network perturbations such that these

Figure 3: Steps in Branch and Bound algorithm for complete verification of \(N\). The nodes are labeled with a name and the \(LB_{N}(n)\). The nodes in the specification tree are annotated with their specifications. The edges are labeled with the branching predicates. Each step in BaB partitions unsolved specifications in \(T_{i}^{N}\) into specification splits in \(T_{i+1}^{N}\). The proof is complete when all specification splits corresponding to the leaf nodes are solved.
claims hold true (Theorem 4). Nevertheless, for networks obtained by perturbation beyond the theoretical bounds, the specification trees are still similar if not identical. In our evaluation, we observe this similarity for large networks with practical updates e.g., quantization (Section 6).

**Reuse:** We first introduce our concept of specification tree reuse which uses \(T_{f}^{N}\), the final tree after verifying \(N\), as the starting tree \(T_{0}^{N^{a}}\) for the verification of \(N^{a}\). In contrast, the standard BaB verification starts with a single node tree that represents the unpartitioned initial specification \((\phi,\psi)\). In the reuse technique, IVAN starts BaB verification of \(N^{a}\) from the leaves of \(T_{0}^{N^{a}}=T_{f}^{N}\). For our running example, analyzer \(A\) successfully verifies \(N^{a}\) specifications for all the leaf nodes of the specification tree \(T_{0}^{N^{a}}\) (Figure 3(b)). We show that for any specification tree (created on the same network architecture), verifying the subproblem property on all the leaves of the specification tree is equivalent to verifying the main property \((\phi,\psi)\) (Lemma 1). Verifying the property on \(N^{a}\) from scratch requires 9 analyzer calls and 4 node branchings. However, with the reuse technique, we could prove the property with 5 analyzer calls corresponding to the leaves of \(T_{0}^{N^{a}}\) and without any node branching. Theorem 4 guarantees that the specification of the leaf nodes should be verified on \(N^{a}\) by the analyzer if the network perturbations are lower than a fixed bound. Although for larger perturbations, we may have to split leaves of \(T_{0}^{N^{a}}\) further for complete verification, we empirically observe that the reuse technique is still effective to gain speedup on most practical network perturbations.

**Reorder:** A split is more effective if it leads to fewer further subproblems that the verifier has to solve to prove the property. Finding the optimal split is expensive. Hence, the heuristic \(H\) is used to estimate the effectiveness of a split, and to choose the split with the highest estimated effectiveness. Often the estimates are imprecise and lead to ineffective splits. We use \(LB_{N}(n)\) to give an approximation to quantifying the effectiveness of a split. We discuss this exact formulation of the observed effectiveness scores \(H_{obs}\) in Section 4.3. Our second concept in IVAN is based on our

Figure 4: BaB specification tree for various techniques proposed for incremental verification.
insight that if a particular branching decision is effective for verifying \(N\) then it should be effective for verifying \(N^{a}\). Likewise, if a particular branching decision is ineffective in the verification of \(N\), it should be ineffective in verifying \(N^{a}\). Based on this insight, we use the observed effectiveness score of splits in verifying \(N\) to modify the original branching heuristic \(H\) to an improved heuristic \(H_{\Delta}\). \(H_{\Delta}\) takes the weighted sum of original branching heuristic \(H\) and observed effectiveness scores on \(N\) denoted by \(H_{obs}\). We formulate the effectiveness of a split and \(H_{\Delta}\) in Section 4.3. For simplicity, in the running example, we rerank the ReLUs based on the observed effectiveness of the splits as \(H_{\Delta}(r_{4})>H_{\Delta}(r_{3})>H_{\Delta}(r_{2})>H_{\Delta}(r_{1})\). Figure 4c presents the specification tree for verifying \(N^{a}\) with the updated branching heuristic \(H_{\Delta}\) that requires 5 analyzer calls and 2 node branchings. Reorder technique starts from scratch with a different branching order \(H_{\Delta}\) and it is incomparable in theory to the reuse technique. In Section 6.2, we observe that reorder works better in most experiments.

**Bringing All Together:** Our main algorithm combines our novel concepts of specification tree reuse and reorder yielding larger speedups than possible with only reuse or reorder. Specification tree reuse and reorder are not completely orthogonal and thus combining them is not straightforward. Since in reuse we start verifying \(N^{a}\) with the final specification tree \(T_{f}^{N}\), the splits are already performed with the original order \((r_{1},r_{4},r_{3},r_{2}\) in our example). Our augmented heuristic function \(H_{\Delta}\) will have a limited effect if we reuse \(T_{0}^{N^{a}}=T_{f}^{N}\), since the existing tree branches may already be sufficient to prove the property.

**Constructing a Pruned Specification Tree:** It is difficult to predict the structure of the tree with augmented order. For instance, in our example, \(N\) is verified with \(r_{1},r_{4},r_{3},r_{2}\) order and we have \(T_{f}^{N}\) branched in that order. However, we cannot predict the final structure of the specification tree if branched with our augmented order \(r_{4},r_{3},r_{2},r_{1}\) without actually performing those splits from scratch (as it was done in Figure 4c).

We solve this problem with our novel pruning operation that removes ineffective splits from \(T_{f}^{N}\) and constructs a new compact tree \(T_{P}\). Figure 5 shows the construction of pruned tree \(T_{P}\) for our running example. We remove the split \(r_{1}\) at \(n_{0}\) as it is less effective. Removing \(r_{1}\) from \(T_{3}^{N}\) also eliminates the nodes \(n_{1}\) and \(n_{2}\). The subtrees rooted at \(n_{1}\) and \(n_{2}\) are the result of split \(r_{1}\). If we undo the split \(r_{1}\) at node \(n_{0}\), then \(n_{0}\) should follow the branching decisions taken by one of its children. For this, we can choose either the subtree of \(n_{0}\) or \(n_{1}\), and attach it to \(n_{0}\). We describe the exact method of choosing which subtree to keep in Section 4.3. For this example, our approach chooses to keep the subtree of node \(n_{2}\) and eliminates the subtree at node \(n_{1}\). The pruning procedure leads to the discarding of entire subtrees creating a tree with fewer leaf nodes (leaf nodes \(n_{3}\), \(n_{4}\) are deleted in the example along with internal nodes \(n_{1}\), \(n_{2}\)). Consequently, we obtain a more compact tree with only influential splits in the specification tree.

We start the verification of \(N^{a}\) from the leaf nodes of the pruned tree i.e. \(T_{0}^{N^{a}}=T_{P}\). For our running example specification splits of all leaf nodes of \(T_{P}\) are verified by the analyzer and no further splitting is needed. Figure 4d presents the final specification tree in case we initialize the

Figure 5. IVAN removes the ineffective split \(r_{1}\) at \(n_{0}\) and construct a new specification tree \(T_{P}\).
proof with the compact tree obtained from the IVAN algorithm. We show the time complexity of incremental verification in Section 4.2. For the running example, the incremental proof requires only 3 analyzer calls and no branching calls, and it is a significant reduction to the 9 analyzer calls and 5 node branchings performed by the baseline starting from scratch.

## 3. Preliminaries

In this section, we provide the necessary background on complete neural network verification.

### Neural Network Verification

**Neural Networks** Neural networks are functions \(N:\mathbb{R}^{n_{0}}\rightarrow\mathbb{R}^{n_{I}}\). In this work, we focus on layered neural networks obtained by a sequential composition of \(l\) layers \(N_{1}:\mathbb{R}^{n_{0}}\rightarrow\mathbb{R}^{N_{1}},\ldots,N_{l}:\mathbb{R }^{n_{l-1}}\rightarrow\mathbb{R}^{n_{l}}\). Each layer \(N_{i}\) applies an _affine function_ (convolution or linear function) followed by a non-linear activation function to its input. The choices for non-linear activation functions are ReLU, sigmoid, or tanh. \(ReLU(x)=max(0,x)\) is most commonly used activation function. In Section 4, we focus on the most common BaB verifiers that partition the problems using ReLU splitting in ReLU networks. The \(i\)-th layer of each network \(N_{i}:\mathbb{R}^{n_{i}}\longrightarrow\mathbb{R}^{n_{i+1}}\) is defined as \(N_{i}(x)=ReLU(A_{i}X+B_{i})\) where \(i\in[l]\).

At a high level, neural network verification involves proving that all network outputs corresponding to a chosen set of inputs satisfying the input specification \(\phi\) satisfy a given logical property \(\psi\). We first define the input and output specifications that we consider in this work:

Definition 1 (Input specification).: _For a neural network \(N:\mathbb{R}^{n_{0}}\rightarrow\mathbb{R}^{n_{I}}\), \(\phi_{t}\) is a connected region and \(\phi_{t}\subseteq\mathbb{R}^{n_{0}}\). **Input specification \(\phi:\mathbb{R}^{n_{0}}\rightarrow\{true,false\}\)** is a predicate over the input region \(\phi_{t}\)._

Definition 2 (output specification).: _For a neural network with \(n_{l}\) neurons in the output layer. **output specification \(\psi:\mathbb{R}^{n_{l}}\rightarrow\{true,false\}\)** is a predicate over the output region._

The output property \(\psi\) could be any logical statement taking a truth value true or false. In our paper, we focus on properties that can be expressed as Boolean expressions over linear forms. Most DNN verification works consider such properties.

\[\psi(Y)=(C^{T}Y\geq 0) \tag{1}\]

We next define the verification problem solved by the verifiers:

Definition 3 (Verification Problem).: _The **neural network verification** problem for a neural network \(N\), an input specification \(\phi\) and a logical property \(\psi\) is to prove whether \(\forall X\in\phi_{t}\). \(\psi(N(X))=true\) or provide a counterexample otherwise._

A complete verifier always verifies the property if it holds or returns a counterexample otherwise. Formally, it can be defined as:

Definition 4 (Complete Verifier).: _A **complete verifier \(V\)** for an input specification \(\phi\), a neural network \(N\), an output property \(\psi\) satisfies the following property:_

\[V(\phi,\psi,N)=\text{Verified}\Longleftrightarrow\forall X\in\phi_{t}.\psi(N (X))=true\]

### Branch and Bound for Verification

In this Section, we discuss the branch and bound techniques for complete verification of DNNs. The BaB approach in these techniques use a divide-and-conquer algorithm to compute the \(LB(C^{T}Y)\) for proving \((C^{T}Y\geq 0)\) (Eq. 1). We next discuss the bounding and branching steps in BaB techniques.
**Bounding:** The bounding step uses an analyzer to find a lower bound \(LB(C^{T}Y)\). In complete verifiers, the analyzers are exact for linear functions (e.g., DeepZ [Singh et al.2018], DeepPoly [Singh et al.2019b]). However, they over-approximate the non-linear activation function through a convex over-approximation. We define these sound analyzers as:

**Definition 5** (Sound Analyzer): _A **sound analyzer**\(A\) on an input specification \(\phi\), a DNN \(N\), an output property \(\psi\) returns Verified, Unknown, or Counterexample. It satisfies the following properties:_

\[A(\phi,\psi,N) =\text{Verified}\implies\forall X\in\phi_{t}.\psi(N(X))=\text{ true}\] \[A(\phi,\psi,N) =\text{Counterexample}\implies\exists X\in\phi_{t}.\psi(N(X))= \text{false}\]

**Branching:** If the analyzer cannot prove a property, the BaB verifier partitions the problem into easier subproblems to improve analyzer precision. Algorithm 1 presents the pseudocode for the BaB verification. The algorithm maintains a \(Unsolved\) list of problems that are currently not proved or disproved. It initializes the list with the main verification problem. Line 5 performs the bounding step in the BaB algorithm using the analyzer \(A\). For simplicity, we abuse the notation and use \(A(prob,N)\) for denoting the analyzer output instead of \(A(\phi,\psi,N)\). Here, the \(prob\) encapsulates the input and output specifications \(\phi,\psi\). Line 13 partitions the unsolved problem into subproblems. The algorithm halts when either the \(A\) finds a counterexample on one of the subproblems or the list of unsolved problems is empty. There are two common branching strategies for BaB verification, input splitting and ReLU splitting, which we describe next.

```
1:functionBaB(\(N,problem\))
2:\(Unsolved\leftarrow[(problem)]\)
3:while\(Unsolved\) is not empty do
4:for\(prob\inUnsolved\)do
5:\(status[prob]=A(prob,N)\)\(\triangleright\) Bounding step
6:for\(prob\inUnsolved\)do
7:if\(status[prob]=\) Verifiedthen
8:\(Unsolved.remove(prob)\)\(\triangleright\) Remove verified subproblems
9:if\(status[prob]=\) Counterexamplethen
10:return Counterexample for\(prob\)\(\triangleright\) Return if a counterexample is found
11:if\(status[prob]=\) Unknownthen
12:\(Unsolved.remove(prob)\)
13:\([\text{suppb}_{1},\text{suppb}_{2}]\leftarrow\) split(prob)\(\triangleright\) Branching step
14:\(Unsolved.insert(\text{suppb}_{1},\text{suppb}_{2})\)
15:return Verified
```

**Algorithm 1** Branch and Bound

**Input Splitting:** In input splitting, the input region \(\phi_{t}\) for verification is partitioned. The typical choice is to cut a selected input dimension in half while the rest of the dimensions are unchanged. The dimension to cut is decided by the branching strategy used. This technique is known to be \(\delta\)-complete for any activation function [Anderson et al.2019], but does not scale for high-dimensional input space. In many computer vision tasks, the input is an image with 1000s of pixels. Thus, a high-dimensional perturbation region on such input cannot be branched efficiently for fast verification.

**ReLU Splitting:** State-of-the-art techniques that focus on verifying DNNs with high-dimensional input and ReLU activation, use ReLU splitting. We denote a ReLU unit for \(i\)-th layer and \(j\)-th index as a function \(x_{i,j}=\max(\hat{x}_{i,j},0)\), where \(\hat{x}_{i,j}\) and \(x_{i,j}\) are the pre-activation and post-activation values respectively. The analyzer computes lower bounds \(lb\) and upper bounds \(ub\) for each intermediate
variable in the DNN. If \(lb(\hat{x}_{i,j})\geq 0\), then the ReLU unit simply acts as the identify function \(x_{i,j}=\hat{x}_{i,j}\). If \(ub(\hat{x}_{i,j})\leq 0\), then the ReLU unit operates as a constant function \(x_{i,j}=0\). In both of these cases, the ReLU unit is a linear function. However, if \(lb(\hat{x}_{i,j})<0<ub(\hat{x}_{i,j})\), we cannot linearize the ReLU function exactly. We call such ReLU units ambiguous ReLUs. In ReLU splitting, the unsolved problem is partitioned into two subproblems such that one subproblem assumes \(\hat{x}_{i,j}<0\) and the other assumes \(\hat{x}_{i,j}\geq 0\). This partition allows us to linearize the ReLU unit in both subproblems leading to a boost in the overall precision of the analyzer. The heuristic used for selecting which ReLU to split significantly impacts the verifier speed.

**BaB for Other Activation Functions:** BaB-based verification can work with the most commonly used activation functions (\(\tanh\), sigmoid, leaky ReLU).

1. For piecewise linear activation functions such as leaky ReLU, activation splitting approaches (e.g, ReLU splitting) can be used for complete verification.
2. For other activation functions (\(\tanh\), sigmoid), BaB with activation splitting cannot yield complete verification but can be used to improve the precision of sound and incomplete verification (Dutta et al., 2017; Muller et al., 2021).
3. Although input splitting is less efficient in the aforementioned cases for high dimensional DNN inputs, it can be applied with any activation function (\(\tanh\), sigmoid, ReLU, leaky ReLU).

## 4. Incremental Verification

In this section, we describe our main technical contributions and the IVAN algorithm. We first formally define the specification tree structure used for incremental verification (Section 4.1). Next, we formulate the problem of incremental verification (Section 4.2). In Section 4.3, we illustrate the techniques used in our algorithm. We characterize the effectiveness of our technique by computing a class of networks for which our incremental verification is efficiently applicable in Section 4.4.

### Specification Tree for BaB

IVAN uses the specification tree to store the trace of splitting decisions that the BaB verifier makes on its execution. A specification tree can be used for any BaB branching method (e.g, input splitting), but without loss of generality, our discussion focuses on ReLU splitting. Let \(\mathcal{N}\) denote the class of networks with the same architecture, and let \(\mathcal{R}\) denote the set of ReLUs in this architecture. The specification tree captures the ReLU splitting decisions and the split specifications in the execution of BaB for a property \((\phi,\psi)\), where we define \((\phi,\psi)\coloneqq\phi\rightarrow\psi\).

For a ReLU \(r_{i}\) with input \(\hat{x}_{i}\), let \(r^{+}_{i}\coloneqq(\hat{x}_{i}\geq 0)\) and \(r^{-}_{i}\coloneqq(\hat{x}_{i}<0)\). We define a split decision as:

Definition 6 (Split Decision).: _For a ReLU \(r\in\mathcal{R}\), a split decision is \(r^{?}\in\{r^{+},r^{-}\}\) where \(r^{?}\) is assigned the predicate \(r^{+}\) or \(r^{-}\)._

A specification split of \((\phi,\psi)\) is a specification stronger than \((\phi,\psi)\) parameterized by the subset of ReLUs in \(\mathcal{R}\) and the corresponding split decisions. Formally,

Definition 7 (Specification Split).: _For a set of ReLUs \(\mathcal{R}^{\prime}=\{r_{1},r_{2}\ldots r_{k}\}\subseteq\mathcal{R}\), and ReLU split decision \(r^{?}_{i}\in\{r^{-}_{i},r^{+}_{i}\}\) for each \(r_{i}\), the corresponding specification split of \((\phi,\psi)\) is \((\phi\wedge r^{?}_{1}\wedge r^{?}_{2}\wedge\ldots r^{?}_{k},\psi)\)._

Since \(\emptyset\subseteq\mathcal{R}\), \((\phi,\psi)\) is a split specification of itself. Let \(\mathcal{S}\) denote the set of specification splits that can be obtained from \((\phi,\psi)\). Each node \(n\) in the tree encodes a specification split in \(\mathcal{S}\). Each edge in the specification tree is labeled with a ReLU split decision \(r^{?}\). Let \(\textit{Nodes}(T)\) denote the nodes of the tree \(T\) and \(\textit{Leaves}(T)\) denote the leaves of the tree \(T\).

**Mapping Nodes to Specification Splits:** The specification associated with the root node is \((\phi,\psi)\). The function \(\textit{Children}(n)\) maps a node \(n\) to either the pair of its children or \(\emptyset\) if \(n\) has no children. If \(n_{l}\) and \(n_{r}\) are the children of node \(n\) and \(\varphi_{n}=(\phi^{\prime},\psi)\) is the specification split at \(n\), then \(\varphi_{n_{l}}=(\phi^{\prime}\wedge r^{+},\psi)\)
and \(\varphi_{n_{r}}=(\varphi^{\prime}\wedge r^{-},\psi)\). For the specifications \(\varphi_{n},\varphi_{n_{I}},\varphi_{n_{r}}\) the following statement holds:

\[(\varphi_{n_{I}}\wedge\varphi_{n_{r}})\Longleftrightarrow\varphi_{n} \tag{2}\]

This relationship implies that verifying the parent node specification is equivalent to verifying the two children node's specifications. Formally, we can now define the specification tree as:

Definition 8 (specification tree).: _Given a set of ReLU \(\mathcal{R}\), a rooted full binary tree \(T\) is a **specification tree**, if for a node \(n\in\mathit{Nodes}(T)\), and nodes \(n_{I},n_{r}\in\mathit{Children}(n)\), edge \((n,n_{I})\) is labeled with predicate \(r^{+}\) and edge \((n,n_{r})\) is labeled with predicate \(r^{-}\), for \(r\in\mathcal{R}\)._

```
1:functionSplit(\(T,n,r\))
2:Input: Specification tree \(T\), a leaf node \(n\in\mathit{Leaves}(T)\), a ReLU \(r\in\mathcal{R}\) for splitting the node
3:Output: returns newly added nodes
4:\(n_{I}\leftarrow\mathit{Add\_Child}(n,r^{+})\)
5:\(n_{r}\leftarrow\mathit{Add\_Child}(n,r^{-})\)
6:return\(n_{I},n_{r}\)
```

**Algorithm 2**_Split_ operation

BaB uses a branching function \(H\) for choosing the ReLU to split. We define this branching function in terms of the node \(n\) of the specification tree as:

Definition 9 (Branching Heuristic).: _Given a set of ReLU \(\mathcal{R}\), a network \(N\), and a node \(n\) in the specification tree, if \(\mathcal{P}\subseteq\mathcal{R}\) denote the set of ReLUs split in the path from the root node \(n\)._

We next state the split operation on a specification tree. Algorithm 2 presents the steps in the split operation.

\(\bullet\)_Split Operation_: Every ReLU split adds two nodes to the specification tree at a given leaf node \(n\). The BaB algorithm chooses the ReLU \(\arg\max_{r\in\mathcal{R}/\mathcal{P}}H(N,n,r)\) to split at node \(n\) using the heuristic function.

### Incremental Verification: Problem Formulation

Give a set of networks \(\mathcal{N}\) with the same architecture with a set of ReLUs \(\mathcal{R}\), \(\mathcal{T}_{\mathcal{N}}\) be the set of all specification trees defined over \(\mathcal{R}\). There exists a partial order (\(<\)) on \(\mathcal{T}_{\mathcal{N}}\) through standard subgraph relation. BaB execution on a network \(N\in\mathcal{N}\) traces a sequence of trees \(T_{0},T_{1}\ldots T_{f}\in\mathcal{T}_{N}\) such that \(T_{i}<T_{i+1}\). It halts with the final tree \(T_{f}\) when it either verifies the property or finds a counterexample. The construction of \(T_{i+1}\) from \(T_{i}\) depends on the branching function \(H\) (Definition 9).

**Incremental Verification:** The incremental verification problem is to efficiently reuse the information from the execution of verification of network \(N\) for the faster verification of its updated version \(N^{a}\). Standard BaB for verification of \(N^{a}\) starts with a single node tree while the incremental verifier starts with a tree \(T_{0}^{N^{a}}\in\mathcal{T}_{\mathcal{N}}\) that is not restricted to be a tree with a single node. We modify the final specification tree \(T_{f}^{N}\) from the verification of \(N\) to construct \(T_{0}^{N^{a}}\). The branching heuristic \(H_{\Delta}\) for incremental verification is derived from the branching heuristic \(H\) based on the efficacy of various branching decisions made during the proof for \(N\). Formally, the complete incremental verifier we propose is defined as:

Definition 10 (Complete and Incremental Verifier).: _A **Complete and Incremental Verifier**\(V_{\Delta}\) takes a neural network \(N^{a}\), an input specification \(\phi\), an output property \(\psi\), analyzer \(A\), the branching heuristic \(H_{\Delta}\) and the initial tree \(T_{0}^{N^{a}}\). \(V_{\Delta}(N^{a},\phi,\psi,T_{0}^{N^{a}},H_{\Delta})\) returns Verified if\(N^{a}\) satisfies the property \((\phi,\psi)\), otherwise, it returns a Counterexample._

Algorithm 3 presents the incremental verifier algorithm for verifying the perturbed network. It takes \(H_{\Delta}\) and \(T_{0}^{N^{a}}\) as input. It maintains a list of active nodes which are the nodes corresponding to the specifications that are yet to be checked by the analyzer. It initializes the list of active nodes with leaves of tree \(T_{0}^{N^{a}}\) (line \(2\)). The main loop runs until the active list is empty (line \(3\)) or it
discovers a counterexample (line 9). At each iteration, it runs the analyzer on each node in the active list (line 5). The nodes that are _Verified_ are removed from the list (line 8), whereas the nodes that result in _Unknown_ are split. The new children are added to the active list (line 12).

**Optimal Incremental Verification:** We define the partial function \(\mathit{Time}_{\Delta}:\mathcal{T}_{\mathcal{N}}\times\mathcal{T}_{\mathcal{N}} \rightarrow\mathbb{R}\), \(\mathit{Time}_{\Delta}(T_{0}^{Na},T_{f}^{Na})\) for a fixed complete incremental verifier \(V_{\Delta}\) as the time taken by \(V_{\Delta}\) that starts from \(T_{0}^{Na}\) and halts with the final tree \(T_{f}^{Na}\). \(\mathit{Time}_{h}(H,H_{\Delta})\) and \(\mathit{Time}_{t}(T_{f}^{N},T_{0}^{Na})\) are the time for constructing \(H_{\Delta}\) from H, and \(T_{0}^{N^{a}}\) from \(T_{f}^{N}\) respectively. We pose the optimal incremental verification problem as an optimization problem of finding the best \(H_{\Delta},T_{0}^{Na}\) such that the time of incremental verification is minimized. Formally, we state the problem as:

\[\operatorname*{arg\,min}_{H_{\Delta},T_{0}^{Na}}\left[\mathit{Time}_{\Delta}( T_{0}^{Na},T_{f}^{Na})+\mathit{Time}_{h}(H,H_{\Delta})+\mathit{Time}_{t}(T_{f}^{N},T _{0}^{Na})\right] \tag{3}\]

The search space for \(T_{0}^{Na}\) is exponential in terms of \(\mathcal{R}\), and the search space for \(H_{\Delta}\) is infinite. Further, \(\mathit{Time}_{\Delta}\) is a complicated function of \(H_{\Delta},T_{0}^{Na}\) that does not have a closed-form formulation. As a result, it is not possible to find an optimal solution.

**Simplifying Assumptions:** To make the problem tractable we make a simplifying assumption that for all networks with the same architecture, each branching and bounding step on each invocation takes a constant time \(t_{H}\) and \(t_{A}\) respectively. We can now compute \(\mathit{Time}_{\Delta}(T_{0}^{Na},T_{f}^{Na})\) as:

Theorem 4.1: _(\(\mathit{Time}_{\Delta}\) for incremental verification). If the increenant verifier \(V_{\Delta}\) halts with the final tree \(T_{f}^{Na}\), then \(\mathit{Time}_{\Delta}(T_{0}^{Na},T_{f}^{Na})=(t_{A}+t_{H})\cdot\left(|Nodes(T _{f}^{Na})|+\frac{1-|Nodes(T_{0}^{Na})|}{2}\right)-t_{H}\cdot|Leaves(T_{f}^{Na} )|\)._

The proof of the theorem is in Appendix 9.2.
In this work, we focus on a class of algorithms for which the preprocessing times \(Time_{h}(H,H_{\Delta})\) and \(Time_{t}(T_{f}^{N},T_{0}^{N^{a}})\) are \(<<Time_{\Delta}(T_{0}^{N^{a}},T_{f}^{N^{a}})\). Furthermore, we also focus on branching heuristics used in practice where \(t_{H}<<t_{A}\). Equation 3 simplifies to finding \(H_{\Delta}\) and \(T_{0}^{N^{a}}\) such that the following expression \(Time_{\Delta}(T_{0}^{N^{a}},T_{f}^{N^{a}})=t_{A}\cdot\left(|Nodes(T_{f}^{N^{a}} )|+\frac{1-|Nodes(T_{0}^{N^{a}})|}{2}\right)\) is minimized. Rewriting and ignoring the constant term we get

\[Time_{\Delta}(T_{0}^{N^{a}},T_{f}^{N^{a}})=t_{A}\cdot\left(\frac{|Nodes(T_{f}^{N ^{a}})|-|Nodes(T_{0}^{N^{a}})|}{2}+\frac{|Nodes(T_{f}^{N^{a}})|}{2}\right) \tag{4}\]

### IVAN Algorithm for Incremental Verification

We describe the novel components of our algorithm and present the full workflow in Algorithm 5. Our first technique called reuse focuses on minimizing \(|Nodes(T_{f}^{N^{a}})|-|Nodes(T_{0}^{N^{a}})|\) in Equation 4. Our second reorder technique focuses on minimizing \(|Nodes(T_{f}^{N^{a}})|\). The \(H_{\Delta},T_{0}^{N^{a}}\) obtained by reuse and reorder are distinct. IVAN algorithm combines these distinct solutions, to reduce \(Time_{\Delta}(T_{0}^{N^{a}},T_{f}^{N^{a}})\).

**Reuse:** This technique is based on the observation that the BaB specification trees should be similar for small perturbations in the network. Accordingly, in the method, we use the final specification tree for \(N\) as the initial tree for the verification of \(N^{a}\) i.e. \(T_{0}^{N^{a}}=T_{f}^{N}\), and keep the \(H_{\Delta}=H\) unchanged. We formally characterize a set of networks obtained by small perturbation for which \(T_{0}^{N^{a}}=T_{f}^{N}\) is sufficient for verifying \(N^{a}\) without any further splitting in Section 4.4.

**Reorder:** Reorder technique focuses on improving the branching heuristic \(H\) such that it reduces \(|Nodes(T_{f}^{N^{a}})|\), and \(T_{0}^{N^{a}}\) is single node tree with \(n_{0}\) encoding the specification \((\phi,\psi)\). If we start \(T_{0}^{N^{a}}=T_{f}^{N}\), \(|Nodes(T_{f}^{N^{a}})|\) is at least \(|Nodes(T_{f}^{N})|\), and thus, we start \(T_{0}^{N^{a}}\) from scratch allowing the technique to minimize \(|Nodes(T_{f}^{N^{a}})|\). We create a branching function \(H_{\Delta}\) from \(H\) with the following two changes. (i) The splits that worked effectively for the verification of the \(N\) should be prioritized. (ii) The splits that were not effective should be depriitized. To formalize the effectiveness of splits, we define the \(LB_{N}(n)\) as the lower bound computed by the analyzer \(A\) on the network \(N\) for proving the property \(\varphi_{n}\) encoded by the node \(n\). Further, using the function \(LB_{N}\) we define an improvement function \(I_{N}\) represents the effectiveness of a ReLU split at a specific node as:

\[I_{N}(n,r)=\min(LB_{N}(n_{r})-LB_{N}(n),LB_{N}(n_{l})-LB_{N}(n)) \tag{5}\]

where \(n_{l},n_{r}\in Children(n)\) in the specification tree \(T_{f}^{N}\). We use \(I_{N}\) to define the observed effectiveness \(H_{obs}(r)\) from a split \(r\) on the entire specification tree for \(N\). It is defined as the mean of the improvement over each node where split \(r\) was made. Let \(Q\subset Nodes(T_{f}^{N})\) denote a set of nodes where split \(r\) was made. Then,

\[H_{obs}(r)=\frac{\sum_{n\in Q}I_{N}(n,r)}{|Q|}. \tag{6}\]

Using the \(H_{obs}(r)\) score we update the existing branching function as:

\[H_{\Delta}(n,r)=\alpha\cdot H(n,r)+(1-\alpha)\cdot(H_{obs}(r)-\theta). \tag{7}\]

Here, we introduce two hyperparameters \(\alpha\) and \(\theta\). The hyperparameter \(\alpha\in[0,1]\) controls the importance given to the actual heuristic score and the observed improvement from the verification on \(N\). If \(\alpha=1\), then \(H_{\Delta}\) depends only on the original branching heuristic score. If \(\alpha=0\), then it fully relies on observed split scores. The hyperparameter \(\theta\) ensures that our score positively changes score for \(r\) that have \(H_{obs}(r)>\theta\) and negatively change scores for \(H_{obs}(r)<\theta\).
**Constructing a Pruned Specification Tree:** The two reordering goals of prioritizing and deprioritizing effective and ineffective splits are difficult to combine with reuse. However, instead of starting from scratch, we can construct a specification tree \(T_{P}\) from \(T_{f}^{N}\) excluding the ineffective splits. For \(n\in\textit{Nodes}(T_{f}^{N})\), where ReLU \(r\) splits \(n\), we denote the set of bad splits as the set \(\mathcal{B}(T_{f}^{N})\) of the pairs \((n,r)\) such that the improvement score \(I_{N}(n,r)\leq\theta\). For \((n,r)\in\mathcal{B}(T_{f}^{N})\) while constructing the pruned tree our algorithm chooses a child \(n_{k}\) of \(n\). If a ReLU \(r_{k}\) is split at \(n_{k}\) in \(T_{f}^{N}\), it performs a split \(r_{k}\) in the corresponding node in \(T_{P}\), and skips over the bad split \(r\). The subtree corresponding to the other child \(n_{k^{\prime}}\) is eliminated and not added to our pruned tree. We choose \(n_{k}\) such that:

\[n_{k}=\operatorname*{arg\,min}_{n_{u}\in\textit{Children}(n)}LB_{N}(n_{u}) -LB_{N}(n) \tag{8}\]

We choose such \(n_{k}\) over \(n_{k^{\prime}}\) since \(LB_{N}(n)\) is closer to \(LB_{N}(n_{k})\) than \(LB_{N}(n_{k^{\prime}})\). Further, combining Equation 5 and 8, we can show \((LB_{N}(n_{k})-LB_{N}(n))<\theta\), i.e. their difference is bounded. We anticipate that on the omission of the split \(r\), the subtree corresponding to \(n_{k}\) is a better match to the necessary branching decisions following \(n\) than \(n_{k^{\prime}}\).

Algorithm 4 presents the top-down construction of \(T_{P}\). The algorithm starts from the root of \(T_{f}^{N}\) and recursively traverses through the children constructing \(T_{P}\). It maintains a queue \(Q\) of nodes yet to be explored and a map \(M\) that maps nodes from the tree \(T_{f}^{N}\) to the corresponding new nodes in \(T_{P}\). At a node \(n\), if \((n,r)\) is not a bad split, it performs the split \(r\) at the corresponding mapping \(\hat{n}\). Otherwise, if \(r_{k}\) is the split at \(n_{k}\), it skips over \(r\) and performs the split of \(r_{k}\) at \(\hat{n}\). The newly created children from a split of \(\hat{n}\) are associated with children of \(n_{k}\) using \(M\). The children of \(n_{k}\) are added in the \(Q\) and they are recursively processed in the next iteration for further constructing \(T_{P}\). \(T_{P}\) is still a specification tree satisfying the Definition 4.1 by construction. The specifications \(\varphi_{n}\) of a node \(n\) in \(T_{P}\) can be constructed using a path from the root to \(n\).

```
1:specification tree \(T_{f}^{N^{a}}\), hyperparameter \(\theta\)
2:Pruned tree \(T_{P}\)
3:\(n_{root}\leftarrow\) root of \(T_{f}^{N^{a}}\), \(\hat{n}_{root}\leftarrow\) copy of \(n_{root}\)
4:\(T_{P}\leftarrow\) Initialize a new tree with \(\hat{n}_{root}\)
5:\(Q\leftarrow\) Initialize list with \(n_{root}\)
6:\(M\leftarrow\) Initialize an empty map
7:\(M[n_{root}]\leftarrow\hat{n}_{root}\)
8:while\(Q\) is not empty do
9:\(n\gets Q.pop()\); \(r\leftarrow\) split at node \(n\); \(\hat{n}\gets M[n]\)
10:if\(I_{N}(n,r)<\theta\)then
11:\(n_{k}\leftarrow\operatorname*{arg\,min}_{n_{k}\in\textit{Children}(n)}LB_{N}(n_{k}) -LB_{N}(n)\)
12:\(r_{k}\leftarrow\) split at node \(n_{k}\)
13:\(n_{l},n_{r}\gets k.children\); \(\hat{n}_{l},\hat{n}_{r}\gets Split(T_{P},\hat{n},r_{k})\)
14:\(M[n_{l}]\leftarrow\hat{n}_{l};M[n_{r}]\leftarrow\hat{n}_{r}\)
15:\(Q.push(n_{l});Q.push(n_{r})\)
16:else
17:\(n_{l},n_{r}\gets n.children\); \(\hat{n}_{l},\hat{n}_{r}\leftarrow Split(T_{P},\hat{n},r)\)
18:\(M[n_{l}]\leftarrow\hat{n}_{l};M[n_{r}]\leftarrow\hat{n}_{r}\)
19:\(Q.push(n_{l});Q.push(n_{r})\)
20:return\(T_{P}\)
```

**Algorithm 4** Creating a Pruned Tree

**Input:** Original network \(N\),

Perturbed network \(N^{a}\),

property (\(\phi\), \(\psi\)),

analyzer \(A\),

branching heuristic \(H\),

hyperparameters

\(\alpha\) and \(\theta\),

incremental verifier \(V_{\Delta}\)

**Output:** Verification result for \(N\) and \(N^{a}\)

```
1:resultN, \(T_{f}^{N}\gets V(N,\phi,\psi,H)\)
2:\(T_{0}^{N^{a}}\leftarrow\) PrunedTree(\(T_{f}^{N},\theta\))
3:\(H_{\Delta}\leftarrow\) UpdateH(\(H,T_{f}^{N},\theta,\alpha\))
4:\(resultN^{a}\leftarrow V_{\Delta}(N^{a},\phi,\psi,T_{0}^{N^{a}},H_{\Delta})\)\(\triangleright\)Incremental verification step calls Algorithm 3
5:returnresultN,resultN^{a}
```

**Algorithm 5** Incremental Verification Algorithm

**Output:** Verification result for \(N\) and \(N^{a}\)
**Main algorithm:** Algorithm 5 presents IVAN's main algorithm for incremental verification that combines all the aforementioned techniques. It takes as inputs the original network \(N\), a perturbed network \(N^{a}\), input specification \(\phi\), and an output property \(\psi\). It prunes the final tree \(T_{f}^{N}\) obtained in the verification of \(N\) and constructs \(T_{0}^{N^{a}}\) (line 2). It computes the updated branching heuristic \(H_{\Delta}\) using Equation 7 (line 3). It uses \(T_{0}^{N^{a}}\) and \(H_{\Delta}\) for performing fast incremental verification of networks \(N^{a}\) (line 4).

We next state the following lemma that states - verifying the property \((\phi,\psi)\) is equivalent to verifying the specifications for all the leaves.

Lemma 1 ().: _The specifications encoded by the leaf nodes of a specification tree \(T\) maintain the following invariance._

\[\left(\bigwedge_{n\in Leaves(T)}\phi_{n}\right)\Longleftrightarrow(\phi \rightarrow\psi)\]

We next use the lemma to prove the soundness and completeness of our algorithm. All the proofs are in Appendix 9.2.

Theorem 2 (Soundness of Verification Algorithm).: _If Algorithm 5 verifies the property \((\phi,\psi)\) for the network \(N^{a}\), then the property must hold._

Theorem 3 (Completeness of Verification Algorithm).: _If for the network \(N^{a}\), the property \((\phi,\psi)\) holds then Algorithm 5 always terminates and produces Verified as output._

**Scope of IVAN:** IVAN utilizes the specification tree to store the trace of the BaB proof. The IVAN algorithm enhances this tree by reusing and refining it to enable faster BaB proof of updated networks. Our paper focuses on using IVAN to verify ReLU networks with BaB that implements ReLU splitting. However, we expect that IVAN's principles can be extended to networks with other activation functions (tanh, sigmoid, leaky ReLU) for which BaB has been applied for verification.

### Network Perturbation Bounds

In this section, we formally characterize a class of perturbations on a network \(N\) where our proposed "Reuse" technique attains maximum possible speed-up. Specifically, we focus on modifications affecting only the last layer which represent many practical network perturbations (e.g, transfer learning, fine-tuning). The last layer modification assumption is only for our theoretical results in this section. Our experiments make no such assumption and consider perturbations applied across the original network.

We leave the derivation of perturbation bounds corresponding to the full IVAN to future work as it requires theoretically modeling the effect of arbitrary network perturbations on DNN output as well as complex interactions between "Reuse" and "Reorder" techniques. Given a specification tree \(T\) and network architecture \(\mathcal{N}\), we identify a set of neural networks \(\mathbf{C}_{T}(\mathcal{N})\) such that any network \(N^{a}\in\mathbf{C}_{T}(\mathcal{N})\) can be verified by reusing \(T\).

We assume the weights are changed by the weight perturbation matrix \(\mathcal{E}\). If \(N_{l}=ReLU(A_{l}\cdot X+B_{l})\) then last layer of \(N^{a}\) is \(N_{l}^{a}=ReLU((A_{l}+\mathcal{E})\cdot X+B_{l})\).

Definition 11 (Last Layer Perturbed Network).: _Given a network \(N\) with architecture \(\mathcal{N}\), the set of last layer perturbed networks is \(\mathcal{M}(N,\delta)\subseteq\mathcal{N}\), such that if \(N^{a}\in\mathcal{M}(N,\delta)\) then \((\forall i\in[l-1])\cdot N_{i}=N_{i}^{a}\), \(N_{l}=ReLU(A_{l}\cdot X+B_{l})\), \(N_{l}^{a}=ReLU((A_{l}+\mathcal{E})\cdot X+B_{l})\) and \(\|\mathcal{E}\|_{F}\leq\delta\). 1_

Footnote 1: \(\|\cdot\|_{F}\) denotes the Frobenius norm of a matrix

We next compute the upper bound of \(\delta\), for which if the property can be proved/disproved using specification tree \(T\) in \(N\) then the same property can be proved/disproved in \(N^{a}\) using the same \(T\). Therefore, once we have the proof tree \(T\) that verifies the property in \(N\) we can reuse \(T\) for
verifying any perturbed network \(N^{a}\in\mathcal{M}(N,\delta)\). Assuming the property \((\phi,\psi)\) and the analyzer \(A\) are the same for any perturbed network \(N^{a}\in\mathcal{M}(N,\delta)\) the upper bound of \(\delta\) only depends on \(N\) and \(T\).

We next introduce some useful notations that help us explicitly compute the upper bound of \(\delta\). Given \(T\) let \(\mathcal{F}(N_{i},T)\) be the over-approximated region computed by the analyzer \(A\) that contains all feasible outputs \(N_{i}\) of the \(i\)-th layer of the original network. Note \(\mathcal{F}(N_{i},T)\) depends on the \(\phi\) and analyzer \(A\) but we omit them to simplify the notation. Let \(V_{\mathcal{T}}(N,T)\) denote whether the property \((\phi,\psi)\) can be verified on network \(N\) with \(T\). Proof of Theorem 3.1 is presented in Section 9.3

\[LB(\mathcal{F}(N_{i},T))=\min_{Y\in\mathcal{F}(N_{i},T)}\mathcal{C}^{T}Y \tag{9}\]

\[V_{\mathcal{T}}(N,T)=(LB(\mathcal{F}(N_{i},T))\geq 0) \tag{10}\]

\[\eta(N,T)=\max_{Y\in\mathcal{F}(N_{i-1},T)}\|Y\|_{2} \tag{11}\]

Theorem 3.1: _If \(\delta\leq\frac{|LB(\mathcal{F}(N_{i},T))|}{\|C\|\cdot\eta(N,T)}\) then for any perturbed network \(N^{a}\in\mathcal{M}(N,\delta)\)\(V_{\mathcal{T}}(N,T)\iff V_{\mathcal{T}}(N^{a},T)\)._

The proof of the theorem is in Appendix 9.3.

## 5. Methodology

**Networks and Properties.** We evaluate IVAN on models with various architectures that are trained with different training methods. Similar to most of the previous literature, we verify \(L_{\infty}\)-based local robustness properties for MNIST and CIFAR10 networks and choose standard \(\epsilon\) values used for evaluating complete verifiers. For the verification of global properties in Section 6.4 we use the standard set of ACAS-XU properties that are part of the VNN-COMP benchmarks (Bak et al., 2021). Table 1 presents the evaluated models and the choice of \(\epsilon\) for the local robustness properties.

**Network Perturbation.** Similar to previous works (Paulsen et al., 2020; Ugare et al., 2022), we use quantization to generate perturbed networks. Specifically, we use int8 and int16 post-training quantizations. The quantization scheme has the form (TTLite, 2017): \(r=s(q-zp)\). Here, \(q\) is the quantized value and \(r\) is the real value; \(s\) which is the scale and \(zp\) which is the zero point are the parameters of quantization. Our experiments use symmetric quantization with \(zp=0\).

**Baseline.** We use the following baseline BaB verifiers:

* For proving the local robustness properties, we use LP-based triangle relaxation for bounding (Bunel et al., 2020; Ehlers, 2017), and we use the estimation based on coefficients of the zonotopes for choosing the ReLU splitting (Henriksen and Lomuscio, 2021).
* For the verification of ACAS-XU global properties, we use RefineZono (Singh et al., 2019). RefineZono uses DeepZ (Singh et al., 2018) analyzer with input splitting. This baseline is used only for experiments in Section 6.4.

**Experimental Setup.** We use 64 cores of an AMD Ryzen Threadripper CPU with the main memory of 128 GB running the Linux operating system. The code for our tool is written in Python. We use the GUROBI (Gurobi Optimization, LLC, 2018) solver for our LP-based analyzer.

\begin{table}
\begin{tabular}{l l l l l l} \hline \hline Model & Architecture & Dataset & \#Neurons & Training Method & \(\epsilon\) \\ \hline ACAS-XU Networks & \(6\times 50\) linear layers & ACAS-XU & 300 & Standard (Julian et al., 2019) & - \\ FCN-MNIST & \(2\times 256\) linear layers & MNIST & 512 & Standard & 0.02 \\ CONV-MNIST & \(2\) Conv, \(2\) linear layers & MNIST & 9508 & Certified Robust (Balunovic and Vechev, 2020) & 0.1 \\ CONV-CIFAR & \(2\) Conv, \(2\) linear layers & CIFAR10 & 4852 & Empirical Robust (Dong et al., 2018) & \(\frac{2}{259}\) \\ CONV-CIFAR-WIDE & \(2\) Conv, \(2\) linear layers & CIFAR10 & 6244 & Certified Robust (Wong and Kolter, 2018) & \(\frac{2}{259}\) \\ CONV-CIFAR-DEEP & \(4\) Conv, \(2\) linear layers & CIFAR10 & 6756 & Certified Robust (Wong and Kolter, 2018) & \(\frac{2}{259}\) \\ \hline \hline \end{tabular}
\end{table}
Table 1. Models and the perturbation \(\epsilon\) used for the evaluation for incremental verification.
**Hyperparameters.** We use Optuna tuner (Akiba et al., 2019) for tuning the hyperparameters. We present more details and sensitivity analysis of the hyperparameters in Section 6.3.

## 6. Experimental Evaluation

We evaluate the effectiveness of IVAN in verifying the local robustness properties of the quantized networks. We then analyze how various tool components contribute to the overall result. We further show the sensitivity of speedup obtained by IVAN to the hyperparameters. We also stress-test IVAN on large random perturbation to the network. Finally, we evaluate the effectiveness of IVAN on global property verification with input splitting.

### Effectiveness of IVAN

Figure 6 presents the speedup obtained by IVAN on FCN-MNIST. The x-axis displays the time taken by the baseline verifier for the verification in Seconds. The y-axis denotes the speedup obtained by IVAN over the baseline on a specific verification instance. Each cross in the plot shows results for a specific verification property. The vertical line denotes the timeout for the experiment and the dashed line is to separate instances that have a speedup greater than 1x.

We observe that IVAN gets higher speedup on hard instances that take more time for verification on the baseline. IVAN has a small overhead for storing the specification tree compared to the baseline. For hard specifications that result in large specification trees, this overhead is insignificant compared to the improvement in the verification time. Our techniques that reuse and refine the tree focus on speeding up such hard specifications. However, for specifications that are easy to prove with small specification trees, we see a slight slowdown in verification time. Since these easy specifications are verified quickly by both IVAN and the baseline, they are irrelevant in overall verification time over all the specifications. For instance, the box labeled by \(c_{2}\) in Figure 5(a) contains all of the 83 cases with low (\(<1.2x\)) speedup on int16 quantized network. Despite low speedup, all of them take 16.27s to verify with IVAN. Whereas the case labeled by \(c_{1}\) alone takes 75.54s on the baseline and 1.73s on IVAN, leading to a 43x speedup - caused by reducing BaB tree size from 345 nodes to 28 nodes on pruning, out of which only 14 leaf nodes are active and lead to analyzer calls.

We observe a similar pattern in the case of the int8 quantized network in Figure 5(b). It shows that the cases confined in box \(c_{3}\), despite having lower speedup, take relatively less time. The cases included in box \(c_{4}\) in Figure 5(b) have a much higher impact on the overall verification time. Box \(c_{3}\) includes the majority of the low-speedup 83 cases that take a total of 18.44s time for verification with IVAN. Whereas for 5 cases in box \(c_{4}\) with higher speedups, take 401 analyzer calls with baseline and 118 analyzer calls with IVAN. Accordingly, solving them takes 130.6s with the baseline and 40.26s with IVAN, leading to a 3.3x speedup.

Figure 6. IVAN speedup for the verification of local robustness properties on FCN-MNIST.
Figure 7 presents speedup for several other networks. IVAN is notably more effective on hard-to-verify specifications that take more than 10s to verify using the baseline. It achieves 3.1x geomean speedup on such cases. In many cases, we see more solved cases by IVAN over the baseline. For instance, the box \(c_{5}\) in Figure 6(a) contains 2 cases that baseline does not solve within the timeout of 100s, but IVAN solves them in 90.6s and 95.8s each. We show speedup vs. time plots for other networks (CONV-CIFAR, CONV-CIFAR-DEEP ) and more statistics of our evaluation in Appendix 9.1.

### Overall Speedup

We observe no cases when the baseline verifies the property and IVAN exceeds the timeout. We cannot compute the speedup for the cases where the baseline exceeds the timeout. Therefore, we compute the overall speedup over the set \(S\) that denotes all the cases that are solved by the baseline within the time limit. \(t_{B}(c)\) and \(\tau_{IVAN}(c)\) denote the time taken by baseline and IVAN on the case \(c\) respectively, then we compute the overall speedup as \(Sp=\frac{\sum_{c\leq S}t_{B}(c)}{\sum_{c\leq S}\tau_{IVAN}(c)}\).

Table 2 presents the comparison of the contribution of each technique used in IVAN for each model. Column _+Solved_ in each case displays the number of extra verification problems solved by the technique in comparison to the baseline. Columns in IVAN[Reuse] present results on only using the reuse technique. Columns in IVAN[Reorder] show results on using the reorder technique. Columns in IVAN present the results on using all techniques from Section 4. Column \(Sp\) for each technique demonstrates the overall speedup obtained compared to the baseline. We observe that in most case combination of all techniques performs better than reuse and reordering. We see that reorder performs better than reuse except for one case (FCN-MNIST on int8).

Figure 7. IVAN speedup for the verification of local robustness properties.
### Hyperparameter Sensitivity Analysis

Figure 8 plots the heatmap for IVAN speedup on various hyperparameter values. The x-axis shows the hyperparameter \(\alpha\) value and the y-axis shows the \(\theta\) value. Each point in the greed is annotated with the observed \(Sp\) on setting the corresponding hyperparameter values. Figure 7(a) presents the plot for IVAN with on reorder technique. \((\alpha,\theta)=(0.25,0.01)\) is the highest speedup point. Choosing \(\theta=0\) implies that are not depriitizing the splitting decisions that did not work well. In that case, we observe no speedup with reordering, showing the necessity of \(\theta\) in our \(H_{\Delta}\) formulation. Figure 7(b) presents the same plot for our main algorithm that also reuses the pruned tree. We observe that the speedup is less sensitive to hyperparameter value changes in this plot. This is expected since reordering starts from single node \(T_{0}^{N^{\alpha}}\) and purely relied on \(H_{\Delta}\) formulation for the speedup. While our main technique also reuses the tree, even when \(\theta=0\) it can get \(\sim\)2.5x speedup.

### Global Properties with Input Splitting

We show that IVAN is effective in speeding up the state-of-the-art verifier RefineZono (Singh et al., 2019) when verifying global properties. This baseline employs input splitting based on a strong branching strategy. Figure 9 presents the speedup achieved by IVAN over this baseline. Overall, IVAN achieves a 9.5x speedup in the int16 quantization case and a 3.1x speedup in the int8 quantization case. Previous work has observed that ACAS-XU properties take a large number of splits with most analyzers. For the int16 case, the average value of \(|T_{f}^{N^{\alpha}}|\) with our baseline is 285.4.

\begin{table}
\begin{tabular}{l l|c|c|c|c|c} \hline \hline Model & Approximation & \multicolumn{2}{c|}{IVAN[Reuse]} & \multicolumn{2}{c|}{IVAN[Reorder]} & \multicolumn{2}{c}{IVAN} \\  & & \(Sp\) & \(+Solved\) & \(Sp\) & \(+Solved\) & \(Sp\) & \(+Solved\) \\ \hline FCN-MNIST & int16 & 2.51x & 0 & 2.71x & 0 & **4.43x** & 0 \\  & int8 & 1.07x & 0 & 1.64x & 0 & **2.02x** & 0 \\ CONV-MNIST & int16 & 1.62x & 0 & 2.15x & 0 & **3.09x** & 2 \\  & int8 & 1.27x & 2 & 1.34x & 3 & **1.71x** & 4 \\ CONV-CIFAR & int16 & 1.02x & 0 & 1.57x & 2 & **2.52x** & 2 \\  & int8 & 1.08x & 0 & 1.53x & 0 & **1.78x** & 0 \\ CONV-CIFAR-WIDE & int16 & 1.43x & 1 & 1.51x & 0 & **1.87x** & 2 \\  & int8 & 0.75x & 0 & **1.62x** & 1 & 1.53x & **2** \\ CONV-CIFAR-DEEP & int16 & 1.64x & 0 & 2.29x & 0 & **3.21x** & 0 \\  & int8 & 1.15x & 0 & 1.13x & 1 & **1.25x** & 1 \\ \hline \hline \end{tabular}
\end{table}
Table 2. Ablation study for overall speedup across all properties for different techniques in IVAN.

Figure 8. Speedup for the combination of hyperparameter values on FCN-MNIST with int16 quantization.
The baseline takes a total of 305s time for verifying cases that have large tree \(|T_{f}^{N^{\mathbf{a}}}|>5\). IVAN verifies those properties in 32s.

### Random Weight Perturbations

In this experiment, we stress-test IVAN for incremental verification by applying uniform random perturbation on the DNN weights. Here, we perturbed each weight in the network by 2%, 5%, and 10%. Even the smallest of these perturbations (2%) to each of the weights already induces larger overall changes in the network than those caused by practical methods such as quantization, pruning, and fine-tuning that often non-uniformly affect specific layers of the network. For each network and perturbation, we run IVAN and the baseline to verify 100 properties and compute the average speedup of IVAN over the baseline.

Table 3 presents the average speedups obtained by IVAN. Each row shows the IVAN speedup under various weight perturbations for a particular network. We see that in most cases IVAN speedup reduces as the perturbations to the weights increase. It is because the specification tree for the perturbed network is no longer similar to the one for the original network. If IVAN is used in such cases, it uses suboptimal splits leading to higher verification time.

## 7. Related Work

**Neural Network Verification:** Recent works introduced several techniques for verifying properties of neural networks (Anderson et al., 2019, 2020; Bunel et al., 2020; Ehlers, 2017; Kabaha and Drachsler-Cohen, 2022; Katz et al., 2017; Laurel et al., 2022; Tjeng et al., 2017; Wang et al., 2018, 2021; Yang et al., 2022). For BaB-based complete verification, previous works used distinct strategies for ReLU splitting. Ehlers (2017) and Katz et al. (2017) used random ReLU selection for splitting. Wang et al. (2018) computes scores based on gradient information to rank ambiguous ReLU nodes. Similarly, Bunel et al. (2020) compute scores based on a formula based on the estimation equations in (Wong and Kolter, 2018). Henriksen and Lomuscio (2021) use coefficients of zonotopes for these scores.

**Incremental Neural Network Verification:** Fischer et al. (2022) presented the concept of sharing certificates between specifications. They reuse the proof for \(L_{\infty}\) specification computed with abstract interpretation-based analyzers based on the notion of proof templates, for faster verification of patch and geometric perturbations. Ugare et al. (2022) showed that the reusing of proof is possible

\begin{table}
\begin{tabular}{c|c|c|c} \hline \hline  & \multicolumn{3}{c}{Weight perturbation} \\ Model & 2\% & 5\% & 10\% \\ \hline FCN-MNIST & 1.65x & 1.57x & 0.87x \\ CONV-MNIST & 1.97x & 0.57x & 0.57x \\ CONV-CIFAR & 1.29x & 1.09x & 0.69x \\ CONV-CIFAR-WIDE & 1.42x & 1.08x & 0.96x \\ CONV-CIFAR-DEEP & 1.32x & 1.06x & 1.05x \\ \hline \hline \end{tabular}
\end{table}
Table 3. IVAN speedup on uniform random weight perturbations

Figure 9. IVAN speedup for the verification of global ACAS-XU properties.
between networks. It uses a similar concept of network adaptable proof templates. It is limited to certain properties (patch, geometric, \(L_{0}\)) and works with abstract interpretation-based incomplete verifiers. Wei and Liu (2021) considers incremental incomplete verification of relatively small DNNs with last-layer perturbation. All of these works cannot handle incremental and complete verification of diverse specifications, which is the focus of our work

**Differential Neural Network Verification:** ReluDiff (Paulsen et al., 2020) presented the concept of differential neural network verification. The follow-up work of (Paulsen et al., 2020) made it more scalable. ReluDiff can be used for bounding the difference in the output of an original network and a perturbed network corresponding to an input region. ReluDiff uses input splitting to perform complete differential verification. Our method is complementary to ReluDiff and can be used to speed up the complete differential verification with multiple perturbed networks, performing it incrementally. Cheng and Yan (2020) reuse previous interval analysis results for the verification of the fully-connected networks where the specifications are only defined over the last linear layer of an updated network. In contrast, IVAN performs end-to-end verification and operates on a more general class of networks, specifications, and perturbations.

**Warm Starting Mixed Integer Linear Programming (MILP) Solvers:** State-of-the-art MILP solvers such as GUROBI (Gurobi Optimization, LLC, 2018) and CPLEX (Cplex, 2009) support warm starting that can accelerate the optimization performance. MILP can warm start based on initial solutions that are close to the optimal solution. This allows MILP solvers to avoid exploring paths that do not improve on the provided initial solution and can help the solver to converge faster. The exact implementation details of these closed-sourced commercial solvers are unavailable. Regardless, our experiments with MILP warm starting of GUROBI for incremental DNN verification showed insignificant speedup.

**Incremental Program Verification:** Incremental verification has improved the scalability of traditional program verification to an industrial scale (Johnson et al., 2013; Lakhnech et al., 2001; O'Hearn, 2018; Stein et al., 2021). Incremental program analysis tasks reuse partial results (Yang et al., 2009), constraints (Visser et al., 2012) and precision information (Beyer et al., 2013) from previous runs for faster analysis of individual commits. Frequently, the changes made by the program are limited to a small portion of the overall program (and its analysis requires significant attention to the impact on control flow). whereas DNN updates typically alter the weights of multiple layers throughout the network (but with no impact on control flow). Therefore, incremental DNN verification presents a distinct challenge compared to the incremental verification of programs.

**Incremental SMT Solvers:** Modern SMT solvers such as Z3 (De Moura and Bjorner, 2008) and CVC5 (Barbosa et al., 2022) during constraint solving learn lemmas, which are later reused to solve similar problems. The incrementality of these solvers is restricted to the addition or deletion of constraints. They do not consider reuse in cases when the constraints are perturbed as in our case.

## 8. Conclusion

Current complete approaches for DNN verification re-run the verification every time the network is modified. In this paper, we presented IVAN, the first general, incremental, and complete DNN verifier. IVAN captures the trace of the BaB-based complete verification through the specification tree. We evaluated our IVAN on combinations of networks, properties, and updates. IVAN achieves up to 43x speedup and geometric mean speedup of 2.4x in verifying DNN properties.

###### Acknowledgements.

 We thank the anonymous reviewers for their comments. This research was supported in part by NSF Grants No. CCF-1846354, CCF-1956374, CCF-2008883, CCF-2217144, CCF-2238079, CNS-2148583, USDA NIFA Grant No. NIFA-2024827 and Qualcomm innovation fellowship.