Main Page

2019-06-18T08:44:26Z

Charlie: /* The goal */

'''Welcome to The Quantum Protocol Zoo -''' ''Explore, Learn, Code and Implement Quantum Protocols''<br/><br/>The quantum protocol zoo is an open repository of protocols for quantum networks. It provides a compact and canonical way to explore such protocols. Moreover, it allows for easy communication among computer scientists, engineers, and physicists on a single platform.
*[[Quantum Protocol Zoo:About|About us]]
*[[Quantum Protocol Zoo:General disclaimer| Disclaimer]]
*[[Quantum Protocol Zoo:Copyrights|Copyrights]]
== Getting started ==
Quantum Protocol Zoo is a repository of protocols for quantum networks. It presents a wiki of protocols for various functionalities classified in terms of the [[:Category: Network Stages|network stages]] for a quantum internet. It is important to note that, although there are several different ways of defining a protocol, we characterise it as something that involves more than one party. In particular, we define a protocol as a sequence of steps, specifically designed to accomplish a task. It may or may not involve an algorithm and could be run between trusted parties as well as parties who don't trust each other.

The wiki consists of two types of pages: The first type is a functionality page, describing a general task which can be realised in a quantum network (the "what"). The second type of page is a protocol page, which describes a specific protocol implementing the defined functionality (the "how"). These pages are listed in [[Protocol Library]]. Furthermore, a page on [[Supplementary Information]] has been provided for background information about quantum theory. Any information on [[How to Submit]] or contact can be found in the Navigation menu on the sidebar. Every page has a Discussion section, where users are welcome to leave their comments.

== The goal ==
The goal of this project is multifold. First, it aims to provide a compact and precise review of all the existing protocols in one place, such that it is accessible to both the young researchers motivated to enter into the field as well as quantum enthusiasts. Second, our platform enables the experts from academia and industry to find real-life use cases for the listed protocols and at the same time innovate on (or compose) the existing ones to tailor-made new protocol for a desired task. Finally, our main intention is to also develop standardised form for protocol descriptions to make the community quantum-internet ready. At the same time, we emphasise that our purpose is not to point out the strengths or weaknesses of any particular protocol or functionality.

As a direct consequence of this effort, hosting and analysing the protocols in this fashion provides an underlying link between several protocols and would enable everyone to gain a deeper understanding of their working. With the rapid progress in quantum technologies and improvements in the current protocols, it is extremely beneficial to have a resource for all the quantum protocols in one place that can be regularly updated to keep track of the advancements, something that can not be achieved with the review articles or a book. We, therefore, invite everyone from the quantum information science community to join and contribute to this initiative in collectively making the quantum protocol zoo a crucial source for quantum protocols.

== Wonder what's the format for contribution? ==

We welcome contributions from various fields, here we give the format of the kinds of pages, the wiki is composed of. A more detailed set of guidelines for submissions can be found on the [[How to Submit]] page.

=== Functionality Page===
----
Functionality page describes a general task which can be realized in a quantum network (the "what"). It consists of the following sections.
</br>
<div style="background-color: white; border: solid thin black;title=Functionality Description;">
* '''Functionality Description''' A lucid definition of functionality in discussion.
----
* '''Tags''' Any related page or list of protocols is connected by this section
----
* '''Use Case''' (if available) compares security, efficiency and practicality of quantum protocols with its available classical analogues; connects protocols with real world applications.

----
*'''Protocols''' List of different types of example protocol achieving the functionality (each protocol in this list is written in the format given below) depending on the task achieved or [[:Category: Network Stages|Network Stages]] required to achieve the same functionality

----
*'''Properties''' All properties that should be satisfied by any protocol achieving the concerned functionality and other common terminologies used in all the protocols.

----
*'''Further Information''' Any issue that could not be addressed or find a place in the above sections or any review paper discussing a feature of various types of protocols related to the functionality.
</div>

=== Protocol Page ===
----
Protocol page describes a specific protocol implementing the defined functionality (the "how"). It consists of the following sections.
</br>
<div style="background-color: white; border: solid thin black;title=Functionality Description;">
*'''Link''' to the corresponding functionality together with a short description of the method used and properties satisfied by a protocol.
----
*'''Tags''' Any related page or list of protocols is connected by this section
----
*'''Assumptions''' It describes the setting in which the protocol will be successful. Any assumption on the setup for the protocol below is listed in this section.
----
*'''Outline''' A non-mathematical detailed outline which provides a rough idea of the concerned protocol. A figure is accommodated for most protocols.
----
*'''Notation''' Connects the non-mathematical outline with further sections.
----
*'''Component requirements''' Order of digits related to threshold values, QBit Error Rate (QBER), parameters, etc.. are illustrated in this section. A figure demonstrating the physical resources, nodal subroutines, and other protocols being used is accommodated here.
----
*'''Properties''' A list of important information extracted from the protocol such as parameters (threshold values), security claim, success probability, etc..
----
*'''Pseudocode''' Mathematical step-wise protocol algorithm helpful to write a subroutine.
----
*'''Further Information''' Any useful information that could not find its place in the above description goes here. Also, some pages on protocols might include a short description as below for a list of protocols in the same class of functionality and network stage that are easy to interpret after reading the concerned formal description (or are variants of the protocol discussed above):
*Theoretical Papers:
**How is it different from the above protocol
**Requirements
**Security
*Experimental Papers:
**Which paper or protocol does it implement
**Benchmark values for this demonstration
</div>

Quantum Token

2019-04-25T10:48:14Z

Charlie: /* Further Information */

Money is issued by one party (bank) to a prover (client) such that when he presents it to a verifier
(merchant), he/she is satisfied that the money presented by client comes from the bank. It comes
with the property of [[unforgeability]] and [[transferrability]]. Unforgeability means that there should exist
no method to produce an identical copy by anyone but the bank, and transferrability, allows that this
money can be used by the verifier as a client himself in the next round.</br>

'''Tags:''' [[:Category: Multi Party Protocols|Multi Party Protocols]], non local games, [[:Category: Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[:Category: Specific Task|Specific Task]]
[[Category: Prepare and Measure Network Stage]]
[[Category: Specific Tasks]]
[[Category: Quantum Enhanced Classical Functionality]]
[[Category: Multi Party Protocols]]

==Assumptions==
* Money is physically transferred to the holders
* If <math>F^{cv}_{tol} > (1+1/\sqrt{2})/2</math> , a dishonest user is exponentially unlikely to be authenticated by two independent verifiers (success in cheating to use same ticket for two independent verifiers by measuring in intermediate basis between the two bases, asked by the verifiers individually).

==Outline==
The protocol can be divided into three parts
* '''Preparation''' Bank prepares few rows of qubit-pairs chosen from two different non-orthogonal sets of basis. Each pair has at least one state from both bases, such that the qubit pair states are non-orthogonal. It associates each such chosen set with a serial number and shares the classical information about the choices for respective serial number with trusted merchants.
* '''Interaction''' This step involves challenge questions by verifier to prove that he has a valid token, by playing part of a [[non-local game]]. In this game, the merchant asks client to measure in one of the two bases in from which the qubit pairs were chosen. As each qubit pair contains at least one state from each basis chosen, after the measurement one of the qubits (encoded in the basis chosen by the merchant) would give the correct result.
* '''Transaction''' The merchant compares this qubit outcome whose encoding basis matches with merchant's basis for the game. Merchant accepts the ticket if the ratio of number of valid outcomes to total number of qubits measured is more than or equal to a certain threshold fidelity value.

==Notation==
*<math>N=n*r*2</math>, total number of qubits
*<math>F^{cv}_{tol}:</math> is the tolerance fidelity set by the verifiers
*<math>F^{cv}_{tol}(r*2) < F^{exp}:</math> where <math> F^{exp}</math> is the average experimental fidelity

==Requirements==
*Network stage: [[:Category: Quantum Memory Network Stage|quantum memory network]][[Category:Quantum Memory Network Stage]].

==Properties==
* Challenge questions reveal no information about the token
* No quantum communication is needed
* Tokens are remotely verifiable/ classically verifiable
* A dishonest user is exponentially unlikely to succeed with probability at most, <math>p_d = e^{ND}(2F^{cv}_{tol}-1||2/3)</math>, where <math>(2F^{cv}_{tol}-1)</math> is the fraction of qubits to be copied in order to forge a ticket and 2/3 is the average fidelity of copies produced by optimal cloning map, D being relative entropy.
* An honest user is exponentially likely to succeed with probability at least, <math>p^{cv}_h = e^{ND}(F^{exp}||F^{cv}_{tol})</math>

==Pseudo-Code==
'''Input:''' (Bank) <math>n*r*2</math>, Qubit-pairs <math>\epsilon_R\{(0,+),(0,-),(1,+),(1,-),(+,0),(-,0),(+,1),(-,1)\}</math> </br>
'''Output:''' (Merchant) accept or reject</br>
<u>'''Stage 1'''</u> Preparation </br>
# Bank prepares Token<math>_S</math> with <math>n*r*2</math> qubit pairs
# Bank distributes tickets to clients
# Bank distributes the classical record of states corresponding to S to trusted
verifiers (merchants)
<u>'''Stage 2'''</u> Interaction </br>
# Merchant asks client to measure a few qubit-pairs(say, a row) in a randomly chosen basis M \epsilon_R \{X,Z\}
# Client returns measurement outcome (m) for all qubit pairs asked to measure
<u>'''Stage 3'''</u> Transaction </br>
# Merchant compares the number of qubit pairs with the valid outcome for the qubit which was
generated in M basis as k.
# Merchant accepts if <math>k/(r*2)>F^{cv}_{tol}</math> else he rejects

==Further Information==

# [https://arxiv.org/abs/1705.01428 BOTZKD-QMoney (2018)] replaces qubits with [[coherent states]] and it implements the quantum money on the fly (i.e. without quantum memory).

<div style='text-align: right;'>''*contributed by Shraddha Singh''</div>

Quantum Token

2019-04-25T10:44:05Z

Charlie: /* Further Information */

Money is issued by one party (bank) to a prover (client) such that when he presents it to a verifier
(merchant), he/she is satisfied that the money presented by client comes from the bank. It comes
with the property of [[unforgeability]] and [[transferrability]]. Unforgeability means that there should exist
no method to produce an identical copy by anyone but the bank, and transferrability, allows that this
money can be used by the verifier as a client himself in the next round.</br>

'''Tags:''' [[:Category: Multi Party Protocols|Multi Party Protocols]], non local games, [[:Category: Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[:Category: Specific Task|Specific Task]]
[[Category: Prepare and Measure Network Stage]]
[[Category: Specific Tasks]]
[[Category: Quantum Enhanced Classical Functionality]]
[[Category: Multi Party Protocols]]

==Assumptions==
* Money is physically transferred to the holders
* If <math>F^{cv}_{tol} > (1+1/\sqrt{2})/2</math> , a dishonest user is exponentially unlikely to be authenticated by two independent verifiers (success in cheating to use same ticket for two independent verifiers by measuring in intermediate basis between the two bases, asked by the verifiers individually).

==Outline==
The protocol can be divided into three parts
* '''Preparation''' Bank prepares few rows of qubit-pairs chosen from two different non-orthogonal sets of basis. Each pair has at least one state from both bases, such that the qubit pair states are non-orthogonal. It associates each such chosen set with a serial number and shares the classical information about the choices for respective serial number with trusted merchants.
* '''Interaction''' This step involves challenge questions by verifier to prove that he has a valid token, by playing part of a [[non-local game]]. In this game, the merchant asks client to measure in one of the two bases in from which the qubit pairs were chosen. As each qubit pair contains at least one state from each basis chosen, after the measurement one of the qubits (encoded in the basis chosen by the merchant) would give the correct result.
* '''Transaction''' The merchant compares this qubit outcome whose encoding basis matches with merchant's basis for the game. Merchant accepts the ticket if the ratio of number of valid outcomes to total number of qubits measured is more than or equal to a certain threshold fidelity value.

==Notation==
*<math>N=n*r*2</math>, total number of qubits
*<math>F^{cv}_{tol}:</math> is the tolerance fidelity set by the verifiers
*<math>F^{cv}_{tol}(r*2) < F^{exp}:</math> where <math> F^{exp}</math> is the average experimental fidelity

==Requirements==
*Network stage: [[:Category: Quantum Memory Network Stage|quantum memory network]][[Category:Quantum Memory Network Stage]].

==Properties==
* Challenge questions reveal no information about the token
* No quantum communication is needed
* Tokens are remotely verifiable/ classically verifiable
* A dishonest user is exponentially unlikely to succeed with probability at most, <math>p_d = e^{ND}(2F^{cv}_{tol}-1||2/3)</math>, where <math>(2F^{cv}_{tol}-1)</math> is the fraction of qubits to be copied in order to forge a ticket and 2/3 is the average fidelity of copies produced by optimal cloning map, D being relative entropy.
* An honest user is exponentially likely to succeed with probability at least, <math>p^{cv}_h = e^{ND}(F^{exp}||F^{cv}_{tol})</math>

==Pseudo-Code==
'''Input:''' (Bank) <math>n*r*2</math>, Qubit-pairs <math>\epsilon_R\{(0,+),(0,-),(1,+),(1,-),(+,0),(-,0),(+,1),(-,1)\}</math> </br>
'''Output:''' (Merchant) accept or reject</br>
<u>'''Stage 1'''</u> Preparation </br>
# Bank prepares Token<math>_S</math> with <math>n*r*2</math> qubit pairs
# Bank distributes tickets to clients
# Bank distributes the classical record of states corresponding to S to trusted
verifiers (merchants)
<u>'''Stage 2'''</u> Interaction </br>
# Merchant asks client to measure a few qubit-pairs(say, a row) in a randomly chosen basis M \epsilon_R \{X,Z\}
# Client returns measurement outcome (m) for all qubit pairs asked to measure
<u>'''Stage 3'''</u> Transaction </br>
# Merchant compares the number of qubit pairs with the valid outcome for the qubit which was
generated in M basis as k.
# Merchant accepts if <math>k/(r*2)>F^{cv}_{tol}</math> else he rejects

==Further Information==

# [https://arxiv.org/abs/1705.01428 BOTZKD-QMoney (2018)]

<div style='text-align: right;'>''*contributed by Shraddha Singh and Mathieu Bozzio''</div>

Quantum Coin

2019-04-25T10:36:30Z

Charlie: /* Requirements */

Quantum Money is a unique object generated by a Trusted Third Party (TTP). Then, it is circulated among untrusted clients (Transferability property). Each client should be able to prove the authenticity of his owned quantum money to a verifier. On the other hand, an adversary must fail in counterfeiting the quantum money with overwhelmingly high probability (Unforgeability property). <br>

'''Tags''': Multiparty, Quantum Enhanced Classical functionality, prepare (bank) and measure (client)

== Outline ==
In this scheme, a Trusted Third Party (TTP) and a coin holder run the following procedure for generating and verifying a quantum coin:<br>
* '''Quantum coin Generation''' - The TTP chooses k random 4-bit strings, keeps them in secret and produce k quantum states. A newly issued quantum coin consists of a piece of paper glued to k quantum registers that hold k quantum states. The piece of paper contains a unique identification tag and k initially unmarked positions, where the i-th position has to be marked in k-bit classical register P when the corresponding quantum state is used in the verification protocol.
* '''Quantum coin Verification''' - To verify a quantum coin through classical communication with the TTP, its holder sends the identification number of the quantum coin to the TTP. Then, the TTP and the coin holder exchange some classical information for choosing some quantum registers. The coin holder measures the chosen registers and sends their corresponding classical information to the TTP. The TTP verifies the authenticity of the coin by the secret information he possesses.

==Requirements==
*Network stage: [[:Category: Quantum Memory Network Stage|quantum memory network]][[Category:Quantum Memory Network Stage]].

== Properties ==

* '''Parameters''': HMP<sub>4</sub>-states, Let x ∈ {0, 1}<sup>4</sup>. The corresponding HMP<sub>4</sub>-states is <math>|\alpha(x)\rangle=\dfrac{1}{2}\sum_{1\leq i\leq4}(-1)^{x_i}|i\rangle</math>
* '''General Features''':
** No need to quantum communication for quantum coin verification.
** The classical communication channel used for verification can be unencrypted.
** The database of the bank is static, and therefore many de-centralized “verification branches” can exist that do not have to communicate with one another.
** The number of verifications that a quantum coin can go through is limited.

*'''Security Claims''':
**The coins are exponentially hard to counterfeit.
**Secure against an adversary who uses adaptive “attempted verifications” in order to collect information about a coin.

== Protocol ==
'''Stage 1: Quantum coin generation'''<br>
''Input'': A secret record consists of <math>k</math> entries <math>x_1, . . . , x_k</math>,<math> x_i\in \{0,1\}^4</math><br>
''Output'': A “fresh” quantum coin<br>
The Trusted Third Party (TTP) chooses <math>x_1, . . . , x_k\in\{{0, 1}\}^4</math> at random, keeps them in secret and produces quantum states <math>|\alpha(x_1)\rangle, . . . , |\alpha(x_k)\rangle</math>.
A “fresh” quantum coin corresponding to this record consists of:
* <math>k</math> quantum registers consisting of 2 qubits each, where the <math>i</math>-th register contains <math>|\alpha(x_i)\rangle</math>;
* a <math>k</math>-bit classical register <math>P</math>, that is initially set to <math>0^k</math>;
* a unique identification number.

'''Stage 2: Quantum coin verification'''<br>
''Input'': the identification number of the quantum coin<br>
''Output'': Accept or Reject<br>
<br>
This stage is run as follows:
* The holder sends the identification number of the quantum coin to the TTP.
* The TTP chooses uniformly at random a set <math>L_{bn}\subset[k]</math> of size <math>t</math>, and sends it to the coin holder.
* The holder consults with P and chooses uniformly at random a set <math>L_{hl} \subset L_{bn}</math> consisting of <math>2t/3</math> yet unmarked positions. He sends <math>L_{hl}</math> to the bank and marks in <math>P</math> all the elements of <math>L_{hl}</math> as used.
* The TTP chooses at random <math>2t/3</math> values <math>m_i \in\{{0, 1}\}</math>, one for each <math>i \in L_{hl}</math> , and sends them to the coin holder.
* The holder measures the quantum registers corresponding to the elements of <math>L_{hl}</math> in order to produce <math>2t/3</math> pairs <math>(a_i, b_i)</math>, such that <math>(x_i,m_i, a_i, b_i)\in HMP_4</math> for all <math>i \in L_{hl}</math>. He sends the list of <math>(a_i, b_i)</math>s to the TTP.
* The TTP checks whether <math>(x_i,m_i, a_i, b_i)\in HMP_4</math> for all <math>i \in L_{hl}</math>, in which case it confirms validity of the quantum coin. Otherwise, the coin is declared to be a counterfeit.

<div style='text-align: right;'>''*contributed by Mashid Delavar''</div>

2019-04-25T10:03:08Z

Charlie: Removed redirect to Quantum Token

Money is issued by one party (bank) to a prover (client) such that when he presents it to a verifier
(merchant), he/she is satisfied that the money presented by client comes from the bank. It comes
with the property of [[unforgeability]] and [[transferrability]]. Unforgeability means that there should exist
no method to produce an identical copy by anyone but the bank, and transferrability, allows that this
money can be used by the verifier as a client himself in the next round.</br>

'''Tags:''' [[:Category: Multi Party Protocols|Multi Party Protocols]], non local games, [[:Category: Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[:Category: Specific Task|Specific Task]]
[[Category: Prepare and Measure Network Stage]]
[[Category: Specific Tasks]]
[[Category: Quantum Enhanced Classical Functionality]]
[[Category: Multi Party Protocols]]

==Assumptions==
* Money is physically transferred to the holders
* If <math>F^{cv}_{tol} > (1+1/\sqrt{2})/2</math> , a dishonest user is exponentially unlikely to be authenticated by two independent verifiers (success in cheating to use same ticket for two independent verifiers by measuring in intermediate basis between the two bases, asked by the verifiers individually).

==Outline==
The protocol can be divided into three parts
* '''Preparation''' Bank prepares few rows of qubit-pairs chosen from two different non-orthogonal sets of basis. Each pair has at least one state from both bases, such that the qubit pair states are non-orthogonal. It associates each such chosen set with a serial number and shares the classical information about the choices for respective serial number with trusted merchants.
* '''Interaction''' This step involves challenge questions by verifier to prove that he has a valid token, by playing part of a [[non-local game]]. In this game, the merchant asks client to measure in one of the two bases in from which the qubit pairs were chosen. As each qubit pair contains at least one state from each basis chosen, after the measurement one of the qubits (encoded in the basis chosen by the merchant) would give the correct result.
* '''Transaction''' The merchant compares this qubit outcome whose encoding basis matches with merchant's basis for the game. Merchant accepts the ticket if the ratio of number of valid outcomes to total number of qubits measured is more than or equal to a certain threshold fidelity value.

==Notation==
*<math>N=n*r*2</math>, total number of qubits
*<math>F^{cv}_{tol}:</math> is the tolerance fidelity set by the verifiers
*<math>F^{cv}_{tol}(r*2) < F^{exp}:</math> where <math> F^{exp}</math> is the average experimental fidelity

==Hardware Requirements==
'''Network Stage''': [[:Category: Prepare and Measure Network Stage|Prepare and Measure]]

==Properties==
* Challenge questions reveal no information about the token
* No quantum communication is needed
* Tokens are remotely verifiable/ classically verifiable
* A dishonest user is exponentially unlikely to succeed with probability at most, <math>p_d = e^{ND}(2F^{cv}_{tol}-1||2/3)</math>, where <math>(2F^{cv}_{tol}-1)</math> is the fraction of qubits to be copied in order to forge a ticket and 2/3 is the average fidelity of copies produced by optimal cloning map, D being relative entropy.
* An honest user is exponentially likely to succeed with probability at least, <math>p^{cv}_h = e^{ND}(F^{exp}||F^{cv}_{tol})</math>

==Pseudo-Code==
'''Input:''' (Bank) <math>n*r*2</math>, Qubit-pairs <math>\epsilon_R\{(0,+),(0,-),(1,+),(1,-),(+,0),(-,0),(+,1),(-,1)\}</math> </br>
'''Output:''' (Merchant) accept or reject</br>
<u>'''Stage 1'''</u> Preparation </br>
# Bank prepares Token<math>_S</math> with <math>n*r*2</math> qubit pairs
# Bank distributes tickets to clients
# Bank distributes the classical record of states corresponding to S to trusted
verifiers (merchants)
<u>'''Stage 2'''</u> Interaction </br>
# Merchant asks client to measure a few qubit-pairs(say, a row) in a randomly chosen basis M \epsilon_R \{X,Z\}
# Client returns measurement outcome (m) for all qubit pairs asked to measure
<u>'''Stage 3'''</u> Transaction </br>
# Merchant compares the number of qubit pairs with the valid outcome for the qubit which was
generated in M basis as k.
# Merchant accepts if <math>k/(r*2)>F^{cv}_{tol}</math> else he rejects

==Further Information==

<div style='text-align: right;'>''*contributed by Shraddha Singh''</div>

Talk:Unforgeable Quantum Token

2019-04-25T10:00:20Z

Charlie: Charlie moved page Talk:Unforgeable Quantum Token to Talk:Quantum Token

#REDIRECT [[Talk:Quantum Token]]

Talk:Quantum Token

Charlie:

All material presented in the Zoo are either created originally by the contributor or taken from the other sources that are cited in the page. As an open source collection, we encourage everyone to use these materials however this should be properly cited both to the Zoo and the original Paper that the contribution is based on.