PaperlayerView exact revision on arXiv

Source-linked AI summary

SimulaQron - A simulator for developing quantum internet software

Axel Dahlberg, Stephanie Wehner

arXiv:1712.08032v2quant-phcs.NIcs.SE

TL;DR

Quantum-network applications require coordinated classical and quantum communication, but a development framework for writing them is needed. SimulaQron uses modular distributed simulation to provide a stand-in for quantum internet hardware; it provides access to simulated hardware for application development, while not targeting efficient large-scale simulation or reliable noise-performance claims.

  • Problem

    As quantum networks emerge, developers need a framework for writing and debugging applications that combine classical communication with quantum operations.

    Source: §I · p. 1

  • Method

    SimulaQron distributes simulations of local processors across network nodes, reusing Python-accessible quantum simulators as backends.

    Source: A. What SimulaQron does · p. 2

  • Results

    SimulaQron provides access to simulated quantum internet hardware for application development.

    Source: §V · p. 11

  • Takeaways & Limitations

    Developers can use SimulaQron to build quantum-internet software intended to run on real hardware with no or minimal modification.

    Source: A. What SimulaQron does · p. 2

    SimulaQron is not intended for efficient large-scale network simulation, and ad hoc noise does not support general, accurate application-performance claims under noise.

    Source: B. What SimulaQron does not · p. 3

Abstract

from arXiv · show

We introduce a simulator for a quantum internet with the specific goal to support software development. A quantum internet consists of local quantum processors, which are interconnected by quantum communication channels that enable the transmission of qubits between the different processors. While many simulators exist for local quantum processors, there is presently no simulator for a quantum internet tailored towards software development. Quantum internet protocols require both classical as well as quantum information to be exchanged between the network nodes, next to the execution of gates and measurements on a local quantum processor. This requires quantum internet software to integrate classical communication programming practises with novel quantum ones. SimulaQron is built to enable application development and explore software engineering practises for a quantum internet. SimulaQron can be run on one or more classical computers to simulate local quantum processors, which are transparently connected in the background to enable the transmission of qubits or the generation of entanglement between remote processors. Application software can access the simulated local quantum processors to execute local quantum instructions and measurements, but also to transmit qubits to remote nodes in the network. SimulaQron features a modular design that performs a distributed simulation based on any existing simulation of a quantum computer capable of integrating with Python. Programming libraries for Python and C are provided to facilitate application development.

I. INTRODUCTION

Quantum-network software needs to coordinate classical messages with local quantum operations, but a development framework and full network stack are missing. SimulaQron provides a distributed, modular stand-in for developing this software, while excluding several large-scale, timing, and security functions.

I. INTRODUCTION

  • A quantum-network development framework is needed because protocols integrate classical and quantum messages, yet no full network stack or application-development framework exists.The challenge includes classical control messages for entanglement tracking and classical protocol communication by applications.Source: §I · p. 1

A. What SimulaQron does

  • SimulaQron targets application development, standing in for platform-dependent quantum processing so software can be written without quantum hardware.Its goal is software that can later run on real quantum internet hardware with no or minimal modification.Source: A. What SimulaQron does · pp. 1–2, B. What SimulaQron does not · p. 2
  • Distributed servers simulate remote processors and their qubit exchange and entanglement, while CQC exposes local and network-specific commands to applications.Simulated processors can run on different classical computers, and applications also exchange classical messages.Source: A. What SimulaQron does · p. 2, Figure 1 · p. 2
  • SimulaQron reuses Python-accessible quantum simulators as modular backends and maps locally simulated entangled qubits to remote nodes; simulated entanglement provides no real security guarantees.The platform supports development of applications, libraries, abstractions, and a quantum network stack.Source: A. What SimulaQron does · p. 2

B. What SimulaQron does not

  • SimulaQron is not intended for efficient large-scale network studies, and ad hoc noise cannot support general, accurate claims about application performance under noise.Timing-dependent noise modeling is meaningful only when simulated delays mirror real-network delays; classical simulation runtime is not a reliable timing measure.Source: B. What SimulaQron does not · pp. 2–3
  • The platform leaves entanglement management and tracking to future stack development and does not secure or authenticate processor access by default.The backend accepts requests from any connecting client that supplies the correct qubit identifiers; access-control mechanisms remain important to develop.Source: B. What SimulaQron does not · p. 3

C. Related Work

SimulaQron combines existing local quantum simulators with distributed simulation to support quantum-internet software development. Its design addresses entanglement across nodes while offering programming interfaces and a modular backend.

C. Related Work

  • No analogue of SimulaQron for quantum-internet application development was known; related tools instead include local simulators such as ProjectQ [21] and QuTip [27].The initial backend uses QuTip, which the paper describes as sufficient for small networks but not designed for efficient simulation.Source: C. Related Work · pp. 3–4

D. Overview

  • SimulaQron is written in Python and uses Twisted internally, with the paper outlining its backend, CQC integration, programming examples, and future extensions.The Python CQC library is presented as the easier way to program applications than directly accessing the backend.Source: D. Overview · p. 4, §II · p. 4

II. BACKEND

  • Direct Twisted access offers full backend access but is highly specific to Twisted; CQC provides a command-packet interface intended for use beyond SimulaQron.Python and C libraries encapsulate CQC, and other languages can connect through the interface.Source: Figure 3 · p. 4

A. Challenges

  • Entanglement prevents independently simulating the qubits at separate nodes, while a single register for all qubits imposes a prohibitive load.The proposed approach keeps separate registers where possible and merges them when qubits become entangled; concurrent merges require locking.Source: A. Challenges · pp. 4–5
  • Distributed registers allow simulation effort to be shared across computers, supporting fragmented entanglement and dynamic network growth.The paper reports no significant problems simulating 60 nodes with 120 qubits on one desktop machine; a single 120-qubit register would require tracking a 2^120-dimensional matrix.Source: A. Challenges · p. 5

B. Design overview

The backend connects participating classical computers as virtual nodes and builds on an underlying quantum simulator through a modular interface. It represents qubits with objects that can be updated as registers change.

B. Design overview

  • Each participating classical computer runs a client and server as a virtualNode, and these programs connect to form the simulated network backend.The design follows from the need to distribute simulation across nodes.Source: B. Design overview · p. 5
  • SimulaQron builds a distributed simulation on an existing quantum simulator, initially QuTip, and can use Python-accessible simulators through a quantumEngine interface.The quantumRegister applies requested operations to the underlying simulation.Source: B. Design overview · p. 5
  • Each simulatedQubit tracks its position in the quantumRegister, allowing measured qubits to be removed and the register to shrink without updating remote virtualQubit objects.This lets the remaining simulation access qubits without knowing that the underlying register has shrunk.Source: B. Design overview · p. 5

C. Virtual Qubits

Virtual qubits let applications at one node use qubits simulated in registers at another. When entangling operations span registers, SimulaQron merges them transparently, using locking to manage concurrent requests.

C. Virtual Qubits

  • A virtualQubit can reside at a different node from its simulatedQubit, with Twisted’s Perspective Broker mapping the remote reference.A virtualNode may hold virtual qubits simulated locally or remotely.Source: C. Virtual Qubits · pp. 5–6
  • Virtual qubits at separate nodes can represent entangled qubits backed by simulatedQubit objects in a shared quantumRegister, which may be located at either node or another.Applications can perform gates, measurements, or send virtual qubits to other network nodes.Source: C. Virtual Qubits · p. 6

D. Register merges

  • Entangling qubits in separate registers requires merging those registers and updating their virtualQubit mappings; SimulaQron performs this in the background.The merge is invisible to applications, but simultaneous merge requests require locking; the current mechanism is described as simple and relatively inefficient, with randomized backoff for deadlocks.Source: D. Register merges · p. 6

III. CQC

CQC gives applications a packet-based interface for issuing quantum commands, with Python and C libraries and support for other languages. Its messages can specify command parameters, options, and follow-on actions.

III. CQC

  • CQC provides a low-level instruction format for gates and measurements, enabling applications to be developed independently of the underlying platform.The interface is intended for execution on any platform that provides CQC.Source: §III · p. 6
  • Python and C libraries program SimulaQron through CQC, with Python presented as the easiest and recommended way to get started.The interface is expected to evolve before use in the Dutch demonstration network, and its current message format is available online.Source: §III · p. 7
  • CQC messages can specify a command, version, application identifier, message length, qubit identifiers, and destination address; options include completion notification and node blocking.A message can contain one request or a batch of requests for a sequence of actions.Source: §III · p. 7
  • Follow-on commands can run after a command completes or conditionally on a measurement result, avoiding a message round trip between each action.The backend consequently supports rudimentary classical logic alongside quantum instructions.Source: §III · p. 7

A. Message types

The CQC interface defines messages between applications and simulated or physical hardware, including application requests, hardware replies, and supported commands. The examples assume the simulated network and backend servers are already configured.

A. Message types

  • The interface specifies application-to-hardware message types in Table II and hardware-to-application message types in Table III.These message directions apply whether the hardware is simulated by SimulaQron or physically implemented.Source: A. Message types · p. 8, Table II · p. 8, Table III · p. 8
  • FACTORY repeats a specified command a specified number of times, including continuously producing EPR pairs for protocols to use.HELLO checks the hardware connection and can return hardware specifications.Source: A. Message types · p. 8

B. Possible commands

  • The COMMAND message type supports listed commands, including pairwise entanglement creation modeled on heralded generation; successful reception or generation returns a notification to the application.The returned TP_RECV or TP_EPR_OK message indicates success and that any required entanglement-generation corrections have been applied.Source: B. Possible commands · p. 8
  • Single-qubit rotation angles use one byte, limiting them to 256 possible angles.Source: B. Possible commands · p. 8
  • The interface returns an entanglement identifier when an EPR pair is requested, but no network protocol for tracking and managing entanglement is available yet.Such a protocol is under development and testing.Source: B. Possible commands · p. 8

IV. EXAMPLES

  • The Python example assumes the simulated network is configured and its communication backend servers are already running.It uses two nodes, Alice and Bob; their names map to IP addresses through the configuration file.Source: §IV · p. 8

A. Sending BB84 States

The BB84 example sends one qubit from Alice to Bob without application-level classical communication. Alice uses the CQC interface to prepare and transmit one of four states selected by two bits.

A. Sending BB84 States

  • Alice sends Bob one qubit without setting up application-level classical communication; both applications connect locally to the SimulaQron CQC backend.Source: A. Sending BB84 States · pp. 8–9

1. Code for Alice

  • The Python example connects Alice to SimulaQron and creates a qubit object tied to that connection.Operations on the object communicate with SimulaQron and update the corresponding simulated qubit.Source: §1 · p. 9
  • Alice prepares one of four BB84 states, determined by bits h_A and x, using H^h_A X^x before sending the qubit to Bob.H is the Hadamard operation and X is the Pauli-X operation.Source: §1 · p. 9

2. Code for Bob

Bob waits for Alice's qubit and measures it in a basis selected by h_B. When Alice's and Bob's basis choices match, the measurement returns Alice's bit x with probability one.

2. Code for Bob

  • Bob waits for a qubit to arrive, then measures it in the standard basis when h_B = 0 or the Hadamard basis when h_B = 1.Source: §2 · p. 9
  • Bob applies H before measurement when choosing the Hadamard basis; otherwise he measures in the standard basis and prints the outcome.Source: §2 · p. 10
  • When h_A = h_B, Bob obtains Alice's bit x with probability one.Source: §2 · p. 10

B. Teleporting a qubit

The teleportation example combines a shared EPR pair, local Bell measurement, and application-level classical communication. Alice sends her measurement outcomes to Bob so he can recover the teleported state.

B. Teleporting a qubit

  • The example demonstrates creating a shared EPR pair and using application-level classical communication alongside teleportation.The Python library offers a convenient testing tool for this communication without requiring familiarity with client/server programming.Source: B. Teleporting a qubit · p. 10

1. Code for Alice

  • After requesting an EPR pair with Bob, Alice prepares an input qubit in |+⟩ for teleportation.Source: §1 · p. 10
  • Alice performs a Bell measurement by applying CNOT with the input qubit as control and the shared-pair qubit as target, then H and standard-basis measurements.Source: §1 · p. 10
  • Alice sends Bob her measurement outcomes so he can recover the teleported state; the built-in sendClassical method opens a socket, sends the message, and closes the connection.A standard client/server setup can also be used, and no socket opens if sendClassical is not called.Source: §1 · p. 10

2. Code for Bob

Bob receives Alice’s measurement outcomes and the teleported qubit, applies outcome-dependent corrections, then measures the corrected state.

Code for Bob

  • Bob first sets up a server to receive Alice’s outcomes and receives qB, one half of their EPR pair.Source: §2 · p. 10
  • Bob receives Alice’s measurement outcomes with recvClassical and uses them to choose corrections to qB.The corrected qB is in Alice’s prepared state, |+⟩.Source: §2 · p. 10
  • After correction, Bob measures qB, obtaining 0 or 1 with equal probability.Source: §2 · p. 10
  • The example then closes Bob’s connection.Source: §2 · p. 11

C. Performance

The performance tests cover teleportation, unentangled-qubit initialization and measurement, and GHZ-state creation. Runtime depends strongly on entanglement structure and the simulation backend.

C. Performance

  • The tests measure ring-network teleportation with EPR pairs created on demand or in advance, and repeated teleportation between two separately simulated nodes.The ring test sends a qubit through all nodes and back; the two-node test performs 2n teleportations.Source: C. Performance · p. 11
  • For the ring test, EPR pairs are either created when the qubit arrives or prepared in advance, with teleportation proceeding as soon as a pair is ready.Source: C. Performance · p. 11
  • Each node uses separate simulation, CQC-listener, and application processes, and TCP communication adds runtime delay.In the 60-node ring test, these amount to 180 processes on one computer.Source: C. Performance · p. 11
  • Unentangled-qubit initialization and measurement scale linearly with qubit count, while GHZ-state creation scales super-exponentially.The paper attributes the GHZ scaling to the QuTip backend and says another backend could improve creation of larger entangled states.Source: C. Performance · p. 11
  • Registers merge only when a two-qubit gate acts across them, so runtime depends on the size of multipartite entangled states.The implementation uses fixed rules for which node stores a merged register and does not split registers when qubits later become unentangled.Source: C. Performance · p. 11
  • SimulaQron is not intended to replace simulators specialized for large multipartite states, though its operations support universal quantum computation.Its intended use includes networks where not all nodes are entangled in one state.Source: C. Performance · p. 11

V. CONCLUSION

SimulaQron provides simulated quantum internet hardware for application development, with Python and C libraries. Its low-level CQC interface is hidden by those libraries, and Python is the fastest route to begin developing applications.

V. CONCLUSION

  • SimulaQron provides access to simulated quantum internet hardware to support application development.Source: §V · p. 11
  • CQC is a low-level language supported directly by SimulaQron, while the Python and C libraries expose higher-level application development.The paper identifies the Python CQC library as the fastest way to get started.Source: §V · p. 12
  • The authors envisage CQC being integrated into higher-level languages through compilers that generate CQC commands, alongside more convenient programming environments and libraries.Source: §V · p. 12
Loading 1712.08032v2…