Earl Campbell, VP of Quantum Science at Riverlane, is interviewed by Yuval Boger. Earl and Yuval discuss the challenges and solutions in making quantum computing practical, including creating reliable qubits in large numbers and managing noise as systems scale. Earl emphasizes that the number of physical qubits needed for a logical qubit varies based on error rates and the type of error correction code used. He notes his belief about upcoming breakthroughs in the industry and much more.
Full Transcript
Yuval Boger: Hello, Earl, thank you for joining me today.
Earl Campbell: It’s a pleasure to be here.
Yuval: So, who are you, and what do you do?
Earl: My name is Earl Campbell. I’m VP of quantum science at Riverlane and at Riverlane we’re working to make quantum computing useful sooner. So at the moment, what that means at Riverlane is that we’re building systems for error correction, control systems and also working on quantum algorithms.
Yuval: What is the biggest hurdle you think right now? You mentioned a couple of things. What’s the biggest hurdle to making quantum computers useful?
Earl: Making reliable qubits and enough of them and the infrastructure to make those qubits reliable. I think those are the key issues. So I think there are systems where people have demonstrated really good one and two-qubit gates between one or two qubits. As you go to hundreds of qubits, which is where some of the bigger systems are at the moment, noise starts to get a little bit out of hand. And there are a few systems that can really kind of reach that scale with error rates of anything better than about 1%. So that means that if you do 100 quantum gates, then you’ll most likely have already encountered an error.
Yuval: Let’s assume I’m a quantum computing vendor and, say, a superconducting one, and I’ve got a working system. It’s got 50 qubits. It’s got some error rate. How do I work with you? What can you deliver to me, and how would you make my system better?
Earl: There are many different ways that we work with hardware partners. One of the main ways that we work with them is by helping them with error correction problems. So, if you don’t know anything about error correction, then we can help you even design what the first experiment might look like. And one thing that we also do is that we can help people with decoding. So this is a big part of the work we do. And this can work in a few different ways. We can design a single experiment or an architecture that you might want to work towards for a larger system. We can decode in post-processing some of the results of those decoding experiments. Or even grander than that, we can do real-time decoding experiments together. So what this means would be taking something that we have, our decoder IP, and then putting it on someone’s control system and then decoding in real-time. And we can go even further than that because RiverLane has its own control systems. So we can deliver a complete packaged, integrated control and decode system to help you do error correction.
Yuval: Could you explain what a decoder is? Is that something that happens during the calculation? Is that something that happens in post-processing that helps me overcome errors? What is a decoder in the context of error correction?
Earl: So there are two different scenarios there that we’ll have to break it down into a few steps to understand what’s going on. Maybe I’ll just talk about what decoding means first before getting into the differences between real-time and non-real-time. So when we perform error correction, we’re performing a circuit over and over again that is measuring some observable of the system and then seeing if it’s changed its value in time. So if I measure one observable and then I measure it again at some later time and I haven’t done anything that should disturb that measurement, then I should expect to get the same value. And if I see a change in value, then that indicates that an error has happened somewhere in that circuit. And so we have this stream of measurement data that’s continuously coming out of our qubits, and taking this data and then figuring out what happened to the qubits and what corrective action we need to take is called the decoding problem. And so this is a fairly large data problem. There are some back-of-the-envelope calculations that indicate that for a large, let’s say, million qubit fault-tolerant quantum computer, the volume of data would be comparable to all of the global data, all of the global traffic of Netflix. So that’s quite a lot of data, and you’re trying to process it in real time and not just move the data around but solve the decoding problem. So kind of work backward from the measurement results you saw to what most likely happened in the system.
So it turns out that for most error correction schemes, if you’re just preserving a logical qubit for some amount of time, so what we might call a quantum memory experiment, then, in fact, you can perform decoding after the experiment is completed. So, if we look at some of the real landmark experiments that have happened in the last couple of years, like the one by Google that showed that when they went from a 17-qubit surface code to a 49-qubit surface code, the logical error rate went down, they collected all of that data, and they decoded it at some point at their leisure. And in fact, they put it online, and you can still go and decode that data with your decoder now. But the need for real-time decoding arises when you want to do gates. So when you start doing logical gates, then the outcome of one decoding problem determines what gates you have to do later. There’s a kind of adaptiveness that is required. And so you can’t just leave it to some arbitrary late time because you need to solve that decoding problem before you do your next gate. Sometimes, I paraphrase this as the speed of your decoder determines the speed of your quantum computer because the faster you can decode, the faster you can do logical gates.
Yuval: In your experience, how many physical qubits do I need to get a high-quality logical qubit? And does that change with different modalities?
Earl: Great question. So, the number of physical qubits you need to make a logical qubit will depend on a few different things. It will depend on the choice of error correction code, what the noise model is like, how noisy the qubits are, and how good your decoder is. So, let’s just pick a specific example. So, let’s say we’re talking about the well-known surface code that Alexei Kataev first came up with in the 90s, which is a really lovely code because you can implement it in 2D. And so this is a favorite, especially in superconducting systems. So let’s say we take the surface code and we consider just a fairly standard decoder like Minimum Weight Perfect Matching. And we say that the error rate uniformly across these qubits is about 0.1%. So, the error correction threshold that you need to get below is 1%. But if you try and build a fault-tolerant quantum computer at around 1%, the overhead will be enormous. So, we need to get comfortably below the threshold. 0.1% is a kind of reasonable number because it’s fairly below the threshold. And people have seen numbers around 0.1% in small demonstrations of one or two qubits; they just don’t see 0.1% error rates at scale. So it’s something we know we can do. So if you take all of those different settings, then what you end up with is that to suppress error rates down to say, one part in a trillion, you’re going to need about 1000 physical qubits. So that’s the kind of good baseline from which you can then go on to talk about other modalities, other codes, other decoders. Now, of course, I’ve given you an optimistic estimate of what error rates we might be able to achieve. The main thing that happens when you talk about different modalities of qubits is that you change the error rate that you’re likely to have. As I said, the error rate that often people have at scale is about 1%. The kind of realistic, optimistic thing at scale is maybe 0.1%. If you take that 1% number, sorry, that 0.1% number, and you move it higher, so the qubits get noisier towards 1%, that 1000 qubit number explodes towards infinite qubits. So what that tells you is that you really do need to have a qubit modality that is going to bring you comfortably below that 1% number. Then if you go below 0.1 further, again, the number of qubits you need goes down and down and down, but it doesn’t necessarily go down that rapidly. And so to me, once you get down to error rates about one part in 1000, so 0.1%, really what becomes important is more how fast you can do the gates and how cheap the qubits are rather than the error rate.
Yuval: So you mentioned 1000 physical qubits to a logical qubit in your example. Now, as I think of the IBM roadmap, for instance, they’re about to announce a 1000-qubit chip or will announce it soon. And so if they implemented what you just described, you would have one logical qubit, which is fun but probably useless. So, are you a couple of years ahead of the market in terms of having something that the market doesn’t need for a while? Or do you think that people can use such a product today?
Earl: Yeah, I think I was just giving a baseline example of a specific kind of error rate and code and what you would need to get the error rate all the way down to one part in a trillion. So, one part in a trillion is much lower than one part in a hundred. So there are actually many, many stepping stones along the path to get into what we sometimes call the TeraQuop regime, which is where you’re trying to get error rates, logical error rates, down to one part in a trillion. So many of the partners that we work with at the moment are at the stage where they’re trying to demonstrate that they can do error correction. The qubits are of sufficient quality now that they can suppress logical error rates. And so, and usually, they’re thinking about just doing it for a single logical qubit. So in that sense, I don’t think we are ahead of the market because many of the people we work with are struggling to figure out how to do these things themselves and what the requirements are for their system. And indeed, the IBM example you gave is a great one because what code you choose to go with can influence how you build your device. So, if IBM had a thousand qubits, they wouldn’t actually be able to do the thousand qubit surface code because most of their devices are currently built with something called the heavy hex lattice. And this was actually the result of some kind of earlier architecture they worked on. They were led by Christopher Chamberlain and some others, where they looked at a specific code that they thought would be nice. And the nice property of Annet was that each qubit only interacted with three other qubits instead of four other qubits. And the IBM fixed frequency transmons, they don’t like to be connected to a large number of qubits. So, for IBM, this was an attractive thing, but it does mean that to achieve the same amount of error suppression, they need even more physical qubits than if they were using the surface code. So, they chose some time ago to go in this direction of having fewer connections because that was easier for them to realize. And the most recent update to the IBM roadmap is that they’re going to go completely the opposite direction now. They’ve been advertising that they’re going to go towards QLDPC codes, which require much higher connectivity and longer-range connectivity. And the attraction of those is that assuming you can engineer these things, the number of qubits you would require is far fewer. So there are claims and some numerical simulations to back up the claims that you might need, say ten times fewer physical qubits per logical qubit if you use QLDPC codes instead of the surface code. But there are still some pretty immense engineering challenges for people to overcome before they demonstrate the first QLDPC code logical qubits.
Yuval: Assuming everyone wants error correction, which I think is a given. And the various codes, surface code, color code, Steane code, [8,3,2] code, whatever are known. Where is the difficulty for people to do it themselves? Is it in a really fast sampling? Is it in taking that data and converting it to something useful fast enough? What is the unique value that Riverlane brings?
Earl: Oh, it’s almost every step of the journey. I mean, I think the hardest end of the spectrum of things that we do is that we build the hardware decoders that work in real-time. And so to do this, what we have is we have a team of people, including scientists with a background in error correction like myself, some people who have come from other backgrounds like mathematics and computer science, and then digital design engineers with a background from some of them came from ARM, for example. And so assembling that team, getting them to learn a common language is really a non, you know, it’s a lot of work, and it’s a big investment for most companies, it’s going to be far too big of an investment for them to make themselves. And the fact that we are doing it on behalf of many, many different hardware companies means that there’s a kind of… Yeah, we can do a much better job than if you split all of those people up equally between all of the hardware companies. I mean, all those people would be duplicating efforts all over the place. So that’s one very hard engineering end of the spectrum. I find that even fairly, kind of more near-term architectural questions like what should my first logical qubit look like? Most companies don’t have enough people who have the years of experience of looking at lots of different QEC codes to be able to tell what would be best for their system.
Yuval: People have been speaking about a quantum chat GPT moment where all of a sudden, the industry realizes that this is great and you should really jump into quantum. What is that moment in your view? What needs to happen, or what’s the demonstration, or what’s the technical threshold that gets the industry to this moment in your opinion?
Earl: Yeah, that’s another great question. I think sometimes people get stuck in local minima in their thinking, and they remember the most recent thing that was a big moment. I’m sure that actually, there have been many big moments across the years for AI, and there are many more of them down the road. So definitely, chat GPT was a big moment, but there are actually lots of incremental advances, some of them building up to chat GPT. So there’s the famous Google transformer paper that was out several years before the big chat GPT moments. So in fact, you only in some sense learned about the impact of that earlier transformer work many years after the big breakthrough was made and it took a while for people to catch up. So yeah, I’m kind of a little bit skeptical of fixating on moments, but let me try anyway. I think we’ve already had a few great moments in the field, but there’s certainly some more that we need to overcome before.
So I think I mentioned one really great experiment already that came from the Google team, which was this demonstration of a logical qubit. So I think you were saying, look, there’s a long way to get to a thousand physical qubits, but in fact, the fact that we’ve seen error correction work in the sense that when we go from a smaller system to a larger system, the reliability of the qubit improves, which is really the hallmark feature of error correction. The fact that that has happened was a massive milestone. And indeed, if you asked me, uh, when I started my Ph.D. back in 2005, what I thought the prospects were, even though I was working in the area, I maybe it wouldn’t have even been that optimistic that it would have happened by that point in time.
And this is because back in 2005 at the surface code wasn’t very well known. Uh, in fact, we thought that if you wanted to do error correction, you needed to reduce error rates to below one part in a million, one part in a million, not 1%, one part in a million before it even starts to work. And you know, I was going to talks by experimental groups that were really world-leading and they were still stuck around 5% error rates. So really, there was this gulf of, you know, four or five orders of magnitude between where we were and where we wanted to be. So there has been a massive, um, shift. We’ve crossed a threshold literally, but that still means that there’s quite a lot of work to do and where that work, uh, where the bottlenecks are, is different for different qubit types. Um, and also for different aspects of the stack. So I think there have also been big moments in error correction from the decoding side in the last year. So Riverlane had its paper out about its FPGA and ASIC decoders, um, where we found that we could go up to very large systems, uh, decoding fast enough to keep up with the error correction cycle whilst also having very kind of low memory and power usage. Um, other similar results were seen by, uh, the Yale University team.
And you know, this is also another problem where if you go back, let’s say even to a conference on error correction back in 2017, I remember Austin Fowler from Google standing up and giving a talk and talking about his attempt to build a decoder that was fast enough. And he really had thrown everything he could think of at the problem. And still he was at least 10X off where he wanted to be. Um, so there’ve been a few breakthroughs.If we think about superconducting qubits, you mentioned the large, uh, IBM chip was of order about a thousand qubits. I think there’s a reason why the largest one they have is about a thousand qubits, and that reasons cables. Um, so there’s a big kind of control electronics slash, uh, cabling, cooling power bottleneck that you hit around a thousand qubits that you really have to engineer your way around. So the really big moments will be when we find ways to massively compress all of those electronics, reduce the power consumption, and get everything in a kind of nicely packaged units that you could really pack many more than a thousand qubits in. And for that, we need progress on multiple fronts.
Yuval: We spoke a lot about superconducting qubits, but obviously there are other modalities. Do you feel that a certain modality is better or worse than others in the march towards error correction?
Earl: Yeah, I think, many different qubit, all the qubit types have different advantages and different hurdles that they have to recover. So I know that you work at QuEra, and there have been some brilliant advances in neutral atoms in recent years. So really, it’s jumped ahead in terms of the, uh, the number of qubits that they can handle. And you know, many people predict that, uh, neutral atoms might be the first platform where they have tens of thousands of, of qubits, uh, partly because they don’t have the same bottlenecks around a thousand qubits that some other systems have. Um, of course, you know, there are disadvantages. I think people maybe fixate on qubit number over other important metrics. The amount of time it takes to perform logic is also very important, and a round of error correction or the time it takes to do a logically error-corrected gate in both neutral atoms and iron traps can be many orders of magnitude longer than it is in a superconducting qubit or perhaps even silicon qubits. Um, yeah, so there, there are, there are many trade-offs to be considered.
Yuval: As we get close to the end of our conversation, I wanted to ask you a hypothetical. If you could have dinner with one of the quantum greats, dead or alive, who would that person be?
Earl: Oh, wow. Uh, I think I’d be lucky to have a dinner with quite a few great people already, but um, let me see. Um, I suspect most of them were alive, so you know I’ve expanded the universe. You could actually choose the dead people as well. Yeah. I may be going to go with Alexei Kitaev. Yeah. And why? Why? Um, well, Alexei Kitaev invented the surface code. Uh, so he’s very important for that reason. He’s done lots of other great work. Another topic that, uh, actually, for me personally, had a huge impact on my trajectory was magic states. So I spent a long time working on, um, magic state theory and factories. So this is a way of doing non-Clifford Gates in fault-tolerantly and, uh, really a landmark paper in that field. Uh, that subfield, should I say, was by Alexei Kitaev and Sergey Bravi and had a huge impact on my career. Um, I’ve already had the luck, the, uh, you know, the, the lucky pleasure of working with Sergey Bravi. So I know him quite well, and I’ve seen Alexei Kitaev from afar on the Caltech campus, uh, walking past as he rushed off to get his lunch, but I’ve not actually met him in person. And so, if I could grab Alexei at the Caltech campus and have lunch with him, that would be great.
Yuval: Wonderful. Earl, thank you so much for joining me today.
Earl: Thank you, Yuval.