An operating system for executing applications on quantum network nodes

Abstract

The goal of future quantum networks is to enable new internet applications that are impossible to achieve using only classical communication^1-3. Up to now, demonstrations of quantum network applications^4-6 and functionalities^7-12 on quantum processors have been performed in ad hoc software that was specific to the experimental setup, programmed to perform one single task (the application experiment) directly into low-level control devices using expertise in experimental physics. Here we report on the design and implementation of an architecture capable of executing quantum network applications on quantum processors in platform-independent high-level software. We demonstrate the capability of the architecture to execute applications in high-level software by implementing it as a quantum network operating system-QNodeOS-and executing test programs, including a delegated computation from a client to a server¹³ on two quantum network nodes based on nitrogen-vacancy (NV) centres in diamond^14,15. We show how our architecture allows us to maximize the use of quantum network hardware by multitasking different applications. Our architecture can be used to execute programs on any quantum processor platform corresponding to our system model, which we illustrate by demonstrating an extra driver for QNodeOS for a trapped-ion quantum network node based on a single ⁴⁰Ca⁺ atom¹⁶. Our architecture lays the groundwork for computer science research in quantum network programming and paves the way for the development of software that can bring quantum network technology to society.

Fig. 1. Application paradigm.

A quantum networking application consists of several programs, each running on one of the end nodes. An end node is a device in a quantum network that executes user applications. A network stack enables entanglement generation between end nodes over a quantum network (Supplementary Fig. 1). The distinct programs at each end node can only interact through: (1) quantum communication (for example, entanglement generation) and (2) classical communication. This allows a programmer to realize security-sensitive applications but prohibits a global orchestration of the quantum execution, such as what we might do in (distributed) quantum computing in which a single quantum program is executed on several nodes. Our architecture allows programs to be written in high-level quantum-hardware-independent software and executed on a quantum-hardware-independent system that controls a hardware-dependent system (QDevice; Fig. 2), such as a NV centre node with a diamond chip (photo taken by authors, left images) or a trapped-ion quantum node (right images). These platforms constitute physically very different QDevice systems but can both be programmed by our architecture.

Fig. 2. QNodeOS architecture.

a, QNodeOS consists of a classical network processing unit (CNPU) and a quantum network processing unit (QNPU) (classical system). QNodeOS controls a QDevice (quantum hardware and low-level classical control). b, Schematic of our implementation of QNodeOS on a two-node setup in which both QDevices control a single qubit in a diamond NV centre. The CNPU is implemented on a general-purpose PC and the QNPU on an embedded system, connected by means of Gigabit Ethernet (blue). The QNPU connects to its QDevice by means of a serial peripheral interface (SPI) (pink). The two QNPUs (brown) and the two CNPUs (green) connect to each other by means of Gigabit Ethernet. The setup is based on ref.  with two QDevices (including AWGs and microcontroller units (MCUs); QDevices communicating over a classical digital input/output (DIO) interface) and a heralding station composed of a balanced 50:50 beam splitter (whose output ports are connected to superconducting nanowire single-photon detectors (SNSPDs) through optical fibres (red)), a time tagger (TT) and a complex programmable logic device (CPLD) that heralds the entanglement generation between QDevices and sends a classical message to the MCU.

Fig. 3. Trapped-ion QDevice implementation.

Schematic of our implementation of QNodeOS on a single-node setup in which the QDevice contains a single trapped-ion qubit. The QNPU QDriver is implemented on a field-programmable gate array (FPGA) that connects to its QDevice through a SPI (Methods). The setup consists of an emulator that translates between SPI messages and TTL signals, experimental control hardware that includes a FPGA and direct digital synthesis (DDS) modules, a trapped-ion qubit under ultrahigh vacuum (Fig. 1) and a photomultiplier tube (PMT) that registers atomic fluorescence.

Fig. 4. Delegated computation between two NV centre nodes using QNodeOS.

a, DQC circuit (effective computation: single-qubit rotation R_Z(α); Methods). The DQC application consists of k circuit repetitions (varying measurement bases for tomography on |ψ⟩) realized by two programs: the DQC-client program (client node, repeating the sequence ‘quantum block (C1, orange)–classical block (computing δ)’ k times) and the DQC-server program (server node, repeating ‘quantum block (S1, blue)–classical block (receiving δ)–quantum block (S2, purple)’ k times). Client and server produce entanglement |Φ⁺⟩ = (|00⟩ + |11⟩)/√2 (S1 and first part of C1). The client performs gates and a measurement, resulting in outcome bit m_c (rest of C1). Client computes δ from m_c and DQC parameters α ∈ [0, 2π) and θ ∈ [0, 2π) and sends δ. Meanwhile, the server keeps its qubit coherent. On receiving δ, the server applies gates depending on δ, resulting in single-qubit state |ψ⟩ (S2) depending only on α and θ. b, Experimental results executing DQC for six different sets of (α, θ) parameters (k = 1,200, that is, 7,200 executions of circuit Fig. 4a). Fidelity to |ψ⟩ estimated using single-qubit tomography (1,200 measurement results per data point) and corrected for known tomography errors (SSRO, blue), post-selected for charge-resonance (CR) check validation (purple) and post-selected for latencies (orange) (Methods). c, Sequence diagram including the interaction CNPU–QNPU–QDevice for one execution of the DQC circuit (repeated k = 1,200 times in each experiment) (time flows to the right; not to scale). CNPUs prepare NetQASM subroutines (C1, S1, S2) and send them to their respective QNPUs. CNPUs perform classical computation (message δ). QNPUs execute subroutines, sending physical instructions to their QDevices. Entanglement is generated by QDevices performing a batch of attempts (triggered by a ‘create EPR’ physical instuction), resulting in the heralding of a two-qubit entangled state rotated to |Φ⁺⟩ by the server. d, Processing times and latencies while server qubit is live (time frame red line in c, averaged over all 7,200 circuit executions except executions with latency spikes; see Methods), including CNPU–QNPU communication latencies, CNPU processing on both nodes and client–server communication latency (CC) (average total of about 4.8(±0.8) ms; error bars (standard deviation) for the sum of individual segments (per segment: Supplementary Information section 4.6)).

Fig. 5. Multitasking experiment on two NV centres with QNodeOS.

a, LGT circuit. A single NetQASM subroutine (L1) executes six times for bases B ∈ {±X, ±Y, ±Z}: initialize to |0⟩, rotate around axis D ∈ {X, Y} by angle ϕ, measure in B. The LGT application consists of a single LGT program, submitting L1 to the QNPU (fixed D and ϕ) k times successively. b, Sequence diagram illustrating concurrent execution (multitasking) of DQC (Fig. 4) and LGT on the client: two DQC circuit repetitions (Fig. 4a; two subroutines on the client (orange), four on the server (blue and purple)) and three LGT circuit repetitions (three subroutines, green). The client QNPU receives subroutines for the DQC program and the LGT program, which the QNPU scheduler can interleave: while the server executes S2 (purple), the client can not yet execute the next S1 (orange), as it involves joint entanglement generation. In idle time, the client can execute LGT subroutines (number can vary). c, Results of multitasking LGT (client) and DQC (on both server and client): for each input pair (D, ϕ) ∈ {(X, 0), (X, π), (Y, π/2), (Y, −π/2), (X, −π/2), (X, π/2)} (six cardinal states {±X, ±Y, ±Z}): simultaneously (1) a single LGT program was initiated on the client (k = 1,000); (2) a single DQC-client program was initiated on the client (k = 200 successive subroutines); and (3) a single DQC-server program was initiated on the server (k = 200, that is, 400 successive subroutines), resulting in a total of 6,000 LGT subroutine executions and 36,000 LGT measurement results, yielding fidelity estimates for the LGT quantum state before measurement. The results are the same as running LGT on its own (no multitasking; Supplementary Information section 5.2). d, Scaling number of programs on the client. For N ∈ {1, 2, 3, 4, 5}, we initiate simultaneously: (1) N LGT programs (each using k = 100) on the client; (2) N DQC-client programs on the client (each k = 60); and (3) N DQC-server programs on the server (each k = 60). This results in 2N programs simultaneously active on the client, each continuously submitting subroutines from the CNPU to the QNPU. Each experiment was repeated but with multitasking disabled. The plot shows the utilization factor of the QDevice (fraction of time spent executing instructions), corrected for variable entanglement generation duration (Methods), with (blue) and without (orange) multitasking, showing that multitasking can increase device utilization. Error bars are standard deviation.