Architecting Scalable Trapped Ion Quantum Computers using Surface Codes

Trapped-ion qubits are among the best quantum bits we have, but scaling them means the modular QCCD design — many small ion traps with ions physically shuttled between them — and to reach useful accuracy those qubits must be bundled into error-correcting surface codes, yet nobody knew how a QCCD machine should be built to run surface codes at scale; this paper (University of Cambridge — Scott Jones, Prakash Murali) builds a near-optimal, topology-aware compiler that maps surface codes onto QCCD hardware 3.8 times faster than existing compilers, then uses it to sweep the hardware design space and finds a counterintuitive answer — tiny traps of just two ions are best for both speed and efficiency, overturning the common belief that big 20-to-30-ion traps would win.

The argument in one glance

Problem

Nobody knew how to build a trapped-ion machine so it can run error correction at scale

Trapped-ion (TI) qubits — individual atoms held still by electric fields and controlled with lasers — are one of the best quantum-computing platforms, with very accurate operations. But today's machines have fewer than sixty qubits, and useful quantum computing needs far more, run far more accurately. The gap is stark: near-term hardware makes roughly one error in a thousand to one in ten thousand operations, while practical applications need fewer than one error in a billion. Closing that gap requires quantum error correction (QEC), which bundles many physical qubits into one protected logical qubit, using a scheme such as the surface code. To scale the hardware itself, the field is moving to a modular design called the Quantum Charge-Coupled Device (QCCD): instead of one big trap holding all the ions, ions are spread across many small traps and physically shuttled between them to interact. QCCD is the promising path to large machines, and surface codes are the standard way to correct errors — but there was no clarity on how a QCCD machine should actually be designed to run surface codes at practical scale. How many ions per trap? How should traps be connected and wired? Those choices are being made now for upcoming systems, with little guidance.
What people did

Assume big traps are better, and reuse general-purpose quantum compilers

The prevailing intuition was that larger traps — holding twenty to thirty ions each — would be preferable, because packing more qubits together means fewer of the slow, error-prone ion movements between traps. And to run circuits on QCCD hardware, designers reused general-purpose quantum compilers that map arbitrary quantum circuits onto a device's qubits and connectivity.
Why it fell short

General compilers cannot map surface codes well, and the trap-size intuition was untested

Both assumptions break down for practical-scale error correction. General-purpose quantum compilers are built for arbitrary circuits; they do not know how to cluster qubits for the highly regular, repetitive structure of surface-code error correction (and its lattice-surgery operations), so they map it inefficiently and cannot scale to the large codes QEC needs. And the belief that bigger traps are better was intuition, not a measured conclusion — it ignores that gates inside a trap run one after another, and that a longer chain of ions in one trap suffers worse vibrational motion and heating, which degrades gate quality. Without a compiler that maps surface codes efficiently and a way to model real QCCD hardware faithfully, there was no way to actually compare architectural choices — trap size, connectivity, wiring — and see which ones make surface codes fast and cheap. The design of scalable trapped-ion machines was proceeding on guesswork.
This paper's idea

Build a surface-code-aware compiler, then sweep the hardware design space with it

This paper studies how to implement surface codes efficiently on QCCD systems, with two pieces. First, a near-optimal, topology-aware compiler specialized for QEC: it takes a surface-code circuit and a QCCD architecture and produces an efficient, scheduled program, translating to the ions' native gates, mapping qubits to ions, routing ions with the QCCD movement primitives (shuttling an ion along a segment, splitting an ion out of a trap, merging one in, swapping ions within a trap, and crossing junctions between traps), and scheduling everything with realistic operation timings — all aimed at minimizing the physical causes of logical error. Because it understands the surface code's structure, it clusters qubits for error correction in a way general compilers cannot, and it outperforms existing QCCD compilers by an average of 3.8 times in logical clock speed (how fast a round of error correction runs). Second, a design-space-exploration toolflow around this compiler, with a QCCD simulator and realistic models — validated against hardware data sheets from Quantinuum and IonQ — for logical error rate (using a standard QEC simulator), error-correction round time, and power. Sweeping trap capacity, connectivity, and wiring, the authors reach a surprising conclusion: small traps of just two ions are ideal, best for both performance and hardware efficiency — overturning the common intuition that twenty-to-thirty-ion traps would be better, and offering concrete guidance for upcoming systems.

Why this problem is worth solving

The choices being made today about how to wire together the next generation of trapped-ion machines will decide whether they can ever run error correction efficiently.

A trapped-ion quantum computer stores each qubit in a single ion suspended by electric fields, and performs gates with precisely controlled lasers or fields. This gives some of the highest-quality operations of any quantum platform, but a single trap can only hold so many ions before control becomes unmanageable and gate quality degrades — beyond roughly thirty ions a monolithic single-trap design stops scaling. The answer is the Quantum Charge-Coupled Device, or QCCD: many small traps connected by junctions and transport segments, with ions physically moved (shuttled) between traps whenever qubits in different traps need to interact. This is how machines are expected to grow to the hundreds or thousands of qubits real algorithms need. But raw qubits are far too error-prone: near-term hardware errs on the order of one operation in a thousand to ten thousand, while useful algorithms need fewer than one error in a billion. That million-fold gap can only be closed by quantum error correction, which encodes one reliable logical qubit across many physical qubits and repeatedly measures parity checks to detect and fix errors. The surface code is the standard scheme for this. So a practical trapped-ion computer will be a QCCD machine running surface codes — which makes the question of how to design the QCCD hardware for surface codes the decisive one, and it was largely unanswered.

The difficulty is that you cannot judge a hardware design without a way to run surface codes well on it and model it faithfully.

To know whether, say, big traps or small traps are better for surface-code error correction, you have to actually map the surface code onto each candidate machine and measure what matters: how fast a round of error correction completes (the logical clock speed), the resulting logical error rate, and the power it burns. That mapping is hard and specialized. A surface code is not an arbitrary circuit; it is a regular grid of data qubits with an ancilla qubit in each cell, running the same neighbour-only parity checks over and over, and its logical operations (like lattice surgery) have their own structure. General-purpose quantum compilers, designed for arbitrary circuits, do not exploit this and cannot cluster qubits appropriately, so they produce slow mappings and do not scale to large codes. On the hardware side, the physics matters: moving ions between traps costs time and can heat them, gates within a trap execute serially, and gate error rates depend on the vibrational motion of the ion chain — so a model that ignores these will give misleading answers. Only with a compiler that maps surface codes near-optimally and a simulator with realistic, hardware-validated timing and error models can you fairly compare architectural choices. Building both is what lets this paper turn guesswork about trap size and connectivity into measured design guidance.

What people did before, and where it broke

Use a monolithic single-trap design. Keep all the ions in one large trap. Where it broke. Control becomes unmanageable and gate quality degrades beyond about thirty ions, so it cannot scale to the qubit counts practical algorithms need.
Assume larger traps (twenty to thirty ions) are best. Pack many ions per trap to minimize slow inter-trap ion movement. Where it broke. It was untested intuition: it ignores that gates within a trap run serially and that longer ion chains suffer worse vibrational motion and heating, which lowers gate quality.
Map error correction with general-purpose quantum compilers. Reuse compilers built to map arbitrary circuits onto a device’s qubits and connectivity. Where it broke. They do not understand the regular, repetitive structure of surface codes and lattice surgery, so they cluster and route qubits inefficiently and do not scale to large codes.
Reason about hardware without faithful models. Compare designs using rough or idealized assumptions about ion movement and gate timing. Where it broke. The physical costs — movement time, serial gates, heating-dependent error rates — dominate, so idealized models give misleading conclusions about which architecture is best.
The gap. No one had a surface-code-aware compiler plus a hardware-validated QCCD model to actually measure how trap size, connectivity, and wiring affect practical-scale surface-code error correction, so scalable trapped-ion machines were being designed on guesswork.

How the framework works

From a surface code and a candidate machine to measured design guidance

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Design the hardware and the error-correcting code together. The paper’s premise is that you cannot pick QCCD hardware parameters in isolation; the right trap size, connectivity, and wiring depend on how a surface code actually runs on them, so hardware and code must be evaluated jointly. Treating the quantum error-correcting code and the hardware that implements it as a single design problem, tuned together rather than separately, is the same principle the work on the co-design of quantum error-correcting codes and modular chiplets covered elsewhere on this site is built on, matching the code to the machine. Here the machine is a modular trapped-ion QCCD system and the code is the surface code, and the co-design question is which architectural parameters make that pairing efficient.

Compile by exploiting the surface code’s regular structure and the machine’s topology. The compiler’s power comes from knowing exactly what a surface code looks like — a regular grid of neighbour-only parity checks — and mapping it onto the machine’s specific trap-and-junction layout, which lets it cluster and route qubits far better than a general compiler. Exploiting the known, regular structure of a quantum workload and the target architecture to compile it efficiently is the same approach the work on exploiting the regular structure of modern quantum architectures for compilation covered elsewhere on this site takes, turning structure into a faster mapping. That specialization is why the compiler beats existing QCCD compilers by 3.8 times in logical clock speed.

Make moving quantum information across the machine a first-class cost. In a QCCD system, qubits interact only after ions are physically shuttled together, so communication — the movement of ions between traps through junctions — is often the dominant cost, and the architecture must be designed around it. Recognizing that in a modular quantum machine the movement of quantum information between modules is a central bottleneck to be engineered, not an afterthought, is the same insight the work on a multi-entry communication highway for superconducting quantum chips covered elsewhere on this site is built on, designing the machine around how quantum information travels. This paper models that ion movement realistically and lets it drive the design-space search, which is part of why the surprising two-ion-trap answer emerges.

Following a design evaluation through the framework

Testing whether two-ion traps or twenty-ion traps run a surface code better

A trace, drawn from the paper, of how the framework compares two candidate QCCD architectures for surface-code error correction.

Step 1 of 5

Propose two candidate machines

The authors set up two QCCD architectures for the same surface code: one with large traps holding many ions (the conventional intuition) and one with tiny traps of just two ions each, differing in connectivity and wiring accordingly.

The goal is to measure, not assume, which trap size is better.

Why it works

A surface-code-aware compiler maps what general ones cannot. Surface codes are regular, repetitive, neighbour-only structures → but general compilers treat them as arbitrary circuits and cluster poorly → so a specialized, topology-aware compiler maps them 3.8 times faster and scales to large codes.
Faithful hardware models expose the real trade-offs. The true costs are ion movement, serial gates, and heating-dependent errors → but idealized models hide them → so a simulator validated against Quantinuum and IonQ data reveals which architecture actually wins.
Small traps give fast, high-quality gates. A long ion chain in a big trap runs gates serially and heats up, hurting fidelity → but a two-ion trap keeps gates clean and quick → so its per-gate quality and speed are better despite needing more movement.
Surface codes only need neighbour interactions. The code never requires many qubits co-located, only adjacent ones → so packing twenty to thirty ions per trap buys little locality benefit → so the case for big traps, which assumed co-location helps, largely evaporates.
Measuring beats intuition for architecture choices. The belief that big traps win was untested → but sweeping the design space with a real compiler and models tests it directly → so the counterintuitive two-ion-trap result rests on evidence, not guesswork.

What it costs (trade-offs and scope)

The two-ion-trap result comes with more ion movement. Small traps minimize in-trap gate problems but require shuttling ions together more often; the paper finds this is a net win for surface codes, but it means the architecture leans heavily on fast, reliable ion transport, which must be engineered well.
It is specific to surface codes on QCCD trapped-ion systems. The compiler and conclusions target the surface code on QCCD hardware; the authors note the framework is more broadly applicable, but the specific guidance (including the trap-size finding) is derived for this code and platform and need not carry over to other codes or qubit technologies.
Conclusions rest on the accuracy of the models. The findings depend on the QCCD simulator and the performance, error, and power models; although validated against Quantinuum and IonQ data sheets, real future hardware may differ, and the models make assumptions (for example about serial versus parallel gates) that shape the results.
Near-optimal is not provably optimal. The compiler is described as near-optimal, and the design-space sweep covers a chosen range of trap capacity, connectivity, and wiring; a design outside that range, or a better mapping, could shift the quantitative comparisons.
It informs design, not a full machine. The work is architectural guidance and a toolflow for design-space exploration; building an actual practical-scale, error-corrected trapped-ion computer involves many further engineering challenges beyond the parameters studied here.

The evaluation

Choosing a QCCD architecture for surface-code error correction

Property	Large traps (20-30 ions), general compiler	Prior QCCD compilers	This framework (two-ion traps)
Maps surface codes efficiently
Logical clock speed
In-trap gate quality
Hardware efficiency
Basis for the conclusion

A comparison of how QCCD architectures for surface codes were chosen. The paper's topology-aware compiler is 3.8 times faster than prior QCCD compilers in logical clock speed, and its hardware-validated design-space sweep shows that two-ion traps are optimal for both performance and hardware efficiency, overturning the intuition that 20-to-30-ion traps would be preferable.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (arXiv:2510.23519). The claims are the paper’s: trapped-ion (TI) qubits are a leading platform, current systems have fewer than sixty qubits, and the modular Quantum Charge-Coupled Device (QCCD) architecture is a promising path to scale; the gap between near-term error rates (about one in a thousand to one in ten thousand) and practical application requirements (below one in a billion) requires quantum error correction with logical qubits built from many physical qubits. The paper studies how surface codes can be implemented efficiently on QCCD systems. It develops a near-optimal, topology-aware compilation method that outperforms existing QCCD compilers by an average of 3.8 times in logical clock speed, and a design-space-exploration toolflow with a QCCD simulator and realistic models (validated against Quantinuum and IonQ hardware data sheets) for logical error rate (via a standard QEC simulator), QEC round time, and power. Using these, it examines how trap capacity, connectivity, and electrode wiring can be optimized for surface codes, and demonstrates that small traps of two ions are ideal from both a performance-optimal and hardware-efficiency standpoint, contrary to prior intuition that larger traps (twenty to thirty ions) would be preferable. Exact compiler details, the models and their parameters, the full design space, and complete results should be read from the paper.

Background

Why building a quantum computer is now an architecture problem

It helps to see this work as part of a shift in quantum computing from making qubits to architecting machines out of them. For years the central challenge was physics: better qubits, higher-fidelity gates. As platforms mature, a second challenge has come to dominate — how to organize thousands or millions of imperfect qubits, plus the error correction they need, into a machine that actually runs useful algorithms. That is fundamentally a computer-architecture question, involving how components connect, how information moves between them, how work is compiled and scheduled, and how error correction is laid out on the hardware. Trapped ions make this especially vivid, because scaling them means physically moving ions around a modular chip, so the layout and the movement network are the architecture. And crucially, the design choices interact with the error-correcting code, so they cannot be made in the abstract. The broad effort to architect fault-tolerant quantum machines at large scale, confronting how to connect and coordinate enormous numbers of qubits, is the same undertaking the work on a fault-tolerant million-qubit-scale distributed quantum computer covered elsewhere on this site pursues, treating scale as an architectural problem. This paper contributes hard, measured guidance for one leading platform, showing that careful, code-aware architecture analysis can overturn long-held intuitions like the belief that bigger ion traps are better.

If you remember only three things

1. Trapped-ion qubits are a leading quantum platform, but scaling past today's fewer-than-sixty-qubit machines needs the modular Quantum Charge-Coupled Device (QCCD) design — many small ion traps with ions shuttled between them — and reaching practical accuracy (from about one error in a thousand-to-ten-thousand down to below one in a billion) needs quantum error correction, bundling physical qubits into logical qubits with surface codes. But there was no clarity on how a QCCD machine should be designed to run surface codes at scale.
2. The paper builds a near-optimal, topology-aware compiler that maps surface codes onto QCCD hardware — clustering qubits for error correction and routing ions with the movement primitives (shuttle, split, merge, swap, junction crossing) — outperforming existing QCCD compilers by an average of 3.8 times in logical clock speed. Around it, a design-space-exploration toolflow with a QCCD simulator and models validated against Quantinuum and IonQ hardware measures logical error rate, error-correction round time, and power for candidate architectures.
3. Sweeping trap capacity, connectivity, and wiring, the authors find a counterintuitive result: small traps of just two ions are optimal for both performance and hardware efficiency, overturning the common belief that twenty-to-thirty-ion traps would be better, because two-ion traps give fast, high-quality gates while surface codes need only neighbour interactions. The finding is specific to surface codes on QCCD and rests on the models, but it offers concrete, measured guidance for designing upcoming trapped-ion systems.

Check yourself

Check your understanding

1. Why does a practical trapped-ion quantum computer need both the QCCD architecture and surface-code error correction?
2. Why can't general-purpose quantum compilers be used to map surface codes onto QCCD hardware?
3. What surprising conclusion does the design-space exploration reach, and why?
4. Predict: a hardware team, trusting the old intuition, builds a QCCD machine with big 25-ion traps to minimize ion movement. Based on this paper, what problem are they likely to hit?

Sources

The paper is “Architecting Scalable Trapped Ion Quantum Computers using Surface Codes” by Scott Jones and Prakash Murali (University of Cambridge), published at ASPLOS 2026, DOI 10.1145/3779212.3790128. It is licensed CC BY.

This explainer is written from the paper’s full text (arXiv:2510.23519). Trapped-ion (TI) qubits are a leading quantum-computing platform; current systems have fewer than sixty qubits, but the modular Quantum Charge-Coupled Device (QCCD) architecture — distributing ions across many small traps and shuttling them between traps — is a promising path to scale. There is a large gap between near-term error rates (about one in a thousand to one in ten thousand) and the requirements of practical applications (below one in a billion), which requires quantum error correction (QEC) to build logical qubits from many physical qubits; while logical qubits have been demonstrated on TI hardware, only for small codes and systems, and there was no clarity on how QCCD systems should be designed to implement practical-scale QEC. The paper studies how surface codes can be implemented efficiently on QCCD systems. It develops a near-optimal, topology-aware compilation method that outperforms existing QCCD compilers by an average of 3.8 times in logical clock speed, and uses it, within a design-space-exploration toolflow (with a QCCD simulator and realistic performance, logical-error-rate, round-time, and power models validated against Quantinuum and IonQ hardware data sheets), to examine how trap capacity, connectivity, and electrode wiring can be optimized for surface codes. It demonstrates that small traps of two ions are ideal from both a performance-optimal and hardware-efficiency standpoint, contrary to prior intuition that larger traps (twenty to thirty ions) would be preferable, with the potential to inform design choices for upcoming systems. No numbers beyond the paper’s own have been introduced; exact compiler details, models, the full design space, and complete results should be confirmed in the paper.