Submissions

Submissions can be made to the google form provided in the link below. A request can be made to include an article in the "Discussion" section for a certain protocol. If you do not find any required functionality or think your protocol requires a new page, submit *.txt version of the protocol file using instructions in the guidelines given below. Note that Quantum Protocol Zoo accepts only published articles. The final decision on a request resides with the Quantum Protocol Zoo team.

Link to Google Form: https://forms.gle/ANokaD4iCzwvYjdb6

Comments are welcomed in order to make it more user-friendly and can be addressed in the 'Discussion'.

Guidelines

• Abstract
  • Links the functionality page, defines objective and method used for the concerned protocol.
  • Should define all the properties of protocol that fit the functionality. E.g. For Blind Quantum Computation, the abstract links Delegated Quantum Computation, defines Blind Computation and states the properties concerned i.e. blindness, correctness and universality linking each term to the properties section on functionality page. Mention any extra property that this specific type of protocol or any of its variants (with reference) achieve. E.g. Blind Quantum Computation hides computation, input and output of a computation from the Server.
  • No new terms should be used unless explained in the same paragraph. If the term is complex and needs further explanation one can also provide a link for the same to the supplementary information page. e.g. fidelity (measure of how close two quantum states are), and the link would direct one to a mathematical formula of the same in the supplementary page.
  • No fictional names to be used. The parties should be called according to their role e.g. Client-Server instead of Alice-Bob is preferred.
  • Should be a short and precise paragraph.
  • Should be lucid.
  • Avoid mathematical equations or notations.
  • If possible, address a user-friendly utility of the protocol

• Tags
  • One- or two-words tags.
  • Tags are terms used to indicate any term related to the concerned functionality or formal description.
  • All related pages which one wants to bring notice to the reader are also included in tags.
  • One should try to put as many tags as possible. e.g for Public Quantum Money, Tags: Money, Specific Task, Multi party, Private Quantum Money,..

Assumptions

---

• All setup assumptions taken into account for this protocol should be mentioned here.
  For e.g. classical or quantum authenticated channel
• Assumptions on adversary. A link to the security definitions section on the supplementary information page should be provided.

Outline

---

• A detailed wordy description.
• No mathematical notations or equations to be used.
• Bullet points are preferred.
• Same as functionality description it should be lucid, but one is free to make this section lengthy (yet avoid redundancy)
• Should give a rough picture of the protocol without any specific details like number of qubits used or threshold value if any.
• In the end, this section should accommodate a figure of the protocol which describes the quantum and classical channels distribution for the protocol and elicits an example of the protocol. See an example in Protocol Library (sidebar). A hand-rough hand drawn figure can be submitted.

Notation

---

The following sections on properties and pseudo code contain mathematical equations and hence to connect it with the wordy outline this section displays all notations used.

Hardware Requirements

---

• Network Stage:
• Network Stage parameters of relevance:
• Benchmark values for the various parameters of the protocol such as fidelity value, transmission distance, Qubit Error Rate (QBER), estimated time, number of rounds, network stage the protocol belongs to, etc.. should be included in this section explicitly.
• Hardware setup for this protocol. (e.g. BB84 QKD or Decoy state preparation and measurement devices, etc)

Properties

---

• This section is a list of all required information and specific details which were not given in the wordy outline.
• Contains no subsections. One could list all that one thinks is important for the reader to know and can be extracted from the protocol. e.g:

1. List of parameters used e.g. threshold value etc.
2. Security Claims and other theorems used for the protocol e.g. correctness, verifiability, blindness, universality
3. Advantages in terms of resources. e.g. no quantum memory needed etc.
4. Success probability of protocols (for entanglement routing and other building blocks protocols).

• Mathematical equations or inequalities for security claims and other items mentioned above can be accommodated here.
• If using new term for any of the above, please explain it here itself and if needed provide a link to supplementary information page for a detailed explanation. E.g. Any property not defined in the functionality description already could be defined here.

Pseudocode

---

• This section contains an algorithm/ pseudo code of the protocol.
• Should be stepwise description of the protocol with mathematical notations.
• Can be divided into stages as governed by the functionality. For example, Delegated Computing can be divided into Preparation and Computation Stage.
• Every stage (there can be only one stage in a protocol too) should have Inputs and Outputs for each party illustrated before the steps of the stage. These inputs and outputs are determined by the resources used. See an example in the wikipedia
• Avoid words as much as possible.

Further Information

---

Any useful information related to the protocols belonging to this class of functionality and network stage as the protocol discussed above, which cannot not find place in the above sections goes here.

Extras

• Greek alphabet to be used for quantum states and Latin alphabet are to be used for classical states.
• If the paper used for given description has multiple protocols, pick the most general one and if needed one can merge it too. The concerned paper thus goes in the Discussion section mentioning the other versions of protocols as its one line description.
• Only published papers with proper security proof are to be considered. One that is easy to summarize and extract pseudo code from.
• Every formal description should contain the above mentioned structure in order to make it an independent page even though we provide a link to the concerned functionality page.
• General Functionality Description file will be written for a functionality once it accommodates more than two different types of protocols.
• Title of the formal description should reflect the functionality and the method/network stage used in the concerned protocol. If not so, the main functionality should at least be included in tags such that when one searches for the concerned functionality he/she has the list of all the different versions in the search result.