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 *.tex/ *.txt/ *.html version of the protocol 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://goo.gl/forms/UXhrqzQEVpm98Mkt1

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

Structure

• Short Paragraph Description
  • Defines the functionality, 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, it defines Delegated Quantum Computation, Blind Computation and the properties concerned i.e. blindness, correctness and universality.
  • 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 formulae 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,..

Model Assumptions

---

• All setup assumptions taken into account for this protocol should be mentioned here.
  

For e.g. classical or quantum authenticated channel

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.

Notations 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 assumptions.
2. Assumptions on adversary. A link to the security definitions section on the supplementary information page should be provided if this is listed (This is mandatory item for almost every protocol except some building blocks protocols).
3. List of parameters used e.g. threshold value etc.
4. Security Claims and other theorems used for the protocol e.g. correctness, verifiability, blindness, universality
5. Advantages in terms of resources. e.g. no quantum memory needed etc.
6. 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.

Pseudo Code

---

• 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.

Discussion

---

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 go here.

Extra Information

• If the paper used for given description has multiple protocols, pick the most general one and if needed one can merge it. The concerned paper thus goes in the relevant papers 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 as we cannot direct the user to go through the general functionality description and then the concerned formal description.
• General Functionality Description is not needed for every protocol. One can write as many different versions of formal descriptions, depending on how different the protocols are in terms of resources used.
• Title of the formal description should reflect the functionality/branch of the functionality discussed in the concerned formal description. 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.
• Only if the number of different formal descriptions for a functionality grows too big such that one can come up with a structure to categorize them in terms of resources, a general functionality description shall be designed.

Link for tex file of skeleton for the above format:yet to be uploaded (a downloadable link)