Skip to content

Classical solution of peaked_circuit_P12_Hqap_98x2457: de-obfuscation + exact TN contraction (182 s, one CPU VM) #252

Open

Description

@dylanneve1

Name

qsimlab_deobfuscation_tn_P12_98x2457

Circuit

peaked_circuit_P12_Hqap_98x2457

Value

100

Method

Structural de-obfuscation (identity blocks -> wire permutation) + exact tensor-network contraction of the core

Method proof

Code, write-up and log

Result

Recovered peak (qubit 0 = leftmost character):

10100011110010100111000100011100110001011111011100111001010110101011001001000000101000100000111100

This equals, bit for bit, the Quantinuum Helios-1 peak in #247 that was accepted by the BlueQubit Peaked Portal. The solver does not read any target; the comparison was made only afterwards.

Method

  1. Parse the circuit into its atomic 2-qubit units (u a; u b; cz a,b; u a; u b).
  2. Fingerprint the single-qubit rotation between consecutive CZs on every wire (SU(2), continuous angles). Gates untouched by the obfuscation reappear in the inverse half as exact inverses; unique exact inverse pairs locate the hidden identity blocks (two nested inner blocks inside an outer U ▷ U†) and give, per inner block, a consistent wire involution (a layer of 49 SWAPs absorbed into the seam).
  3. With the inner blocks replaced by their permutations, the outer halves mirror each other under the identity map, so the whole middle of the circuit is a wire permutation, which is free re-wiring in a tensor network.
  4. What remains is the shallow trained core R ▷ P (~280 two-qubit gates, gate-network treewidth ~15). All single-qubit marginals are contracted exactly with quimb/cotengra; the peak is their argmax and its probability is an exact amplitude.
  5. Obfuscation patches can straddle the R / middle boundary and leave a few marginals weak, so frontier gates are moved across the boundary. The v2 solver does this deterministically: it adds whichever frontier gate maximises the exact peak probability of the core, with a fixed tie order. On P12 it moves gates 60 + 64 (core peak probability 0.005 -> 0.237). The original v1 solver iterated over a Python set, so its choice depended on the hash seed: it accepted 60 + 108 (p = 0.205) or 60 + 64 (p = 0.237). The recovered peak is the same in every case.

The peak probability quoted is that of the de-obfuscated core, not of the obfuscated 98-qubit circuit. The method exploits the published construction (inserted identity blocks), in the same spirit as the MPO + unswapping attack on P9.

Caveats

  • The boundary-repair step (step 5) was added after a first P12 run missed by 4 bits, so the method was not designed fully blind. No target string is read at runtime.
  • "Exact" applies to the de-obfuscated core only. The quoted peak probability is the core's, not the obfuscated 98-qubit circuit's.
  • The classical runtime below is the v1 solver on the VM listed.
  • Corrections and discussion: see the comments below.

Quantum runtime (seconds)

Classical runtime (seconds)

182

Compute resources (quantum)

Compute resources (classical)

Intel Xeon Gold 6548Y+ VM (16 vCPU, shared), single Python process

Notes

Core-only exact TN; peak = Helios-1 #247; 182 s CPU

Authors

Dylan Neve, Claude (Anthropic)

Institutions

qsim-lab

Activity

  1. dylanneve1 commented on Oct 5, 2026

    @dylanneve1
    Author

    Reproducibility update: the solver now ships with a one-command reproduction script that creates a fresh virtual environment from pinned requirements, downloads both circuits from this repository at a pinned commit, verifies their sha256, runs the solver and checks the recovered peaks.

    git clone https://github.com/dylanneve1/qsim-lab && qsim-lab/research/data/peaked-circuits/reproduce.sh

    Script: https://github.com/dylanneve1/qsim-lab/blob/c711ae1/research/data/peaked-circuits/reproduce.sh
    Verified from scratch on 5 Oct 2026: P11 in 98.5 s, P12 in 166.2 s on one CPU VM; both peaks match. The solver is deterministic and never reads a target bitstring.

  2. MonitSharma commented on Oct 5, 2026

    @MonitSharma

    Hi @dylanneve1 , great work on both the P11 and P12 circuits. The approach is very interesting, especially how much of the apparent circuit complexity can be removed before the tensor-network contraction. Its really nice approach to uncovering the structure behind these instances.

    I went through your solver method, In the boundary-repair step, is it necessary to calculate all marginals again for each candidate gate? If a local change does not change the backward causal cone of a qubit, could the solver reuse the exact marginal for that qubit? Could it also reuse a compatible contraction path?
    This could reduce the run time without changing the contraction result.significantly, a few of these improvements can take your runtime to 17-20s for P11 and 27-30s for P12, depending on the machine you used, and will make a better submission.

    I am getting 17.1s and 27.9s for P11 and P12 respectively on a MacBook M3 Pro 36GiB. See here

    Also a very closely conceptually related paper for this: Verifiable Quantum Advantage and Computation
    via Quantum Circuit Obfuscation
    , it tells us what a principled successor to the broken heuristic obfuscation would need to look like.

  3. dylanneve1 commented on Oct 7, 2026

    @dylanneve1
    Author

    Thanks, @MonitSharma. Your review was careful, and it improved the method.

    Caching. You're right on both counts. A boundary move only changes marginals whose backward causal cone contains the moved gate, and the contraction path can be reused when the cone geometry is unchanged. We measured both solvers on the same VM (quimb 1.11.2 / cotengra 0.8.2): ours took 111.4 s / 212.6 s and yours 35.6 s / 57.9 s, a 3.1–3.7× gap from caching and the selection rule alone. Our v2 solver now uses your cached evaluator, credited under its MIT licence.

    Three corrections to what we posted:

    1. "Deterministic" was wrong as stated. The repair step iterated over a Python set, so the path depended on the hash seed. On P12 it accepts gates 60+108 (core p = 0.205) or 60+64 (p = 0.237, your result) depending on PYTHONHASHSEED. The recovered peak is identical either way; only the core probability differs. The v2 solver removes both thresholds (|⟨Z⟩| < 0.6 and the 1.3× rule). It adds whichever frontier gate maximises the exact core peak probability, with a fixed tie order, and it reproduces 60+64 on P12 and 59 on P11.
    2. "Blind" needs a caveat. No target string is read at runtime, but the boundary-repair step was written after the first P12 run missed by 4 bits. We'll add that to both issue texts. We also checked how fragile the boundary choice is: forcing the runner-up first move on P12 converges to a wrong peak whose core p is 2.3–2.7× lower. So the objective separates the right and wrong branches, but it is a model-selection criterion, not a proof.
    3. "Exact" applies only to the reduced core. Sweeping and masking are deliberately lossy, so the middle is a permutation only approximately. We tried to bound the full-circuit peak probability rigorously (p_true ≥ (√p_core − ε)², ε ≥ ‖M − Π‖) and the bound is vacuous. Even where the mirror unzips cleanly, the residual is ~1e-3 per gate, which sums to ε ≈ 1.8 (P11) and 1.3 (P12) against thresholds of 0.55 / 0.49. We also found that the inner-block mirror centres are SWAP·CZ rather than SWAP. The negative result and scripts are in research/data/peaked-circuits/bound-attempt/. Assuming independent errors (an estimate, not a bound), p_true is about 0.19–0.22 for P11 and 0.18–0.19 for P12.

    Thanks also for 2609.40289. Our attack depends on exactly the structure that a qiO-based construction is designed to hide: exact inverse fragments that survive obfuscation, and a mirror skeleton under one permutation.

    Since then we've generalised the method into an anchor-free operator route: find the mirror centre, compress the operator outward, unswap, then contract exactly. Code and logs are in research/data/peaked-circuits/ (generic/, mpou2/, PORTAL.md).

  4. matteoacrossi commented on Oct 21, 2026

    @matteoacrossi

    Hi @dylanneve1, thanks for the submission, and thanks to you and @MonitSharma for the useful discussion here.

    I reproduced the result with your pinned environment, and both v1 and v2 recover the #247 peak. I’m inclined to approve after two minor edits to the issue body:

    • Method proof: please update step 5 to the v2 result (gates 60+64, p ≈ 0.237). Please also add the caveats from your comment: the repair step was added post-hoc, and “exact” applies to the core only.
    • Notes: please keep this to 60 characters or fewer.
  5. dylanneve1 commented on Oct 22, 2026

    @dylanneve1
    Author

    Thanks, @matteoacrossi. I have updated the issue body as requested: step 5 now gives the v2 result (gates 60 + 64, core p ≈ 0.237) alongside the v1 hash-seed behaviour, the caveats are in the method proof (repair step added post hoc; "exact" applies to the core only), the Notes field is under 60 characters, and there are links to reproduce.sh and the v2 solver.

  6. moved this from Backlog to In review in Quantum Advantage Trackeron Nov 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions