{"id":"c84e3261-7431-4aa0-adcc-6adf7b5dae96","arxiv_id":"2412.18939","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"From transpiled quantum circuits, the paper recovers the hardware coupling map and identifies the backend used for transpilation with up to 97.33% accuracy.","lead":"This paper shows that the transpiled version of a quantum circuit, the code a cloud provider returns after compilation, leaks the hardware layout it was compiled for. That makes it possible to audit which backend actually served a job, with reported success rates up to 97.33%.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Algorithm 1 systematically discards routing edges: it treats any pair appearing in a SWAP as non-connected, so edges used only for SWAP routing can never be recovered, contradicting the 'complete accuracy' claim.","rationale":"The entire forensic pipeline—coupling-map extraction, whole-backend assembly, and backend identification—depends on Algorithm 1 correctly distinguishing edges from non-edges. The swap-history exclusion rule is not a heuristic detail; it inverts the physical meaning of a SWAP. A SWAP requires connectivity, so every pair in a SWAP is an edge. The rule removes exactly those pairs from the derived map. The loop-topology result is the visible symptom. The threat-model limitation (user must receive transpiled program) is a scope boundary explicitly stated; the algorithmic issue is an internal correctness flaw that affects the reported results even within that scope. A simple experiment—a single CNOT across a linear chain—should yield an empty map, demonstrating the method fails to recover the topology it was given. Because the paper's headline claims rely on this algorithm, the manuscript needs a fundamental correction, not just additional caveats. The reader's verdict of CONDITIONAL identified the loop-topology failure, but attributed it to SWAP-recognition limits; the deeper cause is the algorithm's exclusion of SWAP pairs, which makes the failure systematic. This is the single most load-bearing concern because it undermines the core mechanism, not merely the application scope. The paper could potentially be revised by changing Algorithm 1 to add SWAP pairs as edges, but as written the central claim is not supported.","tokens_in":9627,"tokens_out":8687,"duration_ms":79265,"concrete_test":"Construct a 5-qubit linear coupling map in Qiskit, transpile a circuit consisting of a single CNOT between qubit 0 and qubit 4 (plus single-qubit gates as needed), and run Algorithm 1 on the resulting transpiled circuit. The only two-qubit operations will be routing SWAPs (or their CNOT decompositions) along the path; every pair involved will be marked in the swap history, so the derived map will contain no edges, even though the transpiled circuit fully pins down the linear topology. If the derived map is empty or misses the routing edges, the SWAP-exclusion rule is the cause.","verdict_should_be":"REJECT","load_bearing_attack":"Algorithm 1 (Section III.A) maintains a swap history matrix and, at lines 12-13, refuses to add a qubit pair to the derived coupling map if that pair was ever involved in a SWAP. The inference is inverted: a SWAP between two physical qubits is itself a two-qubit operation that requires a physical edge connecting them (or, after decomposition, a sequence of CNOTs on such edges). Marking a pair as 'not an edge' because a SWAP used it guarantees that any hardware edge used exclusively for routing is invisible to the method. The loop-topology failure reported in Section III.B.1 (Hamming distance 2, two edges used only by SWAPs) is not an exceptional edge case but the necessary output of this rule. Consequently, the claim of 'complete accuracy' for coupling-map recovery is false for any transpiled program in which some edge of the target subgraph appears only in routing SWAPs; the paper provides no argument that such edges are avoided.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces the problem of forensic analysis of transpiled quantum circuits: given a transpiled circuit (with physical qubit labels) returned by a cloud service, the authors propose to recover the hardware coupling map and to identify which backend in a pool was used. The method (Algorithm 1) scans a transpiled circuit for two-qubit gates, treats direct two-qubit gates as evidence of a physical edge, and discards any qubit pair that ever appears in a SWAP gate, on the rationale that SWAPs indicate non-connectivity. The authors test the approach on several IBM topologies (linear, T-shaped, H-shaped, loop) and report exact recovery for most topologies, with a Hamming distance of 2 for loop topologies. They then combine multiple transpiled circuits to reconstruct full backend coupling maps, including a so-called auto-assignment scenario where the transpiler chooses the logical-to-physical mapping, and finally report 97.33% success in tracing circuits to the correct backend in a pool of three backends. The paper claims this is the first forensics framework of its kind for quantum cloud. The central technical claim is that transpiled programs expose enough structural information to recover hardware coupling maps and identify backends, but the proposed SWAP-exclusion rule systematically loses routing edges, and the backend-tracing statistics are reported without error bars or code.","tokens_in":9799,"tokens_out":3422,"duration_ms":34215,"significance":"If the results held as stated, the paper would open a useful forensic direction for quantum cloud services, complementing prior hardware-fingerprinting work that uses hand-crafted probing circuits. The paper's strengths are that the method is heuristic and has no fitted parameters, the derived maps are compared to externally published IBM coupling maps, and the authors test multiple real and fake IBM backends with circuits of varying sizes. The forensic angle (determining, after the fact, which hardware a supplied transpiled program was compiled for) is genuinely novel relative to the fingerprinting literature that requires sending specifically designed probe circuits. However, the significance is weakened by two load-bearing issues: Algorithm 1 cannot recover edges that are used only for routing SWAPs, which is not an exceptional case but a structural consequence of the algorithm, and the headline backend-tracing accuracy of 97.33% is based on a single random experiment without error bars or released code.","major_comments":[{"comment":"The algorithm's core rule is logically inverted for routing edges. At lines 12–13, any qubit pair that appears in a SWAP gate is permanently marked as 'not an edge' in the derived coupling map. But a SWAP operation between two physical qubits itself requires connectivity between them, either directly or along a path of physical edges; a SWAP that is inserted for routing is therefore executed on actual hardware edges. Consequently, if an edge of the target subgraph is used only by SWAPs and never by a direct CNOT in the transpiled circuit, that edge can never be recovered by Algorithm 1. This is not a rare or accidental failure: the loop-topology result in §III.B.1 (Hamming distance 2, with two supplied edges undetected) is exactly the necessary output of this rule for circuits where some edge appears only in routing SWAPs. The paper even states this result but then concludes 'this shows that we are successful at correctly deriving the coupling map,' which is inconsistent with the abstract's 'complete accuracy' claim. A correct method must treat a SWAP as evidence of a path of edges, not as evidence of non-connectivity; for example, one could decompose SWAPs into the underlying CNOT/ECH sequences or use the distance information encoded in multi-SWAP routing patterns. As written, the completeness claim is not supported for any circuit family that routes through otherwise-unused edges.","section":"§III.A, Algorithm 1, lines 12–13; §III.B.1"},{"comment":"The headline result '97.33% correctly traced' is presented without statistical support. The pools of 60 to 180 circuits are said to be randomly selected, and the authors acknowledge that the percentage varies with the pool ('the pool of 60 and 90 circuits are completely different'), yet only a single percentage per pool size is plotted and reported. There are no error bars, no confidence intervals, and no multiple independent trials. Because the pool composition is random, the reported maximum of 97.33% could be an artifact of one favorable draw. The paper should report the mean and standard deviation over repeated random pools, or at least provide the breakdown per trial. Without this, the backend-tracing claim is not quantitatively established. The authors should also indicate whether the 97.33% figure is the maximum or the mean across pools, and ideally release the circuit pools to make the experiment reproducible.","section":"§III.B.4, Fig. 8 and Table I"},{"comment":"The auto-assignment scenario is simulated by appending the user program to a larger 'dummy' program and transpiling the combined circuit as a single job. The authors correctly note that Qiskit's transpiler does not support multi-programming, but the resulting combined-circuit mapping is not equivalent to a multi-tenant scheduler that maps multiple independent jobs onto disjoint qubit subsets while optimizing each job separately. For instance, the transpiler may route the user's logical qubits around the dummy program's fixed layout, producing SWAP patterns and physical-qubit assignments that would not arise in a real multi-programming environment. The claim that 'as little as three 15-qubit circuits' suffice to extract the entire backend under auto-assignment is therefore not validated for actual multi-tenant cloud execution. To support this claim, the authors would need a more faithful model of multi-job allocation (e.g., dedicating a contiguous subgraph per job before transpilation, or using a scheduler that mimics Qiskit's selection criteria for each job separately). This issue affects the generality of the auto-assignment results.","section":"§III.B.3, Figs. 6–7"}],"minor_comments":[{"comment":"The phrase 'complete accuracy for almost every transpiled circuit' is internally vague: if the loop-topology failures are excluded, the paper should state the exclusion explicitly in the abstract. As written, the abstract overclaims relative to the Hamming-distance-2 result in the body.","section":"Abstract and §III.B.4"},{"comment":"The assumption that the cloud provider returns the transpiled program alongside the measurement results is stated clearly in §I.C, but the paper does not discuss the common case where a provider returns only measurement outcomes (e.g., through a job-result API without circuit metadata). A short paragraph on this limitation's scope would help position the contribution.","section":"§I.C and Fig. 2"},{"comment":"There are several presentation issues: 'archotecture' should be 'architecture' in §I.C; the text repeatedly renders 'SWAP' with a spurious space as 'SW AP'; and reference [8] duplicates reference [2] (the same SHARE paper appears twice).","section":"Throughout, including §VII and Table II"},{"comment":"Table II reports different times under 'Backend (for auto-assignment)' and 'Time (in s)' but the caption 'Time needed for assembling the backend map' does not clarify which column corresponds to which experiment. Please label the columns consistently with the subsections in §III.B.2–§III.B.3.","section":"Table I and Table II"},{"comment":"The paper does not provide the transpiled circuits or the code for Algorithm 1, which makes it difficult to verify the extraction results or to reproduce the reported timings. A code release or a detailed pseudocode with the full SWAP-detection cases (especially the CNOT-sequence SWAP case) would materially improve reproducibility.","section":"§III.B.1"}],"recommendation":"major_revision","confidential_remarks":"The paper addresses a timely and underexplored problem, and the authors are honest in reporting the loop-topology Hamming-distance failure. However, the central completeness claim is contradicted by the algorithm's own SWAP-exclusion rule, and this is not a surface-level issue: it changes the inference from 'edges used by SWAPs' to 'non-edges,' which is the opposite of what a correct physical model would imply. The backend-tracing accuracy also needs proper statistical treatment. I would support a major revision that reworks Algorithm 1 to recover routing edges from SWAP sequences, adds repeated-trial statistics for Fig. 8, and retracts or carefully qualifies the 'complete accuracy' claim. If the authors can demonstrate improved recovery on loop topologies after this fix, the paper would be a solid contribution to the security/forensics literature on quantum cloud. As it stands, the manuscript's headline claims outrun its evidence."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis paper introduces a new forensic angle for quantum cloud security: recovering the hardware coupling map from the transpiled program the provider returns, then matching it against published backend maps to trace execution. The core observation is simple but useful — direct two-qubit gates imply physical edges, and physical qubit labels leak the mapping — and to my knowledge it hasn't been framed as forensics on real programs before. The experiments on Qiskit with several IBM fake backends and topologies show the pipeline works mechanically: topology extraction is sub-second, and backend tracing reaches 97.33% on pools of 60–180 circuits. I also credit the authors for reporting the loop topology failures instead of hiding them.\n\nThe stress-test note is right, and it lands on a load-bearing flaw. Algorithm 1 marks a qubit pair as \"not an edge\" if it ever appears in a SWAP. That is the wrong sign: a SWAP between two physical qubits is implemented with CNOTs on the physical edge connecting them, so any hardware edge used only for routing SWAPs is systematically invisible to the method. The loop topology misses (Hamming distance 2) are not an exceptional case; they are the necessary output of this rule. Consequently the claim of \"complete accuracy for almost every transpiled circuit\" is false in general. The method is better described as recovering a subset of the coupling map — a lower bound on edges — and the paper should say that. The fix is straightforward: treat direct two-qubit gates (excluding SWAP decompositions) as positive evidence, and stop treating SWAPs as negative evidence.\n\nThe other soft spots are real but less severe. The threat model assumes the provider returns the transpiled program with physical qubit labels; if only measurement outcomes come back, the method cannot start — the authors state this assumption explicitly, but it sharply limits practical reach. No code or data is released, and the 97.33% backend-tracing figure has no error bars or per-pool breakdown beyond a sentence. The related-work discussion and the distinction between forensics and fingerprinting are sound.\n\nBottom line: this is a useful proof-of-concept for a real trust gap, and it deserves a serious referee. I would send it out, but with a request to fix the algorithm, soften the completeness claim, and release the artifact. I'd cite it as a first step in quantum cloud forensics, though with a caveat about the routing-edge blind spot.","headline":"Simple, useful idea for quantum cloud forensics, but Algorithm 1 systematically misses routing edges, so the 'complete accuracy' claim is wrong.","tokens_in":10323,"tokens_out":3383,"would_cite":true,"duration_ms":29832,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Transpiled quantum circuits contain enough structural traces to recover the coupling map of the hardware that compiled them, and to identify the backend in a pool with 97.33% accuracy.","keywords":["quantum cloud forensics","transpiled circuits","coupling map extraction","backend identification","SWAP gate analysis","hardware trust","NISQ devices","reverse engineering"],"falsifier":"If a transpiler returns a program in which physical qubit labels are remapped or in which routing is done without inserting SWAP-like gates, the swap-history heuristic should fail; running the algorithm on such a circuit and finding a nonzero Hamming distance between derived and actual coupling maps would refute the completeness claim.","tokens_in":9429,"feed_emoji":"🔍","tokens_out":6699,"duration_ms":57819,"temperature":0.7,"pith_summary":"Quantum cloud providers often return the transpiled version of a submitted circuit along with measurement outcomes, and this paper argues that this returned program leaks the hardware that compiled it. By reading physical qubit labels and the placement of SWAP gates in the transpiled circuit, the authors recover the coupling map (the connectivity graph) of the backend. Across linear, T-shaped, H-shaped, and loop topologies, the recovered map matched the supplied map for almost every circuit, with loop topologies missing two edges in the tested cases. Combining a few transpiled circuits of different sizes reconstructs the whole backend coupling map, and matching derived subgraphs against a pool of backends correctly traced 97.33% of programs to the backend that transpiled them. If correct, this gives users a way to audit whether a third-party cloud actually ran their job on the requested hardware.","feed_headline":"Transpiled circuits spill the quantum backend that ran them","feed_subtitle":"Users can audit cloud claims because physical qubit labels and SWAP gates expose the coupling map.","key_machinery":"The central mechanism is the swap-history matrix, an $n\\times n$ boolean table that records every qubit pair that has appeared as the operand of a SWAP-like gate. The algorithm uses it to distinguish genuine physical connections (two-qubit gates between pairs never swapped) from routed connections (pairs connected only through inserted SWAP operations). Combining derived subgraphs by edge-union reconstructs the whole backend graph.","core_discovery":"The paper's central claim is that transpilation leaves a recoverable signature: the returned program contains explicit physical qubit numbers, direct two-qubit gates that can only occur between physically connected qubits, and SWAP gates that signal non-adjacent interactions. The authors propose a heuristic that maintains a swap-history matrix recording which qubit pairs have been involved in a SWAP-like operation, then treats every two-qubit gate on an un-swapped pair as evidence of a physical edge. Iterating over the instructions yields the coupling subgraph used for that program; taking the union of subgraphs from multiple programs recovers the backend's full coupling map. In their experiments, the extracted map matched the supplied topology for almost every circuit, except that loop topologies for 15- and 20-qubit circuits yielded two undetected edges. With three 15-qubit circuits they reconstructed the entire tested backend's coupling map, and in a mixed pool of three backends they correctly identified the transpiling backend for 97.33% of programs.","pith_inferences":["The same leakage could be exploited by a malicious cloud to misattribute execution, but also by an auditor to enforce service-level agreements; adversarial transpilers could scrub physical qubit labels, so the forensics would need to be paired with measurement-outcome side channels.","The method's dependence on explicit SWAP gates suggests a natural stress test: compilers that route via phase-based or teleportation-style methods, or that cancel SWAPs during optimization, would reduce the recoverable signal.","Combining the recovered coupling map with gate-error data could let a user estimate which sub-region of a backend actually executed the job, extending the paper's identification from backend to subgraph.","Since the extraction runs in milliseconds, it could be deployed as an on-the-fly audit service inside the quantum cloud workflow."],"forward_implications":["A user who receives a transpiled program can check which coupling map the compiler targeted, without trusting the vendor's word.","Backend identification can be done from pools as small as 60 transpiled circuits, with near-total accuracy; full map recovery needs only three large circuits.","Because the method uses ordinary user programs rather than crafted probes, it works retroactively on historically returned transpiled circuits.","In multi-tenant settings, the auto-assignment results show that even when the transpiler chooses physical qubits, the backend remains identifiable from a handful of programs."],"supporting_citations":[{"why":"Supplies the benchmark circuits used as the user programs in the coupling-map extraction experiments.","marker":"[7]"},{"why":"Prior work on dynamic fingerprinting of quantum cloud platforms; the paper uses it to show existing identification methods rely on crafted probing circuits rather than real user programs.","marker":"[3]"},{"why":"Prior server-identification method based on noise-level performance gaps; used to delineate fingerprinting from forensics.","marker":"[4]"},{"why":"Prior work using unique qubit frequencies to identify quantum computers; establishes the fingerprinting baseline the paper distinguishes from its transpiled-program forensics.","marker":"[5]"},{"why":"Proposes quantum physically unclonable functions for hardware authentication; the paper contrasts these crafted-circuit fingerprints with forensics on functional programs.","marker":"[6]"},{"why":"Motivates the untrusted multi-tenant allocation scenario and the need for visibility into hardware allocation decisions that the paper's forensics addresses.","marker":"[2]"}],"fun_headline_variants":["Quantum circuit forensics exposes the hardware used","Coupling map reveals which quantum backend ran your circuit","Transpiled quantum circuits leak their execution backend","New forensics technique identifies quantum cloud backend from circuit traces","How to detect which quantum hardware ran your transpiled program"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole method rests on the user receiving the transpiled program with physical qubit labels intact, and on the transpiler inserting recognizable SWAP gates for every non-adjacent two-qubit interaction.","fun_headline_variants_meta":{"raw":{"variants":["Quantum circuit forensics exposes the hardware used","Coupling map reveals which quantum backend ran your circuit","Transpiled quantum circuits leak their execution backend","New forensics technique identifies quantum cloud backend from circuit traces","How to detect which quantum hardware ran your transpiled program"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000442,"raw_usage":{"total_tokens":2243,"prompt_tokens":950,"completion_tokens":1293,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":566,"completion_tokens_details":{"reasoning_tokens":1218}},"tokens_in":566,"tokens_out":1293,"duration_ms":7300,"temperature":1.0,"reasoning_tokens":1218,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T04:18:21.432228+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"If a transpiler returns a program in which physical qubit labels are remapped or in which routing is done without inserting SWAP-like gates, the swap-history heuristic should fail; running the algorithm on such a circuit and finding a nonzero Hamming distance between derived and actual coupling maps would refute the completeness claim.","supporting_citations":[{"cited_title":"Dueck, Rolf Drechsler: RevLib: An Online Resource for Reversible Functions and Reversible Circuits","cited_arxiv_id":null,"evidence_quote":"Supplies the benchmark circuits used as the user programs in the coupling-map extraction experiments."},{"cited_title":"Detecting Fraudulent Services on Quantum Cloud Platforms via Dynamic Fingerprinting","cited_arxiv_id":"2408.11203","evidence_quote":"Prior work on dynamic fingerprinting of quantum cloud platforms; the paper uses it to show existing identification methods rely on crafted probing circuits rather than real user programs."},{"cited_title":"”Q-ID: Lightweight Quantum Network Server Identification through Fingerprinting.” IEEE Network (2024)","cited_arxiv_id":null,"evidence_quote":"Prior server-identification method based on noise-level performance gaps; used to delineate fingerprinting from forensics."},{"cited_title":"Baker, Jakub Szefer, and Frederic T","cited_arxiv_id":null,"evidence_quote":"Prior work using unique qubit frequencies to identify quantum computers; establishes the fingerprinting baseline the paper distinguishes from its transpiled-program forensics."}],"review_version":1}