How to develop the Quantum Error Correction Stack for every qubit

Different qubit types have different strengths and weaknesses. Some have fast response times but operate at near 0K temperatures. Others have unmatched stability and high gate fidelities but long gate operation times, and some have limited connectivity. 

But every quantum computer will need quantum error correction. 

At Riverlane, we’re developing state-of-the-art decoding techniques and error correction technologies to deliver the full Quantum Error Correction Stack for every hardware provider. We call this QEC Stack: Deltaflow. 

Deltaflow is a modular solution, which works across different qubit modalities and can be adapted to meet the needs and hardware maturity of individual systems.  

Developing Deltaflow requires a robust approach, which I’ll outline in this post.  

Multiple qubit types

There are many factors to consider when developing the QEC Stack across qubit types.

Broadly speaking, these include:

1. Speed: qubits with faster gates need faster decoding to prevent a backlog of error data building up and grinding the quantum computer to a halt.
2. Connectivity: this determines which quantum error correction schemes can and cannot be realised on the qubits.
3. Maturity: the closer a technology is to doing a real-world demonstration, the more urgent the need for QEC.
4. Portability: if a qubit type is similar to other qubit types, then it’s easier to rework existing QEC solutions.

At Riverlane, our expert team is highly conscious of the differences between qubit modalities. 

So, we have made some QEC architectural decisions and committed to three tracks of Deltaflow development, aiming to maximise the reuse of components. 

In addition to supporting all three tracks, our team also keeps up to date with the scientific literature and explores new architectures to be considered for addition to future roadmaps. For example, here’s some recent work from the team on Floquet codes and how to use them on a device with defective qubits.

The main differences between tracks are:

1. Suitable qubit type;
2. Logic instruction set used for quantum error correction, namely: lattice surgery (1) or transversal logic (2) using the surface code, or qLDPC codes (3).

Track 3 is the most flexible of the three. The idea is that we can easily pivot to support up-and-coming qubit modalities under Track 3.

QEC codes

There are a range of quantum error correction codes, each of which works by encoding the information in a logical qubit across a large number of physical qubits to protect the information from errors.

Recently, there has been a lot of discussion in the quantum community about the surface code and qLDPC codes. At the time of writing, the surface code is the most mature QEC code. qLDPC (quantum low-density parity check) codes are less mature but there have been many recent exciting theoretical breakthroughs. 

I should also mention there are a range of alternative codes – but these two are generating much debate amongst quantum researchers. 

A quantum low-density parity check code is one which can be implemented by measuring only small sets of qubits, and not measuring any one qubit too often. For practical reasons, almost all quantum codes are LDPC, including the surface code, so when people talk about qLDPC codes they normally mean a code that beats the surface code in some particular way - often using far fewer qubits to protect the same amount of information. 

The surface code benefits from: 

1. A high threshold (a physical error rate below which we can suppress errors and allow the calculation to run). 
2. Compatibility with strictly 2D qubit arrays like superconducting and silicon. 
3. Decoding maps to graphical problems, which can be solved fast and in real-time at MHz speeds. 
4. Several well understood routes to logic including lattice surgery and transversal gates. 
5. Being stress-tested by years of research. 

In other words, the surface code is a safe bet. But it’s not the only potential solution that we’re investigating at Riverlane.

Unlike standard planar surface codes that encode a single logical qubit, qLDPC codes can encode multiple logical qubits. Such efficiency gains become increasingly important as we scale quantum computers to the point where they can tackle complex real-world problems.

At Riverlane, we measure the usefulness of quantum computers using the ‘QuOp’. One QuOp is, essentially, one error-free quantum operation. Today’s machines are capable of a few-hundred QuOps but we need millions, if not trillions, of QuOps to unlock real-world applications.

The choice of QEC code impacts when we could reach this regime. For example, when using the surface code, each logical qubit may require hundreds of physical qubits to realise a MegaQuOp (million error-free quantum operations) and thousands for a TeraQuOp (trillion error-free quantum operations).  

If we can use an alternative, like a qLDPC code, then this boosts the efficiency massively and means we could reach the MegaQuOp and TeraQuOp regimes with fewer qubits, and, therefore, sooner. But qLDPC codes put bigger demands on qubits, such as much more complex connectivity. 

The most natural candidate qubit modalities for qLDPC codes are neutral atoms, ion traps and longer-term photonics (which currently have lower qubit counts). These modalities are reconfigurable allowing qubits to be moved around and realise any QEC code. 

There have been several recent breakthrough proposals for other modalities.  

Quantum computing startup Alice & Bob is developing cat qubits that are intrinsically more resilient to one type of (bit-flip) errors, but they still need a code and QEC stack to handle other (phase-flip) errors. So, they may only need a “classical” code to reach MegaQuOp scale.  

Early cat qubit proposals (from A&B chief theorist and AWS) used a simple, classical repetition code. Recently, Alice & Bob and collaborators have proposed combining cat qubits with LDPC codes (no “q” because they are classical), which is exciting because they can be built in 2D and reduce the number of cat-qubits needed.

Secondly, a paper from IBM, which graced the cover of Nature, created a qLDPC code that, for quantum memory, performed as well as established error-correction protocols but crucially needed only about one-tenth of the qubits.   

Realising IBM’s bold vision for a qLDPC compatible (high-connectivity) superconducting system will require several breakthroughs in qubit design and fabrication. So Riverlane’s three-year roadmap doesn’t yet target this combination of code and qubit. But we are watching developments closely. 

These are all important results – but have yet to be demonstrated on real devices.  

Developing qLDPC codes is an exciting direction and the payback could be huge. Classical LDPC codes, for example, revolutionised how we communicate, allowing for efficient classical error correction, making sure that our messages, calls, and internet connections are clear and stable. They are the unsung heroes behind the seamless connectivity we often take for granted. And just as LDPC codes have been a game-changer for classical communications, qLDPC codes hold the promise of being a game-changer for quantum computing. 

At Riverlane, we view qLDPC codes as a high-risk but high-reward approach and one that deserves a significant portion of our attention.  

The team’s recent work on a new ‘Ambiguity Clustering’ decoder, for example, has shown promise, with initial results showing this is 150x faster than Roffe’s implementation, which is the industry standard qLDPC decoder. Ambiguity Clustering is now available in our analytics tool, QEC Explorer.

Lattice surgery versus transversal logic

Lattice surgery or transversal logic are ways to perform error-corrected logical gates. We need to perform one of these techniques to perform algorithms that unlock the full potential of quantum computing. 

The choice between lattice surgery and transversal logic is somewhat dictated by the qubit modality and there are pros and cons to both. 

First, let’s look at lattice surgery. 

Broadly speaking, the surface code is restricted to encoding a single qubit. Lattice surgery is crucial for enabling interactions among multiple encoded qubits, ensuring that its sophisticated error-correcting features are maintained without significantly increasing the operational overhead. 

Here, we represent one logical qubit by a patch composed of physical qubits. A logical qubit can interact with another logical qubit when you can perform two-qubit gates between the physical qubits along the edges of the logical qubit patches.  

Lattice surgery involves resizing and moving these logical qubits so that they can interact with each other. The interaction itself is also part of lattice surgery, even if no moving or resizing is required. 

When it comes to transversal logic, instead of interacting two patches along their edges (as done with lattice surgery), two logical qubit patches are physically moved with qubits matching pairwise to perform a “transversal” two-qubit gate. Entanglement is generated directly through regular gates between vertices lying close together.

This method is particularly attractive for neutral atom and ion-trapped architectures because it can provide over a 10x speed-up (perhaps even 100x) by reducing the number of QEC cycles needed compared to lattice surgery.

Indeed, transversal logic is crucial for neutral atoms and ion traps as they have slower physical gates (more than 100x slower) than superconducting qubits, so each QEC cycle takes longer. Because neutral atoms and ion traps have slower QEC cycles, one might think that decoding is easy and does not require a fast solution. However, transversal logic poses a much more complex decoding puzzle known as a correlated (or hypergraph) decoding problem and so a fast solution will still be required to overcome this additional complexity.

In conclusion, to develop our QEC Stack, Deltaflow, across multiple qubit types, we must also develop a range of techniques to help our quantum hardware partners unlock the true potential of their qubits.

If you’d like to find out more about our work and partnering with Riverlane, please email us team@riverlane.com.