Quantum Computing Simulations On Blockchain Platforms

I wrote and presented before on distributed quantum computing simulations, in particular on top of Kubernetes. Adding a qubit to a simulation doubles the computational needs, leading to an exponential increase in allocated resources. However, as explained in the link above, a quantum simulation can be expressed as a perfectly balanced computation, where each node does the same amount of work, and nodes only communicate in pairs when they need to exchange amplitude values.

I spent some time this weekend experimenting with the open-source Corda platform (https://www.corda.net/). I like calling this type of experiment going into a "tiny rabbit hole", a deep diving exercise that is just enough to get a necessary understanding of a problem or solution. I started doing the same exercise on the Cosmos platform before, but I did not finish it. I am happy with the results and the implementation speed of this one though. Note that support for certain distributed computing features, like point-to-point communication, partitioning of state, etc., are essential for the simulation, but are not easily available on all blockchain platform.

This is also my first serious encounter with Kotlin.

Simulation Details

I am simulating a 5-qubit quantum system, whose state of 32 amplitudes are distributed on 4 nodes, each managing 8 of them. Unlike container based computing, the nodes in blockchain platforms are not as dynamic, as they are meant to represent parties in transactions.

If a node can handle 4 million amplitudes (20 qubits), and the platforms allows 1024 nodes, that will add 10 qubits, allowing for handling over a billion amplitudes. For 40 qubits, 1 trillion amplitudes need to be handled.

Initializing The State

The 4 nodes are called Node-0, Node-1, Node-2, and Node-3, each of them managing the amplitudes for outcome states that start with the prefix 00, 01, 10, and 11 respectively. The rest of 3 digits represents the suffix. In addition to these nodes, a Notary and a Driver node are started. The Driver node will send instructions to the 4 nodes, and will retrieve and aggregate information as needed. Flows can be started from any node though.

The Start flow instructs the nodes to create the initial amplitudes of the system, while the FullState flow assembles all pieces together in a view that can be verified or visualized.

Each node maintains a section of the quantum state (consisting of a complex number associated to each of the 32 possible outcomes) on the ledger. That means that historical values will be preserved. The states on the ledger are encrypted, but Corda allows for queryable, and therefore readable, versions. With the proper (Hibernate based) encoding, this is how the values can be seen on each node:

The all-zero outcome has all the probability, to begin with.

Applying Quantum Gates to Evolve The System

The ApplyGate flow will apply a single-qubit gate (2x2 unitary matrix for the linear algebra fans) to one of the 5 qubits as a target. If the target is in the suffix part, the computations happen locally on each node, recombining pairs of amplitudes for outcomes that differ only in the target position. If the target is in the prefix part, the nodes with prefixes that differ only in the target position will exchange and recombine their amplitudes. A few flows and compositions need to cooperate for this to happen, and Corda's point-to-point communication, flow composition, and signature collection are the key to a correct implementation.

For simplicity, we'll apply the gate Ry(pi/4) to all qubits in sequence, which will result in real amplitudes only. If you are into linear algebra, the corresponding matrix looks like this:

In our representation, a Gate is represented as a Kotlin data class with 4 entries called a00, a01, a10, and a11. Corda allows entering constructor values of (data) classes at the command line.

The Final State

We can inspect the final state using the FullState flow:

The histogram of the outcome probabilities shows the expected binomial related shape, where the probability of an outcome depends on the number of 1s in its binary representation.

The nodes show all the (chains of the) historical values of the amplitudes stored in them, which is very useful.

Conclusions

The blockchain inspired versions of distributed computing may well be the future of how we deploy applications. While capabilities and interfaces are still evolving, we are starting to understand what features are essential for decentralization of distributed applications. The Quantum Computing domain is small and beautiful, and could be used as a benchmark for some of the capabilities platforms need to offer.