review-article

Open access

Formal Verification of Quantum Programs: Theory, Tools, and Challenges

Authors:

Marco Lewis,

Sadegh Soudjani,

Paolo ZulianiAuthors Info & Claims

ACM Transactions on Quantum Computing, Volume 5, Issue 1

Article No.: 1, Pages 1 - 35

https://doi.org/10.1145/3624483

Published: 16 December 2023 Publication History

PDF eReader

Abstract

Over the past 27 years, quantum computing has seen a huge rise in interest from both academia and industry. At the current rate, quantum computers are growing in size rapidly backed up by the increase of research in the field. Significant efforts are being made to improve the reliability of quantum hardware and to develop suitable software to program quantum computers.

In contrast, the verification of quantum programs has received relatively less attention. Verifying programs is especially important in the quantum setting due to how difficult it is to program complex algorithms correctly on resource-constrained and error-prone quantum hardware. Research into creating verification frameworks for quantum programs has seen recent development, with a variety of tools implemented using a collection of theoretical ideas.

This survey aims to be a short introduction into the area of formal verification of quantum programs, bringing together theory and tools developed to date. Further, this survey examines some of the challenges that the field may face in the future, namely the development of complex quantum algorithms.

1 Introduction

Quantum computers are capable of solving a variety of problems much faster than classical computers, as seen in Deutsch-Jozsa’s and Grover’s algorithms [46, 62]. With recent results from Google [8] and the Hefei National Laboratory [111, 113], it is becoming more realistic that large-scale quantum computers will be used by academics and companies alike. Within the next few years, we expect to see a quantum computer with the ability to perform computations on 100s or potentially 1,000 quantum bits (otherwise known as qubits), with IBM aiming at debuting a 1,121 qubit computer in 2023.¹ These planned devices are by no means ideal, as they are Noisy Intermediate-Scale Quantum (NISQ) [87] computers that are limited by having hundreds of qubits but no error correction. The quantum threshold theorem [2] provides the theoretical justification as for why arbitrarily long quantum computations are possible in principle, albeit it assumes quantum error correction.

The problem of error in quantum computers needs to be solved to make large-scale quantum computers usable. There are three potential reasons why an incorrect value is measured during a computation on a quantum circuit. The first is due to the innate randomness when measuring qubits within quantum computers: When a qubit is measured, it commonly collapses into one of its two “basis” states. Most quantum algorithms will only return the correct result with high probability (for example, consider the probability that Grover’s algorithm will return the marked element of a database). Therefore, there is still a chance of measuring incorrect results, but this can be solved by running a quantum circuit multiple times and returning the result that is measured the most (as the correct result will be measured most of the time).

Another source of error is the hardware. Hardware error occurs when qubits are interfered with by gates or sources from outside of the system. Qubits may change state when going through a gate in a different way to what is expected, often referred to as gate infidelity. Alternatively, errors can occur at readout when qubits are measured incorrectly. To prevent errors that change the phase or bit value of a qubit, error-correcting codes can be used [88] (see for example [84] for a thorough investigation of the various techniques for achieving fault-tolerant quantum computing).

The final source of error is from within the software. This can occur at various stages, whether that would be when a programmer codes the algorithm incorrectly or if the compiled circuit is flawed. To solve the error that comes within software, tools need to be developed to verify programs and compiled circuits. By reducing errors within hardware and software, it can be guaranteed that readout distributions match those predicted by quantum theory.

This article is focused on the errors caused by software and how to prevent them through the usage of formal verification. That involves the study and development of tools to verify programs and systems. Recent decades have seen the successful development of automatic provers capable of proving properties about programs or mathematical theories with the press of a button. Examples of such tools² include Satisfiability Modulo Theories (SMT) solvers: Z3 [44], Yices2 [49] and dReal [58]; stochastic, discrete model checkers: PRISM [76] and STORM [65]; non-deterministic, discrete model checkers: nuSMV [33] and SPIN [68]; and stochastic, non-deterministic hybrid model checkers: ProbReach [93], SpaceEx [56], and Uppaal [13].

Developing tools that ensure quantum software is correct is vital for quantum computers. Quantum programs are hard to a develop and even harder to test. Ensuring that a programmer is implementing an algorithm without any errors is particularly difficult in the quantum domain and requires dedicated tools to check for correctness. Further, pursuing research down this route may lead to better understanding of quantum computation and show the power of quantum computers over classical computers for certain tasks.

The goal of this survey is to introduce the formal verification techniques and tools that have been developed to prevent errors and bugs within quantum programs. This includes summarising some of the theories that verification tools for quantum programs are based on and investigating implementations of these tools. Future hurdles for verifying complex quantum algorithms and routes for further research are also discussed.

Note that this article is mainly discussing techniques for verifying quantum programs. Verification is important in other areas of computer science, such as communication, security, program equivalence and concurrency. In this article, there will be limited discussion on circuit equivalence (lower level verification of quantum circuits).

A recent survey by Chareton et al. [30] provides an in-depth discussion on the design of formal quantum programming languages and formally verifying at different levels of quantum computation. In quantum computing, low-level verification is focused on verified compilation and equivalence of circuits, whereas high-level verification is based around verifying the behaviour of programs and algorithms. In contrast, our article focuses on designing verification frameworks, the various theoretical foundations to choose from, the design choices that need to be made when building these frameworks, and examples of these frameworks. Further, we consider how complex quantum algorithms need to be verified and the challenges faced from the design of the algorithms as well as the problems they attempt to solve. It should be noted that whilst both surveys overlap in tools covered including SQIR [66], QBricks [29], and QHLProver [78]; our survey focuses on design choices, whereas [30] covers more details on how the tools work.

For more literature, readers are referred to [11, 97] for verification in quantum security, to [43] for verification in quantum communication, and to [7] for verification in concurrent quantum systems. Process calculi/algebras lie at the intersection between communication and concurrency and have been extended to the quantum domain, allowing formal models to analyse quantum communication protocols. Such calculi include CQP [59], QPAlg [77], and qCCS [108].

The organisation of the article is as follows. Section 2 gives an overview of quantum computing and some background on the fundamentals of model checking and deductive verification. Section 3 discusses the various formal verification techniques that have been extended or created to check quantum programs. Section 4 considers what is desirable in verifiable quantum programming languages. Section 5 discusses the most recent verifiable tools for verifying quantum programs with relation to the topics discussed in the previous section. Section 6 gives examples of non-textbook algorithms and details what hurdles need to be overcome to verify them.

2 Background

This section introduces the standard notation used in quantum computing, and the field of formal verification. Whilst there are many techniques for formal verification, this section focuses on the two most popular ones: model checking and deductive verification.

2.1 Quantum Computing Notation

Nielsen and Chuang’s volume [82] is the standard textbook for quantum computing and a full introduction can be found therein. This section will briefly cover some notation used throughout the article, however, new notation is introduced where appropriate.

Throughout, we make use of the Dirac/bra-ket notation to describe quantum states and operations. The states $\vert{0}\rangle = [1, 0]^\intercal$ and $\vert{1}\rangle = [0,1]^\intercal$ describe the computational basis states. In general, a quantum state is described as $\vert {\phi }\rangle = \sum _j \alpha _j \vert{\phi _j}\rangle$ where $\phi _j$ is typically a bitstring. The dual of a quantum state is denoted by a bra, $\vert {\phi }\rangle^\dagger = \langle{\phi }\vert$.

Unitary operations, denoted by U, are operations from quantum states to quantum states and their inverse is their adjoint. So, $U^{-1} = U^\dagger = \overline{U^\intercal }$. We use $U\vert{\phi }\rangle$ to mean the result of applying U to $\vert{\phi }\rangle$. Measurement is encapsulated by a collection of measurement operators $\lbrace M_m\rbrace$, where m denotes the measurement outcome and $\sum _m M_m^\dagger M_m = I$. For a quantum state $\vert{\phi }\rangle$, the probability of measuring m is given by $P(m) = \langle {\phi }\vert M_m^\dagger M_m \vert{\phi }\rangle$ and the state after measurement is $\tfrac{M_m \vert{\phi }\rangle}{\sqrt {P(m)}}$.

Hermitian operators, denoted by H, are operators that are self-adjoint, so $H = H^\dagger$. Further, Hermitian operators have real eigenvalues. The density matrix formalism is also discussed and used instead to represent quantum states. In this setting, states are described by Hermitian matrices and often are written as $\rho = \sum _j \alpha _j \vert{\phi _j}\times {\phi _j}\vert$. This representation is used in various parts of the article, notably Sections 3.2 and 5.2.

2.2 Model Checking and Verification

Verifying software with model checking involves modelling the software through a formal representation. Then the desired behaviour is specified through an appropriate logic. Once these two components are created, model checking algorithms can be used to check whether the model follows the specified behaviour. In this section, we study the temporal behaviour of software and systems. Models are created using Kripke structures and behaviours are specified using a temporal logic. More details can be found in [37].

Kripke structures model software or systems by describing transitions between states in a similar way to finite state machines. But Kripke structures also model properties that hold in each state. Formally:

Definition 2.1.

A Kripke structure is given by a 4-tuple $M = (S, S_0, R, L)$ where

—

S is a finite set of states;

—

$S_0 \subseteq S$ is the set of initial states;

—

$R \subseteq S \times S$ is a total transition relation, where for all $s \in S$, there exists $s^{\prime } \in S$ such that $(s, s^{\prime }) \in R$;

—

$L: S \rightarrow 2^{AP}$ is a labelling function that gives the set of propositions ($p \in AP$) that hold within a given state.

A common type of logic used to specify behaviour is temporal logic, which can be used to describe what propositions may hold about the system over time. Examples of temporal logics include Linear Temporal Logic (LTL) [86], Computation Tree Logic (CTL) [35], and the $\mu$-calculus [75]. The definition of CTL is given and briefly studied as it will be useful for understanding Section 3.3.

Before giving formal semantics of CTL, we first define the paths on a Kripke structure. Throughout, let ${M=(S, S_0, R, L)}$ be a Kripke structure.

Definition 2.2.

A path is a tuple $\sigma = (s_0, s_1, s_2, \dots)$ where $s_i \in S$ and we have that $(s_i, s_{i+1}) \in R$ for all i.

Note that a path can have infinite or finite length as long as there are suitable transitions.

Terms in CTL are given by state formulae, $\theta$, and temporal operators, T, that only exist bound with path quantifiers. These formulae are defined inductively by

\begin{align*} &\theta ::= p \text{ || }\lnot \theta \text{ || } \theta \vee \theta \text{ || } {\bf E} T \text{ || } {\bf A} T \\ & T ::= {\bf X} \theta \text{ || } {\bf F} \theta \text{ || } {\bf G} \theta \text{ || } \theta {\bf U} \theta {,} \end{align*}

where $p \in AP$ is an atomic proposition in the model. The terms X (“next”), F (“eventually”), G (“always”) and U (“until”) denote basic temporal operators. The terms A (for all paths) and E (there exists a path) are path quantifiers. The semantics of the state and temporal operators described for a Kripke structure are given in Equation (1), where $\sigma = (s_0, s_1, \dots)$ denotes a path.

\begin{equation} \begin{aligned}& [\![ p ]\!] _M = \lbrace s \in S : p \in L(s) \rbrace \\ & [\![ \lnot \theta ]\!] _M = S/[\![ \theta ]\!] _M \\ & [\![ \theta _1 \vee \theta _2 ]\!] _M = [\![ \theta _1]\!] _M \cup [\![ \theta _2]\!] _M \\ & [\![ {\bf EX} \theta ]\!] _M = \lbrace s \in S : \exists t \in S \text{ such that } t \in [\![ \theta ]\!] _M\ \text{ and } (s,t) \in R \rbrace \\ & [\![ {\bf EG} \theta ]\!] _M = \lbrace s \in S : \exists \sigma \text{ such that } s = s_0 \text{ and } \forall k \in \mathbb {N}, s_k \in [\![ \theta ]\!] _M\rbrace \\ & [\![ {\bf EF} \theta ]\!] _M = \lbrace s \in S : \exists \sigma \text{ and } \exists k \in \mathbb {N} \text{ such that } s = s_0 \text{ and } s_k \in [\![ \theta ]\!] _M\rbrace \\ & [\![ {\bf E} \theta _1 {\bf U} \theta _2]\!] _M = \lbrace s \in S: \exists \sigma \text{ and } \exists k \in \mathbb {N} \text{ such that } s = s_0 \text{ and }\\ & \qquad\qquad\qquad {s_i \in [\![ \theta _1]\!] _M , s_j \in [\![ \theta _2]\!] _M \text{ for } i \lt k, j\ge k\rbrace } \end{aligned} \end{equation}

(1)

Note that, we can get the semantic formulas for ${\bf A}T$ for all the temporal operators, T, by replacing $\exists \sigma$ for $\forall \sigma$ (similarly replace $\exists t \in S$ for $\forall t \in S$) in the set definitions for the semantics.

Furthermore, the operators F and G are obtained from U simply as ${\bf F}\theta = {\it true}\, {\bf U}\, \theta$ and ${\bf G}\theta = \lnot {\bf F} \lnot \theta$, where ${\it true}$ is the atomic proposition true in all states.

It should be noted that CTL can be described with a subset of temporal and logical expressions as it is possible to create formulae from different terms. For example, the statements “there is no path such that eventually $\theta$ holds” and “for all paths $\lnot \theta$ always holds” are equivalent and specified in CTL by $\lnot {\bf EF} \theta = {\bf AG} (\lnot \theta)$.

Example 2.3.

Figure 1 gives a model and the relative computation tree is given in Figure 2 with an example CTL operation.

Fig. 1.

Fig. 2.

The model checking problem is to find all valid states that satisfy a temporal logic formula. Alternatively, one could just ask whether the formula is true in the initial states. Given M (a Kripke structure) and $\theta$ (a temporal logic formula), then find all $s \in S$ such that M and s model $\theta$, the semantics of which is denoted by $M, s \models \theta \iff s \in [\![ \theta ]\!] _M$. Model checking has been explored in usage for verifying quantum programs against extensions of temporal logics. This can be seen in Sections 3.3 and 5.5.

A reason for choosing model checking as a verification technique is that it efficiently searches over all possible states of a Kripke structure in a completely automated way. However, the main issue of model checking is the state explosion problem [38]. Due to the design of the Kripke structure, an increase in the size of the system can increase the number of states in the structure massively. This can make it very difficult for the system to be verified quickly. Over the last few decades, a number of methods have been developed to address the state explosion problem. For example, bounded model checking (BMC) [19] only considers finite computation trees, effectively meaning that the system is only checked up to a certain point in its temporal evolution.

Another technique is CounterExample-Guided Abstraction Refinement (CEGAR) [34, 36], which starts by creating an abstract model that simulates the original (concrete) model. The abstract system is then model checked against a given universally path-quantified temporal logic property. If the property is satisfied then we are done, since the abstract model encompasses all the possible behaviours of the concrete model. If instead a counterexample to the property is returned, then this is compared in the concrete model: if it is an actual counterexample, then the model checking fails since this is a “real” bug of the concrete model. Otherwise, the counterexample is spurious and the abstraction is refined so that the counterexample no longer fails inside the abstraction. The newly-obtained abstraction is then model checked again – the process is repeated until the property is either verified or a concrete counterexample is found [34].

2.3 Deductive Verification

For a full review of deductive verification the reader is referred to, e.g., [63]. Unlike model checking, which exhaustively explores the possible states that software can be in, deductive verification formally verifies programs through logical inference. Further model checking can ensure certain properties about software automatically, whereas deductive verification can be used to verify complex properties about programs in a way that is understandable by humans. For example, a subroutine can be shown to always return a certain result no matter the input by using deductive verification. The Floyd-Hoare logic [67] is studied below as an example and will be useful later (see Sections 3.2, 5.2).

A program is given some preconditions, assumptions and rules that can be used for verification, and postconditions, goals or requirements to meet after the program has run with the given preconditions. A program is valid if the postconditions can be inferred from the given preconditions using inference rules. This is often written in the form of a Hoare triple denoted by $\lbrace P\rbrace S\lbrace Q\rbrace$, where P is a precondition, Q is a postcondition and S is a program statement. A Hoare triple is considered valid if a sequence of inference rules can be used to generate it. The basic inference rules are given in Equation (2).

\begin{align} &\frac{} {\{P\} \textbf{ skip }\{P\}} &\text{ (Skip)}\nonumber\\ &\frac{} {\{P[a/x]\} x:=a \{P\}} &\text{ (Assign)}\nonumber\\ &\frac{\{P\} S_1 \{Q\}, \{Q\} S_2 \{R\}} {\{P\} S_1; S_2 \{R\}} &\text{ (Composition)} \nonumber\\ &\frac{\{b \land P\}{S_1}{Q}, \{\lnot b \land P\}{S_2}{Q}} {\{P\}{\textbf{if }b\textbf{ then }S_1\textbf{ else }S_2}\{Q\}} &\text{ (Conditional)}\\ &\frac{\{P \land b\}{S}\{P\}} {\{P\}{\textbf{while }b\textbf{ do } S}{\lnot b \land P}} &\text{ (While)}\nonumber\\ &\frac{P_2 \rightarrow P_1, \{P_2\}{S}{Q_2}, Q_2 \rightarrow Q_1} {\{P_1\}{S}\{Q_1\}} &\text{ (Consequence)}\nonumber \end{align}

(2)

The proof of a program or system can be created from the Hoare triple and the use of inference rules. These proofs are converted into proof obligations, which are mathematical formulae that are checked using one of a variety of software tools. The most common tools for software verification are theorem provers and SMT solvers. Theorem provers [102] allow programmers to write the obligations that are to be met in a completely formal environment. Then lemmas and theorems about these obligations can be derived from definitions created within the tool. Normally, the process of proving an obligation is interactive and so the programmer will write the proof with assistance from the tool. Theorem provers are used in a number of the tools discussed in Section 5.

In comparison, SMT solvers [45] convert obligations into logical formulae over a theory, such as, e.g., the natural numbers, rationals and bit vectors. Alongside a statement the user wishes to assert, the solver can automatically check if the formulae are valid. If not, the solver can provide a counterexample. In particular, at least one tool, QBricks [29], has made use of SMT solvers for verifying quantum programs; which we discuss in Section 5.4.

Deductive verification still suffers from scalability issues similar to model checking. Unlike model checking, it requires programmers to have a deeper understanding of why the obligations are correct. This is both an advantage and a setback, since it can take a long time to prove complex obligations that could be solved automatically using model checking. However, it is possible to create human-readable proofs as to why a program is correct.

For examples of some of the most used theorem provers, the reader is referred to [102]; an introduction to SMT solvers is given in [45] and a deeper study is given in [12].

3 Formal Quantum Verification Methods

This section aims at introducing the theoretical ideas that have been used in pursuit of the verification of quantum programs. While this section covers some theories, it is not a complete list. Further theories include quantum Markov chains [55] and quantum automata [74], which are given a brief introduction in a previous survey [107] with further references therein.

3.1 Quantum Weakest Preconditions

In deterministic programming, the weakest precondition [48] gives a method of transforming the problem of checking whether a program is valid in Hoare logic into a problem of determining whether a precondition implies the said weakest precondition. More formally for deterministic programs, given a program S and a predicate postcondition Q, then the weakest precondition $\text{wp}(S)(Q)$ is the precondition to S such that for all preconditions P with $\lbrace P\rbrace S\lbrace Q\rbrace$, then ${P\Rightarrow \text{wp}(S)(Q)}$.

Whilst a probabilistic version of the Hoare logic has been developed and can be used as a means to verify quantum programs [89], D’Hondt and Panangaden [47] demonstrated one can develop a quantum Hoare-style logic using density matrices. This then allows for the notion of a quantum weakest precondition. The difference in definition is that now the program S is a quantum program, where $S(\rho)$ is the density matrix after applying program S to density matrix $\rho$; the precondition P and postcondition Q are each a quantum predicate, which is a Hermitian operator with positive eigenvalues upper bounded by 1; and a valid precondition P must satisfy $\text{tr} (P\rho) \le \text{tr} (Q \; S(\rho))$ for all density matrices $\rho$. We can write $\lbrace P\rbrace S\lbrace Q\rbrace$ if $P,Q$ and S follow the final inequality. Thus, the quantum weakest precondition $\text{wp}(S)(Q)$ is defined such that for all valid preconditions P, $\text{tr} (P\rho) \le \text{tr} (\text{wp}(S)(Q)\rho))$ for all density matrices $\rho$.

With this notion, it is possible to change the verification problem of quantum programs to that of calculating quantum preconditions. In a sense, the quantum weakest precondition gives the most “general” precondition for a postcondition, meaning that as long as we have a “specific” precondition we can always reach the same postcondition as the “general” precondition. The quantum weakest precondition is a concept that can see usage in different verification systems depending on the language and design used. In Section 3.2, we will see an example of its usage.

3.2 Quantum Hoare Logic

Ying [106] has been developing the Quantum Hoare Logic (QHL) over the last decade, as an extension of the standard Floyd-Hoare logic. Introduced in his original work, the classical while-language is extended to a quantum version and the Floyd-Hoare logic is amended to verify the extension. The quantum-while language is

\begin{align*} S ::= & {\bf skip} \text{ | } q := 0 \text{ | } \bar{q} := U \bar{q} \text{ | } S_1 ; S_2 \text{ | } {\bf measure}\ M[\bar{q}] : \bar{S} \text{ | } {\bf while}\ M[\bar{q}] = 1\ {\bf do}\ S. \end{align*}

where q is a qubit, $\bar{q}$ is a quantum register and $\bar{S} = \lbrace S_m\rbrace _{m \in \mathbb{M}}$ is an indexed set of quantum programs, where $\mathbb {M}$ is the set of measurement results with associated measurement operators $\lbrace M_m\rbrace _{m \in \mathbb{M}}$. The commands do the following operations: skip does nothing; ${q := 0}$ initialises a qubit; $\bar{q} :=U \bar{q}$ performs a unitary operation on a number of qubits; ${S_1 ; S_2}$ is composition of statements; ${\bf measure}\ M[\bar{q}] : \bar{S}$ measures several qubits and performs a program from $\bar{S}$ depending on the result of measurement, i.e., if the measurement result is m, the program follows the commands given by $S_m \in \bar{S}$; and ${\bf while}\ M[\bar{q}] = 1\ {\bf do}\ S$ performs S until a “false” measurement is read.

The quantum-while language stands out because it does not define programs in terms of describing quantum circuits. This allows for an imperative approach for writing quantum programs, rather than the very low-level idea of constructing a circuit. Another feature to highlight is the use of measurement within the language. The measure command replaces the classical if statement and the while statement requires measurement on a set of qubits during each iteration.

The Quantum Hoare Logic then extends the Hoare triple $\lbrace P\rbrace S\lbrace Q\rbrace$, where S is a program written in the quantum-while language and $P, Q$ are quantum predicates (as defined in Section 3.1). However, these predicates are additionally upper bounded by the identity operator, I, and lower bounded by the zero operator 0. They are bounded in that for any predicate P (used in QHL), then for all density matrices $\rho$ we have $\text{tr} (0\rho) \le \text{tr} (P\rho) \le \text{tr} (I\rho)$, thus $0 \le \text{tr} (P\rho) \le 1$.

Inference rules can be used to create Hoare triples for quantum programs depending on the statement. Beyond that, the notion of weakest precondition can be used to generate valid Hoare triples. If a desired postcondition is wanted, then rules can be used to find the weakest precondition for a program. The correctness of evaluating the Quantum Hoare Logic on a program and the condition that evaluation terminates (notions of partial and total correctness respectively) are given in [106].

Work has continued on this logic over the last decade to further improve it and create an implementation, as will be seen in Section 5.2. As an example of an improvement to be made on the grammar, it is clear to see that there is no classical functionality defined. This prevents some quantum algorithms, such as Shor’s algorithm [94], being fully implemented within the quantum-while language. A recent work [54] has extended the quantum-while language to include classical variables and the logic has been reworked to show the extension is verifiable. Another version of Quantum Hoare logic has been proposed in [71], which is not designed around the usage of weakest precondition. Further, this other version verifies Selinger’s QPL [90], a quantum programming language based on flowcharts and featuring classical bits as well as if statements.

Example 3.1.

Here we give an example of using Quantum Hoare logic and the quantum weakest precondition to verify Deutsch’s algorithm (a one qubit version of the Deutsch-Jozsa algorithm [46]). Given $f:\lbrace 0,1\rbrace \rightarrow \lbrace 0,1\rbrace$, recall that Deutsch’s algorithm determines the value of $f(0) \oplus f(1)$ with a single evaluation of f. It should be noted that this example does not make use of an ancillary qubit for the sake of simplicity. We begin by writing Deutsch’s algorithm in the quantum-while language:

\begin{equation*} {\it Deutsch}=[q:=0; q:=Hq; q:=O_fq; q:=Hq; {\bf measure}\ M[q] : \bar{S}_D], \end{equation*}

where $\bar{S}_D= \lbrace S_0={\bf skip}, S_1={\bf skip}\rbrace$, H is the single-qubit Hadamard gate and $O_f$ is the quantum oracle defined by the matrix

\begin{equation*} \begin{pmatrix} (-1)^{f(0)} & 0 \\ 0 & (-1)^{f(1)} \end{pmatrix}. \end{equation*}

Furthermore, the measurement operators M consist of measurements on the computational basis:

\begin{equation*} \left\lbrace M_0 = \left(\begin{array}{c@{\quad}c} 1 & 0 \\ 0 & 0 \end{array}\right), M_1 = \left(\begin{array}{c@{\quad}c} 0 & 0 \\ 0 & 1 \end{array}\right) \right\rbrace . \end{equation*}

The result of receiving either measurement outcome in the measurement statement is to simply skip. Using the definition of the weakest precondition for Quantum Hoare Logic, we wish to find the weakest precondition of the postcondition ${\it Post}=(1-f(0)\oplus f(1))\vert {0}\rangle\langle {0}\vert + (f(0)\oplus f(1)) \vert {1}\rangle\langle {1}\vert$. This postcondition states that q should be in the appropriate state depending on the value of $f(0) \oplus f(1)$. Here, we will calculate the weakest precondition of the measurement statement and leave the rest of the calculation for the Deutsch program in Appendix B.

From Proposition 7.1 in [106], we have that

\begin{equation*} wp.({\bf measure}\ M[\bar{q}]:\bar{S}).P := \sum _m M^\dagger _m (wp.(S_m).P) M_m, \end{equation*}

and so for our case, we have

\begin{equation*} \begin{aligned}wp.({\bf measure}\ M[q]: \bar{S}_D).{\it Post} & := M^\dagger _0 (wp.(S_0).{\it Post}) M_0 + M^\dagger _1 (wp.(S_1).{\it Post}) M_1\\ & = M^\dagger _0 (wp.({\bf skip}).{\it Post}) M_0 + M^\dagger _1 (wp.({\bf skip}).{\it Post}) M_1. \end{aligned} \end{equation*}

Further to this, the weakest precondition of skip is simply $wp.({\bf skip}).P = P$. Thus, we have that

\begin{align*} wp.({\bf measure}\ M[q]: \bar{S}_D).{\it Post} & := M^\dagger _0 ({\it Post}) M_0 + M^\dagger _1 ({\it Post}) M_1 \\ & = (1-f(0)\oplus f(1))\vert {0}\rangle\langle {0}\vert + (f(0)\oplus f(1)) \vert {1}\rangle\langle {1}\vert\\ & = {\it Post}, \end{align*}

giving the Hoare triple $\lbrace {\it Post}\rbrace {\bf measure}\ M[q]:\bar{S}_D\lbrace {\it Post}\rbrace$.

Following the rules for quantum weakest precondition of the Quantum Hoare Logic, the resulting Hoare triple for the entire program is $\lbrace I \rbrace {\it Deutsch} \lbrace {\it Post} \rbrace$, where I is the single qubit identity operator. This weakest precondition means that Deutsch can have any precondition and the program will always produce the correct result. This is because quantum predicates are upper bounded by I and I is the most general precondition we can have such that Post is the postcondition.

3.3 Quantum Computation Tree Logic

Various notions of extending Computation Tree Logic (CTL) to the quantum case have been studied, and implemented into model checking algorithms. For example, [55] investigated a quantum extension of probabilistic CTL (PCTL). Recently, in [105] the authors created a different extension of CTL that uses the concept of fidelity (which measures how much a density matrix state is changed after being acted on by a super-operator).

Other temporal logics have been studied both as quantum extensions of the original logic [80, 109] and how temporal logics can model behaviour in quantum systems; examples of investigating linear temporal properties can be found in [17] and more general $\omega$-regular properties in [52]. In this section, the notion of quantum computation tree logic given in [10] is presented.

The Quantum Computation Tree Logic (QCTL) is a temporal logic used to reason about the behaviour of a quantum Kripke structure. Formally:

Definition 3.2.

A (finite) quantum Kripke structure over a set of qubits $\text{qB}$ and variables X is a tuple $(S, R)$ where:

—

$S \subset \mathcal {H}_{\text{qB}} \times \mathbb {R}^X$ is a set of pairs $(\phi , \rho)$, where $\phi$ is a quantum state of the qubits qB and $\rho$ is an assignment of variables to reals;

—

$R \subseteq S \times S$ is a relation such that for any $(\phi , \rho)$, there exists $(\phi ^{\prime }, \rho ^{\prime })$ such that $((\phi , \rho), (\phi ^{\prime },\rho ^{\prime })) \in R$.

Note that in comparison to the standard definition of Kripke structures, propositions are embedded as variables into the state rather than labels on specific states. In the literature for model checking, structures vary between Kripke structures, Markov chains, transition systems and variations on those structures (such as the quantum Kripke structure described). These structures vary in definition but will follow the structure of a state transition system that has some labels (propositions) associated with the states of the structure. The main difference between such structures is the transition relation between states and the temporal logic used for specifying desired behaviour, which changes how these models are checked.

By combining the decidable fragment of the exogenous quantum propositional logic (dEQPL) [28] with the classical CTL used in model checking, we get QCTL. The grammar for dEQPL used in [10] is

\begin{align*} & \text{Classical Formulae} \\ \alpha & ::= \bot _c \text{ | } \text{qb} \text{ | } \alpha \Rightarrow _c \alpha \\ & \text{Terms} \\ t & ::= x (\in Var) \text{ | } m (\in \mathbb {Z}) \text{ | } (t + t) \text{ | } (tt) \text{ | } \text{Re}(\vert {\mathsf {T}\rangle}_A) \text{ | } \text{Im}(\vert {\mathsf {T}\rangle}_A) \text{ | } \int \alpha \\ & \text{Quantum Formulae} \\ \gamma & ::= t \le t \text{ | } \bot _q \text{ | } \gamma \Rightarrow _q \gamma . \end{align*}

We distinguish between logic on classical formulae, $\alpha$, and quantum formulae, $\gamma$, by using subscript c and q respectively. Further, we can abbreviate other connectives ($\lnot , \wedge , \vee , \Leftrightarrow , \top$) using $\bot$ and $\Rightarrow$.³

Classical formulae describe the set of qubits we wish to measure from using classical logic statements and qubit symbols $\text{qb}$ from $\text{qB}$. Terms describe numerical expressions we can make with additional variables, constants, and functions for getting information about the quantum state. The term $\text{Re}(\vert{\mathsf {T}}\rangle_A)$ denotes the real part of the amplitude of the quantum state from a subset of qubit symbols, $A \subseteq \text{qB}$ (similarly $\text{Im}(\vert{\mathsf {T}}\rangle_A)$ for the imaginary part). The term $\textstyle {\int }\alpha$ denotes the probability that $\alpha$ holds when measuring all qubits. Finally, quantum formulae allow us to reason about terms by using logical expressions and comparison formulae. This allows us to reason about the state of a quantum system at a specific time step.

In Reference [10], it is shown that QCTL is sound and (weakly) complete. Further, an algorithm was developed that checks if a QCTL formula is satisfiable by extending an algorithm used for model checking CTL. The grammar for QCTL is

\begin{align*} \theta & ::= \gamma \text{ | } (\theta \Rightarrow _q \theta) \text{ | } {\bf EX}\theta \text{ | } {\bf AF}\theta \text{ | } {\bf E}[\theta {\bf U}\theta ], \\ & \text{where $\gamma $ is a dEQPL quantum formula.} \end{align*}

The semantics of the QCTL given above for the temporal operators are similar to the CTL formula except they act over paths on a quantum Kripke structure. Note that QCTL uses a subset of the temporal logic operations from CTL and the other temporal operations can be derived from this subset.

Unlike some of the other formal methods discussed in this section, this logic would be used in a similar way to the model checking described in Section 2.2. This would involve converting properties of a quantum program or circuit into the QCTL language. By providing a specification for the program, the QCTL formula can be checked for model satisfiability using the algorithm given in [10]. The other QCTLs introduced at the start of this section [55, 105] found use in model checking quantum Markov chains.

We now give two examples of QCTL [10] formulae.

Example 3.3.

Denote $\Box \alpha$ as $(\textstyle {\int } \alpha) = 1$. This is a dEQPL formula that states a classical formula $\alpha$ holds with probability 1 after measuring all qubits. The following formula is used in [10] as the formula for verifying a single bit version of the BB84 protocol [14]:

\begin{equation*} B = (\Box (b_A \Leftrightarrow _c b_B)) \Rightarrow _q {\bf A}\left[(\lnot _q (\Box e)) {\bf U} \left((\Box e) \wedge _q \left((\Box k) \Leftrightarrow _q \left(\int m = 1\right)\right)\right)\right]. \end{equation*}

The formula means “If Alice and Bob are in the same basis $(\Box (b_A \Leftrightarrow _c b_B))$, then down all (quantum) paths the protocol has not ended ($\lnot _q (\Box e))$) until it has ended $(\Box e)$ and the generated key bit is equal to the value of the qubit used ($(\Box k) \Leftrightarrow _q (\textstyle {\int } m = 1)$)”.

Example 3.4.

As a second example, consider Deutsch’s algorithm. Denote $b = f(0) \oplus f(1)$ as a classical bit. Further, use m as a classical bit to say when the algorithm has performed the measurement operation and let q denote the qubit used for the algorithm. Usage of m is required to specify temporal behaviour for Deutsch’s algorithm. We then have the following formula:

\begin{equation} D = {\bf A}\left[(\lnot _q (\Box m)) {\bf U} \left((\Box m) \wedge _q \left((\Box b) \Leftrightarrow _q \left(\int q = 1\right)\right)\right)\right]. \end{equation}

(3)

The formula reads “for all (quantum) paths (${\bf A}$), the qubit is not measured ($\lnot _q (\Box m)$) until it is measured ($\Box m$) and the measured qubit gives us the correct result with certainty (${(\Box b) \Leftrightarrow _q (\textstyle {\int } q = 1)}$)”. We give a quantum Kripke structure in Appendix C that is based on Deutsch’s algorithm and satisfies the formula D. That is, we describe a pair $(S,R)$ such that all states in the structure satisfy D.

3.4 Path Sums

Path sums are a representation of unitary operators in terms of a summation of exponential polynomials with different quantum states. This representation was used in [4] to show the equivalence of quantum programs. Equation (4) shows a path sum represented as a unitary operator. Note that $\mathbf {x} = (x_1, \dots , x_n)$ is a collection of Boolean variables or constants (the input signature), P is a (phase) polynomial with inputs $\mathbf {x}$ and $\mathbf {y}$, and $f : \mathbb {Z}_2^n \times \mathbb {Z}_2^m \rightarrow \mathbb {Z}_2^n$ is a multi-variable Boolean function (the output signature):

\begin{equation} U : \vert {\mathbf {x}}\rangle \rightarrow \frac{1}{\sqrt {2^m}} \sum _{\mathbf {y} \in \mathbb {Z}_2^m} e^{2 \pi i P(\mathbf {x},\mathbf {y})} \vert {f(\mathbf {x},\mathbf {y})\rangle}. \end{equation}

(4)

Path sums are used to represent the semantics of Clifford$+R_k$ circuits⁴ for a fixed k. Reduction rules can be applied to decrease the size of the circuit and so it is easy to check the equivalence of quantum circuits. Experiments in [4] have shown that Clifford$+T$ circuits with a large number of qubits and gates can be efficiently and automatically verified. This gives a useful representation to efficiently verify quantum circuits. However, it will require support through a translation tool to be used to verify circuits written in a high-level programming language, which could include classical components. An extension of path sums has been used for verifying a quantum programming language in the QBricks verification framework, which is generally discussed in Section 5.4.

Example 3.5.

The path sum representation of the Pauli gates are listed below:

\begin{align*} X & : \vert{x}\rangle \rightarrow \vert {1-x}\rangle, \\ Y & : \vert{x}\rangle \rightarrow e^{2\pi i \frac{(2x + 1)}{4}}\vert {1-x}\rangle, \\ Z & : \vert{x}\rangle \rightarrow e^{2\pi i \frac{x}{2}}\vert{x}\rangle. \end{align*}

3.5 The ZX-Calculus

The ZX-calculus [40] can be utilised as an alternate form of verification. The ZX-calculus is a graphical tool designed to convert quantum circuits into a graphical model and back again (but not all graphs are quantum circuits). These graphical models or networks model wires in the form of edges and some operations in the form of vertices.

The ZX-calculus consists of three main vertices: the Hadamard node, green spiders and red spiders (shown in Figure 3). Using a set of rewrite rules, it is possible to add or remove various vertices. This allows the creation of optimised circuits and comparison between circuits.

Fig. 3.

While the ZX-calculus is a useful tool for low-level verification, it is an example in highlighting the difference in what the other tools described are trying to achieve. The ZX-calculus is useful for optimising circuits and showing the equivalence of circuits. It can be used to verify properties of simple circuits, such as the teleportation protocol [40].

However, recently, the ZX-calculus has also been used to verify some properties of oracle-based algorithms [26]. As research continues into the ZX-calculus, the calculus may reach a point where it can be used to represent programs. The Scalable ZX-calculus [27] can represent circuits with a parameterised number of qubits and is used in [26] to represent quantum algorithms. The ZX-calculus has several other applications⁵ and a much more in-depth introduction can be found in [98].

4 Design of Verification Frameworks and Quantum Programming Languages

In this section, several tradeoffs and properties that are desired from a programming language for quantum verification are given. Whilst the tradeoffs are similar to what classical theorem provers need to consider, different requirements need to be met for the language due to the nature of quantum computation. These criteria will later be used to highlight the differences of the available verification frameworks for quantum programming.

4.1 Tradeoffs

Environment. This concerns the environment in which the programmer creates their programs.⁶ There are a few options available when considering this. Firstly, the language could be embedded within an available theorem prover. This gives the benefits of the host language, as well as access to libraries and community support. Further, someone familiar with the environment would be able to pick up the language fairly easily. However, embedding within a theorem prover does mean that the quantum verifier also suffers from the limitations of the said theorem prover. Numerous current tools take this approach, such as SQIR and QHLProver, which are discussed in Section 5. In general, a quantum programming language could be embedded in a classical language, such as how Quipper is embedded in Haskell [61], and a modified verification framework can be used to verify programs.

An alternative is to create a new environment dedicated to the verification of quantum programs from scratch. This gives more freedom in being able to meet the specification the designer creates. On the downside, it may take longer to develop than other methods. It will take longer to fully build a dedicated tool for the verification of programs versus building off or extending a well-known tool. This approach would be akin to building a tool such as an SMT solver (Z3, dReal, etc.) or model checker (PRISM, nuSMV, etc.).

Another approach is to extend a quantum programming language with a verification framework. This would allow both programs to be verified and executed on a simulator or quantum hardware. However, the choice of language needs to be considered and the framework would need to be updated whenever the underlying language gets updated. One example of this approach in the quantum setting is the $\texttt {Entang{$\lambda$}e}$ framework [6]. $\texttt {Entang{$\lambda$}e}$ is capable of translating Quipper [61] programs into quantum Markov chains [53], which can then be checked against temporal logic formulae.

Interactive vs Automated. Here, one needs to consider whether the user should interact with the proofs they are constructing and how much should a tool automate the process of generating the proof. One can design a fully interactive prover, a fully automated prover or a mix between the two.

If the framework is designed to be interactive, then it may take more man-hours to construct proofs. However, this brings the benefit of the user obtaining a better understanding as to how a program is (or is not) valid. On the other hand, an automated-focused framework could only require the push of a button to prove programs, possibly leaving the user in the dark as to why the program is correct.

The size of systems requiring verification are a factor in which type of tool to use. A large system might not be suitable for an interactive approach, requiring the use of an automated approach. In [81], the authors highlight the use of model checkers and SMT solvers for the verification of avionics systems. The case studies provided contain systems with reachable state spaces of up to $1.5 \times 10^{37}$ states.

Executability and Separability. Another property to consider is what should be executable within the framework and how separable a program should be from its specification. For example, should specification be written within the program definition, in the same file as the program or within a separate file.

This will depend on the environment chosen for the framework and how mixed the specification is with the programs created. If a program is to be run on quantum hardware, the specification and verification of a program need to be separated from its definition. This is because the verification of quantum programs occurs classically (at least for now) whereas programs would be executed on quantum hardware. This puts the separation between the definition and execution of programs and specification as a high priority.

Running programs on a simulator is quite different. The reason for running a quantum program on a simulator is to check the outcomes of the program. In verification frameworks that provide counterexamples, simulators can be used to run and test the counterexample. This usage ensures that a counterexample is in fact correct and is particularly useful for abstraction-based approaches, where the result from an abstraction may be different to the result from running the actual program (akin to CEGAR for model checking described within Section 2.2). Simulators can also be used for running small programs and the program is guaranteed to perform as expected. This allows the designer to freely decide how separable program and specification should be.

4.2 Limitations of Quantum Programs

Due to the difference in nature between quantum and classical computing, quantum programming languages have different requirements to classical ones. In [70] a discussion on a number of bugs to avoid when implementing a quantum programming language is given. Here a few of the ideas presented in [70] are discussed as are some other thoughts. The article goes into more details on common bugs that programmers may create due to human error, but this is omitted.

No-cloning. One of the key properties to meet is that the no-cloning theorem [104] is adhered to. The rules that quantum mechanics follows do not allow for the copying of arbitrary quantum data. Therefore, any quantum programming language should have inbuilt functionality to forbid (perfect) cloning. For example, if programs and proofs are mixed within the language, then the no-cloning theorem can be proved within the language. Alternatively, no-cloning can be achieved by making it built into the language through the use of types or linear logic.

Limited Classical Functionality. A useful approach of designing a quantum computer is by having a classical computer being able to access a small quantum processor, known as quantum random access memory (QRAM), in a similar way to a graphics processing unit (GPU) [73]. The quantum part of the computer should perform purely quantum operations, having very little classical functionality within it. Because of this restriction, quantum programming languages need to be designed so that there is very limited classical functionality within the language as to avoid affecting the quantum system.

It should be noted though that there are some nice features that can come with having classical functionality. For instance, oracles implement classical functions into a quantum circuit and having classical functionality would allow for easy implementation of oracles. Silq [18] implements this in an easy-to-do way. Striking the right balance of how much classical functionality to have is therefore very important to consider.

Depending on the amount of classical functionality, there are two ways to verify a program with quantum and classical components. One method is to combine a quantum verifier with a classical verifier, each handling the verification of separate parts of the program. The alternative would be for the verifier to have suitable logic to handle classical and quantum functionality together.

Program Parameters. Moving away from low-level quantum circuit description languages and into the realm of quantum programs requires the use of parameters. Using parameters allows quantum programmers to easily describe their program in a very general manner and then provide specific values during runtime. For example, Grover’s algorithm can use parameters to describe the size of the circuit and a general oracle function that it can take as input. This provides complexity from a verification perspective as the more parameterised a program is, the harder it is to verify for correctness or other properties.

For some quantum programs, it can be useful to use the output of measurement results to influence the control of a program. This concept is a form of dynamical lifting, which allows classical data to be used to affect the control of a quantum program. Classical data can be used as a parameter before or during runtime. Types of control flow include determining the number of wires to use, running different circuits after a qubit is measured (e.g., the teleportation protocol) or a notification to redo the computation (e.g., repeat until success loops). Recent extensions of Quipper have shown how dynamic lifting can be implemented in practice [41, 57]. Techniques such as dynamic lifting will require specific methods to be handled by verifiers.

Ancillary Cleaning. Ancillaries are qubits that are introduced into the system in an initial state, used for a computation temporarily and then returned to their initial state. This process of returning the ancillary to its initial state is known as cleaning and is important for programmers or language designers to take into account. In classical computation, ancillary bits can be easily removed automatically by the processor through garbage collection, since classical bits can be discarded without affecting the state of the program. However, if ancillary qubits are not cleaned, there is the potential for measurement outcomes to be affected due to entanglement between the main qubits and the ancillary ones. It should be decided by the designers whether programs should automatically uncompute ancillaries or if the programmer should perform this task.

A key feature in the programming language Silq [18] is that ancillaries are automatically uncomputed. Whether this feature will be seen in future verifiable programming languages is uncertain. From a verification perspective, it would be advantageous to verify properties of ancillary qubits. For example, one such property is verifying that an ancillary qubit returns to its initial state so that it can be removed from the computation.

Types for Quantum Variables. Another issue that is faced by designers of quantum programming languages is the design of types within their language. This includes problems such as whether measuring a quantum variable causes it to remain the same type, and what properties of a quantum variable need to be embedded into a type.

Another factor to consider when handling types is how to detect entanglement between different variables. Twist [110] features a unique typing system that allows the programmer to change the type of a variable depending on whether it is entangled with other variables or not. This is known as purity checking and it is handled through operations that are run before and during the running of a program. The techniques developed in Twist can be of use for future languages, but advancements need to be made to perform full purity checking before the program is run. Purity checking can be considered a form of verification and is a problem that needs to be explored with different tools.

Algorithm Milestones. Designers of quantum languages often show the capabilities of their language by implementing a quantum algorithm. One should think of each algorithm as a milestone that should be reached. The lowest milestone to reach is being able to implement the Deutsch-Jozsa algorithm [46] or the quantum teleportation protocol [15] as these are fairly well-known algorithms. The next milestone would be to write either Grover’s [62] or the Quantum Phase Estimation algorithm (many of these algorithms mentioned can be found in [82]). This is because both involve some form of iteration and are slightly more complex than the Deutsch-Jozsa and teleportation algorithms. The hardest algorithms to implement would be some of the 7 algorithms implemented in Quipper [61], which includes quantum walks on Binary Welded Trees [32] and the Ground State Estimation algorithm [101].

For verifiable quantum programming languages, it is also necessary to be able to prove these programs run correctly. Many quantum programming languages are already able to implement several of the common “textbook” algorithms and a variety of algorithms in other fields, such as quantum chemistry [25]. So far, verifiable languages have only been able to prove about “textbook” algorithms. Whether they can prove facts about more advanced algorithms is yet to be seen. In Section 6 we discuss two non-textbook algorithms and their challenges to verification.

5 Verifiable Quantum Programming Languages

Here various quantum programming languages that can verify programs are discussed, highlighting their tradeoffs, where they excel and their limitations. At the end of this section, other quantum verification tools, whose focus is not on the formal verification of programs, are briefly discussed.

5.1 SQIR (and QWire)

The languages QWire [85] and SQIR (Small Quantum Intermediate Representation) [66] are domain specific languages built in the Coq interactive theorem prover [16]. QWire was one of the first quantum programming languages to be released with verifiable programs, while SQIR is a more recent language that has various improvements over QWire. These improvements include shorter code, better handling of ill-typed programs and the separation of semantics for unitary and non-unitary (e.g., measurement) operations.

SQIR uses the various functionalities of Coq to act as a proof assistant for writing proofs about quantum programs. In order to verify a program, firstly the program is defined using a dedicated type, with qubits being referred to by a numerical value. Programs can be defined by one of two types: base_ucom, which only contains unitary operations; or com, which allows for measurement. Classical subroutines cannot be performed within a SQIR program, but it is possible to generate circuits using classical parameters.

Theorems can then be conjectured about the program. Unitary SQIR uses state vectors as part of the semantics, whereas full SQIR extends this to density matrices. The user proves the theorem with the assistance of the Coq framework. This format separates programs from how they are specified/proved. No-cloning is satisfied through the use of unitary gates and measurement being the only operations allowed in the language.

An example program and proof can be seen in Figure 6. Whilst the example given is quite trivial, it is possible to make generalisations about what can be proven. The creators of SQIR have already proven some properties about Grover’s algorithm, notably the probability of measuring a marked element after T steps being $\sin ^2((2T+1) \arcsin (\sqrt {k/2^n}))$ (where n is the number of qubits and k is the number of marked elements).

Fig. 6.

Coq requires interaction from the user for theorem proving, but there is some automation when reducing matrices as seen in the ${solve\_matrix}$ function given in Figure 6 (${solve\_matrix}$ is a tactic that attempts to simplify a matrix equality using a variety of sub-tactics). Further, SQIR benefits from a number of gates already implemented and verified within the language. With its capabilities, SQIR has been able to prove properties about most textbook algorithms, including Grover’s, the Quantum Phase Estimation and Shor’s algorithms.

SQIR is designed such that circuits use a predefined number of qubits. Should ancillary qubits be required in the circuit, the user must define these at the start, rather than introducing them when required. This design choice reflects quantum hardware that cannot perform on-the-fly ancillary allocation but could be restrictive should allocation be possible after beginning the computation.

5.2 QHLProver

The Quantum Hoare Logic, as described previously in Section 3.2, has been implemented into the Isabelle/HOL proofing tool [78]. This implementation uses a slightly simpler version of the quantum-while language, omitting the initialisation term $q:=0$.

A full documentation of the implementation is available in the Isabelle Archive of Formal Proofs (AFP) [79]. This implementation is referred to as QHLProver. By using Isabelle, verification is not fully automated, but some automation is used to make manual proving easier when handling complex matrices, which are used to define gates and oracles. An example can be seen in Figure 7, showing how a program is validated within the Isabelle framework.

Fig. 7.

QHLProver is similar to SQIR in a few ways. The way programs are proved is akin to that of Coq, where programs, states and density matrices are defined and then theorems can be conjectured about them. Similar to SQIR, programs in QHLProver require a predefined number of qubits and so ancillary qubits need to be defined at the start of computation.

Programs are written using a specific type (com), which encodes the terms of quantum-while, and the predicates used within the pre- and post-conditions are density matrices. These all need to be verified for a specific triple to be correct as seen in Figure 7.

Unlike SQIR, which defines programs as quantum circuits, QHLProver uses an extension of the quantum-while language to define programs. Whilst there is no theory written for no-cloning within the documentation, no-cloning is adhered to due to the simple grammar that only allows for unitary operations and measurement.

As mentioned previously, there is no classical functionality in the quantum-while language and this is reflected within the Isabelle implementation. Classical parameters are used to extend gates to operate on a subset of qubits. Constructing oracles for different algorithms is done by writing functions defined in terms of natural numbers to booleans, which are then used to create a complex matrix from the matrix indexes.

QHLProver suffers from a lack of implemented and verified logic gates. Currently, the language implements the Pauli gates, Hadamard gates and some gates used within Grover’s algorithm. Out of the common quantum gates, only the Hadamard gate is verified. This makes it difficult to create new programs as the user must verify simple gates (such as CNOT).

CoqQ. A recent tool called CoqQ [112] builds on the work from QHLProver. It shares a number of similarities, such as using QHL and the quantum-while language. As in the name, CoqQ uses the Coq theorem prover instead of Isabelle/HOL.

CoqQ enhances the semantics of QHL by using improved inference rules and allowing dynamic initialisation of qubits. This allows the framework to verify non-textbook algorithms such as algorithms for solving the hidden subgroup problem [82] and the hidden linear function problem [23]; and the HHL algorithm (see Section 6.1).

5.3 Isabelle Marries Dirac

A recent work [20] provides another instance of verified quantum computing using the Isabelle theorem prover. Unlike QHLProver’s use of the quantum-while language and Hoare logic, Isabelle Marries Dirac (IMD) uses the standard matrix formalisation approach of quantum computing to prove properties about algorithms and protocols. Because of this, IMD is closer to a verifiable mathematical library, rather than a verifiable programming language. An example can be seen in Figure 8.

Fig. 8.

Firstly, matrices are defined to have a fixed size, whether through a variable n or a value. Ancillaries are needed to be defined by the user and taken into account when defining matrices. Fortunately, programs in IMD are defined using the dot and Kronecker product of matrices. This makes it easier to add in ancillary definitions.

Since IMD is a mathematical library, classical functionality is possible so long as proofs are developed in the Isabelle theorem prover. Oracles are constructed in a similar way to QHLProver, where the matrix value at an index is determined by a function with indexes as input. Various properties about measurement are implemented within the library such as the probability of a given outcome. It is possible to prove properties about not just standard algorithms (e.g., the Deutsch-Jozsa algorithm) but also different quantum information theoretic results such as quantum teleportation. One result to mention in particular is that IMD explicitly proves the no-cloning theorem within Isabelle. The other tools within this section do not provide such a proof in the framework they use, but the definitions of states and operations that the tools use allow for no-cloning to be followed. More results are discussed in [20].

Further, Echenim and Mhalla [51] have used IMD and density matrices from QHLProver to prove properties about projective measurements (measuring qubits in a basis different from the computational basis $\lbrace \vert{0}\rangle, \vert{1}\rangle\rbrace$). They continued to develop more information theory results by proving the CHSH inequality [39]. As can be seen, the featured libraries have more proofs relating to mathematical concepts of quantum computing that cannot be implemented in a programming language. The documentation for IMD and the extension [51] are available in the Archive of Formal Proofs [21, 50].

5.4 QBricks

QBricks [29] is a circuit-based verifiable quantum programming language built in the Why3 framework. The language is purposefully built so that the writing of programs is separated from the specification to be proved about the program. Programs are written using QBricks-DSL, which is a domain specific language, and the specifications are written in QBricks-SPEC. Figure 9 gives the specification and definition for the oracle used in the Deutsch-Jozsa algorithm.⁷

Fig. 9.

The verification process of programs uses the ideas of the weakest precondition, path sums and quantum Hoare logic to generate proof obligations, building on previous works to suit the requirements of the language. Programs written in QBricks-DSL are converted into a path sum representation, which can then be used in the specification of their program in QBricks-SPEC to verify various properties. Several Hybrid Quantum Hoare Logic (HQHL) rules are given and can be used to generate the proof obligations from the specification and program written in path sums. These obligations are then proved using automatic SMT solvers such as Alt-Ergo [42] and Z3 [44]. QBricks still requires some interactivity from the user when writing the specification, but as mentioned these are mostly proved automatically.

The language features a vast array of functionalities, including the capability of introducing ancillary qubits in the middle of code, unlike SQIR and QHLProver. The framework adheres to the no-cloning theorem as it only allows certain unitary operations within its DSL.

QBricks still has some limitations though. Currently, there are no built-in capabilities to measure qubits within QBricks-DSL. Further, QBricks is not designed to interact with classical data, but classical parameters can be used in the generation of circuits.

Despite these limitations, so far QBricks has been able to verify properties for the Phase Estimation and Shor’s algorithms, which are the most complex algorithms verified by languages so far.

5.5 Related Verification Tools

Quantum Model Checking. The Quantum Program/Protocol Model Checker (QPMC) [53] is a tool developed to check a quantum extension of probabilistic CTL (qCTL; different from the QCTL discussed in Section 3.3) against programs that are modelled by quantum Markov chains. This allows programmers to use model checking techniques against quantum programs. However, QPMC is limited in that one needs to write their program as a Markov chain for it to be checked. This can be circumvented by a tool known as Entang$\lambda$e [5, 6], which allows quantum programmers to convert Quipper programs into Markov chains that can then be checked against qCTL properties.

Feynman - Path Sums. Using the path sum technique from Section 3.4, a Haskell library known as Feynman was produced to perform simulation, verification and equivalence checking of quantum circuits [3, 4].

Equivalence Checking using Binary Decision Diagrams (BDDs). Another form of equivalence checking has been developed through the use of BDDs and extensions. There are two notable tools that take this direction. The first approach [24, 103] makes use of an extension of binary decision diagrams called quantum multiple-valued decision diagrams (QMDDs) [83]. The second approach SliQEC [31, 100] uses a bit-slicing technique to represent complex numbers efficiently in standard BDDs [96].

PyZX. This tool is a module in the Python language that implements the ZX-calculus [72]. Still currently under development, PyZX is able to convert back and forth between circuits and ZX graphs. This allows circuits to be simplified and optimised using the rules of the ZX-calculus. PyZX is not designed for reasoning about programs, but is useful for checking the equivalence of circuits.

CertiQ. This is a verification framework developed for Qiskit [1] that verifies if a compiled circuit is the same as the circuit that is programmed by the user [92]. Interestingly, it makes use of Z3 and other SMT solvers to perform this verification automatically, requiring the user to only input a few lines of specification. While this uses automatic verification, again it should be highlighted that this is used for verifying circuit equivalence, similarly to PyZX, and not for reasoning about programs.

QSharpCheck. This tool extends Q# with a means of testing programs [69]. Users can initialise qubits, notably their phase, and a number of different postconditions to be met by the resulting qubits. With this, the user can then define parameters that are used to run the tests. When run, test cases are randomly generated, executed on the program and checked they meet the postconditions given. This makes it very easy to quickly test a few properties of a program. However, this tool is designed for testing purposes and not for formal verification of programs. Despite this, it may find use for simpler programs that do not need to be verified extensively.⁸

6 Challenges in Verifying Complex Quantum Algorithms

Whilst many standard quantum algorithms have been verified in a number of the tools described above, specific techniques will be needed to verify complex algorithms. Here we study the problems that arise for verifying the Harrow-Hassidim-Lloyd algorithm [64] and the Binary Welded Tree quantum walk algorithm [32].

6.1 The Harrow-Hassidim-Lloyd Algorithm

The Harrow-Hassidim-Lloyd (HHL) [64] quantum algorithm solves linear systems of equations. Specifically, given a sparse, Hermitian matrix $\mathbf {A}$ and unit vector $\mathbf {b}$, find $\mathbf {x}$ such that $\mathbf {Ax} = \mathbf {b}$.⁹ Using a matrix $\mathbf {A}$ as described above, the classical Conjugate-Gradient method can be used to find $\mathbf {x}$ in time $O(N\kappa s \log {(1/\epsilon)})$, where N is the size of $\mathbf {A}$, $\kappa$ is the condition number of $\mathbf {A}$, s denotes how sparse $\mathbf {A}$ is and $\epsilon$ is the error [91]. In the case of the HHL algorithm, the actual output is an approximation of $\mathbf {x}$ using a measurement matrix $\mathbf {M}$. This approximation can be found classically in $O(N \kappa \text{poly}(1/\epsilon))$. The run time of HHL is $O(\log {(N)} \kappa ^2 s^2 / \epsilon ^3)$ and returns the answer with high probability, providing an exponential speedup with respect to N. The circuit for the HHL algorithm is given in Figure 10 and some Silq code is presented in Figure 11.

Fig. 10.

Fig. 11.

Here we give a brief explanation of how the HHL algorithm works. Let $N = 2^n$ and the N-length unit vector $\mathbf {b}$ be represented by the quantum state $\vert{b}\rangle = \sum _{i= 0}^{N-1} \mathbf {b}_i \vert{i}\rangle$. This is loaded into a n-qubit register using an operator B. Hamiltonian simulation is used to represent $\mathbf {A}$ in a quantum phase estimation call. The unitary matrix U in quantum phase estimation is $e^{-i\mathbf {A}t}$ for HHL and rotates $\vert{b}\rangle = \sum _{j} \beta _j \vert {\mu _j}\rangle$ around the eigenvectors of $\mathbf {A}$, which are $\mathbf {\mu _j}$ and $\vert {\mu _j}\rangle$ being their quantum state representation (similarly to $\vert{b}\rangle$).

Performing the quantum phase estimation (QPE) call entangles the eigenvalue representations of $\mathbf {A}$ in a new quantum register with their associated eigenvectors. This gives a quantum state of the form $\sum _j \vert {\lambda _j}\rangle\vert {\mu _j}\rangle$. The eigenvalues are then embedded into the phase of the quantum state using controlled rotations on an ancillary qubit (using an operator R), leaving the quantum state as $\sum _j \vert {\lambda _j}\rangle\vert {\mu _j}\rangle(C\vert {0}\rangle + \frac{1}{\lambda _j}\vert {1}\rangle$).

The quantum phase estimation routine is undone and the ancillary qubit is then measured. If it returns $\vert{0}\rangle$, then the entire quantum state is dumped and the algorithm is run again. If it returns $\vert{1}\rangle$, then the register that previously contained $\vert{b}\rangle$ now contains $\vert{x}\rangle = \sum _j \frac{\beta _j}{\lambda _j} \vert {\mu _j}\rangle$, a representation of $\mathbf {x}$. This can then be measured after applying $\mathbf {M}$, which changes the basis that $\vert{x}\rangle$ is measured in.

As mentioned previously, only the CoqQ tool can verify an instance of HHL with assumptions on the inputs to the algorithm. The HHL algorithm has a number of features that will make formal verification of an implementation challenging. Some of these features are not common in the standard algorithms and are discussed.

Repeat until Success. One of the key aspects involved in this algorithm is the Repeat until Success loop that is dependent on the measurement of an ancillary qubit. This feature is also an aspect of Shor’s algorithm [94], since there are possibilities for a measured result to be invalidated through classical checks. QHLProver is the only suitable verification framework that can handle Repeat-until-Success loops dependent on measurement outcomes. This is achieved through the verification of the while statement in the quantum-while language.

Subroutines. As mentioned the HHL algorithm features the quantum phase estimation algorithm. This would need to be verifiable first before much progress could be made on the HHL algorithm. However, it is also important to consider what properties of quantum phase estimation need to be proved for different algorithms. For HHL, it will be important to show that $\mathbf {b}$ has a representation under the eigenvectors of $\mathbf {A}$. It will also be important to consider how the eigenvalue representations affects the phase of the quantum state. Verification will be needed here to prevent side effects within a program.

Hamiltonian Simulation Approximation. Hamiltonian simulation is used to give a unitary approximation of the evolution of a Hamiltonian system. This technique has been used with matrices of different types for different purposes (as is the case in HHL). A verification tool will need to ensure that an implementation of an approximation is actually a good approximation of the behaviour that is expected. Techniques for verifying that implementations of a Hamiltonian are correct have not yet been studied (to the best of our knowledge). None of the tools given have verified an example of Hamiltonian simulation. Tools embedded within theorem provers might be able to perform this verification but this will require separate study.

6.2 Walking on Binary Welded Trees

The problem statement of the Binary Welded Tree (BWT) algorithm [32] is that there are two trees, of the same depth, that are joined together by a weld at their leaves. The task is to walk from one root node (the entrance node) to the root node on the other tree (the exit node). When at a node, you only have local knowledge, where you cannot ask where you are on the tree but you can identify edges you have been down. For trees of depth n, one can walk to the weld and then walk down edges randomly until the exit node is reached. This is referred to as a random walk and has a worst case run time of $O(2^n)$, as one may visit almost every node in the tree.¹⁰ The random quantum approach allows the walker to traverse down all edges from a node by entering a superposition of staying at the current node and traversing to a new node. This quantum approach achieves an exponential speed up in comparison to the classical approach, running in $O(\text{poly}(n))$ and the quantum system will collapse to the root of the other tree with high probability.

Each leaf node in the weld is connected to two leaves on the other tree. Further, the weld is designed such that it is cyclic and every leaf is in the cycle. An example of a binary welded tree is given in Figure 12. To identify edges at a node, they are coloured. Edges only need to have a unique colour to the other edges on attached nodes. There is no constraint on the number of colours used, but it is possible to colour a tree using only 4 colours (this can be seen in Figure 12).

Fig. 12.

Again, the reader should refer to [32] for full details on how the algorithm works. To explain briefly, a quantum register is used to represent the nodes and the register is initialised to the start node. The algorithm features a number of colour oracles that modify some ancillary register. A colour oracle returns a connected node if a node has an edge of that colour or the error state if not. Further, an additional qubit is used to flag the error state.

Fig. 13.

For a specific colour, the quantum register is put through the colour oracle. Then a rotation occurs through a Hamiltonian simulation. The entangled node register and ancillary register are rotated so that the connected node is slightly rotated into the quantum state. Then the colour oracle is reversed. The algorithm loops through the colour oracles and repeats this loop a specified number of times. By selecting an appropriate time, the algorithm will stop and return the label of the root of the right tree with high probability. Sample Silq code is presented in Figure 13 and Figure 14 shows a diagrammatic evolution of the quantum state for the first iteration through the colour oracles.

Fig. 14.

Through the description of the algorithm, one can see that there are various features that will be difficult to formally verify. Some of these features are discussed.

Loop Invariants. Unlike the measurement based loops in the HHL algorithm, the BWT algorithm features two classical loops: one for the colour oracles and one for repeating the process. This leads to very deep circuits being created and so making the verification process slow from simply unwinding the entire loop. To verify these loops, either loop invariants need to be made or Bounded Model Checking could be used to unwind the procedure for a number of iterations. QBricks already features an iter statement for repeating a quantum circuit a finite number of items. Such a feature could be used to verify aspects of BWT, but this is expected to be a challenging task.

Quantum Objects - Nodes vs Qubits. Whereas most of the standard algorithms use qubits to represent values, the BWT algorithm works on a “quantum” graph. While physically this graph would be represented by qubits, it would be helpful for verification to verify about the nodes and graph structure easily. QuantumOne [99] is a recent endeavour into verifying about quantum objects rather than qubits.

Oracle Implementation. In standard algorithms (e.g., Deutsch-Jozsa), oracles only refer to a single function with defined constraints. However, the oracles for the BWT algorithm are more complex, depending on a classical variable from a loop and featuring an error flag. This provides difficulty in terms of defining the expected behaviour for the oracle function.

7 Conclusion

This article provides the reader with some insights into the current state of research for verification within quantum programming. It should also demonstrate the importance of verification techniques keeping pace with the development of quantum hardware and software.

Given the various topics discussed, we list a few open problems. Whilst this is not an exhaustive list, it should give room for researchers to investigate problems within formal verification of quantum programs:

—

Many of the tools listed can only perform verification up to a certain extent. For example, QBricks is unable to handle measurement of qubits and QHLProver is unable to initialise qubits in the middle of a program. Further, most tools do not have the means to verify classical data and operations. So, can a verifier, such as QBricks or a new tool, be used to verify programs with measurement and classical bits? Can properties of various verifiers be merged together or are there practical limits in terms of complexity?

—

Languages in the NISQ-era have seen development and it would be worth investigating how theoretical frameworks can be applied to them. Some tools, such as CertiQ, already provide some verification for programming languages. Can a tool be made for the formal verification of programs written in a widely used language (or a subset of it), such as Q# [95]?

—

We have seen examples of the complex quantum algorithms that are currently available. The question remains as to whether simple examples of these algorithms can be verified using tools currently available. CoqQ [112], mentioned at the end of Section 5.2, has been able to verify a few complex algorithms using QHL, but other techniques still need to tackle this hurdle.

—

Further, whilst general quantum programs have been discussed, a question remains over the verification of specific quantum techniques. For example, how to verify simulations of Hamiltonians or quantum loops with classical control?

A final point to highlight is that verifiable programming languages need to be developed to be easy to learn or use. Non-verifiable languages have the benefit that users can quickly learn the syntax of the language and have access to dedicated documentation. Those that require verification also require the user to learn the underlying tool that is used to write them if they have not used theorem provers before, e.g., Coq for SQIR and Isabelle for QHL. Making a tool that is easy to use and quick to learn would encourage more programmers to use them.

Acknowledgments

We would like to thank Leo Freitas, for sharing his thoughts on theorem provers and reference [102]; Bohua Zhan, for sharing insight in using QHLProver [79]; Robert Rand, for pointing out the tools CoqQ [112] and Feynman [3]; and the editors and reviewers for their constructive feedback.

Footnotes

https://www.research.ibm.com/blog/quantum-development-roadmap/

Some can be found competing at competitions including SMT-COMP (https://smt-comp.github.io/) for SMT solvers and ARCH (https://cps-vo.org/group/ARCH) for hybrid system model checkers.

Note that in [10] classical formulae do not use the subscript and different symbols are used for quantum formulae: $\lnot _q$ is $\boxminus$, $\wedge _q$ is $\sqcap$, $\vee _q$ is $\sqcup$, $\Leftrightarrow _q$ is $\equiv$.

⁴

See Appendix A for information on Clifford circuits.

⁵

Such as usage in circuit optimisation, surface codes and measurement-based quantum computation.

⁶

Some of the environment tradeoffs discussed are common in other domain specific languages.

⁷

At the time of writing, a tutorial article is being written by the team.

⁸

In early 2021, Microsoft added some testing and debugging functionality to Q#: https://docs.microsoft.com/en-us/azure/quantum/user-guide/testing-debugging?tabs=tabid-vs2019

⁹

Although it is possible to change a linear system problem that uses a non-Hermitian matrix to one that uses a Hermitian matrix (details are within [64]).

¹⁰

One can achieve a polynomial classical algorithm, but this uses global knowledge of the walkers position on the graph.

A Clifford Gates

The Clifford gates [60] are the following gate operations:

\begin{equation} H = \frac{1}{\sqrt {2}}\left(\begin{array}{c@{\quad}c} 1 & 1 \\ 1 & -1 \end{array}\right),\ S = \left(\begin{array}{c@{\quad}c} 1 & 0 \\ 0 & i \end{array}\right),\ CX = \left(\begin{array}{c@{\quad}c@{\quad}c@{\quad}c} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 0 & 1 \\ 0 & 0 & 1 & 0 \end{array}\right). \end{equation}

(5)

Circuits that can be generated from Clifford gates are referred to as being in the Clifford group and can be simulated efficiently on a classical computer, as stated by the Gottesman-Knill theorem [60]. It is unknown if all non-Clifford circuits (i.e., circuits containing operations that cannot be broken down to Clifford operations) can be simulated efficiently. If this was the case, then quantum computers could be efficiently simulated on classical computers.

The operation S can be generalised to $R_k$, where

\begin{equation} R_k = \left(\begin{array}{c@{\quad}c} 1 & 0 \\ 0 & e^{\frac{2\pi i}{2^k}} \end{array}\right), \end{equation}

(6)

and it can easily be seen that if $k\ge 2$, then $(R_k)^{2^{k-2}} = S$ (with $R_2 = S$). For $k \ge 3$, $R_k$ is a non-Clifford operation. The circuits generated by using Clifford gates and the $R_k$ gate (for a fixed k) are referred to as the Clifford$+R_k$ group. In particular, denote $T = R_3 = {\left(\scriptsize\begin{array}{c@{\quad}c} 1 & 0 \\ 0 & e^{\pi i/4} \end{array}\right)}$ and then $\text{Clifford}+R_3 = \text{Clifford}+T$. Algorithms for simulating Clifford$+T$ gates are discussed in [22]. The algorithms’ runtimes are exponential based on the number of T gates.

B Quantum Hoare Logic Example

As seen earlier, we have that $\lbrace {\it Post}\rbrace {\bf measure}\ M[q]:\bar{S}_D\lbrace {\it Post}\rbrace$. We now calculate $wp.(q:=Hq).{\it Post}$. For ease of notation, denote $c = 1-f(0)\oplus f(1)$ and $b = f(0)\oplus f(1)$ (so ${\it Post} = (c\vert{0}\rangle\langle {0}\vert + b \vert{1}\rangle\langle {1}\vert$). Using the weakest precondition rules from Proposition 7.1 in [106], we have

\begin{align*} wp.(q:=Hq).{\it Post} & = H^\dagger {\it Post} H \\ & = H (c\vert{0}\rangle\langle {0 }\vert + b \vert{1}\rangle\langle {1}\vert ) H \\ & = c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert , \end{align*}

and so we have the Hoare triple $\lbrace c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert \rbrace q:=Hq \lbrace {\it Post}\rbrace$. Next we find the weakest precondition of $q := O_f q$ for $\lbrace c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert \rbrace$. Using the same rule we have

\begin{align*} wp.(q:=O_f q). (c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert ) &= O_f^\dagger (c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert ) O_f \\ &= O_f (c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert ) O_f \\ &= ((-1)^{f(0)} \vert{0}\rangle\langle {0 }\vert + (-1)^{f(1)} \vert{1}\rangle\langle {1}\vert ) \\ & (c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert ) \\ & ((-1)^{f(0)} \vert{0}\rangle\langle {0 }\vert + (-1)^{f(1)} \vert{1}\rangle\langle {1}\vert ) \\ &= c ((-1)^{f(0) + f(0)} \vert{0}\rangle\langle {0 }\vert + (-1)^{f(0) + f(1)} \vert{0}\rangle\langle {1}\vert \\ & + (-1)^{f(1) + f(0)} \vert{1}\rangle\langle {0 }\vert + (-1)^{f(1) + f(1)} \vert{1}\rangle\langle {1}\vert ) \\ & + b ((-1)^{f(0) + f(0)} \vert{0}\rangle\langle {0 }\vert - (-1)^{f(0) + f(1)} \vert{0}\rangle\langle {1}\vert \\ & - (-1)^{f(1) + f(0)} \vert{1}\rangle\langle {0 }\vert + (-1)^{f(1) + f(1)} \vert{1}\rangle\langle {1}\vert ) \\ & = (c+b)(-1)^{2f(0)} \vert {0}\times 0\vert \\ & + (c - b)(-1)^{f(0)+f(1)} \vert {0}\times{1}\vert \\ & + (c - b)(-1)^{f(1)+f(0)} \vert {1}\times {0}\vert \\ & + (c+b)(-1)^{2f(1)}\vert {1}\times 1\vert \\ & = \vert{0}\rangle\langle {0 }\vert + \vert{0}\rangle\langle {1}\vert + \vert{1}\rangle\langle {0 }\vert + \vert{1}\rangle \langle {1}\vert = \vert {+}\rangle\langle {+}\vert . \end{align*}

The penultimate equality holds because ${c - b = 1-2(f(x) \oplus f(y)) = (-1)^{f(x)+f(y)}}$. Thus, we have the Hoare triple $\lbrace \vert {+}\rangle\langle {+}\vert \rbrace q:=O_f q\lbrace c\vert {+}\rangle\langle {+}\vert + b \vert {-}\rangle\langle {-}\vert \rbrace$.

It is not hard to see that $\lbrace \vert{0}\rangle\langle {0 }\vert \rbrace q:=Hq\lbrace \vert {+}\rangle\langle {+}\vert \rbrace$ with $\vert{0}\rangle\langle {0 }\vert$ being the weakest precondition of the given statement and postcondition.

Finally, we can use the weakest precondition rule for initialisation:

\begin{equation*} wp.(q:=0).P=\vert{0}\rangle_q\langle {0 }\vert P\vert{0}\rangle_q\langle {0 }\vert +\vert{1}\rangle_q\langle {0 }\vert P\vert{0}\rangle_q\langle {1}\vert . \end{equation*}

For simplicity, we can drop the q notation from the equation, since we only have a 1-qubit program. Thus, it is easy to see that

\begin{align*} wp.(q:=0).\vert{0}\rangle\langle {0 }\vert &= \vert{0}\rangle\langle {0 }\vert \vert{0}\rangle\langle {0 }\vert \vert{0}\rangle\langle {0 }\vert +\vert{1}\rangle\langle {0 }\vert \vert{0}\rangle\langle {0 }\vert \vert{0}\rangle\langle {1}\vert \\ &= \vert{0}\rangle \langle {0 }\vert + \vert{1}\rangle \langle {1}\vert = I, \end{align*}

and therefore the Hoare triple $\lbrace I\rbrace q:=0\lbrace \vert{0}\rangle\langle {0 }\vert \rbrace$ holds. By following the sequential rule, it is easy to see that $wp.({\it Deutsch}).{\it Post} = I$ and we get the desired Hoare triple of $\lbrace I\rbrace {\it Deutsch}\lbrace {\it Post}\rbrace$.

C QCTL Deutsch Example

We begin by setting up the quantum Kripke structure. For simplicity, we do not use variables and omit the $\rho$ terms from states. The set of qubits is denoted $\text{qB} = \lbrace m, b, q\rbrace$ and the initial state of qubits is denoted $I = \lbrace \vert {0,b,0}\rangle: b \in \lbrace 0, 1\rbrace \rbrace$. Next we introduce the operation for Deutsch’s algorithm. Again, for simplicity, we perform all the operations in a single unitary

\begin{equation*} U_D = (X \otimes I_2 \otimes I_2) (I_2 \otimes I_2 \otimes H) (I_2 \otimes I_2 \otimes O_f) (I_2 \otimes I_2 \otimes H) = X \otimes I_2 \otimes H O_f H. \end{equation*}

Thus we have the set of states being $S = \lbrace {U_D}^n a\vert {\psi }\rangle: n \in \mathbb {N}_0, \vert {\psi }\rangle\in I, a\in \lbrace 1,-1\rbrace \rbrace$ and, since $U_D$ is self-inverse, we have that $S = \lbrace \pm \vert {0,0,0}\rangle, \pm \vert {0,1,0}\rangle, \pm \vert {1,0,0}\rangle, \pm \vert {1,1,1}\rangle\rbrace$. The transition relation is then given by $R = \lbrace (\vert {\psi }\rangle, U_D\vert {\psi }\rangle) : \vert {\psi }\rangle\in S\rbrace$ and the quantum Kripke structure is $(S,R)$.

We use the specification given in Equation (3) but convert the temporal operators to ones used in [10]:

\begin{equation*} \begin{aligned}\theta _1 = & \lnot _q (\Box m), \\ \theta _2 = & (\Box m) \wedge _q \left((\Box b) \Leftrightarrow _q \left(\int q = 1\right)\right), \\ D = & {\bf A}[\theta _1 {\bf U} \theta _2] \\ = & {\bf AF} \theta _2 \wedge _q \lnot _q {\bf E}(\lnot _q \theta _2 {\bf U} \lnot _q (\theta _1 \vee _q \theta _2)). \end{aligned} \end{equation*}

We can now check set of states from S that satisfy D, which we write as $Sat_{(S,R)}(D) \subseteq S$ and can use the algorithm in Table 9 from [10] to determine the set. Firstly, note that

\begin{equation*} \begin{aligned}Sat_{(S,R)}(D) &= {\bf FixedPoint}[\lambda X.\lbrace R^{-1}X\rbrace \cup X, Sat_{(S,R)}(\theta _2)] \wedge _q \\ &\quad S \setminus {\bf FixedPoint}[\lambda Y.\lbrace R^{-1}Y \cap Sat_{(S,R)}(\lnot _q \theta _2)\rbrace , Sat_{(S,R)}(\lnot _q(\theta _1 \vee _q \theta _2))], \end{aligned} \end{equation*}

where ${\bf FixedPoint}[f,x_0]$ performs the computation $x_{i+1} = f(x_{i})$ until $x_{i+1} = x_i$. We denote the set of states that satisfy a dEQPL formula, $\gamma$, by $[\![ \gamma ]\!]_{\text{dEQPL}} = \lbrace \vert {\psi }\rangle\in S: s \Vdash _{\text{dEQPL}} \gamma \rbrace$. We have the following evaluations of dEQPL formula

\begin{align*} [\![ \Box m ]\!]_{\text{dEQPL}} &= \lbrace \vert {\psi }\rangle\in S: \sum _{b,q}\Vert {\langle {1,b,q\vert}{\psi\rangle }}\Vert^2 = 1\rbrace , \\ [\![ \Box b ]\!]_{\text{dEQPL}} &= \lbrace \vert {\psi }\rangle\in S: \sum _{m,q}\Vert {\langle {m,1,q\vert}{\psi\rangle }}\Vert^2 = 1\rbrace , \\ \left[\!\left[ \int q = 1 \right]\!\right]_{\text{dEQPL}} &= \lbrace \vert {\psi }\rangle\in S: \sum _{m,b}\Vert {\langle {m,b,1\vert}{\psi\rangle }}\Vert^2 = 1 \rbrace , \\ \left[\!\left[ (\Box b) \Leftrightarrow _q \left(\int q = 1\right) \right]\!\right]_{\text{dEQPL}} &= \lbrace \vert {\psi }\rangle\in S: \sum _{m}\Vert {\langle {m,c,c\vert}{\psi\rangle }}\Vert^2 = 1 \text{ for } c \in \lbrace 0,1\rbrace \rbrace . \end{align*}

Next we find the set of states that satisfy the quantum formulas

\begin{align*} Sat_{(S,R)}(\theta _1) &= S \setminus [\![ \Box m ]\!]_{\text{dEQPL}}\\ &= S \setminus \lbrace \vert {\psi }\rangle\in S: \sum _{b,q}\Vert {\langle {1,b,q\vert}{\psi }}\rangle\Vert^2 = 1\rbrace \\ &= \lbrace \pm \vert {0,0,0}\rangle, \pm \vert {0,1,0}\rangle \rbrace ; \\ Sat_{(S,R)}(\theta _2) &= [\![ \theta _2 ]\!]_{\text{dEQPL}} \\ &= \lbrace \vert {\psi }\rangle\in S: \Vert {\langle {1,c,c\vert}{\psi\rangle }}\Vert^2 = 1 \text{ for } c \in \lbrace 0,1\rbrace \rbrace \\ &= \lbrace \pm \vert {1,0,0}\rangle, \pm \vert {1,1,1}\rangle \rbrace ; \\ Sat_{(S,R)}(\lnot _q \theta _2) &= S \setminus \lbrace \pm \vert {1,0,0}\rangle, \pm \vert {1,1,1}\rangle\rbrace = \lbrace \pm \vert {0,0,0}\rangle, \pm \vert {0,1,0}\rangle \rbrace ; \\ Sat_{(S,R)}(\lnot _q (\theta _1 \vee _q \theta _2)) &= S \setminus (|[ \theta _1 |]_{\text{dEQPL}} \cup |[ \theta _2 |]_{\text{dEQPL}}) \\ &= S\setminus (\lbrace \pm \vert {0,0,0}\rangle, \pm \vert {0,1,0}\rangle \rbrace \cup \lbrace \pm \vert {1,0,0}\rangle, \pm \vert {1,1,1}\rangle \rbrace) = \emptyset . \end{align*}

We find the evaluations of the fixed point evaluations are

\begin{align*} &{\bf FixedPoint}[\lambda X.\lbrace R^{-1}X\rbrace \cup X, Sat_{(S,R)}(\theta _2)] = \lbrace \pm \vert {0,0,0}\rangle, \pm \vert {0,1,0}\rangle, \pm \vert {1,0,0}\rangle, \pm \vert {1,1,1}\rangle \rbrace = S, \end{align*}

and

\begin{align*} &{\bf FixedPoint}[\lambda Y.\lbrace R^{-1}Y \cap Sat_{(S,R)}(\lnot _q \theta _2)\rbrace , Sat_{(S,R)}(\lnot _q(\theta _1 \vee _q \theta _2))] \\ &= {\bf FixedPoint}[\lambda Y.\lbrace R^{-1}Y \cap \lbrace \pm \vert {0,0,0}\rangle, \pm \vert {0,1,0}\rangle \rbrace \rbrace , \emptyset ] = \emptyset . \end{align*}

Finally, we have that

\begin{equation*} Sat_{(S,R)}(D) = S \cap (S\setminus \emptyset) = S \cap S = S. \end{equation*}

All states in $(S,R)$ satisfy D and thus the algorithm correctly returns the value b.

References

[1]

Qiskit contributors. 2023. Qiskit: An open-source framework for quantum computing.

Abstract

1 Introduction

2 Background

2.1 Quantum Computing Notation

2.2 Model Checking and Verification

2.3 Deductive Verification

3 Formal Quantum Verification Methods

3.1 Quantum Weakest Preconditions

3.2 Quantum Hoare Logic

3.3 Quantum Computation Tree Logic

3.4 Path Sums

3.5 The ZX-Calculus

4 Design of Verification Frameworks and Quantum Programming Languages

4.1 Tradeoffs

4.2 Limitations of Quantum Programs

5 Verifiable Quantum Programming Languages

5.1 SQIR (and QWire)

5.2 QHLProver

5.3 Isabelle Marries Dirac

5.4 QBricks

5.5 Related Verification Tools

6 Challenges in Verifying Complex Quantum Algorithms

6.1 The Harrow-Hassidim-Lloyd Algorithm

6.2 Walking on Binary Welded Trees

7 Conclusion

Acknowledgments

Footnotes

A Clifford Gates

B Quantum Hoare Logic Example

C QCTL Deutsch Example

References

Cited By

Index Terms

Recommendations

Verification of Distributed Quantum Programs

symQV: Automated Symbolic Verification of Quantum Programs

Formal verification of ASMs using MDGs

Comments

Information

Published In

Publisher

Publication History

Check for updates

Author Tags

Qualifiers

Funding Sources

Contributors

Other Metrics

Bibliometrics

Article Metrics

Other Metrics

Citations

Cited By

View options

PDF

eReader

Get Access

Login options

Full Access

Figures

Other

Share

Share this Publication link

Share on social media

Affiliations