Imagine you're planning a cross-country road trip with 30 stops. The order you visit them in determines your total mileage — visit them naively and you drive 10,000 miles; find the right sequence and you drive 4,000. Now imagine each "mile" costs a GPU-hour, and the trip has a million stops. That's tensor-network contraction ordering for quantum circuit simulation: same math as the traveling salesman problem, but the cost function is floating-point operations and the constraint is intermediate tensor size (memory). ArcTN is a new route-planner that finds shorter trips faster. The committed claim: ArcTN's Light preset reduces FLOPs by 61.32% while planning 1.62× faster than Cotengra Auto/CMA-ES, and its Heavy preset beats Cotengra AutoHQ/Optuna by 43.83% fewer FLOPs at 7.21× faster planning — all on 30 QC32 benchmark circuits that every compared configuration could complete. Against OMECO TreeSA-8, the current best contraction-order optimizer from the Chinese quantum computing program, Heavy needs 11.85% fewer FLOPs and plans 1.33× faster. This is not a methods-only paper; it ships numbers on 672 MQT Bench networks and provides public code. Architecturally, ArcTN belongs to the stochastic-search family for contraction-order optimization — the same lineage as Cotengra's hyper-optimization and OMECO's simulated-annealing tree search. The core recipe combines three ingredients: randomized-greedy construction (fast initial solutions), subtree reconfiguration (local refinement that swaps subgraphs of the contraction tree), and parallel tempering (running multiple search threads at different "temperatures" to escape local minima). What distinguishes ArcTN is stage-specific stopping rules that decide when to stop refining and move on, plus a Dynamic slicing mode that reslices the contraction tree to meet memory limits after optimization rather than fixing slicing upfront. Dynamic slicing succeeded in all 90 runs on 18 scalar-output networks, cutting sliced FLOPs by 31.99% over Fixed slicing at the cost of longer planning. The ladder is honestly constructed. The authors benchmark against eight configurations spanning two major competitors: Cotengra (the de facto community standard by Johnnie Gray, with both Auto and AutoHQ presets using CMA-ES and Optuna respectively) and OMECO (TreeSA with 8-thread parallel search). On QC32 circuits — random 32-qubit circuits designed to be hard for simulators — ArcTN Heavy achieves the lowest geometric-mean FLOPs on the 142 large MQT Bench networks while planning 3.1× faster than Cotengra AutoHQ and 31× faster than Hyper128. Critically, the paper reports results only on circuits all compared configurations could complete, avoiding survivorship bias. The weaknesses are acknowledged: Dynamic slicing takes longer to plan, and on smaller circuits the gains compress. Integrity is solid for a systems paper. The benchmarks are public (QC32, MQT Bench — 320 circuits yielding 672 networks). Code and benchmarks are released on GitHub. The comparisons use current baselines, not stale ones. The main integrity question is that validation is purely computational — there is no independent physical experiment, and the FLOPs-to-wall-clock translation depends on the executor (they use a common NumPy backend, not optimized GPU). Also, benchmark selection was presumably post-hoc (they picked QC32 and MQT Bench because those are what the community uses, not because they pre-registered), though this is standard practice in the subfield. The milestone question is about where contraction-order optimization sits on the road to practical quantum advantage verification. Today's frontier is simulating ~50-60 qubit random circuits (the regime Google and USTC claim quantum advantage in). ArcTN's demonstrated scale is 32-qubit circuits with up to 672 networks. The next concrete milestone: can ArcTN-class optimizers enable classical simulation of 50+ qubit circuits that were previously intractable, thereby tightening the quantum advantage boundary? The gap is probably 1-3 years — the algorithms are improving faster than the circuits are getting harder, but memory limits remain the binding constraint. The obvious next experiment not run: GPU-accelerated execution. ArcTN benchmarks planning time and FLOPs, but uses NumPy for execution — not CuPy, not JAX, not a custom CUDA kernel. The honest read is (a): this is a planning-algorithm paper, not an execution-engine paper, and building a competitive GPU backend is a separate engineering project. But the practical question every user will ask is "how fast does my simulation actually run?" and that answer requires GPU execution. The authors are almost certainly saving this for the next paper or a collaboration with a hardware team.
