Submissions

We invite you to contribute to the Quantum Protocol Zoo. Your contribution can have one of the following forms:

• Functionality file: describing a general task for a quantum network;
• Protocol file: describing a particular protocol for a defined functionality.

Each of the files has a predefined format, see below. To keep the wiki consistent, we kindly ask you to follow the guidelines on the format.

Currently, submissions can be made via Google forms, see link below. In the Google form you should specify which file (functionality or protocol file) you would like to submit. Currently, we accept submissions in plain text (.txt file), supplemented with .png, .jpg or .pdf for figures. Note that Quantum Protocol Zoo accepts only published work. Submissions will be considered by the Quantum Protocol Zoo team and the final decision on acceptance resides with the team.

What is more, you can submit a request for an article in the Discussion section on this page. Such a request will be considered and, if accepted, added by to the wiki by the team. You are welcome to express your general comments in the Discussion to make the wiki more user-friendly.

Link to Google Form

https://forms.gle/ANokaD4iCzwvYjdb6

Guidelines

Following are the section-wise guidelines for both types of files available on the zoo. Contributors may consider an example from the Protocol Library too, if needed.

Functionality File

Functionality file describes a general task which can be realized in a quantum network (the "what"). It consists of the following sections.

• Functionality Description
• Tags
• Use Case (if available)
• Protocols
• Properties
• Further Information

Protocol File

Protocol file describes a specific protocol implementing the defined functionality (the "how"). It consists of the following sections.

• Introductory paragraph gives a link to the functionality page, article on the example protocol and justify how the

protocol is different from other protocol drafts for the concerned functionality.

• • 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 roles. E.g. Client-Server instead of Alice-Bob is preferred.
  • Avoid mathematical equations or notations.
  • Try to provide a real life use case for the protocol example signing documents etc..
• Tags are terms used to link several pages on the zoo similar or useful in certain aspect for the concerned file. Categories to which the files belong can also be mentioned here.
  • Available categories for the zoo files can be found in the Navigation menu.
• Assumptions describe the scenerio in which the protocol will be successful and hence, it is necessary to be mentioned before one starts discussing the protocol.
  • List all the assumptions taken on the hardware setup or adversary in the given protocol.
• Outline is a comprehensive wordy description. Guidelines should be strictly followed for this section.
  • No mathematical notations or equations should be used.
  • Bullet points are preferred.
  • It should be lucid, and one is free to make this section lengthy (yet avoid redundancy) such that it gives a rough picture of the protocol without any specific details like number of qubits used or threshold value if any.
• 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.
• Requirements Mentions implementation details like benchmark values, network stage, required parameters and accommodates a figure on the decomposition of the protocol into various components required for implementation.
• Properties This section is a list of all important details which were not given in the wordy outline. 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).
5. Mathematical equations or inequalities for security claims and other items mentioned above can

be accommodated here.

1. 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 CodeThis section contains an algorithm/ pseudo code of the protocol.
  • Should be step-wise description of the protocol with mathematical equations. Avoid words as much as possible.
  • Can be divided into stages common for all the protocols in the concerned 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.
• Further Information This is a review section on all the similar protocol in terms of method used. It can be skipped and different contributors can choose to write this section for various files uploaded on the zoo.