Routing Anonymity and Identifiability of Noisy Quantum Hardware Ben Priestley
arXiv:2607.05281v1 [quant-ph] 6 Jul 2026
Centre for Quantum Information and Foundations, DAMTP, University of Cambridge Quantum Software Lab, School of Informatics, University of Edinburgh
Mina Doosti Quantum Software Lab, School of Informatics, University of Edinburgh
Abstract Present-day quantum computing—and its very likely future—is cloud-based, where a user submits a circuit to be executed by a service provider on proprietary backend hardware. While providers may wish to hide implementation details, scheduling choices, or even which physical device was used, noisy finite-shot outputs can carry backend-specific “fingerprints”—information imprinted in the classical output distribution that can reveal the backend identity. So far, such fingerprints have mostly been studied from a benchmarking perspective, for example as a tool for verification, with only limited attention to the privacy considerations for both users and providers in these scenarios. This work develops the first formal framework for backend identifiability and the corresponding privacy notion. We introduce an operational backend-identifiability game and use it to formalise routing anonymity as a security notion for quantum cloud services. We show that backend identifiability is exactly a hypothesis-testing problem and prove that, under passive i.i.d. access to a single backend, routing anonymity decays exponentially at the Chernoff rate. We also establish a utility-anonymity trade-off, imposing fundamental limits on how much backendspecific information can be removed from classical outputs without degrading their usefulness. In addition, we observe that, for noisy quantum hardware, identifying fingerprints are inherently an intermediate-depth phenomenon, and establish a formal depth principle using Pauli-transfermatrix tools. We complement the theory with experiments on a platform that reflects this real-life scenario, namely Amazon Braket on AWS, and run our experiments on different hardware platforms, including ion-trap and superconducting quantum processors. We observe 87–90% classification between superconducting backends and 96–100% classification across physical platforms, and find that identifiability can survive several natural forms of post-processing. Overall, these results establish routing anonymity as a distinct security requirement for quantum cloud computing, and provide a framework for quantifying and controlling the resulting utility-anonymity trade-off.
1
1
Introduction
The prospect of quantum computation has long transitioned from a theoretical novelty to an active practical pursuit of useful quantum advantages across many different domains: cryptography and cryptanalysis [1–9]; quantum chemistry and material science [10–16]; many-body, condensed matter, and high-energy physics [17–22], fundamental physics and quantum gravity [23–28], combinatorial optimisation [29–31], quantum machine learning [32–38], etc. Unlike the traditional (classical) computing paradigm of individual hardware ownership,1 large-scale quantum technologies are inevitably more suited to cloud-based access and “quantum-as-a-service (QaaS)” settings [39, 40]. In this paradigm, a user writes a description for a quantum circuit—implementing some task that she is interested in—and submits it to a service provider, who then goes off and executes this circuit for her on some quantum processing unit (QPU) and later returns a finite-shot sample output. As far as the user is concerned, cloud-based quantum computing offers an interface through which implementation details are abstracted to such an extent that the hardware itself can feel almost interchangeable. The same interface may expose superconducting, trapped-ion, neutral-atom, simulator backends, etc. often from several hardware providers all through a single high-level account [41, 42]. Physically, of course, the QPUs are decidedly not interchangeable to the service provider, who must care a great deal about each QPU’s calibration history, native gates, topology, crosstalk, readout asymmetries, compilation path, slowly drifting environment, and such related hardware-specific details. Consequently, in the noisy near-term of quantum computation, while the provider can feign some privacy about his choice of backend by hiding the label on his execution routing, it is has been observed that a ‘fingerprint’ specific to the chosen backend will be left in the classical outputs that he returns to the user [43–48]. There are two perspectives to take about this observation: (user-side) the user herself may want to be able to verify that her circuit has actually be run on the claimed backend hardware without having to rely on a promise alone; and (provider-side) the provider may want to keep secret his choices of backend routing, with some guarantee about the user’s inability to violate that privacy. In either case, the operational question is equivalent: How much route information is leaked by classical outputs of noisy quantum hardware? There is a large literature on security notions and verifiability for delegated quantum computation, but its dominant emphasis is on user-side privacy and correctness. Blind quantum computation and verifiable blind quantum computation protect the user’s input, output, and computation from an untrusted quantum server, while also allowing the user to detect incorrect behaviour in the verifiable variants [49–54]. Quantum verification protocols ask whether a classical verifier, or a verifier with limited quantum capabilities, can certify the correctness of a quantum computation performed by a quantum prover [55–62]. Related approaches based on remote or oblivious state preparation, quantum homomorphic encryption, and hardware-assisted secure execution similarly aim to protect the user’s computation or to certify the service outcome under additional cryptographic or hardware assumptions [63–66]. Indeed, the aforementioned observations about backend-specific fingerprints [43–48] largely take the user-side perspective in their experimental or analytical approaches. Even where provider-side concerns are discussed, the protected mathematical object is never formally given as the anonymity of the provider’s route [67]. 1
At least prior to the unprecedented demand for incredibly large-scale compute that has followed the development of large large language models; even in the classical computing world, remote/cloud services are becoming standard practice, and increasingly so!
2
In this work, we take the much-neglected provider-side perspective and ask the complementary security questions; namely, to what extent can the provider’s routing choice be anonymised without invalidating the promised service? It is worth emphasising the distinction of this question from the standard user-side perspective, in that we reverse the goals to describe mechanisms through which information is removed/obscured rather than inferred (either experimentally or by analysis of known/assumed noisy behaviour). Our novelty is then the proposal of a unified framework for backend identification which establishes, to our knowledge, the first formalisation of routing anonymity for cloud quantum computing, with supporting statements about how this privacy notion interacts with the information implicit in backend-specific noise fingerprints. We describe precisely how privacy depends jointly on the workload of circuits submitted by the user, the finite-shot resolution of the executing hardware, repeated access, any post-processing of the measured output, and the promised utility. In fact, for the latter, it is interesting in and of itself to describe his privacy as a property of the very service he intends to provide, which we note is explicitly missing from the current (user-side) literature. We propose a game of backend identifiability in which the provider secretly selects a backend, executes a user-chosen circuit from some agreed ensemble, and returns a classically post-processed outcome distribution from which the user should guess the backend label (Section 2.1). Our framework formalises how this game can be reduced exactly to a hypothesis testing question, and thus can be modeled statistically and sufficiently described as combinations of binary identification games (Section 2.2). Under a ‘persistent routing’ extension of the game (which assumes a fixed backend label and passive i.i.d. probing from the user), we can observe a similar reduction to see that anonymity decays at the Chernoff rate. Following this, we describe how post-processing can act as a suppression mechanism for route-specific noise, and then incorporate the promised utility of the service to place fundamental bounds on the degree of anonymity that can be obtained (Section 2.3). This is formalised as a utility-anonymity no-free-lunch theorem that informs the provider how he should mathematically model his utility with respect to the anonymity he desires. We can understand backend identifiability as existing in an ‘intermediate-depth’ window, and prove this characteristic of distinguishability in a Pauli-transfer-matrix model (Section 2.4). Finally, we also proposes a new channel (psuedo-)distance which is designed to act as a tight measure on backend distinguishabilty tailored to the user’s workload, which can then be used to provide some simple sufficient conditions on anonymity (Section 2.5). To support our framework and theoretical results, we design a series of experiments using Amazon Web Services (AWS) Braket, running on Rigetti’s Ankaa-3, IQM’s Garnet, and IonQ’s Aria-1, to demonstrate how finite-shot transcripts carry route-specific information in practice (Section 3). These are similar in spirit to existing fingerprinting work [43–48], although we distinguish our experimentation in a few key ways to better suit our unique perspective. Firstly, we design multiple suites of experiments to understand different mechanisms of distinguishability; our ‘depth-varied’ experiments use random circuits of varying depth—a far more challenging classification task than we see in most existing literature—while our ‘time-varied’ experiments more closely match those of other works. Secondly, we investigate multiple forms of post-processing on classical outcomes to understand the utility-based arguments of our work, and observe the intermediate-depth principle’s reaction over different transcript forms. Thirdly, we make an explicit and unique effort to visualise how noise fingerprints are learned by simple classifiers, giving an intuition for how separability between backends presents with respect to the workload circuits. We also offer some preliminary ideas and exploration of fingerprint forecasting, in which we indicate how we may be able to predict the evolution of the fingerprint in time, without explicit assumptions on the noise model.
3
1.1
Security Motivations and Applications
Motivations for a notion of ‘routing anonymity’ can be relatively direct, particularly in analogy to the classical case, in which routing metadata is ubiquitously security-sensitive. For example, mix networks and onion routing aim to hide communication paths, unlink senders and receivers, or limit what observers can infer from traffic metadata [68–70]. More generally, the provider may have any number of valid reasons for wanting to keep his routing choices hidden; e.g. keeping private his scheduling policies, confidentiality agreements that he may have with his hardware providers which require particular implementation details to be kept private from competing parties, preventing users from interpreting QPU loads or inferring times of increased stress, etc. If the reader would only humour us for a moment, we will now describe a select few toy examples in which a motivation for provider-side security is required immediately by design. The motivation need not be so contrived in typical cases of quantum cloud computation, as we note above, but it is nevertheless interesting to acknowledge specialised settings in which anonymity of routing choice is not only desirable but also application critical. The reader who is convinced about the relevance of routing anonymity can skip this section, humourlessly. In the following examples, we use the backend as a private verifier/oracle (Example 1) of a usersupplied object; as a private issuer whose signatures must be resistant to imitation (Example 2); and as a hidden target whose identity reveals vulnerabilities (Example 3). Example 1 (Quantum Lock-and-Key). Suppose that Alice guards a collection of locked vaults, whose contents are so valuable that even she herself is not allowed to know the secret keys which open them. She is only permitted to blindly try presented keys on the requested vault’s lock and observe whether it opens. We can model this setting as follows: define some quantum circuit to be the ‘key’ and associate with each vault a noisy quantum backend to be the ‘lock’, and allow Alice to observe the backend-specific output of the circuit prior to locking the vault. Now, when Bob comes along and presents a circuit and asks to open a particular vault, Alice routes it to the appropriate backend (assuming a private mapping between the vault and backend label), then passes the output through a decision function to decide whether the key fits the lock to open the vault. If Bob can collect decisions over an ensemble of candidate key circuits, then we better guarantee that such a collection does not provide him with enough information to identify the lock! Knowing the lock makes designing the key somewhat trivial. Hence, in this setting, the anonymity of Alice’s routing choice is critical and should be preserved, even after (finitely-)many attempts. The above quantum lock-and-key example can be viewed more generally as a private oracle whose hidden physical backend defines a decision rule, and whose output is then a backend-specific accept/reject bit. This specific set up is interesting not only for its overt requirements for routing anonymity, but also because it demonstrates a problem setting in which multiple layers of security are required. Notably, Alice is essentially asked to be a middle-woman routing a given key to a privately-known lock, thereby setting up privacy of the key for Bob (assuming that Alice cannot look at the given key, she herself is not able to unlock the vault, except maybe after many attempts) and privacy of the lock for Alice. A ‘double-blind’ security setting, if you like. Example 2 (Noisy-Issued Tokens). Suppose that Alice is a bank who secretly chooses one of several noisy backends to act as the active mint for each time period. To issue a token, she picks a public classical serial number s which generates a corresponding quantum circuit Cs , then executes Cs on the active backend and compresses its output into a short classical signature of the token to give to 4
a customer, Bob. To later verify a presented signature, Alice can use her privileged knowledge of the then-active backend to test whether its particular fingerprint is sufficiently present in the signature. Now suppose that Bob collects a genuine token and attempts to produce a counterfeit with a new serial number s′ . If he is able to identity the active mint from his valid signature, he can tailor his counterfeit to imitate its fingerprint on Cs′ . But, if the routing can be anonymised and he cannot infer the active mint, then his counterfeit signature will fail to carry the appropriate fingerprint and Alice will deem it to be invalid. Example 3 (Selective Probing). Suppose that Alice has a collection of N backends which are each very slow on a disjoint family of circuits, and we assume that they are arbitrarily fast at everything else. We might also assume that the union of these families covers all possible circuits; i.e. for any circuit that a user, Bob, can define, exactly one backend will execute it slowly. She allocates each backend to a distinct, non-overlapping time slot lasting (1/N )-th of the day, and routes any of Bob’s requests to the corresponding backend whenever he happens to ask. She waits until the end of the time slot before returning the classical outcome distributions of any executions within that slot. Assume that Bob knows exactly which family each backend is slow on, but that he is only allowed to prepare M ≪ N 2 probe circuits to be submitted whenever he likes. Upon receiving a response from the backend at the end of slot t, he can look at the output and design new probes for t + 1. His task is to overload the N -th and final backend such that it takes longer than its prescribed 1/N time and Alice cannot go home at the end of the day. In the above example, the condition on the number of probes that Bob can submit prevents him from brute-force finding a slow circuit for each backend in turn; instead he must learn something about how his probe was routed. After N − 1 time slots, he will ideally have guessed at which backend each slot had been assigned to, and be left at the final slot with an idea about which backend remains. He can then design a probe which he knows will be slow for this final backend, and if his guess is right, he will win the game and make Alice late for bed. Clearly then, it is in Alice’s interest to ensure that Bob cannot learn how she routes his requests in each slot. This example could be viewed in analogy to a distributed denial-of-service (DDoS) attack, tailored to the quantum cloud. As a final applications remark, note that here we are not interested in quantum process tomography, due to its demanding resource requirements. Full generic process tomography scales exponentially with system size, gate-set tomography is deliberately invasive, and scalable benchmarking or noise-learning methods make structural choices about which figures of merit to estimate [71–76]. System-level benchmarks, such as quantum volume and cycle benchmarking, compare hardware capabilities and error rates, but they are not designed from a security or privacy perspective [77–79]. In practice, a user trying to identify a backend may succeed using a much cheaper-to-extract notion.
1.2
Contributions
We summarise our primary contributions as follows: • Unified framework and formal privacy notion. We introduce the backend identifiability game and formally define routing anonymity as an operational privacy notion for hiding the service provider’s routing choices in the quantum cloud setting. We extend to a multi-round version of the game under assumed i.i.d. passive access and describe the rate of anonymity decay via Chernoff information. 5
• Statistical characterisation of backend identifiability. We reduce optimal backend identification to classical hypothesis testing over route-induced transcript laws, allowing us to use known statistical results to describe distinguishing bias via total variation distance, and give a sufficient condition for general routing anonymity with respect to constituent binary identification games. • Utility-anonymity trade-off. Formalising post-processing as the provider’s principal mechanism for suppressing route-specific information, we introduce ideas about utility preservation and prove a corresponding no-free-lunch result about its relationship with routing anonymity. • Workload-relative conditions for anonymity. We introduce a workload-probed channel (pseudo-)distance that measures average channel separation over the permitted probe workloads, yielding a tighter practical bound on routing anonymity than worst-case diamond norm. • Intermediate-depth principle. In a contractive Pauli-transfer-matrix model with a common mixing component and small backend-specific perturbations, we prove that route-specific noise signals initially accumulate in depth before rapidly decaying. This formalises an intermediatedepth window in which backend identification is most effective. • Experimental implementation. Using both random and structured workloads, several forms of transcript post-processing, and designing temporal experiments, we demonstrate our framework in practice to show that finite-shot outputs from real QPUs can expose substantial route information. Routing anonymity is then of considerable practical interest.
2
Framework Overview and Informal Theoretical Results
In this section, we present our theoretical framework intuitively and informally to give a technical overview of our main results. The formal framework is deferred to Appendix A, and precise statements and theoretical results to Appendix B.
2.1
A Game of Routing
We formalise the discussed security notion as a game played between a user with a desire to learn backends, and a provider with the converse desire to keep secret his routing choice. In this context, a ‘backend’ is any machinery with the capacity to execute a quantum circuit and return measurements thereof; e.g. a single quantum hardware device, a cohort of devices, a portion of a device, or some subset of registers, etc. We call the provider’s choice of backend a ‘routing’ —he selects a route through which to execute a given circuit. Generally, we use the terms ‘backend’ and ‘route’ interchangeably, but the rule of thumb is that the user wants to identify the backend that runs her computation while the provider wants to anonymise his route (to a backend) from the user. The interaction between these parties looks like the following: the user probes the provider with a workload (quantum) circuit of her choosing, and the provider then dutifully executes that circuit through a route of his choosing over a finite precision of shots to produce an empirical probability distribution, which is thus naturally associated with both the backend and circuit. Before handing this distribution back to the user, the provider passes it through some (deterministic) post-processing map in accordance with the service that he is promising to provide. The idea is that the user is not generally interested in the raw outcome sequences of her circuit, but rather some property; e.g. 6
expectations of observables, energies of Hamiltonians, ground states, correlator functions, decision outcomes, etc.; hence it is prudent on the provider’s part to reveal only the property of interest when his privacy is of concern. Following this interaction, the user has received a transcript in association with her known circuit and the unknown backend. The question—and the unmistakable fun in this game—is whether there is enough information accessible in the transcript to identify this backend. Other questions linger on the periphery; e.g. which ensemble of workload circuits makes accessible the most amount of usable information for this identification; which classes of post-processing maps are most hiding of information in the exposed transcript; what relationship does the capacity for identification have with the number of shots? All very interesting and natural aspects of the game. The security game can be described as follows: Game 1: Backend/Route Identification Game The user fixes a collection of n-qubit workload circuit ensembles {µd }d≥0 , and a finite number m ∈ N of shots. The provider fixes a known (deterministic) post-processing map ϕ : Y → X , and a prior π ∈ ∆(k) over a backend set D = {D1 , . . . , Dk }. The game is then played like: 1. Provider randomly samples a hidden route I ∼ π. 2. User chooses a circuit depth d ∈ N and randomly samples a depth-d workload circuit C ∼ µd , then submits it to the provider. 3. Provider executes C over m independent shots on backend DI , producing a raw empirical distribution p̂I,C ∈ ∆m ({0, 1}n ). 4. Provider produces a transcript X = ϕ(C, p̂I,C ), then returns it to the user. ˜ winning the game if I˜ = I. 5. User observes X and outputs a guess I,
We can extend this game into a more realistic setting by allowing the user to probe the backend over multiple rounds. There are many plausible constructions for a multi-round version of the above identification game; we consider a persistent routing setting in which the provider fixes a backend prior to playing, allows the user to submit multiple workload circuits to the backend, and then executes them in bulk before returning a lengthened transcript. Importantly, this is a passive and i.i.d. access model as opposed to e.g. adaptive access models that permit the user to sample her t-th circuit after having observed the (t − 1)-th transcript. This assumption simplifies our later observations, but is certainly worth developing in future work.
7
Game 2: Persistent Routing Game The backend/route identification game can be extended over T rounds as follows: 1. The user samples a sequence (C1 , . . . , CT ) of workload circuits, with each Ct ∼ µd sampled from the same depth-d ensemble, and submits them all the provider; 2. The provider then produces a sequence (X1 , . . . , XT ) of independent transcripts in turn by executing and post-processing each circuit on the same fixed backend DI ; and ˜ 3. The user finally receives the lengthened transcript and again guesses I. At this point, we can explicitly state the provider’s goal in this game. In contrast to the user’s goal of identifying the backend, the provider succeeds if the user cannot identify the backend with probability substantially higher than random guessing. A central contribution of this work is to show how routing anonymity emerges through different instantiations of the game and its parameters: which classes of post-processing maps, which circuit ensembles, how many shots, and related choices preserve anonymity of the route, and to what degree? First, we define the routing anonymity with respect to the described games as follows. (Informal Definition 6) Routing Anonymity We say that the (persistent) backend/route identification game has ε-anonymity if the user’s probability to guess the chosen route is bounded to within ε > 0 of the baseline random guess.
2.2
Identification and Anonymity via Statistical Tests
Any ensemble µ of workload circuits, executed on a particular backend Di over m shots, has an associated raw transcript law Qi (µ, m) by which the empirical distribution is sampled. After being passed through a post-processing map ϕ, we can instead refer to an induced transcript law Pi (µ, m, ϕ) = ϕ# Qi (µ, m). For brevity, write Qi and Pi when the context is clear. (Informal Theorem 1) Backend Identifiability Reduces to Hypothesis Testing Identifying the backend producing a received transcript X is exactly a statistical hypothesis test with hypotheses of the form Hi : X ∼ Pi ; accepting Hi implies guessing backend Di . In particular, between two equally-likely backends D1 and D2 , the probability p⋆s to correctly identify the backend is given by, p⋆s =
1 1 + TV(P1 , P2 ) , 2
where TV(·, ·) denotes the usual total variation (TV) distance between probability distributions. Our first result, Theorem 1, makes the conceptually simple connection between classical discrimination of probability distributions from an observed sample and the backend identifiability game, as a 8
security notion. The observation that bounds guessing probability is then imported immediately from the abundance of known classical literature in hypothesis testing, and allows us to obtain a clean relation for distinguishing bias βD1 ,D2 in the uniform-binary case as exactly the TV distance between the respective induced laws; i.e. we have βD1 ,D2 ≡ TV(P1 , P2 ) bias, beyond random guessing. Throughout this work, as in Theorem 1, it will be convenient to restrict our attention to this ‘uniformbinary’ setting between a pair of equally-likely backends. In fact, the following Proposition 1 should settle our nerves about this restriction by showing that pairwise indistinguishability is sufficient to obtain a global anonymity in the fully general setting among an entire set of finitely-many backends with arbitrary priors. Hence, we can reason about anonymity via simple pairwise arguments, at least in that we can provide sufficient conditions for the general setting. (Informal Proposition 1) Pairwise Indistinguishability is Sufficient The optimal probability to correctly identify among a set of finitely-many backends with arbitrary priors can be decomposed as a sum of pairwise distinguishing biases. In particular, the excess advantage Adv (i.e. beyond random guessing) in the fully general setting can be bounded by the worse-case distinguishing bias among pairs of backends; Adv ≤ max TV(Pi , Pj ) . i̸=j
Our second important result, Theorem 2, then extends Theorem 1 into the persistent routing setting to observe that, under our passive i.i.d. assumptions, the provider’s anonymity decays exponentially at the Chernoff rate between the relevant induced laws. (Informal Theorem 2) Persistent Routing Reduces to Chernoff Testing In the passive i.i.d. access model of persistent routing over T rounds, the hypotheses of Theorem 1 become Hi : (X1 , . . . , XT ) ∼ Pi⊗T , again with acceptance of Hi corresponding to guessing Di . Then, between two equally-likely backends D1 and D2 , the probability p⋆s (T ) to correctly identify the backend after T rounds satisfies, 1 − p⋆s (T ) = exp − T · DCh (P1 , P2 ) + o(T ) , where DCh (·, ·) denotes the usual Chernoff information between probability distributions.
2.3
Post-Processing and a Utility-Anonymity Trade-Off
A fundamental observation about post-processing is that there do not exist deterministic maps which can increase information. Generically speaking, the information contained within a raw observation, relevant to identifying the backend, tends to be stripped out by the post-processing. A natural corollary is then that raw observations are informally maximal for backend identifiability. This reveals a very useful role for post-processing: it is perhaps the principal means by which the provider can reduce the amount of information leaked to the user in the returned transcripts, and thus improve routing anonymity. But to what end? Trivially, choosing a deliberately destructive map, 9
say the constant map ϕ(· · · ) = 1, clearly reduces both the TV distance and Chernoff information to zero and so preserves anonymity indefinitely, but there is a clear lack of utility for the user. Unless the promised service is similarly trivial, this is an abuse of power by the provider in the backend/route identification game that abandons the practical motivation for such a setting. Introduce a utility map u representing the service that user is actually looking for. Subsequently, call the induced law Pi (. . . , u) under this map the utility law. Now, we can say that the provider’s post-processing map map ϕ exactly preserves the utility u if the user is able to decode the output of ϕ to obtain her desired utility output (as if from u). We should note that u is a quite abstract object, in much the same way that ϕ itself is left abstract, and indeed it may be natural to discuss entire classes of utility and post-processing maps, for example if the service is left reasonably flexible. We now have our third important result: that anonymity and utility have a trade-off relationship. (Informal Theorem 3) Utility-Preserving No-Free-Lunch If a deterministic post-processing map ϕ exactly preserves a utility u, then the induced laws Pi (. . . , ϕ) under ϕ must contain at least as much information as the utility laws Pi (. . . , u). Any further loss of information necessarily degrades the utility. Hence, if the provider is restricted to choose only utility-preserving ϕ, then he is only able to remove route-specific information which is extraneous to the promised utility u; he cannot remove route-specific information already encoded in the utility output under this restriction. To be clear, by ‘degrades the utility’, we mean that the transcript that the user ultimately receives contains only partial information about the property of interest represented by the utility, and hence she can only partially reconstruct the property. For example, the provider may only be providing an estimate about the ground-state energy, with an error proportional to the degree to which the utility is not preserved. We can further note approximate versions of utility preservation and the accompanying no-free-lunch argument of Theorem 3. The definitions of such versions should be delicately crafted with respect to the utility, as the approximation measure should yield a suitable interpretation for how the utility is degraded. We further discuss this problem and suggest solutions in Appendix B.2.
2.4
Identifiability as an Intermediate-Depth Phenomenon
An important observation can at this point be made about the role of depth d in the user’s workload circuits. In writing her ensemble of circuits µd with respect to a chosen depth d, we should ask what interval she should consider choosing d to lie in. We have the following intuition: • At very low depths (or in the noiseless setting), backends are indistinguishable because they implement very close to (or exactly) the same ideal circuit; and • Beyond some large depth, if noise becomes dominated by a common strongly mixing component, then any route-specific information is typically washed out, yielding indistinguishability; but • In the ‘intermediate-depth’ window, enough noise will have accumulated to reveal backendspecific structure, yet not so much that everything has collapsed to universal fixed-point behaviour—this is the interesting regime. 10
To formalise this idea, in Appendix C we record a pair of idealised theorems in a simplified Pauli-transfer/noisy-channel model. We prove these results by moving to Pauli-transfer-matrix (PTM) coordinates, wherein we can represent the effect of each noisy layer of a circuit as a linear contraction of the traceless Pauli components of the state. We assume that this contraction can be suitably decomposed into a common depolarising-like mixing component and a small backend-specific perturbation, then look at how the difference between two backends evolves with depth. (Informal Theorem 5 and 6) Identifiability Lies in Intermediate Depths
Expected Distinguishing Bias βDi ,Dj (d)
Denote circuit depth by d, and let λ, ε ∈ (0, 1) be noise-controlling parameters such that λ+ε < 1. At shallow depths, backend-specific noise fingerprints initially grow at a rate Ω(dλd−1 ). Over all depths, they are bounded by O(d(λ + ε)d−1 ), vanishing exponentially at large depths. Hence, optimal backend identifiability lies in some ‘intermediate’ depth window.
Theorem 5; O(d(λ + ε)d−1 ) Theorem 6; Ω(dλd−1 )
d0
Circuit Depth d
Figure 1: Illustration of the lower and upper bounds on expected distinguishing bias by circuit depth, as given by Theorem 5 and Theorem 6. The shaded region between the curves covers the perturbative range 0 ≤ d ≤ d0 of depths satisfying Theorem 6’s additional assumptions.
2.5
Noise Channel Bounds and Relation to Noise Characterisation
We observe (in Proposition 3) that the distinguishability of backends in our framework is governed by average-case notions of TV distance on only the states actually induced by the user’s probing protocol, rather than any worst-case separation of the full channels over all possible inputs and ancillas. The natural channel distance to consider is thus not e.g. diamond norm but instead a particular workload-probed channel (pseudo-)distance, denoted by δµ (·, ·) and defined with respect to the user’s chosen ensemble µ of workload circuits. Usefully, the following Proposition 4 shows that the workload-probed channel (pseudo-)distance serves as a tighter bound on the distinguishing bias than the worst-case diamond norm, and is thus 11
the more practical sufficient condition to target in the backend/route identification game. This is very much in agreement with recent ideas that these kinds of average-case distances are the more relevant quantities for NISQ-era applications than worst-case norms like diamond norm [80, 81]. (Informal Proposition 4) Between any two backends, Di and Dj , the workload-probed (pseudo-)distance δµ (Ni , Nj ) between their associated noisy channels, Ni and Nj , is a tighter bound than the diamond norm; βDi ,Dj (µ, m) ≤ mδµ (Ni , Nj ) ≤
m Ni − N j 2 ⋄
.
A natural corollary, following Proposition 4, is that two backends can be made indistinguishable by ensuring that the workload-probed (pseudo-)distance between their associated noisy channels is not too large (more immediately than ensuring the diamond norm is not too large). Recalling the pairwise argument of Proposition 1, we can then give a sufficient condition for routing anonymity in the fully general setting—that no two pair of backends among the full set have large workload-probed channel (pseudo-)distance. Again, this is an experimentally-achievable condition in the NISQ setting that often cannot be said about diamond norm.
3
Experimental Results
In this section, we complement the above framework with experimental evidence that real finite-shot output distributions, from QPUs offered via current quantum cloud services, carry learnable route information. It is not the intent to reconstruct device noise models, or perform full tomography, but rather to instantiate the backend identification game of Definition 1 (and its extension to persistent routing via Definition 2) in a realistic setting and exemplify the risk to privacy. Our experiments are run via AWS Braket on three QPUs: Rigetti’s Ankaa-3 and IQM’s Garnet, both superconducting devices, and IonQ’s Aria-1, an ion-trap device. We categorise classification into two qualitatively different settings: the like-type setting between the two superconducting devices, and the differing-type setting generally between Ankaa-3 and Garnet for consistency. We also categorise experiments into two families of (5-qubit) probe circuits: varying depth circuits composed of Haar-random two-qubit gates arranged in an alternating brickwork pattern (“depth-varied”); and fixed GHZ preparation circuits repeated in time (“time-varied”). Broadly speaking, the former understands the backend identification problem in the case where the user cannot rely on hand-picked outcomes to probe deliberately, while the latter understands the extension to persistent routing and the temporal structure of noise signals. For each circuit, we obtain a finite-shot histogram over computational-basis bitstrings. We then train simple classifiers on datasets of transcript representations (“features” in the machine learning lexicon), including both for raw outcomes and several forms of problem-independent post-processing. Comparing how classification performance depends on feature type gleans empirical insight into how route-specific information may survive post-processing. Detailed experimental setup and a full account of our results is given in Appendices D–G. We find that, in the depth-varied experiments, backend labels can be learned well above random guessing, with like-type test classification accuracies around 87–90%, and differing-type essentially 12