doug-q
commented
1 month ago @mark-koch and I discussed this with @daniel-mills-cqc last week. I will summarise my understanding of blind computing with MBQC here, and layout how we could apply guppy to it.
MBQC is a model of quantum computing equivalent to the gates model, An MBQC program is an undirected graph, and a directed "flow" graph on the same vertices. The constraints on the "flow" graph are subtle, complicated, and of various flavours.
An MBQC program "compiles" to gates in an interesting way, we always get three circuits that are applied one after the other: A "preparation" step, an "entanglement" step, and a "measurement" step. Important for us is that in the measurement step, where some qubits are measured, various conditional "correction" gates are applied, conditioned on the measurement result on other qubits.
Dan has written a python library that he uses to construct MBQC graphs, which then uses pytket to build a circuit.
"Blind" MBQC programs are ones where at least part of the preparation step is physically separated from the rest of the circuit, and the circuit has some additional parameters. For example, A qubit may be randomly rotated by the client. The server recieves that qubit, and some angle (which depends on, in a way the server does not know, the random angle) which specifies the rotation of same gate.
An important part of "Blind" MBQC programs is that each shot of the circuits is randomly in one two "modes".
- A real shot
- a verification shot: some of the qubits are specially prepared so that they do not become entangled. The outcome of the circuit thus becomes predictable
As part of constructing the circuit, A two-colouring of the qubits is chosen. During a verification shot, one of the colours is chosen at random, and the qubits of that colour are specially prepared.
Applications of guppy:
- The random choice of verification, colour, and special preparation of qubits is very annoying in tket. It would be straightforward in guppy. It would be interesting to do JUST this preparation with guppy, and then to call into tket for the rest of the circuit.
- Gates depending on the outcome of measurements would be straightforward in guppy.
- A guppy library allowing the building of graphs is ambitions, but achievable. Note that graphs are not dynamicly constructed at present, so guppy constructing graphs and building circuits at runtime seems frivilous. perhaps the computation is small enough that this doesn't matter. Perhaps this is a good case for looking more at "staged" compilation with guppy.
- It is natural to "concatenate" graphs, although Dan's library does not attempt this.
You'll see that lecture 15 here -> http://pwallden.gr/courseiqc.asp covers this topic. I wonder if a notion of 'client' and 'server' could be created with guppy? Then the approach taken in these lecture notes would make sense as it requires 2 quantum capable parties.
Alec mentioned a cryptographic approach, which would be along the lines of this -> https://arxiv.org/abs/2209.14316. This is becoming quite complicated though, and an implementation of this would be publication worthy :P
I probably would not worry too much about blindness as I don't see that it adds significantly more complicated control flow. This is unless there is a natural way of writing a client and a server, in which case this would be very interesting.