Formal Verification of Quantum Programs: Theory, Tools and Challenges

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.


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 largescale 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 to debut a 1,121 qubit computer in 2023. 1 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 results 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 error caused by software and how to prevent it 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 2 include SMT (Satisfiability Modulo Theories) 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 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 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 [30] provides an in-depth discussion on circuit equivalence and details on quantum programming languages.In contrast, our article focuses on designing verification frameworks and how more complex quantum algorithms need to be verified.
Otherwise, 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 paper 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.

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
antum 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 paper, 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 |0 = [1, 0] ⊺ and |1 = [0, 1] ⊺ describe the computational basis states.In general, a quantum state is described as | = where is typically bitstring.The dual of a quantum state is denoted by a bra, | † = |.Unitary operations, denoted by , are operations from quantum states to quantum states and their inverse is their adjoint.So, −1 = † = ⊺ .We use | to mean the result of applying to | .
Hermitian operators, denoted by , are operators that are self-adjoint, so = † .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 = .This representation is used in various parts of the paper, notably Sections 3.2 and 5.2.

Model Checking and Verification
Verifying software with model checking involves modelling the software through a formal representation.Then 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 = ( , 0 , , ) where • is a finite set of states; • 0 ⊆ is the set of initial states; • ⊆ × is a total transition relation, where for all ∈ , there exists ′ ∈ such that ( , ′ ) ∈ ; • : → 2 is a labelling function that gives the set of propositions ( ∈ ) 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 -calculus [75].The definition of CTL is given and briefly studied as it will be useful for understanding Section 3.3.
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, , and temporal operators, , that only exist bound with path quantifiers.These formulae are defined inductively by where ∈ is an atomic proposition in the model.The terms X ("next"), F ("eventually"), G ("always") and U ("until") denote basic temporal operations.The terms A (for all paths) and E (there exists a path) are path quantifiers.The semantics of the state and temporal operations described for a Kripke structure are given in Equation (1), where = ( 0 , 1 , . . . ) denotes a path.
Note that we can get the semantic formulas for A for all the temporal operators, , by replacing ∃ for ∀ (similarly replace ∃ ∈ for ∀ ∈ ) in the set definitions for the semantics.
Further, the operators F and G are obtained from U simply as F = true U and G = ¬F¬ , where 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 holds" and "for all paths ¬ always holds" are equivalent and specified in CTL by ¬EF = AG(¬ ).
Example 2.3.Figure 1 gives a model and the relative computation tree is given in Figure 2 with an example CTL operation.
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 (a Kripke structure) and (a temporal logic formula), then find all ∈ such that and models , the semantics of which is denoted by . Model checking has been explored in usage for verifying quantum programs against extensions of temporal logics.This can be seen in Section 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.Fig. 2. A computation tree for the automata given in Figure 1 that shows the CTL operation E( U ).The proposition holds in states 0 and 1 , but the proposition holds in state 2 .
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].

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 { } { }, where is a precondition, is a postcondition and 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).
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 (Satisfiability Modulo Theory) 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, one tool 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].

FORMAL QUANTUM VERIFICATION METHODS
This section aims to introduce 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.

antum Weakest Precondition
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 and a predicate postcondition , then the weakest precondition wp( ) ( ) is the precondition to such that for all preconditions with { } { }, then =⇒ wp( ) ( ).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 is a quantum program, where ( ) is the density matrix after applying program to density matrix ; the precondition and postcondition are each a quantum predicate, which is a Hermitian operator with positive eigenvalues upper bounded by 1; and a valid precondition must satisfy tr( ) ≤ tr( ( )) for all density matrices .We can write { } { } if , and follow the final inequality.Thus, the quantum weakest precondition wp( ) ( ) is defined such that for all valid preconditions , tr( ) ≤ tr(wp( ) ( ) )) for all density matrices .
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
antum 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 whilelanguage is extended to a quantum version and the Floyd-Hoare logic is amended to verify the extension.The quantum-while language is: The commands do the following operations: skip does nothing, := 0 initialises a qubit, ¯ := ¯ performs a unitary operation on a number of qubits, 1 ; 2 is composition of statements, measure [¯ ] : ¯ measures some qubits and performs a program from ¯ depending on the result and while [¯ ] = 1 do performs 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 { } { }, where is a program written in the quantum-while language and , are quantum predicates (as defined in Section 3.1).However, these predicates are additionally upper bounded by the identity operator, , and lower bounded by the zero operator 0. They are bounded in that for any predicate (used in QHL), then for all density matrices we have tr(0 ) ≤ tr( ) ≤ tr( ), thus 0 ≤ tr( ) ≤ 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 quantumwhile 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.Given : {0, 1} → {0, 1}, recall that Deutsch's algorithm determines the value of (0) ⊕ ( 1) with a single evaluation of .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: Here, is the single-qubit Hadamard gate and is the quantum oracle defined by the matrix Further, the measurement operators consist of measurements on the computational basis: 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 Post = (1 − (0) ⊕ ( 1)) |0 0| + ( (0) ⊕ ( 1)) |1 1|.This postcondition states that should be in the appropriate state depending on the value of (0) ⊕ (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 and so for our case, we have Further to this, the weakest precondition of skip is simply .(skip).= .Thus, we have that Following the rules for quantum weakest precondition of the Quantum Hoare Logic, the resulting Hoare triple for the entire program is { }Deutsch{Post}, where 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 and is the most general precondition we can have such that is the postcondition.

antum 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 -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 qB and variables is a tuple ( , ) where: , where is a quantum state of the qubits and is an assignment of variables to reals; • ⊆ × is a relation such that for any ( , ), there exists ( ′ , ′ ) such that (( , ), ( ′ , ′ )) ∈ .
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 quantum model checking, names alternate between Kripke structures and Markov chains.These structures vary in definition, but will loosely follow the structure of a classical Kripke structure where each state can perform some transitions and has some labels (propositions) associated with it.
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: We distinguish between logic on classical formulae, , and quantum formulae, , by using subscript and respectively.Further, we can abbreviate other connectives (¬, ∧, ∨, ⇔, ⊤) using ⊥ and ⇒.Classical formulae describes the set of qubits we wish to measure from using classical logic statements and qubit symbols qb from qB.Terms describe numerical expressions we can make with additional variables, constants, and functions for getting information about the quantum state.The term Re(|T ) denotes the real part of the amplitude of the quantum state from a subset of qubit symbols, ⊆ qB (similarly Im(|T ) for the complex part).The term ∫ denotes the probability that 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 [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: where is a dEQPL quantum formula.
The semantics of the QCTL given above for the temporal operators are similar to 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 as ( ∫ ) = 1.This is a dEQPL formula that states a classical formula 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]: The formula means "If Alice and Bob are in the same basis ( ( ⇔ )), then down all (quantum) paths the protocol has not ended (¬ ( ))) until it has ended ( ) and the generated key is equal to the value of the qubit used (( ) ⇔ ( ∫ = 1))".
Example 3.4.As a second example, consider Deutsch's algorithm.Denote = (0) ⊕ (1) as a classical bit.Further, use as a classical bit to say when the algorithm has performed the measurement operation and let denote the qubit used for the algorithm.Usage of is required to specify temporal behaviour for Deutsch's algorithm.We then have the following formula: The formula reads "for all (quantum) paths (A), the qubit is not measured (¬ ( )) until it is measured ( ) and the measured qubit gives us the correct result with certainty (( ) ⇔ ( ∫ = 1))".For the ℎ program given in Example 3.1 to satisfy this specification, it would need to initialise new qubits and at the start of the program and only modify after the rest of the program has been completed.Then the program could be modelled by a quantum Kripke structure and shown to satisfy .

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 (3) shows a path sum represented as a unitary operator.Note that x = ( 1 , . . ., ) is a collection of Boolean variables or constants (the input signature), is a (phase) Fig. 3.The Hadamard node (le ), green spider (middle) and red spider (right) with their matrix representation.The vertices can have more than one edge enter and exit them, but for simplicity we consider the case when only one edge enters a vertex.The spiders represent rotations on an axis, with the green spider rotating around the -axis and the red spider rotating around the -axis.Note that when = 0, the spiders are simply identity operators and when = the spiders represent the pauli-and pauli-gate respectively.
polynomial with inputs x and y, and : Z 2 × Z 2 → Z 2 is a multi-variable Boolean function (the output signature): Path sums are used to represent the semantics of Clifford+ circuits3 for a fixed .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+ 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.This usage is discussed in Section 5.4.
Example 3.5.The path sum representation of the Pauli gates are listed below:

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.
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 Fig. 4. A number of different rewrite rules [9].It is important to note that the colours of spiders can be swapped (so green spiders replace red spiders and vice versa).The summation of scalars is modulo 2 .Fig. 5. Derivation of two Hadamard gates being equivalent to the identity operation using the rules of the ZX-calculus.The derivation uses instances of the rewrite rules given in Figure 4. Firstly, the Hadamard gates are decomposed and then the red spiders are merged.Two of the spiders are swapped and then the green spiders are merged.This combined green spider can be removed by the identity rule and the final red spiders can be similarly merged and removed.An alternative way of proving the Hadamard gate is self-inverse can be found in [9].
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 ZXcalculus has several other applications 4 and a much more in-depth introduction can be found in [98].
Example 3.6.Here we first give a few rewrite rules from [9] in Figure 4. Whilst many different rewrite rules can be used, these are a few key ones for this example.
Using these rules, it is now possible to show optimisations of different circuits.For example, we can use the rewrite rules to show that applying two Hadamard gates to a circuit is the same as doing nothing (performing the identity operation).This derivation is given in Figure 5.

DESIGN OF VERIFICATION FRAMEWORKS AND QUANTUM PROGRAMMING
LANGUAGES In this section, several trade-offs and properties that are desired from a programming language for quantum verification are given.Whilst the trade-offs 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.

Trade-offs
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.
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 wellknown tool.
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.
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 × 10 37 states.
Executability and Separability.Another property to consider is what should be executable within the framework.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 proofs 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.With a verification framework, this becomes unnecessary.Thus, the separation between program and proof could be avoided if this approach is taken.

Limitations of antum 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 paper 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.

VERIFIABLE QUANTUM PROGRAMMING LANGUAGES
Here various quantum programming languages that can verify programs are discussed, highlighting their trade-offs, 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.

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 steps being sin 2 ((2 + 1) arcsin /2 ) (where is the number of qubits and is the number of marked elements).
Coq requires interaction from the user for theorem proving, but there is some automation when reducing matrices as seen in the _ function given in Figure 6 ( _ 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.
The key issue that may hinder SQIR is that circuits require 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.

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 := 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 Definition Program : base_ucom 2 := H 0; X 0; CNOT 0 1; X 0.  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.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.It also suffers the flaw of SQIR where programs require a predefined number of qubits and so ancillary qubits need to be defined at the start of computation.

Local Open Scope
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).

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. Firstly, matrices are defined to have a fixed size, whether through a variable 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 {|0 , |1 }).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].

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. 5al function deutsch_oracle (f: bitvec -> int)(n:int): circuit requires{1<=n} requires{(not (constant_bin f n)) -> balanced_bin f n} ensures{width result = n+1} ensures{forall x: bitvec.forall y: matrix complex.is_a_ket_l y 1 -> path_sem result (kronecker (bv_to_ket x) y) = kronecker (bv_to_ket x) (xor_qbits (ket 1 (f x)) y)} Fig. 9.The definition of a Deutsch-Jozsa oracle within the QBricks language [29].The require statements note the preconditions of the oracle (there is at least 1 qubit and if is not constant then it is balanced).The first ensures statement maintains the width of the oracle from input to output.The second ensures statement gives the usual definition of a quantum oracle ( | | = | | ( ) ⊕ ) from necessary preconditions.This function can be used later to prove properties about the Deutsch-Jozsa algorithm.Full documentation is available at https://github.com/Qbricks/qbricks.github.io.
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.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.

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 e [5,6], which allows quantum programmers to convert Quipper programs into Markov chains that can then be checked against qCTL properties.
Feynmann -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 . 6  6 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].

The Harrow-Hassidim-Lloyd Algorithm
The Harrow-Hassidim-Lloyd (HHL) [64] quantum algorithm solves linear systems of equations.Specifically, given a sparse, Hermitian matrix A and unit vector b, find x such that Ax = b. 7Using a matrix A as described above, the classical Conjugate-Gradient method can be used to find x in time ( log (1/ )), where is the size of A, is the condition number of A, denotes how sparse A is and is the error [91].In the case of the HHL algorithm, the actual output is an approximation of x using a measurement matrix M.This approximation can be found classically in ( poly(1/ )).The run time of HHL is (log ( ) 2 2 / 3 ) and returns the answer with high probability, providing an exponential speedup with respect to .The circuit for the HHL algorithm is given in Figure 10 and some Silq code is presented in Figure 11.
Here we give a brief explanation of how the HHL algorithm works.Let = 2 and the -length unit vector b be represented by the quantum state | = −1 =0 b | .This is loaded into a -qubit register using an operator .Hamiltonian simulation is used to represent A in a quantum phase estimation call.The unitary matrix in quantum phase estimation is − A for HHL and rotates | = around the eigenvectors of A, which are j and being their quantum state representation (similarly to | ).
Performing the quantum phase estimation ( ) call entangles the eigenvalue representations of A in a new quantum register with their associated eigenvectors.This gives a quantum state of the form .The eigenvalues are then embedded into the phase of the quantum state using controlled rotations on an ancillary qubit (using an operator ), leaving the quantum state as ( |0 + 1 |1 ).The quantum phase estimation routine is undone and the ancillary qubit is then measured.If it returns |0 , then the entire quantum state is dumped and the algorithm is run again.If it returns |1 , then the register that previously contained | now contains | = , a representation of x.This can then be measured after applying M, which changes the basis that | is measured in.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 b has a representation under the eigenvectors of 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.

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 , 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 (2 ), as one may visit almost every node in the tree. 8The 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 (poly( )) 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).
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.
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.Figure 14 shows a diagrammatic evolution of the quantum state for the first iteration through the colour oracles.
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.13.A section of Silq code [18] for the BWT Algorithm.The colours are looped over, represents the colour oracle function and _ represents the Hamiltonian simulation that takes places.The colour oracle is used twice to uncompute the ancillaries (full code available at https://github.com/marco-lewis/silq-binary-welded-trees).
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 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.

CONCLUSION
This paper 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.

Fig. 7 .
Fig. 7. Documentation of a simple program that implements a single CNOT gate and checks that the state |10 is transformed to |11 .The state |10 is represented by the predicate proj-10 = |10 10| and a similar predicate represents |11 .The lemmas qp-pre and qp-post prove that the predicates are valid, well-com-cnot confirms that the program is a valid and prog-partial-deduct proves the deduction.It would be possible to prove more general properties about CNOT, such as its effect on a general quantum state, but this requires experience with Isabelle and the QHLProver library.The full Isabelle theory file for this example is available in this repository: https://github.com/marco-lewis/QHLProverCNOT

Fig. 8 .
Fig. 8. Documentation of a simple CNOT program similar to that of QHLProver.The circuit performs a NOTgate on the first qubit and then the CNOT gate with the first qubit as control.The lemma circ-result uses the circuit definition and how the state evolves through each transition to show the resulting state.The full Isabelle theory file for this example is available in this repository: https://github.com/marco-lewis/IMD_CNOT.

Fig. 12 .
Fig. 12. Examples of a binary welded tree with 4 colours used to colour the edges (solid is red, dashed is greed, dot-dashed is blue and double-line is yellow).

Fig. 14 .
Fig.14.Example of the first iteration performing the main procedure through each colour oracle.Inside each node is the probability of that node being measured.A variable can be set to change the proportion of probability moved to a connected node.In this example, half of the probability from a node is shared with its neighbour.Changing the order the oracles are called in would change the evolution of the system.