Forensics of Transpiled Quantum Circuits

Archisman Ghosh; Rupshali Roy; Swaroop Ghosh

REVIEW 3 major objections 5 minor 2 cited by

Forensics of Transpiled Quantum Circuits

T0 review · 3 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict Simple, useful idea for quantum cloud forensics, but Algorithm 1 systematically misses routing edges, so the 'complete accuracy' claim is wrong. read the letter →

arxiv 2412.18939 v1 pith:RM2CV3TS submitted 2024-12-25 cs.CR

Rupshali Roy , Archisman Ghosh , Swaroop Ghosh This is my paper · ORCID

classification cs.CR

keywords quantumcloudforensicstranspiledcircuitscouplingmapextractionbackendidentificationSWAPgateanalysishardwaretrustNISQdevicesreverseengineering

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

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

The 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.

The 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.

Bottom 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.

Referee Report

3 major / 5 minor

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.

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 (3)

[§III.A, Algorithm 1, lines 12–13; §III.B.1] 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.
[§III.B.4, Fig. 8 and Table I] 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.
[§III.B.3, Figs. 6–7] 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.

minor comments (5)

[Abstract and §III.B.4] 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.
[§I.C and Fig. 2] 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.
[Throughout, including §VII and Table II] 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).
[Table I and Table II] 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.
[§III.B.1] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the coupling-map extraction is an independent heuristic validated against externally published IBM coupling maps, and its acknowledged failures are correctness limitations, not circular reasoning.

full rationale

The paper's central derivation—recovering the hardware coupling map from transpiled circuits—is not circular. Algorithm 1 infers edges from direct two-qubit gates and excludes pairs involved in SWAP gates, using a stated assumption about compiler behavior (Section I.C and III.A). This is an empirical heuristic, not a quantity fitted to the target result. The derived maps are validated against externally published IBM coupling maps (e.g., IBM Kyiv, fake Cambridge, fake Singapore), so the validation target is independent of the algorithm's inputs. The paper contains self-citations ([2], [8], [6]) but none are load-bearing: they appear only as background on scheduling, resource allocation, and quantum PUF fingerprinting, not as justification for the coupling-map extraction or backend tracing. The acknowledged failure on loop topologies (Hamming distance 2, two edges used only by SWAPs) is a correctness limitation: Algorithm 1 systematically discards any pair that ever appeared in a SWAP, so routing-only edges are unrecoverable. This undermines the 'complete accuracy' claim for those cases but is not circularity—the method's output is not defined in terms of the ground truth, nor is any fitted parameter renamed as a prediction. No step in the derivation chain reduces to its own inputs by construction.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No free parameters are fitted. The method relies on three domain assumptions: standard Qiskit SWAP routing, availability of transpiled programs with physical qubit labels, and the accuracy of published coupling maps. These are behavioral assumptions about the compiler and the cloud service, not fitted constants.

assumptions (3)

domain assumption IBM/Qiskit transpiler inserts SWAP gates to route two-qubit gates between non-adjacent qubits and only emits direct two-qubit gates on physically connected qubits.
Section III.A: the heuristic assumes direct 2-qubit operations imply edges and SWAPs imply non-edges.
domain assumption The user is given the transpiled circuit with physical qubit labels.
Section I.C contributions: 'we assume that the user will submit the job and let the cloud vendor perform the transpilation ... and provide the computation results back along with the transpiled program.'
domain assumption Published coupling maps of the backends are accurate and serve as ground truth for matching.
Section III.B.4: subgraph matching uses the physical coupling map of the backends.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Forensics of Transpiled Quantum Circuits." pith.science (2026). https://pith.science/paper/RM2CV3TS

@misc{pith2026241218939,
  author       = {Pith},
  title        = {Pith review of: Forensics of Transpiled Quantum Circuits},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RM2CV3TS}},
  note         = {Machine review of arXiv:2412.18939}
}

read the original abstract

Many third-party cloud providers set up quantum hardware as a service that includes a wide range of qubit technologies and architectures to maximize performance at minimal cost. However, there is little visibility to where the execution of the circuit is taking place. This situation is similar to the classical cloud. The difference in the quantum scenario is that the success of the user program is highly reliant on the backend used. Besides, the third-party provider may be untrustworthy and execute the quantum circuits on less efficient and more error-prone hardware to maximize profit. Thus, gaining visibility on the backend from various aspects will be valuable. Effective forensics can have many applications including establishing trust in quantum cloud services. We introduce the problem of forensics in the domain of quantum computing. We trace the coupling map of the hardware where the transpilation of the circuit took place from the transpiled program. We perform experiments on various coupling topologies (linear, T-shaped, H-shaped, and loop) on IBM backends. We can derive the coupling map from the transpiled circuits with complete accuracy for almost every transpiled circuit we considered. We could correctly trace 97.33% of the programs to the correct backend.

Figures

Figures reproduced from arXiv: 2412.18939 by the authors.

**Figure 2.** (1) Coupling map for IBM Kyiv. The qubits in red are an example of nd [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 4.** Percentage of fake singapore backend extracted with respect to the number of transpiled circuits of different sizes. Using larger programs with 10 and 15 qubits, we can predict the full map with just 3 circuits. Further investigation was carried out by considering 10 randomly selected pools of transpiled circuits, each of random sizes, and analyzing how much of the coupling map can be predicted with a pool of 5, 10 … view at source ↗

Figures from the paper (4 more)

**Figure 5.** Figure 5: Percentage of backend predicted using pools of differently sized [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

**Figure 6.** Figure 6: Percentage of (a) fake singapore (b) fake cambridge backends extracted with the number of transpiled circuits of different sizes. Auto-assignment of logical-physical qubit mapping by the transpiler is used for these results [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

**Figure 7.** Figure 7: Percentage of (a) fake cambridge (b) fake singapore backends extracted using pools of differently sized transpiled circuits. Auto-assignment of logical-physical qubit mapping by the transpiler is used for these results. 0 20 40 60 80 100 60 90 120 150 180 Percentage #…

**Figure 8.** Figure 8: Percentage of circuit pool that is traced accurately to its backend, for [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Inverse-Transpilation: Reverse-Engineering Quantum Compiler Optimization Passes from Circuit Snapshots
quant-ph 2025-04 conditional novelty 6.0 of 10

A machine learning classifier can identify which of a fixed set of known circuit optimization passes were applied to a quantum circuit, with a best Hamming score of 0.68 on synthetic random circuits.
Forensics of Error Rates of Quantum Hardware
cs.CR 2025-05 conditional novelty 5.0 of 10

A frequency-based method ranks qubit link error rates from transpiled circuits, matching IBM's public calibration bins within two ranks for about 80% of links on two 127-qubit machines.

Reference graph

Works this paper leans on

11 extracted references · 10 canonical work pages · cited by 2 Pith papers

[1]

https://quantum-computing.ibm.com/services/resources/docs/resources /manage/systems/queue

work page
[3]

Detecting Fraudulent Services on Quantum Cloud Platforms via Dynamic Fingerprinting

Wu, Jindi, Tianjie Hu, and Qun Li. ”Detecting Fraudulent Services on Quantum Cloud Platforms via Dynamic Fingerprinting.” arXiv preprint arXiv:2408.11203 (2024)

work page Pith review arXiv 2024
[4]

”Q-ID: Lightweight Quantum Network Server Identification through Fingerprinting.” IEEE Network (2024)

Wu, Jindi, Tianjie Hu, and Qun Li. ”Q-ID: Lightweight Quantum Network Server Identification through Fingerprinting.” IEEE Network (2024)

work page 2024
[5]

Baker, Jakub Szefer, and Frederic T

Smith, Kaitlin N., Joshua Viszlai, Lennart Maximilian Seifert, Jonathan M. Baker, Jakub Szefer, and Frederic T. Chong. ”Fast fingerprinting of cloud-based nisq quantum computers.” In 2023 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pp. 1-12. IEEE, 2023

work page 2023
[6]

Phalak, A

K. Phalak, A. A. -. Saki, M. Alam, R. O. Topaloglu and S. Ghosh, ”Quantum PUF for Security and Trust in Quantum Computing,” in IEEE Journal on Emerging and Selected Topics in Circuits and Systems, vol. 11, no. 2, pp. 333-342, June 2021, doi: 10.1109/JETCAS.2021.3077024

arXiv 2021
[7]

Dueck, Rolf Drechsler: RevLib: An Online Resource for Reversible Functions and Reversible Circuits

Robert Wille, Daniel Große, Lisa Teuber, Gerhard W. Dueck, Rolf Drechsler: RevLib: An Online Resource for Reversible Functions and Reversible Circuits. Int’l Symp. on Multi-Valued Logic, 2008

work page 2008
[8]

Upadhyay, S., & Ghosh, S. (2024). SHARE: Secure Hardware Allocation and Resource Efficiency in Quantum Systems. https://arxiv.org/abs/2405.00863

work page Pith review arXiv 2024
[9]

M., & Venter, H

Karie, N. M., & Venter, H. S. (2015). Taxonomy of challenges for digital forensics. Journal of Forensic Sciences, 60(4), 885–893

work page 2015

Show all 11 references

[10]

Sayakkara, A., Le-Khac, N.-A., & Scanlon, M. (2019). A survey of elec- tromagnetic side-channel attacks and discussion on their case-progressing potential for digital forensics. Digital Investigation, 29, 43–54

2019
[11]

Rekhis, S., & Boudriga, N. (2011). Logic-based approach for digital forensic investigation in communication networks. Computers & Security, 30(6–7), 376–396

2011
[12]

Thongkamwitoon, T. (2014). Digital forensic techniques for the reverse engineering of image acquisition chains. Imperial College London

2014

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [1]

https://quantum-computing.ibm.com/services/resources/docs/resources /manage/systems/queue

work page

[2] [3]

Detecting Fraudulent Services on Quantum Cloud Platforms via Dynamic Fingerprinting

Wu, Jindi, Tianjie Hu, and Qun Li. ”Detecting Fraudulent Services on Quantum Cloud Platforms via Dynamic Fingerprinting.” arXiv preprint arXiv:2408.11203 (2024)

work page Pith review arXiv 2024

[3] [4]

”Q-ID: Lightweight Quantum Network Server Identification through Fingerprinting.” IEEE Network (2024)

Wu, Jindi, Tianjie Hu, and Qun Li. ”Q-ID: Lightweight Quantum Network Server Identification through Fingerprinting.” IEEE Network (2024)

work page 2024

[4] [5]

Baker, Jakub Szefer, and Frederic T

Smith, Kaitlin N., Joshua Viszlai, Lennart Maximilian Seifert, Jonathan M. Baker, Jakub Szefer, and Frederic T. Chong. ”Fast fingerprinting of cloud-based nisq quantum computers.” In 2023 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pp. 1-12. IEEE, 2023

work page 2023

[5] [6]

Phalak, A

K. Phalak, A. A. -. Saki, M. Alam, R. O. Topaloglu and S. Ghosh, ”Quantum PUF for Security and Trust in Quantum Computing,” in IEEE Journal on Emerging and Selected Topics in Circuits and Systems, vol. 11, no. 2, pp. 333-342, June 2021, doi: 10.1109/JETCAS.2021.3077024

arXiv 2021

[6] [7]

Dueck, Rolf Drechsler: RevLib: An Online Resource for Reversible Functions and Reversible Circuits

Robert Wille, Daniel Große, Lisa Teuber, Gerhard W. Dueck, Rolf Drechsler: RevLib: An Online Resource for Reversible Functions and Reversible Circuits. Int’l Symp. on Multi-Valued Logic, 2008

work page 2008

[7] [8]

Upadhyay, S., & Ghosh, S. (2024). SHARE: Secure Hardware Allocation and Resource Efficiency in Quantum Systems. https://arxiv.org/abs/2405.00863

work page Pith review arXiv 2024

[8] [9]

M., & Venter, H

Karie, N. M., & Venter, H. S. (2015). Taxonomy of challenges for digital forensics. Journal of Forensic Sciences, 60(4), 885–893

work page 2015