Prepare-and-Send Verifiable Universal Blind Quantum Computation: Difference between revisions

From Quantum Protocol Zoo
Jump to navigation Jump to search
No edit summary
No edit summary
 
(17 intermediate revisions by 3 users not shown)
Line 11: Line 11:
This protocol is a modified version of [[Prepare-and-Send Universal Blind Quantum Computation]], which is based on [[Supplementary Information#Measurement Based Quantum Computation (MBQC)|(MBQC)]]. Here a powerful adversarial server is delegated with quantum computation which maintains the privacy of the computation. Any computational deviations by this server are detected by high probability. This is achieved by insertion of randomly prepared and blindly isolated single qubits in the computation, which act as a trap (trap qubits), hence assisting the client in verification.
This protocol is a modified version of [[Prepare-and-Send Universal Blind Quantum Computation]], which is based on [[Supplementary Information#Measurement Based Quantum Computation (MBQC)|(MBQC)]]. Here a powerful adversarial server is delegated with quantum computation which maintains the privacy of the computation. Any computational deviations by this server are detected by high probability. This is achieved by insertion of randomly prepared and blindly isolated single qubits in the computation, which act as a trap (trap qubits), hence assisting the client in verification.


MBQC required a set of the initial state for computation. The [[Supplementary Information#Brickwork States|brickwork states]] used in [[Prepare-and-Send Universal Blind Quantum Computation]] are modified to [[cylinder brickwork states]] which enables the client to embed a trap qubit surrounded by multiple dummy qubits without disrupting the computation. This state is universal and maintains the privacy of the client's preparation. The dummy qubits here do not take part in the actual computation as they are disentangled from the rest of the qubits of the graph state. Hence by adding them to the neighboring nodes of the trap qubits, they are blindly isolated and thus do not interfere with the actual computation. The dummy qubits are added next to the trap qubit in a tape format as seen in [[cylinder brickwork states]].  
MBQC required a set of the initial state for computation. The [[Glossary#Brickwork States|brickwork states]] used in [[Prepare-and-Send Universal Blind Quantum Computation]] are modified to [[Glossary#Cylinder Brickwork States|cylinder brickwork states]] which enables the client to embed a trap qubit surrounded by multiple dummy qubits without disrupting the computation. This state is universal and maintains the privacy of the client's preparation. The dummy qubits here do not take part in the actual computation as they are disentangled from the rest of the qubits of the graph state. Hence by adding them to the neighboring nodes of the trap qubits, they are blindly isolated and thus do not interfere with the actual computation. The dummy qubits are added next to the trap qubit in a tape format as seen in [[Glossary#Cylinder Brickwork States|cylinder brickwork states]].  


This protocol is dived into four stages: Client's preparation, server's preparation, interaction and measurement, verification.
This protocol is divided into four stages: Client's preparation, server's preparation, interaction and measurement, verification.


* '''Client's preparation''': The partially quantum client prepares the quantum states with embedded traps qubits and sends them to the server for creation of the cylinder brickwork state.  
* '''Client's preparation''': The partially quantum client prepares the quantum states with embedded traps qubits and sends them to the server for creation of the cylinder brickwork state.  
** For the server to create a cylinder brickwork state, the client prepares <math>m*n</math> single qubit states. The first <math>n</math> qubit input states are specially encoded and [[Supplementary Information#Quantum One Time Pad|Quantum one time pad]] is applied to these states with randomly chosen keys.
** For the server to create a cylinder brickwork state, the client prepares <math>m</math> single qubit states. The first <math>n</math> qubit input states are specially encoded and [[Supplementary Information#Quantum One Time Pad|Quantum one time pad]] is applied to these states with randomly chosen keys.
** Then the client randomly selects one qubit as the trap qubit and corresponding to the graph of cylinder brickwork state, all the other qubits in the tape are set as the dummy qubits. The trap qubit is prepared with the local phase angle set to <math>0</math>. The dummy qubits isolate the trap qubit from the graph state.
** Then the client randomly selects one qubit as the trap qubit and corresponding to the graph of cylinder brickwork state, all the other qubits in the tape are set as the dummy qubits. The trap qubit is prepared with the local phase angle set to <math>0</math>. The dummy qubits isolate the trap qubit from the graph state.
** The remaining non-input qubit states (not including the dummy states and trap qubit) are prepared with randomly chosen local phase angles.
** The remaining non-input qubit states (not including the dummy states and trap qubit) are prepared with randomly chosen local phase angles.
** The client then sends all the prepared qubits in the respective order to the server so the graph state can be constructed.
** The client then sends all the prepared qubits in the respective order to the server so the graph state can be constructed.


* '''Server's Preparation''': The server receives the qubits in the order of <math>m</math> rows and <math>n</math> columns and entangles them according to the cylinder brickwork state (using CZ gate).
* '''Server's Preparation''': The server receives the qubits in a sequential order of rows and columns till all <math>m</math> qubits are received. The server then entangles them according to the cylinder brickwork state (using CZ gate).


* '''Interaction and Measurement''': This step is exactly the same as for [[Prepare-and-Send Universal Blind Quantum Computation]].
* '''Interaction and Measurement''': This step is exactly the same as for [[Prepare-and-Send Universal Blind Quantum Computation]].
** For a specific computation, MBQC decides which measurement angle is selected along with some extra Pauli X, Z corrections for every qubit. The correction sets are unique for every graph state and depend on the previous measurement. These can obtained from '''[[Supplementary Information#Flow Construction-Determinism|flow construction]]'''. The qubits have a randomly chosen local phase angle and hence the same local phase angle is used for computation as well as for output correction. To hide the state, a randomly chosen <math>\pi</math> rotation which may or may not be added. From all the above-mentioned conditions, a final measurement angle is formed and the client sends a classical message to the server to inform the server about the final measurement basis (in (X,Y) plane) in which they should measure the corresponding qubit. Thus it reveals no information about the underlying computation.
** For a specific computation, MBQC decides which measurement angle is selected along with some extra Pauli X, Z corrections for every qubit. The correction sets are unique for every graph state and depend on the previous measurement. These can obtained from '''[[Supplementary Information#Flow Construction-Determinism|flow construction]]'''. The qubits have a randomly chosen local phase angle and hence the same local phase angle is used for computation as well as for output correction. To hide the state, a randomly chosen <math>\pi</math> rotation which may or may not be added. From all the above-mentioned conditions, a final measurement angle is formed and the client sends a classical message to the server to inform the server about the final measurement basis (in (X, Y) plane) in which they should measure the corresponding qubit. Thus it reveals no information about the underlying computation.
** The server sends the classical output of each non-input qubit's measurement to the client. The client considers the <math>\pi</math> rotation to get the corrected output. The client also uses this to calculate the measurement angle for the next qubit and thus repeats the process until the last output qubits are reached.
** The server sends the classical output of each non-input qubit's measurement to the client. The client considers the <math>\pi</math> rotation to get the corrected output. The client also uses this to calculate the measurement angle for the next qubit and thus repeats the process until the last output qubits are reached.


Line 46: Line 46:
* <math>\theta_i</math>: Random local phase angles for qubit <math>i</math>.
* <math>\theta_i</math>: Random local phase angles for qubit <math>i</math>.
* <math>|+\rangle_{\theta_i}</math>:  <math>\frac{1}{\sqrt{2}} (|0\rangle +e^{i\theta_i}|1\rangle)</math>
* <math>|+\rangle_{\theta_i}</math>:  <math>\frac{1}{\sqrt{2}} (|0\rangle +e^{i\theta_i}|1\rangle)</math>
* <math>\phi_i</math>: True measurement angle for qubit <math>i</math>.
* <math>\phi_i</math>: True measurement angle for qubit <math>i</math>. This is assigned corresponding to the graph state.
* <math>\phi^{'}_i</math>: Updated version of measurment angle for qubit <math>i</math>.
* <math>r \in \{ 0, 1\}</math>: randomly chosen parameter for <math>\pi</math> rotation in order to hide classical output.
* <math>r \in \{ 0, 1\}</math>: randomly chosen parameter for <math>\pi</math> rotation in order to hide classical output.
* <math>N_g(k)</math>: Denotes neighborhood of vertex k in graph state
* <math>f</math>: Function which defines flow from measured qubits to noninput qubits, <math>f:</math> output vertices <math>\xrightarrow{}</math> input vertices
* <math>\theta^{'}_i</math>: Updated version of Random local phase angle for qubit <math>i</math>.
* <math>\delta_i</math>: Final measurement angle for qubit <math>i</math>.
* <math>\delta_i</math>: Final measurement angle for qubit <math>i</math>.
* <math>b_i</math>: Measurement output by the server.
* <math>b_i</math>: Measurement output by the server.
* <math>s</math>: Sequence of length m describing the result of the nonoutput measurements. <math>s_i \in \{0, 1\}</math>
* <math>s</math>: Sequence of length m describing the result of the nonoutput measurements. <math>s_i \in \{0, 1\}</math>


==Hardware Requirements==
==Requirements==
* Quantum computation resources for the server.
* Quantum computation resources for the server.
* A quantum channel from the client to the server to transfer initial quantum states.
* A quantum channel from the client to the server to transfer initial quantum states.
* Classical channel from the client to the server to transfer measurement angles and outputs.
* Classical channel from the client to the server to transfer measurement angles and outputs.
* Measurement devices for the server and the client in case of quantum outputs.
* Measurement devices for the server.
* Measurement devices for the client in case of quantum outputs.
 
==Knowledge Graph==
 
{{graph}}


==Properties==
==Properties==
* The client is partially quantum and should be able to prepare the given initial quantum states.
* The client is partially quantum and should be able to prepare the given initial quantum states.
* This protocol is secure against malicious adversary setting and also detects a cheating server.
* Security: This protocol is secure against malicious adversary setting and also detects a cheating server.
* This protocol is universal in nature. The universality of the cylinder brickwork state guarantees that the server’s knowledge about the graph does not reveal anything about the underlying computation.
* Universality: This protocol is universal in nature. The universality of the cylinder brickwork state guarantees that the server’s knowledge about the graph does not reveal anything about the underlying computation.
* Correctness If Client and Server follow the protocol as described above, the outcome will be correct.
* Blindness: This protocol is blind in nature, only revealing <math>n</math> and <math>m</math>.
* This protocol requires no quantum memory for the client.
* This protocol requires no quantum memory for the client.
* This protocol is blind in nature, only revealing <math>n</math> and <math>m</math>.
* This protocol is <math>1-\frac{1}{2m}</math> verifiable in quantum output case.
* This protocol is <math>1-\frac{1}{2m}</math> verifiable in quantum output case.
* This protocol is <math>1-\frac{1}{m}</math> verifiable in classical output case.
* This protocol is <math>1-\frac{1}{m}</math> verifiable in classical output case.
Line 70: Line 78:
* Every qubit of the underlying graph could potentially be an isolated trap qubit.
* Every qubit of the underlying graph could potentially be an isolated trap qubit.


==Pseudo-Code==
==Protocol Description==


'''Protocol for quantum output case''': <br></br>
'''Protocol for quantum output case''': <br></br>
'''Stage 1: '''Client's preparation:</br>
'''Stage 1: '''Client's preparation:</br>


'''Input''': Input quantum states, prepared non-input qubits, a trap qubit, and dummy qubits.
'''Input''': Cylindrical brickwork state, <math>|I\rangle</math>.
</br>
</br>
'''Output''': The server receives all the quantum states in order of the labeling of the vertices of the graph state.
'''Output''': Server: <math>m</math> qubits sequentially.  


 
* The client prepares <math>|e\rangle = X^{x1}_1 Z_1(\theta_1) \otimes ... \otimes X^{xn}_n Z_n(\theta_n)|I\rangle</math> using QOTP.
* The client encodes and prepares the first <math>n</math>-input state.
* Client randomly chooses <math>t</math>, where <math>t \in D</math>.
<div style="text-align: center;"><math>|e\rangle = X^{x1}_1 Z_1(\theta_1) \otimes ... \otimes X^{xn}_n Z_n(\theta_n)|I\rangle</math> </div>
* For <math>i = n+1, n+2, ....m</math> (non-input qubits):
* Client randomly chooses the <math>t</math> to be the trap qubit, where <math>t \in D</math>.
* For <math>i = n+1, n+2, ....m</math>:
** if <math>i \in D</math>:
** if <math>i \in D</math>:
*** if <math>i</math> == dummy qubit:
*** if <math>i != t</math> then state <math>|0\rangle</math> or <math>|1\rangle</math> is prepared
**** State <math>|0\rangle</math> or <math>|1\rangle</math> is prepared
*** if <math>i == t</math> then <math>|+\rangle_{\theta_i}</math> is prepared
*** if <math>i</math> == trap qubit:
** else <math>|+\rangle_{\theta_i}</math> is prepared
**** <math>|+\rangle_{\theta_i}</math> is prepared
* <math>\forall l\epsilon\{1,..,n\}</math>, Client sends all qubits to server.
** if <math>i</math> == non-input qubit:
*** <math>|+\rangle_{\theta_i}</math> is prepared
* For <math>l = 1, 2, ...n</math>:
** The client sends the qubits to the server.




'''Stage 2: '''Server's preparation:</br>
'''Stage 2: '''Server's preparation:</br>
'''Output''': Cylinder brickwork state which has a disentangled trap qubit.
'''Input''': <math>m</math> qubits sequentially.</br>
'''Output''': entangled graph state with a disentangled trap qubit.
* Server creates an entangled state from all received qubits using CZ operations according to their indices and creates the cylinder brickwork state.
* Server creates an entangled state from all received qubits using CZ operations according to their indices and creates the cylinder brickwork state.


'''Stage 3: '''Interaction and Measurement:</br>
'''Stage 3: '''Interaction and Measurement:</br>
'''Input''': <math>\delta_i</math></br>
'''Input''': <math>\delta_i</math></br>
'''Output''': <math>b_i</math>
'''Output''': <math>s_i</math>


* For <math>i = 1, 2, ... m-n</math>:  
* For <math>i = 1, 2, ... m-n</math> (received qubits):  
** Client computes <math>\phi_i</math>.
** Client computes <math>\phi_i</math>.
*** if <math>i == t</math>:
*** if <math>i == t</math>, then <math>\phi_i = 0</math>
**** <math>\phi_i = 0</math>
** Client randomly selects <math>r_i</math> and generates <math>\theta'_i = \theta_i + r_i</math>.
** Client randomly selects <math>r_i</math>.
** Client then computes the angle <math>\delta_i = (-1)^{x_i + s_{f^{-1}(i)}}\phi_i + \sum_{j:i \in N_g(f(j)}\theta'_i + s_i\pi</math> and sends <math>\delta_i</math> to server.
** Client then computes the angle <math>\delta_i</math> and sends this to the server.
** Server measures <math>i</math> and sends <math>b_i</math> to client.
<div style="text-align: center;"><math>\delta_i = \phi^{'}_i + \theta_i + r_i\pi</math></div>
** Client sets the value <math>s_i = b_i \oplus r_i</math> in <math>s</math>
** Server measures <math>b_i</math> and sends it to client.
** Client sets the value of <math>s_i</math> in <math>s</math> to be <math>b_i \oplus r_i</math>.


'''Stage 4: '''Verification:</br>
'''Stage 4: '''Verification:</br>
'''Input''': Output qubits <math>m-n+1</math> to <math>m</math></br>
'''Input''': Output qubits <math>m-n+1</math> to <math>m</math></br>
'''Output''': Verification result
'''Output''': Verification result
* For <math>i = m-n+1, ... m</math>:  
* For <math>i = m-n+1, ... m</math> (output qubits):  
** Server sends output qubit <math>i</math> to client.
** Server sends <math>i</math> to client.
* Client measures the output trap qubit <math>t</math> (which was disentangled) with angle <math>\delta_t = \phi_t + r_t\pi</math>.  
* Client measures the output trap qubit <math>t</math> (which was disentangled) with angle <math>\delta_t = \phi_t + r_t\pi</math>.  
** Client obtains the result <math>b_t</math>.
** Client obtains the result <math>b_t</math>.
*** If <math>b_t == r_t</math>:
*** If <math>b_t == r_t</math>, then computation is accepted.
**** Computation is accepted.
*** else, computation is rejected.
*** else:
 
**** Computation is rejected.
==Simulation and benchmark==
A simulation code for benchmarking the Quantum Token Protocol is available [https://github.com/LiaoChinTe/netsquid-simulation/tree/main/VBQC here].
Hardware parameter analysis can be found in the following [https://cloud.veriqloud.fr/index.php/s/iiw1SxU4D22FyQ7 preprint]
 


==Further Information==
==Further Information==
<div style='text-align: right;'>''*contributed by Rhea Parekh''</div>
<div style='text-align: right;'>''*contributed by Rhea Parekh''</div>

Latest revision as of 07:07, 12 November 2021

The example protocol achieves the functionality of Secure Verifiable Delegated Quantum Computation which enables a client with limited quantum technology to delegate a computation to an untrusted but powerful quantum server in such a manner, where the privacy of the computation is maintained. This protocol introduces verifiability as a property and allows the client to verify the correctness of Prepare-and-Send Universal Blind Quantum Computation. The client has an ability to verify whether the server has followed the instructions of the protocol and also can check if the server tried to deviate from the protocol which would have resulted in an incorrect output state.

Tags: Two Party,Universal Task, Quantum Functionality, Quantum Offline communication, Classical Online communication, Measurement Based Quantum Computation (MBQC), Measurement Only UBQC, Pseudo-Secret Random Qubit Generator (PSQRG), Prepare-and-Send Universal Blind Quantum Computation.

Assumptions[edit]

  • The protocol assumes perfect state preparation, transmissions, and measurements.
  • The client never deviates from the protocol.
  • The position of the trap qubit always remains hidden from the server.

Outline[edit]

This protocol is a modified version of Prepare-and-Send Universal Blind Quantum Computation, which is based on (MBQC). Here a powerful adversarial server is delegated with quantum computation which maintains the privacy of the computation. Any computational deviations by this server are detected by high probability. This is achieved by insertion of randomly prepared and blindly isolated single qubits in the computation, which act as a trap (trap qubits), hence assisting the client in verification.

MBQC required a set of the initial state for computation. The brickwork states used in Prepare-and-Send Universal Blind Quantum Computation are modified to cylinder brickwork states which enables the client to embed a trap qubit surrounded by multiple dummy qubits without disrupting the computation. This state is universal and maintains the privacy of the client's preparation. The dummy qubits here do not take part in the actual computation as they are disentangled from the rest of the qubits of the graph state. Hence by adding them to the neighboring nodes of the trap qubits, they are blindly isolated and thus do not interfere with the actual computation. The dummy qubits are added next to the trap qubit in a tape format as seen in cylinder brickwork states.

This protocol is divided into four stages: Client's preparation, server's preparation, interaction and measurement, verification.

  • Client's preparation: The partially quantum client prepares the quantum states with embedded traps qubits and sends them to the server for creation of the cylinder brickwork state.
    • For the server to create a cylinder brickwork state, the client prepares single qubit states. The first qubit input states are specially encoded and Quantum one time pad is applied to these states with randomly chosen keys.
    • Then the client randomly selects one qubit as the trap qubit and corresponding to the graph of cylinder brickwork state, all the other qubits in the tape are set as the dummy qubits. The trap qubit is prepared with the local phase angle set to . The dummy qubits isolate the trap qubit from the graph state.
    • The remaining non-input qubit states (not including the dummy states and trap qubit) are prepared with randomly chosen local phase angles.
    • The client then sends all the prepared qubits in the respective order to the server so the graph state can be constructed.
  • Server's Preparation: The server receives the qubits in a sequential order of rows and columns till all qubits are received. The server then entangles them according to the cylinder brickwork state (using CZ gate).
  • Interaction and Measurement: This step is exactly the same as for Prepare-and-Send Universal Blind Quantum Computation.
    • For a specific computation, MBQC decides which measurement angle is selected along with some extra Pauli X, Z corrections for every qubit. The correction sets are unique for every graph state and depend on the previous measurement. These can obtained from flow construction. The qubits have a randomly chosen local phase angle and hence the same local phase angle is used for computation as well as for output correction. To hide the state, a randomly chosen rotation which may or may not be added. From all the above-mentioned conditions, a final measurement angle is formed and the client sends a classical message to the server to inform the server about the final measurement basis (in (X, Y) plane) in which they should measure the corresponding qubit. Thus it reveals no information about the underlying computation.
    • The server sends the classical output of each non-input qubit's measurement to the client. The client considers the rotation to get the corrected output. The client also uses this to calculate the measurement angle for the next qubit and thus repeats the process until the last output qubits are reached.
  • Verification: The verification is carried on by the client by comparing the outcome of the trap qubit measurements with the expected outcome.
    • For Quantum outputs:
      • The server sends all the output qubits to the client.
      • From these output qubits, the client performs a measurement on the trap qubit. If the output is equal to the expected outcome, the computation is verified. Otherwise, it is rejected.
      • If the computation is accepted, output correction is performed on the other output qubits (except the trap qubit).
    • For Classical outputs:
      • The server continues performing measurements on the output qubits with the measurement angles sent by the server.
      • The client compares the output of the trap qubit with the expected output. If it is equal, computation is verified. Otherwise, it is rejected. If the computation is accepted, the client accepts the other output measurement results as the computation result.

Notation[edit]

  • : Total number of input qubits. Also total number of output qubits in quantum outputs.
  • : Total number of qubits in the graph state.
  • : qubit input state.
  • : Encoded qubit input state.
  • : Set of random bits used in encoding via quantum one time pad.
  • : Trap qubit position vertex in the graph state.
  • : Set of all position vertices in the tape of the cylinder brickwork state.
  • : Random local phase angles for qubit .
  • :
  • : True measurement angle for qubit . This is assigned corresponding to the graph state.
  • : randomly chosen parameter for rotation in order to hide classical output.
  • : Denotes neighborhood of vertex k in graph state
  • : Function which defines flow from measured qubits to noninput qubits, output vertices input vertices
  • : Updated version of Random local phase angle for qubit .
  • : Final measurement angle for qubit .
  • : Measurement output by the server.
  • : Sequence of length m describing the result of the nonoutput measurements.

Requirements[edit]

  • Quantum computation resources for the server.
  • A quantum channel from the client to the server to transfer initial quantum states.
  • Classical channel from the client to the server to transfer measurement angles and outputs.
  • Measurement devices for the server.
  • Measurement devices for the client in case of quantum outputs.

Knowledge Graph[edit]

Properties[edit]

  • The client is partially quantum and should be able to prepare the given initial quantum states.
  • Security: This protocol is secure against malicious adversary setting and also detects a cheating server.
  • Universality: This protocol is universal in nature. The universality of the cylinder brickwork state guarantees that the server’s knowledge about the graph does not reveal anything about the underlying computation.
  • Correctness If Client and Server follow the protocol as described above, the outcome will be correct.
  • Blindness: This protocol is blind in nature, only revealing and .
  • This protocol requires no quantum memory for the client.
  • This protocol is verifiable in quantum output case.
  • This protocol is verifiable in classical output case.
  • The trap qubit in the tape format of the cylinder brickwork state remains disentangled from the rest of the graph.
  • Every qubit of the underlying graph could potentially be an isolated trap qubit.

Protocol Description[edit]

Protocol for quantum output case:

Stage 1: Client's preparation:

Input: Cylindrical brickwork state, .
Output: Server: qubits sequentially.

  • The client prepares using QOTP.
  • Client randomly chooses , where .
  • For (non-input qubits):
    • if :
      • if then state or is prepared
      • if then is prepared
    • else is prepared
  • , Client sends all qubits to server.


Stage 2: Server's preparation:
Input: qubits sequentially.
Output: entangled graph state with a disentangled trap qubit.

  • Server creates an entangled state from all received qubits using CZ operations according to their indices and creates the cylinder brickwork state.

Stage 3: Interaction and Measurement:
Input:
Output:

  • For (received qubits):
    • Client computes .
      • if , then
    • Client randomly selects and generates .
    • Client then computes the angle and sends to server.
    • Server measures and sends to client.
    • Client sets the value in

Stage 4: Verification:
Input: Output qubits to
Output: Verification result

  • For (output qubits):
    • Server sends to client.
  • Client measures the output trap qubit (which was disentangled) with angle .
    • Client obtains the result .
      • If , then computation is accepted.
      • else, computation is rejected.

Simulation and benchmark[edit]

A simulation code for benchmarking the Quantum Token Protocol is available here. Hardware parameter analysis can be found in the following preprint


Further Information[edit]

*contributed by Rhea Parekh