If I say “quantum internet”, you probably think of an upgrade to our current internet. Faster? Safer perhaps? More reliable? Something along the lines of “internet everywhere and for everyone all the time” might come to mind. That's the narrative echoed across LinkedIn at least ... Yet after four years in this field, I still don't see the bridge between that idea and the actual reality of quantum internet research. To me, the “quantum internet” means something very different: it's about distributing quantum correlations in a network, enabling things like collaborative sensing, atomic clock synchronization, long-distance non-local experiments, quantum cryptography, and maybe one or two more niche technologies. Could we one day see quantum networks improve or reshape what we understand as “the internet”? Perhaps. Quantum cryptography is a strong candidate. But the misnomer we've created, and keep reinforcing, is a real issue. It fuels a flood of papers proposing new architectures with little regard for the actual physics. This blog post aims to dive into what makes distributed quantum computing fundamentally different from a classical networking problem. Because after all, new problems mean new opportunities.

The Quantum aspect

So what does the Q in DQC entail? First of all, any quantum computation can be fundamentally thought of as a large quantum state, made up of multiple qubits, correlated amongst themselves. Every time you implement a CNOT gate between two qubits, you're creating a new correlation between them. At the end of the day, all a quantum circuit does is build a big graph state aka an interconnected network (not in the networking sense) that encodes and processes a problem. A quantum network's job is to distribute this quantum state (which is itself a network) across its nodes, like a matryoshka doll. It IS NOT meant to send data across, but to send correlations across. The difference is important, we will come back to it. For now, let's focus on these correlations, also known as entanglement. Our first quantum beast. A quantum state (aka a qubit) is encoded as \( |\phi\rangle = \alpha |0\rangle + \beta |1\rangle \), with \( \alpha \) and \( \beta \) complex amplitudes such that \( |\alpha|^2 + |\beta|^2 = 1 \). When two qubits are entangled, their joint state becomes indistinguishable: \( |\phi_1\rangle |\phi_2\rangle = \frac{1}{\sqrt{2}} (|00\rangle + |11\rangle) \). One way to create this entangled state is by sending two photons with different polarizations through a beam splitter, letting them interfere, and selecting the cases where they exit in separate paths. There's also such a thing as pseudoentanglement. This occurs when states are correlated in a way that looks like entanglement, but isn't quite. Both entanglement and pseudoentanglement are considered resources for quantum communication. They are things we "burn" when we distribute quantum computations across devices.

Our second beast is the no-cloning theorem. As I said before, the name of the game here is not data transfer. And the reason is quite sound: we can't copy quantum states. The no-cloning theorem states that it is impossible to create an identical copy of an arbitrary unknown quantum state. In classical networks, data can be freely copied for redundancy or routing. Quantum networks can't do that. No fan-out. No replication. No repeaters as we know them. It's all out the window. Memories are also a problem, although incredibly speedy progress is being made. (This was actually the topic of my first patent: quantum memories for networking, a very exciting and deeply problematic challenge.) Not all is lost tho, data movement can still be helped along with classical crutches. We can forward information if we combine a quantum connection with a classical one, sidestepping the copying issue. It's a simplification, but one I found useful when I first entered the quantum communications world. This is a whole new paradigm, with a whole new set of problems and opportunities. Straightforward classical translations won't always work, as the purpose of these communications is simply different: Correlations, correlations, correlations.

Our third beast is a fun one: measurement collapse. Schrödinger's cat is no longer superposed between life and death once we look into the box. It chooses its state. It collapses down to one of its two binary values. It becomes a bit. In the same spirit, when we measure qubits, they collapse into classical outcomes. They can't be copied, and they can't be re-used after being observed. This has a crazy upside: built-in cryptographic detection. You copy -> you kill -> I notice the qubit is gone -> I shut down the compromised communication. A one-tap wonder, if properly executed. Measurement collapse is also what enables the classical crutches I mentioned earlier. In the teleportation protocol, classical information obtained from measuring entangled qubits is sent to a receiving party over classical channels. They then apply a correction to their half of the entangled state and recover the original global quantum state. In this way, classical comms can help quantum comms forward information. But teleportation comes at a cost: the entanglement shared between parties is consumed (the qubits have collapsed), and we need at least two classical bits for every qubit teleported. This entanglement must be created ahead of time, distributed, and often purified (distilled). An expensive and fragile process.

Local is now Global

Because the quantum distribution game is a correlations game, not a data forwarding game, a new reality arises. The idea of locality can be violated. A change in one node can instantly affect the entire global quantum state. This is because distributed quantum systems often maintain entangled states across nodes. In classical computing, local operations affect local memory. In distributed quantum systems, even a local gate may have non-local effects. This violates classical assumptions about node independence. A single phase shift on one qubit can change interference patterns across the entire system. Fun thing to deal with when your qubits are fragile...

Due to this, error propagation becomes a serious challenge. In classical systems, faults are local, isolated, and often detectable. But in quantum systems, errors can spread through entanglement. They can even occur at the level of the entanglement generation and distribution itself. We don't just have to deal with bit flips on individual qubits, but with corrupted correlations. In this framework, classical fault isolation breaks down. An error on one node of the global state can trigger a cascade across the system. This interconnectivity is the power and the achiles heel of quantum computing. Even simulations are non-trivial when we can't just cut up a large computation into partitions to run them independently. Unless there were clear un-connected subgraphs in the larger global graph state, cutting up a large graph without interconnecting its partitions would not be equivalent to the original graph.

Furthermore, synchronization can be quite the issue if not dealt with properly. Qubits are fragile things requiring precise timings and control alignments. Even nanosecond-scale timing drift can cause an entangled pair to decohere before it's useful. Distributed gates require tight control over laser pulses, clocks, and coherence windows.

The sun will come out: tomorrow

The good news is that for those of us who missed the original internet boom (we were lazy, waiting to be born and all that), we've got a new round to play. This time, the name of the game is correlations. They're fragile, unpredictable, and break down a lot of the convenient architectural assumptions we're used to. Different labs and devices still can't plug into a shared network without custom glue. The translation layers aren't set in stone yet. It's a new dawn for networking. And for one, I can't wait to see the new applications it will bring.

Distributed Quantum Computing (DQC) is not just a near-term workaround, it's a long-term necessity. Practical physical constraints such as decoherence, gate errors, and crosstalk place strict limits on how large a single quantum processor can be, i.e. how many qubits we can fit into one chip. Given the excessive physical qubit requirements needed for error correction and the implementation of useful algorithms, we are exploring distributed architectures: networks of quantum processors coordinated to act as one. This relatively recent shift in the quantum landscape has opened up a host of new challenges. In this blog post, I intend to walk you through some of the most important theoretical issues that have arisen in the wake of DQC, ranging from error fragility to temporal coordination and algorithmic decomposability. We'll map the nooks and crannies of the DQC problem space, where physics, architecture, and computation collide.

So the main question we're facing is: How do we connect and coordinate multiple quantum devices, possibly alongside classical devices, so they can collaborate on a task they couldn't solve individually due to physical constraints? As you might expect, there is no straightforward answer. For one, we're (or at least may be) dealing with two kinds of devices, quantum and classical, and two kinds of channels, again quantum and classical. That gives us a combinatorial mess of interactions: quantum computers communicating over quantum links, over classical links, interacting with classical processors, and all the hybrid setups in between. Let's also not forget what we're trying to send around: fragile quantum information. Qubits have short lifetimes, their error tolerance is pretty poor, and coherent control is still noisy and slow. Worse still, we're not just trying to manipulate them, we're trying to fly them across a network and use them at the other end. To make things even trickier, that's just hardware; believe me, the software end of the stick doesn't help either. We have maybe ten quantum algorithms that are practically useful today. Most quantum toolkits are still in their infancy, and we're only beginning to build the foundational layers of the quantum software stack. Robust languages, compilers, and coordination protocols? Not there yet. Probably not close to be honest. On top of all that, DQC adds yet another layer to this barely functional stack. Can we really cope with the added complexity? How will we achieve interoperability across devices, vendors, and platforms? Let's take a deep breath and dive into some of these issues in more detail.

The Error Problem

The first horse of our apocalypse has been tormenting the monolithic world (those normies working on single quantum devices) for decades now: errors! Errors, errors, errors... If something is capable of driving this field into the ground, it will be errors. We have an entire field, arguably two (error correction and error mitigation), purely designed for fighting them. Entire careers have been built around fixing the swifty quantum errors, many more will follow. With DQC, we now get to ask these poor mathematicians and computer scientists who have been struggling to fix errors on a single device for decades: How should we fix errors at a network scale? Do we design a global error correction code like qLDPC for our entire system? Do we use a modular approach, stitching together local surface code patches via teleportation or lattice surgery? How do we balance the trade-off between global encoding efficiency and local modularity in networks that may have variant use of individual devices? The answer? We don't know, and frankly we've barely started to scratch the surface. Any Uni of Edinburgh error correction PhD student has been pursued by me to look into this - I recently caught one, stay tuned for future work in the error correction space ;). But back to business: we don't know what the DQC-EC world is going to look like. What we do know is what the DQC-error landscape looks like. The current status, as you might expect, is that individual device noise is not the problem, but communication noise is. Sure, individual devices may be noisy to unusable levels, but their individual noise is laughable compared to their interconnected counterpart. Quantum Data Centres: A Simulation-Based Comparative Noise Analysis by Kenneth Campbell, et al. would be a good further reading on this. But the TLDR is that communication is — and will be — the bottleneck of error correction and mitigation in DQC. That's what we should focus on. Figuring out how to fly qubits around without destroying all the useful information they carry.

The Composition Problem

Next, we've got the network composability problem. As I mentioned earlier, two technologies, two applications, way too many permutations. We know that "simulating" a quantum link over a classical one (aka probabilistically decomposing the channel) is quite expensive. It's a short-term solution to interconnect devices whilst we resolve physical mobility limitations for qubit technologies that don't directly interface with photons and require interconnects, and a placeholder to the error issue. But when it comes down to quantifying how bad it is, beyond just the re-shot cost, answers get murky. We, or at least I, don't know. So the question remains: can we compose systems through this dual network option without breaking the system? Will there ever be a viable hybrid solution where sometimes we can use cheaper classical channels at the expense of other resources?

The Beyond-Necessity Problem

Parallelism speedup is another one that I am particularly interested in. In the classical world, a big driver of why we started building distributed systems was the benefits offered by parallelised algorithms (algorithms designed to run multiple operations on various devices such that the overall execution time is reduced). But quantum computers have a sort of "native" parallelism: multiple qubits can be manipulated simultaneously. So no real parallelism is offered by a network; within one device we can already perform various operations. Of course, the fidelity at which we can perform these operations or the number of them might be limited, but really that limit is the qubit limit, aka the reasoning that we distribute quantum computation because we can't fit it in one device. Still, could there be other reasons to do that?

The Compilation Problem

Another big question is: How do we design or compile quantum workloads in a distributed setting? I think there are four main levels at which we can look at this question: the problem, the algorithm, the subroutine, and the model.

1) Problem → There are a few problems that are supposedly well suited to quantum computers, i.e., we think QCs will provide some sort of advantage or speedup in solving them over classical computers. An easy one to reason about is Hamiltonian simulation (in many quantum devices it can be emulated), but others exist: unstructured search, optimization problems, the hidden subgroup problem, linear equations, etc. At this level, the current approach is somewhat straightforward: we cut up the problem space into local problems. Think of a Hamiltonian: here you would partition its problem space into local Hamiltonians that can be solved on individual devices and look at how these local Hamiltonians interact with each other across the evolution of the problem. These interactions would be mapped to communication Hamiltonians, which are run as teleportation protocols over the connective channels, making the total Hamiltonian = sum of local Hamiltonians + sum of communication Hamiltonians.

2) Algorithm → Next, we look at the algorithms being used to solve these quantum problems. This would be your Grover, Shor, QAOA, Trotterization, etc. Some of these are starting to get distributed variants. The idea is to take a global function f and decompose it into 2^k sub-functions f_i, each defined over a reduced input space {0,1}^n−k. You then run many quantum circuits in parallel, each searching a different subspace. This distributes both the memory requirement and the query load, allowing each node to operate on (n−k) qubits instead of the full input.

3) Subroutine → Below most quantum algorithms there are subroutines, which you can think of as "reusable" components across various algorithms. Things like VQE, QFT, state preparation, oracles... Distributing subroutines looks similar to the algorithm and problem levels. Often they are solved through them. The general idea is once again the decomposition of the subroutine into local and communication components, which are driven by a cost function and mixing operators such that variational parameters are updated. By updates I mean that an initial run of the cut-up system is executed, read, and the classical result injects the new initialization for the next run.

4) Model → Finally, the model level is the only truly "flexible level", meaning it should allow for distribution of any workload. Various theoretical and implemented quantum computational models exist today: quantum circuits, measurement-based quantum computing, quantum walks, boson sampling, etc. At this step, operations are abstracted into connected nodes where connections represent sections of the workload that can be replaced with communication primitives if they are run over various devices. These primitives are in essence small quantum circuits that ensure the teleportation of the qubit(s) or the implementation of a non-local quantum gate over two devices. Post-abstraction, the graph (or hypergraph, if you are working with a model that has qubit operations with more than two qubits) is cut up, it basically boils down to a graph partitioning problem (spoiler alert: NP-hard).

Closing Thoughts: DQC's Theoretical Frontier

So far, we've looked at the mess of challenges that show up the moment you try to stretch quantum computation beyond a single chip-errors, links, timing, algorithms, abstractions. These aren't small tweaks; they force us to rethink what computation looks like when it's not confined to one box. In future posts, I'll dig into what it means to actually transform circuits for distribution: which cuts are cheap, which ones break things, and how to track the cost of coordination. Dwelving into how DQC is not just a hardware problem, but a compiler and design problem too.

PS: I'll be giving a short talk on these issues at FQC 2025 this week. You can find my slides here: DQC: The 5 Minute Blitz (slides). They might be useful to illustrate some of the ideas described in this text.

Building ever-larger quantum computers by simply adding more qubits into a single device isn't a sustainable strategy. Let's look at why:

No matter how small we make qubits, we are still constrained by fundamental physical limits. One such limit arises from the area law in quantum physics, which states that the entanglement entropy of a subsystem (a measure of quantum correlations) scales with the boundary area of that subsystem. This concept was first introduced in black hole thermodynamics by Jacob Bekenstein and Stephen Hawking in the 1970s, who found that a black hole's entropy is proportional to the area of its event horizon. In the context of quantum hardware, this means that as we build larger devices, the entanglement structure becomes increasingly complex along subsystem boundaries. Managing these correlations (generating, routing, and maintaining them accurately) is a growing challenge, especially in architectures with limited connectivity or distributed components.

Errors can arise not only from external noise but also from internal mismanagement of these correlations. Entanglement that is too weak, too strong, misplaced, or accidentally extended can all lead to computational faults. Unlike classical bits, quantum information is deeply relational: getting the structure of these relationships wrong introduces logical errors, even in the absence of decoherence. The challenge is not just to keep qubits isolated from the environment, but to ensure they are entangled with the right partners, in the right way, at the right time.

At some point, adding more qubits to a single device is expected to yield diminishing returns, due to the increasing complexity of correlation control and system architecture. Building wide forever is not viable. Instead, we must build tall and distribute computations across multiple devices rather than growing one monolithic system indefinitely. This architectural shift offers a path to scalability without running into the hard limits imposed by correlation structure, control precision, and spatial layout.

These challenges are reminiscent of the obstacles faced in classical computing during the late 20th century. In the late 20th century, classical computers hit expected physical limits, similar to the ones we are predicting in the quantum world. Moore's law kept pushing the number of transistors up, but at some point, packing more into a chip caused too much heat and reliability issues. Processors started to run into both physical limits (how small you can make features) and thermal limits (how hot the chips get). By the 1980s and 1990s, it became clear that scaling a single processor indefinitely wasn't going to work. Clock speeds stopped rising dramatically after the early 2000s because of these heat and power problems. So we stopped building wide, and started building tall. People started working with multiple processors and building distributed systems. Instead of making one super-powerful chip, we started connecting lots of smaller chips together. Thus, avoiding the physical limits of single-chip designs, whilst still growing system size and performance. This is how concepts like cluster computing, parallel computing, and eventually cloud computing took off. Instead of making one super-powerful chip, we started connecting lots of smaller chips together. Famous early examples include Beowulf clusters (mid-1990s) for scientific computing, and Google's early distributed file systems and computing frameworks (like MapReduce, early 2000s) for handling web-scale data. The key takeaway from the classical distributed world beginings was: When scaling one machine hits a wall, we have to change the architecture: we network machines, distribute the workloads, and let many processors work together.

The bells are pointing to a similar moment in quantum computing. Except this time the rules of the game are even weirder. Quantum parallelism, entanglement, and superposition are not just fancy tricks to make things faster. They are the very fabric of quantum computing. And how they will behave in a set distributed open quantum systems (because after all this is what quantum computers really are: open quantum systems) is a fascinating open question, that I hope to convince you is worth pursuing.

A Proven Classical Solution: Networks

In classical systems, networking machines means moving bits around. You send them, store them, copy them. No drama. You just need to make sure your logic doesn't eat its own tail: avoid deadlocks, prevent resending the same bit, maintain cache consistency, and so on. Over time, incredibly sophisticated protocols have been developed to keep everything running smoothly. A graduate-level distributed systems course will walk you through the basics. And although you may grind your teeth while learning about Paxos, Raft, and other consensus algorithms, you eventually get the hang of it. You learn what kinds of problems to expect. There are many, but they tend to follow familiar patterns.

Quantum systems, on the other hand, introduce a different class of challenges. Qubits can exist in superpositions. We are no longer dealing with combinations of zeros and ones, but with physical states—arguably some of the most complex objects in the universe. These states can be entangled across nodes. Not only can we move bits (for example, using photons), but we can now also move correlations. Quantum teleportation opens a window to new capabilities, but it also brings a host of new, headache-inducing problems.

Alongside these new power plays, we lose some familiar ones. A window may open, but a door closes. You cannot simply read a qubit and resend it without destroying it. Copying quantum information is impossible (no-cloning theorem). We can move correlations between systems, but we cannot directly observe or duplicate them. As a result, networked quantum computing introduces fundamentally different challenges from classical networked computing. This is not just an engineering problem. It forces us to grapple with an entirely new layer of physics, one that classical protocols never had to consider.

New Quantum-Specific Questions

What are the genuinely new challenges introduced by distributed quantum computing? At the implementation level, most concerns fall into two categories: when to connect machines, and how to do it.

• When should we connect quantum machines? Not all quantum computations benefit from distribution. The overhead of inter-device communication and coordination can easily outweigh any potential advantages. In particular, there is growing evidence that highly entangled regions of a quantum system are especially fragile when split across devices. Improper partitioning can cause decoherence that is difficult or even impossible to recover from. Determining when distribution is helpful, and when it becomes harmful, remains an open problem.
• Classical, quantum, or hybrid networks? Distributed quantum computing does not rely on quantum processors alone; it also depends on the networks that connect them. These networks can be classical (such as standard optical fiber) or quantum (such as photonic entanglement links). Each type of channel brings distinct advantages and limitations. Classical communication is reliable and well-established, but only quantum channels enable entanglement distribution and teleportation. Choosing between classical, quantum, or hybrid channels is a critical architectural decision. Each choice impacts latency, fidelity, scalability, and error tolerance differently. Understanding these trade-offs, and identifying how channel choice influences computation, is still an evolving research area. So far, most efforts have focused on enabling distribution itself, rather than on studying how the choice of communication channel shapes the computation.

Parallelism: Lessons and Differences

One of the other motivations behind classical distributed computing was the discovery of performance gains through parallelism. As early as the 1970s, Amdahl's Law formalized the limits of speedup in a system with a fixed sequential portion. In the 1980s, Gustafson's Law reframed the discussion by showing that for larger problem sizes, more of the workload can be parallelized. These insights supported the shift toward multi-core architectures and distributed systems, even when communication overhead was non-trivial.

Quantum computing approaches parallelism differently. Superposition and entanglement give quantum systems a form of inherent parallelism. You will often hear the simplification that quantum computers explore exponentially many paths at once within a single state. This is misleading. Quantum parallelism is not directly accessible: we cannot observe all computational branches at the same time, nor can we selectively operate on individual ones. At the same time, quantum devices can perform operations on separate qubits simultaneously. This form of operational parallelism is fundamental to the model. Because of this, the usual arguments for speedup through distributed execution do not carry over directly. In fact, current expectations suggest the opposite. Distributing a quantum computation introduces new overheads, including the need for error correction, qubit teleportation, and additional coordination, all of which can slow down the overall process.

Still, scientists are not easily discouraged. If you were to ask me, one of the many early in career researchers who are dedicating their PhD to this field, I believe that distributed quantum computing will offer new kinds of speedup: not by splitting work across nodes in the classical sense, but by allowing more complex entangled systems, enabling new types of measurements, or increasing algorithmic diversity through heterogeneity of nodes. When and how these speedups manifest is still poorly understood - ergo why we are eagerly working on it.

Infrastructure Challenges

Implementation challenges aside, there are also practical problems we can't ignore. Right now, we're working within a fractured quantum ecosystem. Superconducting qubits, trapped ions, photonics — each platform is racing to prove itself as the dominant one. They all come with strengths and tradeoffs, but there's no clear winner. Worse still, they don't speak the same language. Not everything runs on circuits! Today's quantum computers run on different computational models. From measurement-based quantum computing (MBQC) to topological models, these machines don't perform computations in the same way. They don't interoperate cleanly, and they certainly weren't designed to work together. Despite this hardware reality, most of the current distributed infrastructure work assumes circuit-based computation. But the moment you try cross between modalities, that assumption no longer holds.

Ecosystem heterogeneity becomes a serious problem when we start distributing. Abstracting above or below the model is nice in theory, but today, distribution is anything but model-agnostic. And inter-model interoperability? Not even close. This is more than a hardware limitation, it's a conceptual mismatch between how we compute and how we communicate. Solving this will mean rethinking some of our core assumptions about distributed quantum computing. That's where some of my current work is heading. Keep an eye out for model-agnosticism on the horizon.

Current Strategies: Cutting and Knitting

So what do I mean by current distributed infrastructure assumes circuit-based computation? Let's break it down.

The standard approach today is to take a quantum circuit (a sequence of gates acting on qubits) and split it into smaller parts that can run on different devices. We usually model the circuit as a hypergraph, where qubit wires are nodes and gates are hyperedges connecting them. The goal is to solve a cutting problem: how can we partition this graph across devices while keeping communication costs low? This is an NP-hard problem, meaning even small circuits can produce difficult tradeoffs between cut size, depth, and overall fidelity.

Once the circuit is cut, the pieces need to be "knitted" back together. This can happen in two main ways: we can cut qubit wires, which requires teleporting quantum states between devices, or we can cut gates, which involves creating long-range entanglement links to simulate the missing multi-qubit interaction. Both approaches are valid in theory. But they rely on real quantum networks with high-fidelity links, fast entanglement distribution, and precise coordination between remote devices. And right now, quantum networks for quantum compute are not yet at that level.

The alternative we see available in industry today is to simulate these quantum links using classical communication. This works in simulation and in small experimental settings, but it's a bit like trying to run a Formula 1 car on a bicycle track. You can move forward, but the track isn't designed for that kind of speed or fidelity. You're constantly adapting the system to the limitations of classical infrastructure, instead of building infrastructure suited to quantum behavior. When we talk about circuit "knitting" today, we're often referring to this classical workaround, which is something of a misnomer. To emulate a quantum link over a classical channel, we run many shots on both sides of the cut and stitch together correlated measurement statistics. This allows us to reconstruct expectation values as if the circuit had been whole. But we aren't actually knitting quantum circuits together in the physical sense. We're approximating their output distributions using classical post-processing. Which racks up costs.

The Hardware conversation

Many quantum platforms (e.g., superconducting qubits) were not built with networking in mind. They're excellent for local, high-fidelity gates and fast control, but they cannot natively emit or absorb flying qubits like photons. To interface with a quantum network, these qubits require an interconnect, a device that converts stationary qubits into photonic ones, typically via microwave-to-optical transduction (e.g., using resonators). These interconnects are still in early stages. They introduce unavoidable losses, noise, and latency. The fidelity hit is significant, and the success rates for conversion remain low. Even the "super" in superconducting can't dodge these super losses. This creates a serious bottleneck. A device may perform well in isolation but become nearly unusable when asked to communicate with others. Until we have high-fidelity, low-loss interfaces / architectures that avoid the need for conversion entirely hardware will remain a core limitation for distributed quantum computing.

Recent Progress and Open Needs

But despite this bleak state, the first real steps toward distributed quantum computing have been arriving! In early 2025, Xanadu introduced Aurora, the first modular, networked photonic quantum computer. Aurora connects 35 photonic chips via 13 kilometers of optical fiber across four server racks, forming a 12-qubit system designed for scalability and fault tolerance. This marks the first time a quantum computer has been built to be modular, networked, and truly scalable with quantum channels. And although it is still in the early stages, it represents a significant step toward a future where quantum computers can be distributed across multiple locations and connected via quantum networks.

Around the same time, researchers at Oxford University demonstrated the first instance of distributed quantum computing by linking two separate quantum processors via a photonic network. They executed a distributed version of Grover's search algorithm, achieving an 86% fidelity for a teleported controlled-Z gate between modules and a 71% success rate for the algorithm. The experiment used trapped-ion QPUs and showed that non-trivial distributed algorithms are feasible even with current hardware.

Another major development came from TU Delft, where researchers at QuTech and the Quantum Internet Alliance introduced QNodeOS, the first operating system for quantum networks. QNodeOS provides a hardware-agnostic abstraction layer, letting quantum applications issue high-level commands like entanglement generation or inter-node operations without being tied to specific devices. These requests are translated into hardware-specific instructions that coordinate timing, entanglement, and classical messaging between nodes. However, the system still assumes that each node runs gate-based quantum circuits. The computational model remains fixed, even if the hardware platform is abstracted. This is a major step forward, but it still leaves open the question of how to coordinate distributed computations across different models entirely.

When all is said and done these are significant milestones, but much remains to be done:

• Conducting experiments on actual distributed computations, such as complex circuits, quantum walks, and MBQC patterns.
• Developing quantum network experiments that specifically target quantum computing needs, moving beyond network oriented applications like quantum key distribution (QKD).
• Demonstrating even short-distance server-to-server quantum communication, which is both urgent and impactful for validating distributed architectures.

The field is progressing, but to realize the full potential of distributed quantum computing, we need to focus on these open challenges and continue building upon these foundational experiments.

Closing: Why work on DQC?

Distributed Quantum Computing isn't just a niche topic. It's essential if we want to scale quantum computing beyond the limits of single devices. The physical constraints are real, and they won't be solved by squeezing more qubits onto a chip. DQC forces us to ask hard questions: How do we coordinate entanglement across distance? How do we distribute algorithms across heterogeneous platforms? How do we rethink hardware and software to support modular, network-aware architectures? These aren't engineering challenges, they're fundamental questions about what it means to compute in a quantum world. And they're questions we need to answer if we want quantum computing to move from lab demos to real-world impact. That's why I work on DQC. It's one of the few paths forward that can take quantum computing to its next phase.