Building Quantum Computers Like LEGO: Quantum LDPC Codes for Modular Architectures

A deep dive into the Strikis & Berent construction—how the hypergraph product of connectivity codes gives quantum error-correcting codes that automatically respect modular hardware constraints.

Introduction: Why Should We Care About Modular Quantum Computers?

If you have been following the quantum computing world, you know that one of the biggest headaches we face is scaling up. We are pretty good at making small quantum processors with a handful of qubits, but making a single monolithic chip with millions of qubits? That is an engineering nightmare. Every quantum computing platform—whether it is superconducting circuits, trapped ions, or photonic systems—hits a wall at some point in terms of how many qubits you can cram into one device.

The solution? Modularity. Just like classical supercomputers are built from many smaller processing nodes connected together, future quantum computers will likely consist of many small quantum modules linked via some form of inter-module connectivity. Think of it as building with LEGO blocks: each block (module) is a small, well-controlled quantum processor, and you snap them together to build something much larger.

But here is the catch. In a fault-tolerant quantum computer, we need quantum error-correcting codes to protect our fragile quantum information. The error-correcting code we choose must respect the connectivity constraints imposed by the hardware architecture. If our code demands that qubit 1 talks to qubit 10,000, but our hardware can only connect nearest neighbours within a module and a few qubits between adjacent modules, we have a problem.

This is precisely the gap that the beautiful paper by Armands Strikis and Lucas Berent [1] bridges. They give us a recipe for constructing quantum LDPC codes that are tailored to modular architectures. The key insight is remarkably elegant: if we can describe the intra-modular connectivity (how qubits connect within a module) and the inter-modular connectivity (how modules connect to each other) as Tanner graphs of some classical or quantum LDPC codes, then the hypergraph product of these codes gives us a new quantum code that automatically respects all the architectural constraints.

In this blog post, I will walk you through:

  1. Why modular constructions are essential for scaling quantum computers.
  2. How to design LDPC codes that fit modular architectures.
  3. The mathematical framework—chain complexes, tensor products, and the Künneth formula—that makes this all work.
  4. How inter-modular entanglement operations connect to these code constructions.
  5. The balanced product generalisation that allows twisted connections for even better codes.

Let us dive in!

Why Are Modular Constructions Important?

The Scalability Wall

Every quantum computing platform faces fundamental limits. Superconducting chips can only hold so many qubits before crosstalk and wiring become unmanageable [4]. Ion traps have a finite number of ions that can be stably trapped in a single potential well [3]. Photonic systems need to manage increasingly complex optical networks.

The modular approach says: do not fight these limits—embrace them. Build many identical, well-characterised modules and connect them. This is essentially the same philosophy that made classical computing scalable through distributed and cluster architectures [2].

The Error Correction Challenge

Here is where it gets interesting for us in quantum error correction. The surface code—the current gold standard—is beautifully suited for 2D nearest-neighbour connectivity [5, 6]. But it has a major drawback: its encoding rate scales as \(k/n \sim 1/n\), meaning you need \(O(d^2)\) physical qubits to encode one logical qubit with distance \(d\). That is a lot of overhead.

Quantum LDPC (QLDPC) codes can potentially do much better. Recent breakthroughs have shown the existence of asymptotically good QLDPC codes [7, 8], where both the encoding rate \(k/n\) and the relative distance \(d/n\) remain constant. But these codes require “long-range” qubit connectivity—something that a 2D planar chip simply cannot provide.

And here is the key observation: a modular architecture naturally provides a degree of long-range connectivity! When module \(M_1\) talks to module \(M_5\) across the chip, the qubits involved are effectively performing long-range interactions. The question then becomes: how do we design codes that exploit exactly this type of structured, sparse, long-range connectivity?

The Gap This Paper Fills

Before Strikis and Berent’s work, people had mentioned that QLDPC codes and modular architectures should be compatible [9], but nobody had given a precise, general construction showing which codes work for which architectures and how to partition qubits into modules. This paper fills that gap completely by providing:

The Main Recipe:
  1. Describe the intra-modular connectivity as a Tanner graph (equivalently, a chain complex) of some code \(C\).
  2. Describe the inter-modular connectivity as a Tanner graph (chain complex) of some code \(D\).
  3. Take their hypergraph product \(E = C \otimes D\).
  4. The resulting code \(E\) automatically respects all connectivity constraints!

How to Design LDPC Codes for Modular Architectures

What is a Modular Architecture, Formally?

Let me set up the notation carefully, because getting the definitions right is half the battle.

Definition (Modular Architecture). A modular architecture consists of a finite collection of qubits \(\{q_N\}\) partitioned into modules \(\{M_k\}\), where each module contains \(n\) qubits. The modules are equivalent copies of each other.

There are two types of connectivity:

Definition (Intra-Modular Connectivity). A qubit \(q_i \in M_k\) is connected to a qubit \(q_j \in M_k\) if the architecture allows us to directly implement two-qubit entangling operations between them, for all modules \(k\).

Definition (Inter-Modular Connectivity). A module \(M_k\) is connected to a module \(M_j\) if the architecture allows us to directly implement two-qubit entangling operations between a qubit \(q_i \in M_k\) and its respective qubit \(q_i \in M_j\) for all \(i\).

The word “respective” is crucial here. In the basic (untwisted) setting, when two modules are connected, qubit \(i\) in one module talks to qubit \(i\) in the other. It is a one-to-one, index-preserving correspondence.

Viewing Connectivity as Tanner Graphs

Here is the beautiful insight. Consider a 1D chain of qubits within a module with nearest-neighbour connectivity. What classical code has a Tanner graph that looks exactly like a 1D chain? The repetition code!

Example (Repetition Code as Intra-Modular Connectivity). The \([L, 1, L]\) classical repetition code on \(L\) bits has a parity check matrix \(H\) whose Tanner graph is a bipartite graph: data bits on one side, parity checks on the other, with each check connected to two adjacent bits. This is exactly the connectivity of a 1D chain with nearest neighbours.

Similarly, the 2D layout of modules on a grid looks exactly like the Tanner graph of a surface code:

Example (Surface Code as Inter-Modular Layout). A 2D surface code on an \(L \times L\) grid has X-checks on vertices, data qubits on edges, and Z-checks on faces. If we label each of these as a “module”, the adjacency structure defines the inter-modular connectivity.

The point is: any LDPC code can serve as a blueprint for connectivity. The sparser the code (lower weight checks), the fewer connections each qubit or module needs. The better the code parameters, the better the resulting product code.

The Step-by-Step Recipe

  1. Characterise your modules. How many qubits per module? What is the intra-modular connectivity graph?
  2. Find a code \(C\) whose Tanner graph matches the intra-modular connectivity. For a 1D chain, use a repetition code. For something more connected, use a random LDPC code.
  3. Characterise the module layout. How are modules connected to each other?
  4. Find a code \(D\) whose Tanner graph matches the inter-modular connectivity. For a 2D grid, use a surface code.
  5. Compute the hypergraph product \(E = C \otimes D\). By Theorem IV.1 of [1], \(E\) automatically respects all architectural constraints.
  6. Compute the code parameters using the Künneth formula and distance bounds.

A Concrete Example

Setup: Modules arranged in a \(20 \times 20\) surface code layout. Each module contains qubits connected according to a classical \([60, 9, 20]\) LDPC code (max check weight 8, average weight \(\approx 5\)).

Chain complexes:

  • \(\mathcal{C} = C_1 \xrightarrow{H} C_0\): a 2-term complex from the \([60, 9, 20]\) code. \(\dim C_1 = 60\), \(\dim C_0 = 51\). Homology: \(\dim H_1(\mathcal{C}) = 9\), \(H_0(\mathcal{C})\) trivial.
  • \(\mathcal{D} = D_2 \xrightarrow{\partial_2} D_1 \xrightarrow{\partial_1} D_0\): a 3-term complex from the \(20 \times 20\) surface code. Homology: \(\dim H_1(\mathcal{D}) = 1\), others trivial.

Product code \(E = \mathcal{C} \otimes \mathcal{D}\):

\[\begin{align} n &= \dim E_2 = \dim(C_1 \otimes D_1 \oplus C_0 \otimes D_2) = 65{,}040 \\ k &= \dim H_2(\mathcal{E}) = 9 \\ d_Z &= \min(d_1(\mathcal{D}) \cdot d_1(\mathcal{C}),\; d_2(\mathcal{D}) \cdot d_0(\mathcal{C})) = 400 \\ d_X &= 20 \end{align}\]

So the final code has parameters \(\llbracket 65040, 9, 20 \rrbracket\). Compared to the 3D surface code with parameters \(\llbracket 22820, 1, 20 \rrbracket\), we encode 9 times more logical qubits at the cost of only \(3\times\) more physical qubits. Not bad at all!

Understanding the Mathematics: Chain Complexes and Product Codes

Now let us get into the mathematical guts. I promise to keep it as intuitive as possible, but some formalism is unavoidable—and honestly, the formalism is what makes the whole thing so powerful.

Classical Codes as Chain Complexes

A classical binary linear \([n, k]\) code \(C\) is defined by its parity check matrix \(H\). We can view this as a two-term chain complex:

\[\mathcal{C} = C_1 \xrightarrow{\partial_1 = H} C_0\]
  • \(C_1 = \mathbb{F}_2^n\): space of \(n\)-bit strings (data bits).
  • \(C_0 = \mathbb{F}_2^m\): space of syndromes (parity checks).
  • \(\partial_1 = H\): the parity check matrix.
  • Codewords: \(\ker \partial_1 = \ker H\).

Quantum CSS Codes as Chain Complexes

A CSS code is defined by two parity check matrices \(H_X\) and \(H_Z\) satisfying:

\[H_X H_Z^T = 0\]

This is equivalent to \(\text{im}(H_Z^T) \subseteq \ker(H_X)\), which is the chain complex condition \(\partial_i \circ \partial_{i+1} = 0\). A CSS code corresponds to a three-term chain complex:

\[\mathcal{C} = C_{i+1} \xrightarrow{\partial_{i+1} = H_Z^T} C_i \xrightarrow{\partial_i = H_X} C_{i-1}\]
Chain complex elementCode element
\(C_{i+1}\) (2-chains, “faces”)Z parity checks
\(C_i\) (1-chains, “edges”)Data qubits
\(C_{i-1}\) (0-chains, “vertices”)X parity checks
\(\partial_{i+1} = H_Z^T\)Z check matrix (transposed)
\(\partial_i = H_X\)X check matrix

The code parameters are:

\[\begin{align} n &= \dim C_i \\ k &= \dim H_i(\mathcal{C}) = \dim(\ker \partial_i / \operatorname{im} \partial_{i+1}) \\ d &= \text{min weight of a non-trivial representative of } H_i(\mathcal{C}) \end{align}\]

A prototypical example is the toric code, where \(C_2\), \(C_1\), \(C_0\) are the vector spaces of faces, edges, and vertices of a square cellulation of the torus.

Tensor Product of Chain Complexes

Given two chain complexes \(\mathcal{C}\) and \(\mathcal{D}\), their tensor product \(\mathcal{E} = \mathcal{C} \otimes \mathcal{D}\) is formed via the double complex:

\[(\mathcal{C} \boxtimes \mathcal{D})_{p,q} = C_p \otimes D_q\]

with vertical boundary \(\partial^v = \partial^{\mathcal{C}} \otimes \text{id}_{\mathcal{D}}\) and horizontal boundary \(\partial^h = \text{id}_{\mathcal{C}} \otimes \partial^{\mathcal{D}}\). The total complex sums over diagonals:

\[E_n = \bigoplus_{p+q=n} C_p \otimes D_q, \quad \partial^{\mathcal{E}} = \partial^{\mathcal{C}} \otimes \text{id}_{\mathcal{D}} \oplus \text{id}_{\mathcal{C}} \otimes \partial^{\mathcal{D}}\]

Example (Product of Two 2-Term Complexes). Let \(\mathcal{C} = C_1 \xrightarrow{\partial_1^C} C_0\) and \(\mathcal{D} = D_1 \xrightarrow{\partial_1^D} D_0\). The total complex is:

\[C_1 \otimes D_1 \xrightarrow{\partial_2} (C_0 \otimes D_1 \oplus C_1 \otimes D_0) \xrightarrow{\partial_1} C_0 \otimes D_0\]

where:

\[\partial_2 = \begin{pmatrix} \partial^C \otimes \text{id} \\ \text{id} \otimes \partial^D \end{pmatrix}, \quad \partial_1 = \begin{pmatrix} \text{id} \otimes \partial^D & \partial^C \otimes \text{id} \end{pmatrix}\]

This is exactly the hypergraph product code of Tillich and Zémor [10]!

The Künneth Formula: Computing Code Parameters

\[H_n(\mathcal{C} \otimes \mathcal{D}) \cong \bigoplus_{p+q=n} H_p(\mathcal{C}) \otimes H_q(\mathcal{D})\]

This lets us compute \(k = \dim H_i(\mathcal{E})\) directly from the homologies of \(\mathcal{C}\) and \(\mathcal{D}\). For the distance, Zeng and Pryadko [11] showed:

\[d_i(\mathcal{A} \otimes \mathcal{B}) = \min\big(d_{i-1}(\mathcal{A}) \cdot d_1(\mathcal{B}),\; d_i(\mathcal{A}) \cdot d_0(\mathcal{B})\big)\]

Why Does the Product Code Respect the Architecture?

Theorem (Theorem IV.1 of [1]). Let \(\mathcal{C}\) and \(\mathcal{D}\) be two- or three-term chain complexes. Let \(\partial^{\mathcal{C}}\) and \(\partial^{\mathcal{D}}\) define the intra- and inter-modular connectivity. Then the quantum code \(E\) corresponding to \(\mathcal{E} = \mathcal{C} \otimes \mathcal{D}\) respects the connectivity constraints.

Proof sketch. The boundary operator decomposes as:

\[\partial^{\mathcal{E}} = \underbrace{\text{id}_{\mathcal{C}} \otimes \partial^{\mathcal{D}}}_{\text{inter-modular}} \oplus \underbrace{\partial^{\mathcal{C}} \otimes \text{id}_{\mathcal{D}}}_{\text{intra-modular}}\]
  • The horizontal (inter-modular) term: \((c, d) \mapsto (c, \partial^{\mathcal{D}}(d))\). Connects qubit \(c\) in module \(d\) to the same qubit \(c\) in adjacent modules. This is exactly inter-modular connectivity!
  • The vertical (intra-modular) term: \((c, d) \mapsto (\partial^{\mathcal{C}}(c), d)\). Connects qubit \(c\) to qubits \(\partial^{\mathcal{C}}(c)\) within the same module \(d\). This is exactly intra-modular connectivity!

Since every parity check uses only allowed operations, the code respects all constraints. ◼

The beauty is in the tensor product structure: the “identity” factors ensure each term uses only one type of connectivity, never both simultaneously.

The Entanglement Connection: How Inter-Modular Operations Link to Code Constructions

Entanglement as the Bridge Between Modules

In a modular quantum computer, modules are typically connected through entanglement generation:

  • Photonic links: Qubits emit photons that interfere at a beamsplitter, generating Bell pairs [14].
  • Direct coupling: Superconducting modules via microwave resonators [4, 15].
  • Shuttling: Physical transport of qubits between modules [13].
  • Multipartite entanglement: GHZ-like states across modules [16].

Boundary Maps as Entanglement Patterns

Consider \(\mathcal{D}\) as a surface code on a 2D grid: \(D_2 \xrightarrow{\partial_2} D_1 \xrightarrow{\partial_1} D_0\). The boundary maps dictate which modules need entangling:

  • \(\partial_1\): Connects “edge modules” to “vertex modules”.
  • \(\partial_2\): Connects “face modules” to “edge modules”.

Each interaction requires an entangling gate. In photonic-link architectures, each inter-module CNOT consumes one Bell pair [17]. The pattern of Bell pairs is precisely dictated by \(\partial^{\mathcal{D}}\).

How the Horizontal Differential Encodes Entanglement Schedules

Physical Interpretation of \(\partial^h\): For each qubit \(c\) within a module and each pair of adjacent modules \((d, d')\) where \(d' \in \partial^D(d)\), we need an entangling operation between qubit \(c\) in module \(d\) and qubit \(c\) in module \(d'\). This is precisely an entanglement-mediated two-qubit gate.

If \(\mathcal{D}\) is LDPC, the number of inter-modular operations grows only linearly with the number of modules—exactly what makes this practical.

Vertical Differential as Local Processing

The vertical differential \(\partial^v = \partial^C \otimes \text{id}_D\) corresponds to purely local operations within each module. The crucial observation:

\[\boxed{\partial^{\mathcal{E}} = \underbrace{\partial^C \otimes \text{id}_D}_{\text{local gates}} \oplus \underbrace{\text{id}_C \otimes \partial^D}_{\text{entanglement-mediated gates}}}\]

The syndrome extraction naturally decomposes into: (1) local gates within each module, and (2) entanglement-mediated gates between modules. These can be parallelised.

The Looped Pipeline: A Physical Realisation

The paper illustrates this through the looped pipeline architecture [13]:

  • Each “module” is a rectangular loop of qubits shuttled around the loop.
  • When qubits from adjacent loops pass near each other, they entangle.
  • Intra-loop connectivity (nearest neighbours) → repetition code \(\mathcal{C}\).
  • Inter-loop layout (2D grid) → surface code \(\mathcal{D}\).
  • Product \(\mathcal{E} = \mathcal{C} \otimes \mathcal{D}\) gives a 3D surface code!

The schedule of which qubits interact when is entirely determined by the boundary maps of the chain complexes.

Going Beyond: Balanced Products and Twisted Connections

The hypergraph product is already powerful, but Strikis and Berent show we can do even better by relaxing inter-modular connectivity slightly.

What Are “Twists”?

In the basic construction, when module \(M_k\) connects to \(M_j\), qubit \(q_i\) in \(M_k\) talks to qubit \(q_i\) in \(M_j\)—strict index-preserving. But what if we allow a permutation? Qubit \(q_i\) in \(M_k\) talks to qubit \(q_{\sigma(i)}\) in \(M_j\). This is a “twist.”

Definition (Twisted Inter-Modular Connectivity). A module \(M_k\) is connected to \(M_j\) if the architecture allows entangling operations between \(q_i \in M_k\) and \(q_l \in M_j\) for all \(i\), \(l\) (where \(l\) may differ from \(i\)).

Many platforms already allow this! In photonic-link architectures, you choose which qubit to entangle with. Photons don’t care about labels.

The Balanced Product

The mathematical structure capturing twists is the balanced product [8]. Let \(V\) and \(W\) have right and left actions of group \(G\):

\[V \otimes_G W = V \otimes W / \langle vg \otimes w - v \otimes gw \rangle\]

For chain complexes with \(G\)-actions:

\[\mathcal{C} \otimes_G \mathcal{D} = \text{Tot}(\mathcal{C} \boxtimes_G \mathcal{D}), \quad (\mathcal{C} \boxtimes_G \mathcal{D})_{p,q} = C_p \otimes_G D_q\]

The balanced product is a quotient of the ordinary tensor product, reducing qubit count while potentially preserving distance.

Fiber Bundle Codes

When \(\mathcal{C}\) is 2-term and \(G\) abelian acting freely, the balanced product becomes a fiber bundle code [12]:

\[\mathcal{E} = \mathcal{D} \otimes_\varphi \mathcal{C}, \quad \partial^{\mathcal{E}} = \underbrace{\partial^\varphi}_{\text{twisted inter-modular}} \oplus \underbrace{\text{id}_D \otimes \partial^C}_{\text{intra-modular}}\]

The connection \(\varphi(d_1, d_0)\) permutes qubits within a module for inter-modular connections—exactly the twisted connectivity!

Theorem (VI.2 of [1]). A fiber bundle code \(\mathcal{E} = \mathcal{D} \otimes_\varphi \mathcal{C}\) respects the connectivity constraints with twisted inter-modular connections.

Why Twists Help: A Concrete Example

  • \(\mathcal{C}\): \(d=15\) cyclic repetition code (intra-modular).
  • \(\mathcal{D}\): random sparse code, \(255 \times 450\) parity check matrix, cyclic symmetry order 15 (inter-modular).
  • Group: \(G = \mathbb{Z}_{15}\).

The balanced product gives:

\[\llbracket 705, 13, 15 \rrbracket\]

All qubits partition into 47 modules with 30 qubits each. Compare: 13 logical qubits at distance 15 with surface codes needs 2925 data qubits. The balanced product needs only 705—roughly a \(4\times\) improvement!

Putting It All Together: From Architecture to Code and Back

Architecture → Code

  1. Given: A modular architecture with defined intra/inter-module connectivity.
  2. Step 1: Express intra-modular connectivity as Tanner graph → chain complex \(\mathcal{C}\).
  3. Step 2: Express inter-modular connectivity as Tanner graph → chain complex \(\mathcal{D}\).
  4. Step 3 (HGP): If index-preserving, compute \(\mathcal{E} = \mathcal{C} \otimes \mathcal{D}\).
  5. Step 3′ (Balanced): If twists allowed, find group \(G\) and compute \(\mathcal{E} = \mathcal{C} \otimes_G \mathcal{D}\).
  6. Step 4: Künneth formula for \(k\), distance theorem for \(d\).

Code → Architecture

The construction works in reverse! If you can choose how to connect modules:

  1. Choose a good QLDPC code \(\mathcal{D}\) with desired parameters.
  2. Map its Tanner graph to a modular layout (each node → one module).
  3. Module connectivity = edges of the Tanner graph.

The architecture emerges from the code, not the other way around.

Comparison of Constructions

Comparison of code constructions from [1]. HGP = Hypergraph Product.
PropertySurface CodeHGP CodeBalanced Product
Inter-module connectivity2D gridGeneral graphGeneral + twists
Intra-module codeRepetitionAny LDPCAny LDPC
Product type\(\mathcal{C} \otimes \mathcal{D}\)\(\mathcal{C} \otimes \mathcal{D}\)\(\mathcal{C} \otimes_G \mathcal{D}\)
Twist allowed?NoNoYes
Example parameters\(\llbracket 22820, 1, 20 \rrbracket\)\(\llbracket 65040, 9, 20 \rrbracket\)\(\llbracket 705, 13, 15 \rrbracket\)
Modules∼60047
Qubits per module∼11130

Why Modular Constructions Matter: A Concluding Perspective

The work of Strikis and Berent represents a crucial step in bridging the theoretical world of QLDPC codes and the engineering world of modular quantum computing architectures.

First, it provides a universal recipe. No matter what your modular architecture looks like—trapped-ion modules with photonic links, superconducting chips with microwave resonators, or semiconductor spin qubits in a looped pipeline—as long as you can describe the connectivity as a code, you can construct a tailored QLDPC code.

Second, it makes the theoretical breakthroughs practical. The modular perspective shows that structured long-range connectivity—exactly the kind modular architectures naturally provide—is sufficient.

Third, the balanced product extension opens the door to significantly better codes with minimal additional hardware requirements. The \(4\times\) improvement over surface codes is likely just the beginning.

Fourth, this work establishes that architecture and error correction are not separate design problems—they are two sides of the same coin. The chain complex is the code. The boundary maps are the entanglement patterns. The homology is the logical information.

As someone working in quantum error correction, I find this unification deeply satisfying. It suggests the right way to design a fault-tolerant quantum computer is to co-design the architecture and the code from the ground up using the language of homological algebra.

The road ahead includes many open questions: fault-tolerant logic, efficient decoding, handling heterogeneous modules, and finding small near-term instances. But the foundation laid by this paper is solid, elegant, and—I believe—essential for the future of scalable quantum computing.

References

  1. A. Strikis and L. Berent, “Quantum Low-Density Parity-Check Codes for Modular Architectures,” PRX Quantum 4, 020321 (2023). DOI
  2. R. Buyya, High Performance Cluster Computing, Vol. 2 (Prentice Hall, 1999).
  3. C. Monroe et al., “Large-scale modular quantum-computer architecture with atomic memory and photonic interconnects,” Phys. Rev. A 89, 022317 (2014).
  4. A. Gold et al., “Entanglement across separate silicon dies in a modular superconducting qubit device,” npj Quantum Inf. 7, 142 (2021).
  5. E. Dennis, A. Kitaev, A. Landahl, and J. Preskill, “Topological quantum memory,” J. Math. Phys. 43, 4452 (2002).
  6. A. Y. Kitaev, “Fault-tolerant quantum computation by anyons,” Ann. Phys. 303, 2 (2003).
  7. P. Panteleev and G. Kalachev, “Asymptotically good quantum and locally testable classical LDPC codes,” Proc. 54th ACM STOC (2022), pp. 375–388.
  8. N. P. Breuckmann and J. N. Eberhardt, “Balanced product quantum codes,” IEEE Trans. Inf. Theory 67, 6653 (2021).
  9. E. T. Campbell, B. M. Terhal, and C. Vuillot, “Roads towards fault-tolerant universal quantum computation,” Nature 549, 172 (2017).
  10. J.-P. Tillich and G. Zémor, “Quantum LDPC codes with positive rate and minimum distance proportional to the square root of the blocklength,” IEEE Trans. Inf. Theory 60, 1193 (2013).
  11. W. Zeng and L. P. Pryadko, “Higher-dimensional quantum hypergraph-product codes with finite rates,” Phys. Rev. Lett. 122, 230501 (2019).
  12. M. B. Hastings, J. Haah, and R. O’Donnell, “Fiber bundle codes: breaking the \(n^{1/2}\operatorname{polylog}(n)\) barrier for quantum LDPC codes,” Proc. 53rd ACM STOC (2021), pp. 1276–1288.
  13. Z. Cai, A. Siegel, and S. Benjamin, “Looped pipelines enabling effective 3D qubit lattices in a strictly 2D device,” PRX Quantum 4, 020345 (2023).
  14. L. J. Stephenson et al., “High-rate, high-fidelity entanglement of qubits across an elementary quantum network,” Phys. Rev. Lett. 124, 110501 (2020).
  15. J. Niu et al., “Low-loss interconnects for modular superconducting quantum processors,” Nature Electronics 6, 235 (2023).
  16. F. Riera-Sàbat and W. Dür, “A modular entanglement-based quantum computer architecture,” New J. Phys. 26, 123015 (2024).
  17. E. T. Campbell, “Distributed quantum-information processing with minimal local resources,” Phys. Rev. A 76, 040302 (2007).
  18. N. P. Breuckmann and J. N. Eberhardt, “Quantum low-density parity-check codes,” PRX Quantum 2, 040101 (2021).
  19. P. Panteleev and G. Kalachev, “Degenerate quantum LDPC codes with good finite length performance,” Quantum 5, 585 (2021).
  20. H. Bombin and M. A. Martin-Delgado, “Topological quantum error correction with optimal encoding rate,” Phys. Rev. A 73, 062303 (2006).
← Back to Blog